From tkapela at gmail.com Fri Jun 1 00:44:37 2012 From: tkapela at gmail.com (Anton Kapela) Date: Fri, 1 Jun 2012 00:44:37 -0500 Subject: The Tubes Message-ID: <8359821217392369125@unknownmsgid> All, Andrew Blum was interviewed on NPR's Fresh Air this week -- and gets a lot right about the Tubes we built. FYI, because your boss will be asking you about it: http://m.npr.org/story/153701673?url=/2012/05/31/153701673/the-internet-a-series-of-tubes-and-then-some -Tk From hmurray at megapathdsl.net Fri Jun 1 01:03:06 2012 From: hmurray at megapathdsl.net (Hal Murray) Date: Thu, 31 May 2012 23:03:06 -0700 Subject: Wacky Weekend: The '.secure' gTLD Message-ID: <20120601060306.D6C6A80003B@ip-64-139-1-69.sjc.megapath.net> > I think this is an interesting concept, but i don't know how well it will > hold up in the long run. All the initial verification and continuous > scanning will no doubtingly give the .secure TLD a high cost relative to > other TLD's. Right. But your "high cost" is relative to dime-a-dozen vanity domains and/or domains for small/tiny businesses. That's not their target market. How much would it be worth to a bank if they could keep a few of their customers from being scammed? How much would it be worth to an ISP if they could keep a few of their customers from being phished? For starters, just consider the support costs. Here is a note from a different context that says it only costs $99 for Verisign to certify you to sign secure-boot stuff for Windows 8, so I think that's the right ballpark. http://mjg59.dreamwidth.org/12368.html I'm assuming that the hard part is the initial verification, not the ongoing monitoring that can be automated. YMMV. I might be all wet. ... -- These are my opinions. I hate spam. From danny at danysek.cz Fri Jun 1 03:19:16 2012 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 01 Jun 2012 10:19:16 +0200 Subject: HE.net BGP origin attribute rewriting In-Reply-To: <20120531170646.GA2477@pob.ytti.fi> References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> Message-ID: <4FC87B04.20200@danysek.cz> On 05/31/2012 07:06 PM, Saku Ytti wrote: > On (2012-05-31 08:46 -0700), David Barak wrote: > >> On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a "purely advisory flag which has no real meaning"? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is "network abuse" - it's more accurately described as "network routing policy." As has been stated here before: your network, your rules. > > When provider rewrites MED, they do it, because they don't want peer to > cause them to cold-potato, to which they may have compelling reason. > Then some clever people realise they forgot to rewrite origin, working > around the implicit agreement you had with them. > You CAN rewrite MED, as stated in RFC 4271, section 5.1.4 - but you SHOULD NOT change origin attribute, as stated in section 5.1.1. So, in terms of rewriting, MED is not comparable to origin. I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear here. Back to the standard, why condone it's violation? Yes, statement about origin is here since January 2006 - older RFC 1771 didn't contain similar rule. But 6 years after publishing I think everyone had enough time to implement this correctly. I still think, that professionals shoult follow RFC and not insert their own creativity to places, where's not expected - just because they decide that as a "cool" idea. For local routing policy - there're still lot of knobs, which can be used internally (typically MED, LOCPREF) to enforce expected policy and there's technically no reason to change origin. -- Daniel From saku at ytti.fi Fri Jun 1 03:28:00 2012 From: saku at ytti.fi (Saku Ytti) Date: Fri, 1 Jun 2012 11:28:00 +0300 Subject: HE.net BGP origin attribute rewriting In-Reply-To: <4FC87B04.20200@danysek.cz> References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz> Message-ID: <20120601082800.GA19206@pob.ytti.fi> On (2012-06-01 10:19 +0200), Daniel Suchy wrote: > I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear > here. Back to the standard, why condone it's violation? Yes, statement It's extremely hard to find RFC which does not contain incorrect information or practically undeployable data. Many things if reading RFC anally are not standard compliant, like no one does IPv6 in the world and no one does MPLS VPNs etc. I'm repeating myself, but if you reset MED, you do it because you have reason why you do not allow peer to force you to cold-potato. There is little point in resetting MED and not resetting origin, as what you tried to stop from occurring still occurs. -- ++ytti From tknchris at gmail.com Fri Jun 1 06:06:54 2012 From: tknchris at gmail.com (chris) Date: Fri, 1 Jun 2012 07:06:54 -0400 Subject: The Tubes In-Reply-To: <8359821217392369125@unknownmsgid> References: <8359821217392369125@unknownmsgid> Message-ID: for those who want to read or download, here are some easier links non mobile link: http://www.npr.org/2012/05/31/153701673/the-internet-a-series-of-tubes-and-then-some direct mp3: http://npr.vo.llnwd.net/kip0/kip0/_pxn=0+_pxK=17273+_pxE=mp3/anon.npr-mp3/npr/fa/2012/05/20120531_fa_01.mp3?orgId=1&topicId=1033&dl=1 On Fri, Jun 1, 2012 at 1:44 AM, Anton Kapela wrote: > All, > > Andrew Blum was interviewed on NPR's Fresh Air this week -- and gets a > lot right about the Tubes we built. > > FYI, because your boss will be asking you about it: > > > http://m.npr.org/story/153701673?url=/2012/05/31/153701673/the-internet-a-series-of-tubes-and-then-some > > -Tk > > From jcurran at istaff.org Fri Jun 1 06:46:30 2012 From: jcurran at istaff.org (John Curran) Date: Fri, 1 Jun 2012 07:46:30 -0400 Subject: Accuracy of RFCs (was: Re: HE.net BGP origin attribute rewriting) In-Reply-To: <20120601082800.GA19206@pob.ytti.fi> References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz> <20120601082800.GA19206@pob.ytti.fi> Message-ID: <344DD3D8-1E14-40C6-9D18-0984A235C17A@istaff.org> On Jun 1, 2012, at 4:28 AM, Saku Ytti wrote: > It's extremely hard to find RFC which does not contain incorrect > information or practically undeployable data. Actual errors in RFC's (typos, incorrect references, etc.) - Differing views regarding RFC subject material; feel free to work with others of similar to write up your perspective - The RFC series is an Internet-wide community effort. Thanks! /John From brunner at nic-naa.net Fri Jun 1 07:46:06 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 01 Jun 2012 08:46:06 -0400 Subject: Wacky Weekend: The '.secure' gTLD In-Reply-To: <20120601025243.53806.qmail@joyce.lan> References: <20120601025243.53806.qmail@joyce.lan> Message-ID: <4FC8B98E.8010906@nic-naa.net> On 5/31/12 10:52 PM, John Levine wrote: >> What will drive the price up is the lawsuits that come out of the >> >woodwork when they start trying to enforce their provisions. "What? I >> >have already printed my letterhead! What do you mean my busted DKIM >> >service is a problem?" > History suggests that the problem will be the opposite. They will > find that the number of registrations is an order of magnitude less > than their worst case estimate (a problem that every domain added in > the past decade has had), and they will make the rules ever looser to > try to gather more registrations and appease their financial backers > until it's yet another meaningless generic TLD. agree. > For concrete examples, see what happened to .AERO, .TRAVEL, .PRO, and start with .biz as its re-purposing occurred first. > of course the race to the bottom of first regular SSL certificates, > and now green bar certificates. > > What might be useful would be .BANK, with both security rules and > limited registrations to actual banks. Identifying banks is > relatively* easy, since you can use the lists of entities that > national bank regulators regulate. agree. proposed by core. opposed by aba. > R's, > John > > * - I said relatively, not absolutely. even within the financial services industry, useful taxonomies exist, e.g., ethical banks, islamic banks, depositor owned cooperative banks, ... again, proposed by core. opposed by aba. and you _were_ on the high security generic top-level domain working group where you pushed for anti-spamdom and i for forms of "more secure banking". -e From jimmys at myesn.com Fri Jun 1 08:51:17 2012 From: jimmys at myesn.com (Jimmy Sadri) Date: Fri, 1 Jun 2012 06:51:17 -0700 Subject: Comcast IPv6 Update In-Reply-To: References: Message-ID: Jason, I remembered this post and decided to check on the status of this for World Ipv6 day coming up in on the 5th of this month and so I called Comcast bussiness support... what a nightmare... the first guy told me that I already have static IP address so why do I need Ipv6 addresses? Then he told me that I can still "surf the Internet" with Ipv4 addresses and I don't need Ipv6 addresses. I asked to speak to someone who knows more about the Ipv6 rollout he then told me that there is nothing to know. I tried to get him to "escalate it" as you suggested below but he refused telling me that a request for Ipv6 addresses is not a valid technical reason to escalate. He did offer to let me speak to his supervisor. His supervisor wasn't much better. I explained to him how I have been following things on comcast6.net and with Ipv6 day coming up I thought maybe there had been somekind of forward progress on deployment and could he at least point me in the right direction for someone to talk to about it. He then told me that there is no such person and that if there was such a person that Comcast's Ipv6 rollout plans and locations are proprietary information not to revealed to customers like me. I referenced NANOG and the below post and was told first that how do I know that person is actually a Comcast employee? I guess besides the addresses from you guys @cable.comcast.com I don't know for sure that you guys are actually Comcast employees I just asume that you are who you say you are. For the record I don't doubt that you guys work for Comcast but then the supervisor tells me that even IF the people I referenced DO work for Comcast that they are in violation of company policy for speaking in a public forum and claiming to work for Comcast... Wow... I just wanted some info on deployment scheduling and possilbe timelines for getting Ipv6 and I get all that. Gotta say they could really do better in the customer service dept. I wonder if you guys have any more info on this or can at least point me in the right direction... like I said I already tried Comcast Business Support with the above results... so I guess if you can help find out this before World Ipv6 day so that I could participate that would be ideal... I wonder if anyone else has tried getting this info on the list with better results? - Jimmy -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] Sent: Wednesday, November 09, 2011 8:58 AM To: Blake T. Pfankuch; Brzozowski, John; NANOG Subject: Re: Comcast IPv6 Update On 11/9/11 11:54 AM, "Blake T. Pfankuch" wrote: >This appears directed at the Home market. Any word on the Business >Class market even as a /128? Business Class is coming later. It won't hurt to contact the Business Class sales number and ask about IPv6 (and tell them to escalate it) - it all helps get us internal support and buy in. It is definitely on our radar though. - Jason From jared at puck.nether.net Fri Jun 1 08:56:21 2012 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 1 Jun 2012 09:56:21 -0400 Subject: Comcast IPv6 Update In-Reply-To: References: Message-ID: My understanding is that Comcast only does IPv6 on business customers that are on their "backbone" network, not those on their docsis network. If you have BGP or fiber with 7922 you should be able to get IPv6. - Jared On Jun 1, 2012, at 9:51 AM, Jimmy Sadri wrote: > Wow... I just wanted some info on deployment scheduling and possilbe > timelines for getting Ipv6 and I get all that. Gotta say they could really > do better in the customer service dept. I wonder if you guys have any more > info on this or can at least point me in the right direction... like I > said I already tried Comcast Business Support with the above results... so I > guess if you can help find out this before World Ipv6 day so that I > could participate that would be ideal... I wonder if anyone else has tried > getting this info on the list with better results? From wayne at tuckerlabs.com Fri Jun 1 09:03:25 2012 From: wayne at tuckerlabs.com (Wayne Tucker) Date: Fri, 1 Jun 2012 07:03:25 -0700 Subject: BGP ORF in practice In-Reply-To: <18022357-823A-4AA5-94B9-C97B7E7B52D8@rob.sh> References: <18022357-823A-4AA5-94B9-C97B7E7B52D8@rob.sh> Message-ID: On Thu, May 31, 2012 at 10:59 AM, Rob Shakir wrote: > It has some potential to be difficult to manage where implementations > begin to experience complexities in building UPDATE message replication > groups (where peers have a dynamic advertisement (egress) policy due to ORF, > then this may mean that the number of peers with common UPDATE policies > reduces, and hence concepts like policy-driven UPDATE groups become less > efficient). This may impact the scaling of your BGP speakers in ways that > are not easy to model - and hence may be undesirable on PE/border devices > where control-plane CPU is a concern. Makes sense - ORF would reduce the net amount of processing required, but puts more of it on the advertising side. > In an inter-domain context, I have seen some discussion of ORF as a means > by which an L3VPN customer may choose to receive only a subset of their > routing information at particular "low feature" sites - but the > inter-operability issues mentioned above resulted in this not being > deployed. Do you have a similar deployment case? My deployment case is as an end user of multiple ISPs. At previous jobs (at service providers) I got used to the flexibility provided by multiple full tables, but at this job I don't have the budget for hardware that's really designed to handle that. Without ORF, my choices are: 1.) default prefixes only Way too little control for my taste. I'm stuck either letting it pick one "best" 0/0 to use or tweaking the config so that I can do ECMP (which freaks out support staff when their traceroute bounces around). 2.) default + subset (such as customer routes) Better than #1, but less flexible if I want to steer a prefix anywhere other than to a service provider which is advertising it to me. 3.) default + full Flexible in that I can filter what I accept and still rely on the 0/0 prefix for "full" reachability. The control plane on my routers can handle that many prefixes in memory, but it bogs them down a bit and I have to be careful of how many prefixes I let into the forwarding table. Thanks for the input. It sounds like ORF could be viable, but only if the service provider is amenable and the equipment is compatible. :w From John_Brzozowski at Cable.Comcast.com Fri Jun 1 09:04:54 2012 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Fri, 1 Jun 2012 14:04:54 +0000 Subject: Comcast IPv6 Update In-Reply-To: Message-ID: Jimmy, Trust me, I work for Comcast and run the IPv6 program. This has been the case for nearly 7 years. We can take some of the items below off list. We have launched IPv6 for residential broadband at this time. Commercial DOCSIS support is later this year. We can do two things. Get you a residential trial kit so you can have IPv6 for W6L and make sure I have your information for when we start trials for commercial DOCSIS support for IPv6. John ========================================= John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski at cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net ========================================= -----Original Message----- From: Jimmy Sadri Date: Friday, June 1, 2012 9:51 AM To: Jason Livingood , "'Blake T. Pfankuch'" , John Jason Brzozowski , NANOG Subject: RE: Comcast IPv6 Update >Jason, > I remembered this post and decided to check on the status of this >for World Ipv6 day coming up in on the 5th of this month and so I called >Comcast bussiness support... what a nightmare... the first guy told me >that >I already have static IP address so why do I need Ipv6 addresses? >Then he told me that I can still "surf the Internet" with Ipv4 addresses >and >I don't need Ipv6 addresses. I asked to speak to someone who >knows more about the Ipv6 rollout he then told me that there is nothing to >know. I tried to get him to "escalate it" as you suggested below >but he refused telling me that a request for Ipv6 addresses is not a valid >technical reason to escalate. He did offer to let me speak to his >supervisor. His supervisor wasn't much better. I explained to him how I >have been following things on comcast6.net and with Ipv6 day coming >up I thought maybe there had been somekind of forward progress on >deployment >and could he at least point me in the right direction for someone >to talk to about it. He then told me that there is no such person and >that >if there was such a person that Comcast's Ipv6 rollout plans and >locations are proprietary information not to revealed to customers like >me. >I referenced NANOG and the below post and was told first that >how do I know that person is actually a Comcast employee? I guess besides >the addresses from you guys @cable.comcast.com I don't know for sure >that you guys are actually Comcast employees I just asume that you are who >you say you are. For the record I don't doubt that you guys work for >Comcast but then the supervisor tells me that even IF the people I >referenced DO work for Comcast that they are in violation of company >policy >for speaking in a public forum and claiming to work for Comcast... > >Wow... I just wanted some info on deployment scheduling and possilbe >timelines for getting Ipv6 and I get all that. Gotta say they could >really >do better in the customer service dept. I wonder if you guys have any >more >info on this or can at least point me in the right direction... like I >said I already tried Comcast Business Support with the above results... >so I >guess if you can help find out this before World Ipv6 day so that I >could participate that would be ideal... I wonder if anyone else has >tried >getting this info on the list with better results? > >- Jimmy > >-----Original Message----- >From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com] >Sent: Wednesday, November 09, 2011 8:58 AM >To: Blake T. Pfankuch; Brzozowski, John; NANOG >Subject: Re: Comcast IPv6 Update > >On 11/9/11 11:54 AM, "Blake T. Pfankuch" wrote: > > >>This appears directed at the Home market. Any word on the Business >>Class market even as a /128? > >Business Class is coming later. It won't hurt to contact the Business >Class >sales number and ask about IPv6 (and tell them to escalate it) - it all >helps get us internal support and buy in. It is definitely on our radar >though. > >- Jason > > From John_Brzozowski at Cable.Comcast.com Fri Jun 1 09:05:47 2012 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Fri, 1 Jun 2012 14:05:47 +0000 Subject: Comcast IPv6 Update In-Reply-To: Message-ID: Commercial DOCSIS is later this year. Commercial fiber can be supported now. John ========================================= John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski at cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net ========================================= -----Original Message----- From: Jared Mauch Date: Friday, June 1, 2012 9:56 AM To: Jimmy Sadri Cc: Jason Livingood , "'Blake T. Pfankuch'" , John Jason Brzozowski , NANOG Subject: Re: Comcast IPv6 Update >My understanding is that Comcast only does IPv6 on business customers >that are on their "backbone" network, not those on their docsis network. > >If you have BGP or fiber with 7922 you should be able to get IPv6. > >- Jared > >On Jun 1, 2012, at 9:51 AM, Jimmy Sadri wrote: > >> Wow... I just wanted some info on deployment scheduling and possilbe >> timelines for getting Ipv6 and I get all that. Gotta say they could >>really >> do better in the customer service dept. I wonder if you guys have any >>more >> info on this or can at least point me in the right direction... like I >> said I already tried Comcast Business Support with the above results... >>so I >> guess if you can help find out this before World Ipv6 day so that I >> could participate that would be ideal... I wonder if anyone else has >>tried >> getting this info on the list with better results? > From mjl at caida.org Fri Jun 1 12:24:32 2012 From: mjl at caida.org (Matthew Luckie) Date: Fri, 01 Jun 2012 10:24:32 -0700 Subject: Number of providers Message-ID: <4FC8FAD0.8080000@caida.org> Based on feedback we have received at http://as-rank.caida.org/ we are in the process of updating our AS relationship inference algorithm. We're interested to know how many providers different ASes have based on their size. We assume that it changes with size of the AS, e.g. Tier-1 have zero. We would appreciate it if anyone who is willing to provide us with their AS number and the number of their providers, would email this information to mjl at caida.org. Matthew Luckie CAIDA. p.s. It would be great if you could also tell us who your providers are. From nanog-post at rsuc.gweep.net Fri Jun 1 12:38:42 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 1 Jun 2012 13:38:42 -0400 Subject: HE.net BGP origin attribute rewriting In-Reply-To: <4FC87B04.20200@danysek.cz> References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz> Message-ID: <20120601173841.GA47560@gweep.net> On Fri, Jun 01, 2012 at 10:19:16AM +0200, Daniel Suchy wrote: > On 05/31/2012 07:06 PM, Saku Ytti wrote: > > On (2012-05-31 08:46 -0700), David Barak wrote: > > > >> On what precisely do you base the idea that a mandatory > >> transitive attribute of a BGP prefix is a "purely advisory flag > >> which has no real meaning"? I encourage you to reconsider that > >> opinion - it's actually a useful attribute, much the way that MED > >> is a useful attribute. Many providers re-write MED, and apparently > >> some re-write ORIGIN. Neither of those is "network abuse" - it's > >> more accurately described as "network routing policy." As has been > >> stated here before: your network, your rules. > > > > When provider rewrites MED, they do it, because they don't want peer to > > cause them to cold-potato, to which they may have compelling reason. > > Then some clever people realize they forgot to rewrite origin, working > > around the implicit agreement you had with them. > > > > You CAN rewrite MED, as stated in RFC 4271, section 5.1.4 - but you > SHOULD NOT change origin attribute, as stated in section 5.1.1. So, in > terms of rewriting, MED is not comparable to origin. > > I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear > here. Back to the standard, why condone it's violation? Yes, statement > about origin is here since January 2006 - older RFC 1771 didn't contain > similar rule. But 6 years after publishing I think everyone had enough > time to implement this correctly. Please remind yourself the standard language from rfc 2119. SHOULD NOT is not in the same ball park as MUST NOT: "4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label." > I still think, that professionals shoult follow RFC and not insert their > own creativity to places, where's not expected - just because they > decide that as a "cool" idea. For local routing policy - there're still > lot of knobs, which can be used internally (typically MED, LOCPREF) to > enforce expected policy and there's technically no reason to change origin. You clearly did not read the previous posts involving actual historical evidence [and apparently ongoing] of remote networks attempting action at a distance knowing that many overlook this part of the decision tree. Preventing your company from bleeding money or degrading performance at whim of remote parties certainly is "cool" but also just good business and proper network hygiene. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From danny at danysek.cz Fri Jun 1 13:03:50 2012 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 01 Jun 2012 20:03:50 +0200 Subject: HE.net BGP origin attribute rewriting In-Reply-To: <20120601173841.GA47560@gweep.net> References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz> <20120601173841.GA47560@gweep.net> Message-ID: <4FC90406.1000606@danysek.cz> On 06/01/2012 07:38 PM, Joe Provo wrote: > You clearly did not read the previous posts involving actual historical > evidence [and apparently ongoing] of remote networks attempting action > at a distance knowing that many overlook this part of the decision tree. > Preventing your company from bleeding money or degrading performance at > whim of remote parties certainly is "cool" but also just good business > and proper network hygiene. By overwriting origin field, there's no warranty that someone improves performance at all - it's just imagination. In extreme cases, performance can be degraded when someone in the middle plays with origin field and doesn't know reasons, why originating network uses something else than IGP origin. In RFC 2119 words, full implications were not understanded - when this overwriting is done generally. Also, there must be some historical reason, why origin should not be rewritten (this changed in January 2006). For internal reasons within the network operator still haves enough knobs to enforce own policy (by setting localpref, med on his network). Daniel From sethm at rollernet.us Fri Jun 1 13:06:24 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 01 Jun 2012 11:06:24 -0700 Subject: Comcast IPv6 Update In-Reply-To: References: Message-ID: <4FC904A0.6010702@rollernet.us> On 6/1/12 7:04 AM, Brzozowski, John wrote: > Jimmy, > > Trust me, I work for Comcast and run the IPv6 program. This has been the > case for nearly 7 years. We can take some of the items below off list. > > We have launched IPv6 for residential broadband at this time. Commercial > DOCSIS support is later this year. > > We can do two things. Get you a residential trial kit so you can have > IPv6 for W6L and make sure I have your information for when we start > trials for commercial DOCSIS support for IPv6. > Forgive me if this is a stupid question since I've never been a cable guy, but what's physical difference between residential and commercial coax? ~Seth From tdurack at gmail.com Fri Jun 1 13:18:47 2012 From: tdurack at gmail.com (Tim Durack) Date: Fri, 1 Jun 2012 14:18:47 -0400 Subject: 1310nm optics over Corning LEAF G.655? Message-ID: Anyone run 1000BASE-LX/10GBASE-LR 1310nm optics over a ~10km Corning LEAF G.655 span? I understand this fiber is not optimized for such usage, but what is the real-world behaviour? I'm having a hard time finding hard data. (Normal optics will be 1550nm and DWDM over ~40-100km spans.) -- Tim:> From Kevinkarch at vackinc.com Fri Jun 1 13:30:19 2012 From: Kevinkarch at vackinc.com (Kevin L. Karch) Date: Fri, 1 Jun 2012 13:30:19 -0500 Subject: 1310nm optics over Corning LEAF G.655? In-Reply-To: References: Message-ID: <031001cd4024$994700a0$cbd501e0$@vackinc.com> Tim Yes we have built several links with the 1310nm devices on Corning LEAF. One span distance was 14 KM. Can we offer you a quote on optics and installation support? Thanks, Kevin L. Karch Network Specialist Direct: 847-833-8810 Fax: 847-985-5550 Email: kevinkarch at vackinc.com Web: www.vackinc.com The Optical Network Specialists -----Original Message----- From: Tim Durack [mailto:tdurack at gmail.com] Sent: Friday, June 01, 2012 1:19 PM To: nanog at nanog.org Subject: 1310nm optics over Corning LEAF G.655? Anyone run 1000BASE-LX/10GBASE-LR 1310nm optics over a ~10km Corning LEAF G.655 span? I understand this fiber is not optimized for such usage, but what is the real-world behaviour? I'm having a hard time finding hard data. (Normal optics will be 1550nm and DWDM over ~40-100km spans.) -- Tim:> ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2178 / Virus Database: 2425/5038 - Release Date: 06/01/12 From tdurack at gmail.com Fri Jun 1 13:41:16 2012 From: tdurack at gmail.com (Tim Durack) Date: Fri, 1 Jun 2012 14:41:16 -0400 Subject: 1310nm optics over Corning LEAF G.655? In-Reply-To: <031001cd4024$994700a0$cbd501e0$@vackinc.com> References: <031001cd4024$994700a0$cbd501e0$@vackinc.com> Message-ID: On Fri, Jun 1, 2012 at 2:30 PM, Kevin L. Karch wrote: > Tim > > Yes we have built several links with the 1310nm devices on Corning LEAF. One > span distance was 14 KM. > > Can we offer you a quote on optics and installation support? That's a kind offer, but we are quite well setup :-) Just looking for field experience. 14km with standard 1310nm optics? No issues with the cutoff wavelength being >1310nm? GigE or 10GigE? -- Tim:> From rdekema at gmail.com Fri Jun 1 14:06:32 2012 From: rdekema at gmail.com (Rusty Dekema) Date: Fri, 1 Jun 2012 15:06:32 -0400 Subject: Comcast IPv6 Update In-Reply-To: <4FC904A0.6010702@rollernet.us> References: <4FC904A0.6010702@rollernet.us> Message-ID: On Fri, Jun 1, 2012 at 2:06 PM, Seth Mattinen wrote: > Forgive me if this is a stupid question since I've never been a cable > guy, but what's physical difference between residential and commercial > coax? > Not much, as far as I can tell. I'm a commercial ("Business Class" in Comcast's terminology) coax customer; the CPE is just plugged into the cable outlet in my apartment. Comcast requires you to use the CPE they supply if you want a static IP up through a /28 on commercial coax, which is kind of a shame. (Also, a /28 seems to be the largest block they will give you over commercial coax.) Their CPE announces your address space into Comcast's network with RIPv2, and presumably they don't wish to share the RIP credentials with small customers. In the past, the admin ("mso") passwords were the same on all of their commercial coax CPE so you could tinker if desired, but that is no longer the case. Some people have speculated that there are different QAMs (frequencies) for commercial vs residential customers, but I have not seen any indication that that is the case. Finally, there is no 250 GB cap on commercial coax service, for now. (Not that that's a physical difference.) -Rusty From sra+nanog at hactrn.net Fri Jun 1 14:18:09 2012 From: sra+nanog at hactrn.net (Rob Austein) Date: Fri, 01 Jun 2012 15:18:09 -0400 Subject: rpki vs. secure dns? In-Reply-To: <4FC5AAEA.103@isc.org> References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi> <4FC3F5D7.5000206@isc.org> <20120529102759.GA25838@nic.fr> <4FC4ACCE.6000903@isc.org> <6C8F01BD-72C5-4361-B5C8-6603B24B426C@virtualized.org> <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net> <5B556145-6859-49F0-BCD4-4E8D316CD828@castlepoint.net> <4FC5AAEA.103@isc.org> Message-ID: <20120601191809.4E56A17244@thrintun.hactrn.net> Another difference between RPKI and ROVER which hasn't come up much: RPKI incorporates a lot of pre-existing machinery from X.509 et al. This drags in some tedious detail which makes people's eyes cross, but it gives us some tools which simply aren't available in DNS at present. In particular, X.509's CRL mechanism combined with the way that RPKI uses CMS messages with single-use EE certificates means that in RPKI we have a way to revoke individual objects (eg, ROAs) at will. DNSSEC only just barely has revocation at all, and that only for DNSKEYs. The nearest equivalent to per-object revocation one could do in DNSSEC would be either: - generate a new ZSK, re-sign everything in the zone with the new ZSK except for the RRsets you want to get rid of, and revoke the old ZSK, or - keep as many distinct ZSKs in the zone as you intend to have distinctly revocable groups of objects in the zone, and make sure you sign the right objects with the right ZSKs. Neither of these solutions is very good: the first may involve re-signing a lot of data every time you change anything, while the latter is complex and tends to bloat the zone's apex DNSKEY RRset. I suppose a third option would be to make every DNS owner name in the reverse tree be a separate zone. Doesn't seem like an improvement. 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. - 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. - 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. - 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. - 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 (conflicting data for same prefix can appear in multiple zones, relying party has to sort this out, yum). As far as I can tell, ROVER doesn't solve any of the hard problems in RPKI. It's a different encoding of a partial subset of the data, with some of the features removed. From jared at puck.nether.net Fri Jun 1 14:21:18 2012 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 1 Jun 2012 15:21:18 -0400 Subject: Comcast IPv6 Update In-Reply-To: <4FC904A0.6010702@rollernet.us> References: <4FC904A0.6010702@rollernet.us> Message-ID: <20120601192118.GC3335@puck.nether.net> On Fri, Jun 01, 2012 at 11:06:24AM -0700, Seth Mattinen wrote: > On 6/1/12 7:04 AM, Brzozowski, John wrote: > > Jimmy, > > > > Trust me, I work for Comcast and run the IPv6 program. This has been the > > case for nearly 7 years. We can take some of the items below off list. > > > > We have launched IPv6 for residential broadband at this time. Commercial > > DOCSIS support is later this year. > > > > We can do two things. Get you a residential trial kit so you can have > > IPv6 for W6L and make sure I have your information for when we start > > trials for commercial DOCSIS support for IPv6. > > > > > Forgive me if this is a stupid question since I've never been a cable > guy, but what's physical difference between residential and commercial coax? Usually these are terminated on a different CMTS and may use different frequencies allocated. From a business side, there is a higher SLA afforded to the users, including phone notification of planned outages, etc that would happen. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From jimb at jsbc.cc Fri Jun 1 14:25:54 2012 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 01 Jun 2012 12:25:54 -0700 Subject: Comcast IPv6 Update In-Reply-To: <4FC904A0.6010702@rollernet.us> References: <4FC904A0.6010702@rollernet.us> Message-ID: <4FC91742.704@jsbc.cc> On 6/1/2012 11:06, Seth Mattinen wrote: > On 6/1/12 7:04 AM, Brzozowski, John wrote: >> Jimmy, >> >> Trust me, I work for Comcast and run the IPv6 program. This has been the >> case for nearly 7 years. We can take some of the items below off list. >> >> We have launched IPv6 for residential broadband at this time. Commercial >> DOCSIS support is later this year. >> >> We can do two things. Get you a residential trial kit so you can have >> IPv6 for W6L and make sure I have your information for when we start >> trials for commercial DOCSIS support for IPv6. >> > > Forgive me if this is a stupid question since I've never been a cable > guy, but what's physical difference between residential and commercial coax? > > ~Seth > I'm a Comcast biz customer, mostly so I can have static IPs. I believe the main differences are that biz class has a different group of people supporting it and provisioning it. They also use different CPE. Probably also use different VLANs and such past the head end. But for biz class customers on cable, it uses the same underlying infrastructure as residential. I'm mostly speculating here, but I'd think a big hurdle for getting IPv6 service on biz class is in coming up with the support/provisioning/logistics infrastructure to support biz customers with IPv6. The residential customers have less control over the CPE than business class, likely making it easier for comcast to make changes for residential service. Comcast can update the CPE image, start running DHCPv6, and voila. But biz customers routers are somewhat configurable, and many biz class customers run their own routers/firewalls behind the comcast CPE (as do some residential customers also, of course), likely making things more complicated. I'd speculate that all the technical pieces are there to do it, but the logistical/support/management pieces probably aren't ready yet. Obviously, only the Comcast guys on here (John and Jason) know the whole story. But I'm patiently waiting for my native v6! It'll happen eventually. :-) From jimb at jsbc.cc Fri Jun 1 14:28:09 2012 From: jimb at jsbc.cc (Jim Burwell) Date: Fri, 01 Jun 2012 12:28:09 -0700 Subject: Comcast IPv6 Update In-Reply-To: <20120601192118.GC3335@puck.nether.net> References: <4FC904A0.6010702@rollernet.us> <20120601192118.GC3335@puck.nether.net> Message-ID: <4FC917C9.5000905@jsbc.cc> On 6/1/2012 12:21, Jared Mauch wrote: > On Fri, Jun 01, 2012 at 11:06:24AM -0700, Seth Mattinen wrote: >> On 6/1/12 7:04 AM, Brzozowski, John wrote: >>> Jimmy, >>> >>> Trust me, I work for Comcast and run the IPv6 program. This has been the >>> case for nearly 7 years. We can take some of the items below off list. >>> >>> We have launched IPv6 for residential broadband at this time. Commercial >>> DOCSIS support is later this year. >>> >>> We can do two things. Get you a residential trial kit so you can have >>> IPv6 for W6L and make sure I have your information for when we start >>> trials for commercial DOCSIS support for IPv6. >>> >> >> Forgive me if this is a stupid question since I've never been a cable >> guy, but what's physical difference between residential and commercial coax? > Usually these are terminated on a different CMTS and may use different > frequencies allocated. > > From a business side, there is a higher SLA afforded to the users, > including phone notification of planned outages, etc that would happen. > > - Jared > Ah I didn't know they even used separate CMTS for the biz customers. From joly at punkcast.com Fri Jun 1 15:48:40 2012 From: joly at punkcast.com (Joly MacFie) Date: Fri, 1 Jun 2012 16:48:40 -0400 Subject: NYC World IPv6 Launch event Message-ID: As for IPv6 Day last year, when it went amazingly well, ISOC-NY is organizing a chat + booze-up to mark the IPv6 Launch next Wednesday Jun 6 2012. Hopefully by 7pm initial kinks will have been well ironed out and everyone will be free to attend.. *What*: World IPv6 Launch Discussion and Celebration. *When*: Wed. June 6, 2012 - 7pm-8.30pm *Where*: Courant Institute NYU, Rm 201, 251 Mercer St. NYC *Who*: Free. Public welcome, especially network admins! *Hashtags*: #v6launch ; #ipv6 *RSVP*: email | facebook | meetup More info: http://isoc-ny.org/p2/?p=3526 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From cidr-report at potaroo.net Fri Jun 1 17:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Jun 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201206012200.q51M02QN055688@wattle.apnic.net> BGP Update Report Interval: 24-May-12 -to- 31-May-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS383 192192 8.5% 1779.6 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group 2 - AS8452 91007 4.0% 89.9 -- TE-AS TE-AS 3 - AS8402 60332 2.6% 47.7 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS9829 54914 2.4% 62.4 -- BSNL-NIB National Internet Backbone 5 - AS19647 47156 2.1% 9431.2 -- HPOD20001 - Hewlett-Packard Operation Division 6 - AS38142 33384 1.5% 2086.5 -- UNAIR-AS-ID Universitas Airlangga 7 - AS12479 27393 1.2% 351.2 -- UNI2-AS France Telecom Espana SA 8 - AS35994 26629 1.2% 951.0 -- AKAMAI-AS - Akamai Technologies, Inc. 9 - AS7908 25800 1.1% 344.0 -- Comsat Argentina S.A. 10 - AS5800 23102 1.0% 86.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - AS41661 21899 1.0% 61.7 -- ERTH-CHEL-AS CJSC "ER-Telecom Holding" 12 - AS1257 20680 0.9% 108.8 -- TELE2 13 - AS13118 20040 0.9% 417.5 -- ASN-YARTELECOM OJSC Rostelecom 14 - AS28306 19103 0.8% 2122.6 -- TC Net Inform?tica e Telecomunica??es LTDA 15 - AS10455 18155 0.8% 2017.2 -- LUCENT-CIO - Lucent Technologies Inc. 16 - AS17813 17513 0.8% 142.4 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 17 - AS3549 16826 0.7% 168.3 -- GBLX Global Crossing Ltd. 18 - AS36856 16593 0.7% 8296.5 -- MOZILLA-CORP - Mozilla Corporation 19 - AS25543 15053 0.7% 273.7 -- FasoNet-AS 20 - AS24560 13716 0.6% 19.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19647 47156 2.1% 9431.2 -- HPOD20001 - Hewlett-Packard Operation Division 2 - AS36856 16593 0.7% 8296.5 -- MOZILLA-CORP - Mozilla Corporation 3 - AS44798 7750 0.3% 7750.0 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 4 - AS3 2638 0.1% 683.0 -- PRED-AS PRED-Telecom OOO 5 - AS32528 12095 0.5% 2419.0 -- ABBOTT Abbot Labs 6 - AS28306 19103 0.8% 2122.6 -- TC Net Inform?tica e Telecomunica??es LTDA 7 - AS38142 33384 1.5% 2086.5 -- UNAIR-AS-ID Universitas Airlangga 8 - AS10455 18155 0.8% 2017.2 -- LUCENT-CIO - Lucent Technologies Inc. 9 - AS383 192192 8.5% 1779.6 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group 10 - AS55665 1043 0.1% 1043.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 11 - AS35994 26629 1.2% 951.0 -- AKAMAI-AS - Akamai Technologies, Inc. 12 - AS29126 918 0.0% 918.0 -- DATIQ-AS Datiq B.V. 13 - AS16535 890 0.0% 890.0 -- ECHOS-3 - Echostar Holding Purchasing Corporation 14 - AS19318 12159 0.5% 715.2 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 15 - AS53531 672 0.0% 672.0 -- MIDWEST-CARECENTER - Midwest Palliative & Hospice CareCenter 16 - AS38857 950 0.0% 475.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 17 - AS56616 451 0.0% 451.0 -- SHARIF-AS Tarahan Shabake Sharif LTD 18 - AS25821 450 0.0% 450.0 -- NET-SCNB - Suffolk County National Bank 19 - AS29512 2199 0.1% 439.8 -- TVK-WROC-AS TVK Tel-Ka Wroclaw 20 - AS48068 435 0.0% 435.0 -- VISONIC Visonic Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 19671 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 63.245.221.0/24 16573 0.7% AS36856 -- MOZILLA-CORP - Mozilla Corporation 3 - 168.87.176.0/24 14222 0.6% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division 4 - 168.87.128.0/21 14171 0.6% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division 5 - 130.36.34.0/24 10737 0.4% AS32528 -- ABBOTT Abbot Labs 6 - 69.31.106.0/23 9520 0.4% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 7 - 155.72.152.0/21 9383 0.4% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division 8 - 155.72.158.0/24 9376 0.4% AS19647 -- HPOD20001 - Hewlett-Packard Operation Division 9 - 41.43.147.0/24 9035 0.4% AS8452 -- TE-AS TE-AS 10 - 23.2.6.0/23 8522 0.3% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 11 - 23.65.27.0/24 8520 0.3% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 12 - 62.36.252.0/22 8022 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 13 - 91.202.212.0/22 7750 0.3% AS44798 -- PERVOMAYSK-AS PP "SKS-Pervomaysk" 14 - 62.36.249.0/24 6535 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 15 - 62.36.241.0/24 6218 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 16 - 62.36.210.0/24 6060 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 17 - 59.177.48.0/20 5860 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 18 - 194.63.9.0/24 4646 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 19 - 182.64.0.0/16 4607 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 20 - 192.11.177.0/24 3616 0.1% AS10455 -- LUCENT-CIO - Lucent Technologies Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 1 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Jun 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201206012200.q51M00hr055681@wattle.apnic.net> This report has been generated at Fri Jun 1 21:12:54 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 25-05-12 414357 242094 26-05-12 414444 242009 27-05-12 414372 242171 28-05-12 414483 242396 29-05-12 414855 242346 30-05-12 415000 242304 31-05-12 414797 242308 01-06-12 415005 242253 AS Summary 41293 Number of ASes in routing system 17231 Number of ASes announcing only one prefix 3411 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 112706016 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 01Jun12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 415012 242341 172671 41.6% All ASes AS6389 3411 196 3215 94.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3353 1843 1510 45.0% WINDSTREAM - Windstream Communications Inc AS22773 1638 135 1503 91.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2643 1176 1467 55.5% KIXS-AS-KR Korea Telecom AS18566 2092 706 1386 66.3% COVAD - Covad Communications Co. AS28573 1896 521 1375 72.5% NET Servicos de Comunicao S.A. AS2118 1301 14 1287 98.9% RELCOM-AS OOO "NPO Relcom" AS4323 1575 387 1188 75.4% TWTC - tw telecom holdings, inc. AS10620 1926 760 1166 60.5% Telmex Colombia S.A. AS1785 1912 806 1106 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1577 542 1035 65.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7303 1435 448 987 68.8% Telecom Argentina S.A. AS7552 1097 188 909 82.9% VIETEL-AS-AP Vietel Corporation AS26615 901 32 869 96.4% Tim Celular S.A. AS8151 1490 684 806 54.1% Uninet S.A. de C.V. AS18101 948 159 789 83.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS17974 1927 1161 766 39.8% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4808 1105 349 756 68.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9394 839 159 680 81.0% CRNET CHINA RAILWAY Internet(CRNET) AS13977 772 122 650 84.2% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS3356 1099 463 636 57.9% LEVEL3 Level 3 Communications AS30036 1420 792 628 44.2% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS17676 692 75 617 89.2% GIGAINFRA Softbank BB Corp. AS22561 1020 419 601 58.9% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 997 398 599 60.1% VZGNI-TRANSIT - Verizon Online LLC AS8452 1369 779 590 43.1% TE-AS TE-AS AS24560 1027 447 580 56.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3549 1002 443 559 55.8% GBLX Global Crossing Ltd. AS22047 583 31 552 94.7% VTR BANDA ANCHA S.A. AS4780 831 283 548 65.9% SEEDNET Digital United Inc. Total 43878 14518 29360 66.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 98.159.96.0/20 AS46975 100.100.0.0/16 AS9198 KAZTELECOM-AS JSC Kazakhtelecom 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.136.17.0/24 AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 194.33.112.0/23 AS12859 NL-BIT BIT BV 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/21 AS14754 Telgua 200.106.128.0/20 AS3257 TINET-BACKBONE Tinet SpA 200.115.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.122.134.0/24 AS38615 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From ras at e-gerbil.net Fri Jun 1 19:42:57 2012 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 1 Jun 2012 19:42:57 -0500 Subject: HE.net BGP origin attribute rewriting In-Reply-To: <4FC90406.1000606@danysek.cz> References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz> <20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz> Message-ID: <20120602004256.GB66560@gerbil.cluepon.net> On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote: > > By overwriting origin field, there's no warranty that someone improves > performance at all - it's just imagination. In extreme cases, > performance can be degraded when someone in the middle plays with > origin field and doesn't know reasons, why originating network uses > something else than IGP origin. In RFC 2119 words, full implications > were not understanded - when this overwriting is done generally. Uh, what part of "to prevent remote networks from improperly forcing a cold potato routing behavior on you" sounds imaginary? > Also, there must be some historical reason, why origin should not be > rewritten (this changed in January 2006). For internal reasons within > the network operator still haves enough knobs to enforce own policy > (by setting localpref, med on his network). Not really, no. Not every RFC is 100% correct, and they're often written by people who are not operators (because operators are too busy running real networks :P). Besides, "SHOULD NOT" means "you probably don't want to do this, unless you have a really good reason", and enforcing such an important point in a peering policy is a pretty good reason. You also clearly don't understand the practical use of localpref. When you're trying to implement a simple and relatively common policy like "closest exit routing to a peer with multiple exits", you set the localprefs the same (localpref is usually used to determine WHICH peer you'll be sending to), you set the MEDs the same (if you don't want to artifically select which EXIT to use), AS-PATH lengths are obviously the same if you have multiple exits, and then the next one down is origin code. If you can't reset origin code, you run the risk of a remote network being able to force your network to do something you probably don't want to do (or at least probably wouldn't want to do, if you had any idea what you were doing :P). Please see the previous commentary from Joe Provo, Saku Ytti, etc, they are quite correct. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From nanog-post at rsuc.gweep.net Fri Jun 1 19:53:37 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 1 Jun 2012 20:53:37 -0400 Subject: HE.net BGP origin attribute rewriting In-Reply-To: <4FC90406.1000606@danysek.cz> References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz> <20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz> Message-ID: <20120602005336.GA7394@gweep.net> On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote: > On 06/01/2012 07:38 PM, Joe Provo wrote: > > You clearly did not read the previous posts involving actual historical > > evidence [and apparently ongoing] of remote networks attempting action > > at a distance knowing that many overlook this part of the decision tree. > > Preventing your company from bleeding money or degrading performance at > > whim of remote parties certainly is "cool" but also just good business > > and proper network hygiene. > > By overwriting origin field, there's no warranty that someone improves > performance at all - it's just imagination. Cost and performance were merely two reasons someone may wish to prevent remote parties from using origin to influence outbound traffic from my network. I can state it is not imagination when I encountered networks doing this in the past for prefixes they were sourcing. To be clear - these were prefixes being sourced by a neighbor who was providing different origin codes on different sessions. Either they were [to Nick Hilliard's point] using different kit and unaware of the differnt implementations or [as evidence bore out] purposefully shifting traffic without arrangement on links that were worse for me and in violation of the agreement we entered into when peering. > In extreme cases, > performance can be degraded when someone in the middle plays with origin > field and doesn't know reasons, why originating network uses something > else than IGP origin. The issues that were repeatedly mentioned were not not 'use something other than origin IGP'. Rather, two clear examples were: - a party in the middle adjusting prefixes not of their origin with the express intent of attracting traffic [from paying downstreams] - a directly connected party cost-shifting long-haul carriage for their sourced prefixes without prior arrangement > In RFC 2119 words, full implications were not > understanded - when this overwriting is done generally. I think you're trying to make sense here but it isn't coming through. You are saying that dealing with someone shifting costs to my network *after8 asking them what they were doing and getting no useful reply is not thinking it through? > Also, there must be some historical reason, why origin should not be > rewritten (this changed in January 2006). For internal reasons within > the network operator still haves enough knobs to enforce own policy (by > setting localpref, med on his network). There certainly were historical reasons for treating origin as sacrosanct. Time has marched on and those reasons are now *historical*, hence the quite reasonable updat eto the RFC. You seem to fail to understand that MED comes after origin on the decision tree, and therefore someone can influence traffic carriage without agreement. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From danny at danysek.cz Sat Jun 2 02:03:24 2012 From: danny at danysek.cz (Daniel Suchy) Date: Sat, 02 Jun 2012 09:03:24 +0200 Subject: HE.net BGP origin attribute rewriting In-Reply-To: <20120602004256.GB66560@gerbil.cluepon.net> References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz> <20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz> <20120602004256.GB66560@gerbil.cluepon.net> Message-ID: <4FC9BABC.9090107@danysek.cz> On 06/02/2012 02:42 AM, Richard A Steenbergen wrote: > On Fri, Jun 01, 2012 at 08:03:50PM +0200, Daniel Suchy wrote: >> By overwriting origin field, there's no warranty that someone improves >> performance at all - it's just imagination. In extreme cases, >> performance can be degraded when someone in the middle plays with >> origin field and doesn't know reasons, why originating network uses >> something else than IGP origin. In RFC 2119 words, full implications >> were not understanded - when this overwriting is done generally. > > Uh, what part of "to prevent remote networks from improperly forcing a > cold potato routing behavior on you" sounds imaginary? It depends, not everything looking as proper from single network operator in the middle can be proper in end-to-end user experience, where multiple networks are traversed. >> Also, there must be some historical reason, why origin should not be >> rewritten (this changed in January 2006). For internal reasons within >> the network operator still haves enough knobs to enforce own policy >> (by setting localpref, med on his network). > > Not really, no. Not every RFC is 100% correct, and they're often written > by people who are not operators (because operators are too busy running > real networks :P). Besides, "SHOULD NOT" means "you probably don't want > to do this, unless you have a really good reason", and enforcing such an > important point in a peering policy is a pretty good reason. If someone comes with some implementation overwriting ASPATH (even it may not) and excuses this by RFC incorrectness from his perspective, you'll understand it? Probably not. It's relative. > You also clearly don't understand the practical use of localpref. When > you're trying to implement a simple and relatively common policy like > "closest exit routing to a peer with multiple exits", you set the > localprefs the same (localpref is usually used to determine WHICH peer > you'll be sending to), you set the MEDs the same (if you don't want to > artifically select which EXIT to use), AS-PATH lengths are obviously the > same if you have multiple exits, and then the next one down is origin > code. If you can't reset origin code, you run the risk of a remote > network being able to force your network to do something you probably > don't want to do (or at least probably wouldn't want to do, if you had > any idea what you were doing :P). Well, this matches situatios, where two networks have more than single interconnection and still for prefixes originated from that particular network. But when there's only one interconnection, there's no such reason. Intermediate networks, even having multiple peers will probably see similar origin on all their peers. > Please see the previous commentary from Joe Provo, Saku Ytti, etc, they > are quite correct. I don't think they admits all consequences. When some knob (origin) is not disabled by policy for single prefix visible at multiple points, some "creative" operators should come with other methods to achieve what they wants. Prefix deagregation is first thing, that comes to mind. Even they'll also slightly violate RFC (having not single policy - well, they assume RFC is not correct), they simply start to announce deagregated prefixes next to aggregate one. But deaggregated prefixes are announced only to specific peers - and yes, this works. Then, you can have any policy, have everything normalized at all peers - but most specific prefix in your table visible over particular path simply wins over everything. And this is not a imaginary case - this is clearly visible in real routing table - 41% of address space (in IPv4) is deaggreated, in my experience mainly due to "traffic engineering" purposes - smaller end networks are simply enforced to do this, and some people here confirmed this in this discussion... - Daniel From danny at danysek.cz Sat Jun 2 02:27:36 2012 From: danny at danysek.cz (Daniel Suchy) Date: Sat, 02 Jun 2012 09:27:36 +0200 Subject: HE.net BGP origin attribute rewriting In-Reply-To: <20120602005336.GA7394@gweep.net> References: <4FC746A2.5010707@danysek.cz> <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz> <20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz> <20120602005336.GA7394@gweep.net> Message-ID: <4FC9C068.2070506@danysek.cz> On 06/02/2012 02:53 AM, Joe Provo wrote: > Cost and performance were merely two reasons someone may wish to prevent > remote parties from using origin to influence outbound traffic from my > network. As I mentioned already, it will influence that by another way. And this costs *you* more money - you have to pay for router with larger TCAMs, more memory, faster CPUs... and yes, deaggregation is very simple task for originating network - much easier than playing with the origin flag, which is not understanded widely. > I can state it is not imagination when I encountered networks > doing this in the past for prefixes they were sourcing. To be clear - > these were prefixes being sourced by a neighbor who was providing > different origin codes on different sessions. Either they were [to > Nick Hilliard's point] using different kit and unaware of the differnt > implementations or [as evidence bore out] purposefully shifting traffic > without arrangement on links that were worse for me and in violation > of the agreement we entered into when peering. More specific prefix in addition to aggregate one visible only over specific peers will do the job, too. And will do that job better... but for what cost (not only to you)...? > There certainly were historical reasons for treating origin as sacrosanct. > Time has marched on and those reasons are now *historical*, hence the > quite reasonable updat eto the RFC. You seem to fail to understand that > MED comes after origin on the decision tree, and therefore someone can > influence traffic carriage without agreement. You seem to fail realize other (easier) ways to influence traffic carriage. Deaggregation with selective route announcement is quite common way, many networks do that. - Daniel From nanog-post at rsuc.gweep.net Sat Jun 2 05:43:15 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sat, 2 Jun 2012 06:43:15 -0400 Subject: HE.net BGP origin attribute rewriting In-Reply-To: <4FC9C068.2070506@danysek.cz> References: <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz> <20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz> <20120602005336.GA7394@gweep.net> <4FC9C068.2070506@danysek.cz> Message-ID: <20120602104315.GA23204@gweep.net> Last post on this topic for me. You seem to wish to argue against the lessons of history and the reality of running a network on the global Internet. On Sat, Jun 02, 2012 at 09:27:36AM +0200, Daniel Suchy wrote: > On 06/02/2012 02:53 AM, Joe Provo wrote: > > Cost and performance were merely two reasons someone may wish to prevent > > remote parties from using origin to influence outbound traffic from my > > network. > As I mentioned already, it will influence that by another way. And this > costs *you* more money - you have to pay for router with larger TCAMs, > more memory, faster CPUs... and yes, deaggregation is very simple task > for originating network - much easier than playing with the origin flag, > which is not understanded widely. The two issues are orthogonal. Deaggregating sources have been cost-shifting [in a highly visible and easily examined and often trivially-filtered] manner for ages. There is no data to support the premis that touching origin creates more of this behavior and plenty to refute it. Deaggregation preexists and was always a problem with which one had to deal as supposed "needed TE" by those too cheap to build a proper network sadly became more acceptable over time. A midspan network deaggregating someone else's prefixes is broken and gets called out, generally by the originator if they have a clue. > > I can state it is not imagination when I encountered networks > > doing this in the past for prefixes they were sourcing. To be clear - > > these were prefixes being sourced by a neighbor who was providing > > different origin codes on different sessions. Either they were [to > > Nick Hilliard's point] using different kit and unaware of the differnt > > implementations or [as evidence bore out] purposefully shifting traffic > > without arrangement on links that were worse for me and in violation > > of the agreement we entered into when peering. > > More specific prefix in addition to aggregate one visible only over > specific peers will do the job, too. And will do that job better... but > for what cost (not only to you)...? See above. > > There certainly were historical reasons for treating origin as sacrosanct. > > Time has marched on and those reasons are now *historical*, hence the > > quite reasonable updat eto the RFC. You seem to fail to understand that > > MED comes after origin on the decision tree, and therefore someone can > > influence traffic carriage without agreement. > > You seem to fail realize other (easier) ways to influence traffic > carriage. Deaggregation with selective route announcement is quite > common way, many networks do that. See above. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From danny at danysek.cz Sat Jun 2 06:45:19 2012 From: danny at danysek.cz (Daniel Suchy) Date: Sat, 02 Jun 2012 13:45:19 +0200 Subject: HE.net BGP origin attribute rewriting In-Reply-To: <20120602104315.GA23204@gweep.net> References: <4FC75565.4000404@foobar.org> <088CAAF4-B6AD-4CA7-B4A3-0905B0ED3FAB@yahoo.com> <4FC77434.5000306@foobar.org> <1338479206.77423.YahooMailNeo@web31803.mail.mud.yahoo.com> <20120531170646.GA2477@pob.ytti.fi> <4FC87B04.20200@danysek.cz> <20120601173841.GA47560@gweep.net> <4FC90406.1000606@danysek.cz> <20120602005336.GA7394@gweep.net> <4FC9C068.2070506@danysek.cz> <20120602104315.GA23204@gweep.net> Message-ID: <4FC9FCCF.8040808@danysek.cz> On 06/02/2012 12:43 PM, Joe Provo wrote: > Last post on this topic for me. You seem to wish to argue > against the lessons of history and the reality of running > a network on the global Internet. Based on observations from routeviews / RIPE RIS / other public sources, overwriting BGP origin isn't a common practice. I did some analysis before I opened this topic. >From tier-1 networks, only Level3 seems to do this, from other major networks only HE. Based on network listed at http://en.wikipedia.org/wiki/Tier_1_network, there're 2 of 22 major (and only 11 tier-1) worldwide networks performing origin overwritting. That's really not a representation of common and widely used practice. I'm not arguing with common practice on the internet. Majority doesn't touch origin attribute... (and yes, basically I don't care about pure tier-2/3 networks, their impact isn't peremptory in terms of their global impact) > The two issues are orthogonal. Deaggregating sources have > been cost-shifting [in a highly visible and easily examined > and often trivially-filtered] manner for ages. In global table, there's 41% overhead, in terms of prefixes announced. I don't think it's trivial to filter this overhead. If you're correct (I don't think so), why there's this huge ammount of unfiltered deaggregated prefixes in global table? Because it's easier to buy new hardware. > A midspan network deaggregating someone else's prefixes is > broken and gets called out, generally by the originator if > they have a clue. This is bad at all - but sometimes also happens with huge impact and this is historically documented on some cases like Pakistan Telecom/Youtube. And this happened, even you said that filtering is trivial... - Daniel From bking at inline.com Sat Jun 2 07:14:13 2012 From: bking at inline.com (Bryan King) Date: Sat, 2 Jun 2012 07:14:13 -0500 Subject: limestone networks abuse department Message-ID: <2E2217480B29844BA5E3B4A4BEACE51DF97AF947DE@TCNMAIL1> ...Or lack thereof... Anyone on list from Limestone that can respond to continued abuse complaints please contact me off list. bryan king| Internet Department Director InLine> Solutions Through Technology 600 Lakeshore Pkwy Birmingham AL, 35209 205-278-8139 [p] 205-314-7729 [f] bking at inline.com www.InLine.com All Quotes from InLine are only valid for 30 days. This message and any attached files may contain confidential information and are intended solely for the message recipient. If you are not the message recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. From caldcv at gmail.com Sat Jun 2 08:37:31 2012 From: caldcv at gmail.com (Chris) Date: Sat, 2 Jun 2012 09:37:31 -0400 Subject: limestone networks abuse department In-Reply-To: <2E2217480B29844BA5E3B4A4BEACE51DF97AF947DE@TCNMAIL1> References: <2E2217480B29844BA5E3B4A4BEACE51DF97AF947DE@TCNMAIL1> Message-ID: Continued abuse complaints? Time to contact the uplink. Shoot me an email off list and I'll help you how I can because I lean hard on uplinks in regards to hosting companies ignoring the Wordpress spam problem On Sat, Jun 2, 2012 at 8:14 AM, Bryan King wrote: > ...Or lack thereof... > > Anyone on list from Limestone that can respond to continued abuse complaints please contact me off list. > > > bryan king| Internet Department Director > InLine> Solutions Through Technology > 600 Lakeshore Pkwy > Birmingham AL, 35209 > 205-278-8139?[p] > 205-314-7729?[f] > bking at inline.com > www.InLine.com > > All Quotes from InLine are only valid for 30 days. This message and any attached files may contain confidential information and are intended solely for the message recipient. If you are not the message recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. > > -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton From j at arpa.com Sat Jun 2 12:06:28 2012 From: j at arpa.com (jamie rishaw) Date: Sat, 2 Jun 2012 12:06:28 -0500 Subject: limestone networks abuse department In-Reply-To: <2E2217480B29844BA5E3B4A4BEACE51DF97AF947DE@TCNMAIL1> References: <2E2217480B29844BA5E3B4A4BEACE51DF97AF947DE@TCNMAIL1> Message-ID: Go top down. Gary Kendall - CEO Logan Vig - CTO (All names should be considered "in quotes" as, well, do these people exist?) Their 'Interim Designation' (copyright) person of record: Anthony Winters (7/1/2011) Same tel, fax 242-3600. Tho, from previous experience both here and irl, lstn peeps dont seem too responsive. Given their last address is a UPS store, well, good luck. If you -really- want to rattle some cages: http://www.databank.com/company/leadership.html appear to be bldg owners at their current(?) addr (dctr bldg), and, well, .. should get you somewhere. -j On Sat, Jun 2, 2012 at 7:14 AM, Bryan King wrote: > ...Or lack thereof... > > Anyone on list from Limestone that can respond to continued abuse > complaints please contact me off list. > > > bryan king| Internet Department Director > InLine> Solutions Through Technology > 600 Lakeshore Pkwy > Birmingham AL, 35209 > 205-278-8139 [p] > 205-314-7729 [f] > bking at inline.com > www.InLine.com > > All Quotes from InLine are only valid for 30 days. This message and any > attached files may contain confidential information and are intended solely > for the message recipient. If you are not the message recipient you are > notified that disclosing, copying, distributing or taking any action in > reliance on the contents of this information is strictly prohibited. E-mail > transmission cannot be guaranteed to be secure or error-free as information > could be intercepted, corrupted, lost, destroyed, arrive late or > incomplete, or contain viruses. The sender therefore does not accept > liability for any errors or omissions in the contents of this message, > which arise as a result of e-mail transmission. If verification is required > please request a hard-copy version. > > > -- Jamie Rishaw // .com.arpa at j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs From nabilsharma at hotmail.com Sat Jun 2 16:08:36 2012 From: nabilsharma at hotmail.com (Nabil Sharma) Date: Sat, 2 Jun 2012 21:08:36 +0000 Subject: Comcast Paid Peer Pricing Message-ID: Dear NANOG: I seek pricing on Comcast AS7922 paid peer at following commit level: 1G 10G 100G Please reply in private and I will sum up on list. Sincerely, Nabil From jmaslak at antelope.net Sat Jun 2 18:54:55 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Sat, 2 Jun 2012 17:54:55 -0600 Subject: Comcast Paid Peer Pricing In-Reply-To: References: Message-ID: <78B56A9A-D2EE-4DE6-90EE-C27ADDDDB166@antelope.net> On Jun 2, 2012, at 3:08 PM, Nabil Sharma wrote: > Dear NANOG: > I seek pricing on Comcast AS7922 paid peer at following commit level: > 1G > 10G > 100G > Please reply in private and I will sum up on list. > Sincerely, > Nabil I'd suggest contact Comcast sales. From streiner at cluebyfour.org Sat Jun 2 18:57:11 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 2 Jun 2012 19:57:11 -0400 (EDT) Subject: Comcast Paid Peer Pricing In-Reply-To: References: Message-ID: On Sat, 2 Jun 2012, Nabil Sharma wrote: > Dear NANOG: > I seek pricing on Comcast AS7922 paid peer at following commit level: > 1G > 10G > 100G > Please reply in private and I will sum up on list. Perhaps these would be worth reviewing? http://www.concast.com/peering/ http://www.comcast.com/dedicatedinternet/?SCRedirect=true http://as7922.peeringdb.com/ Your best bet would be to hit up their sales contact if you want pricing on non-SFI peering. jms From apishdadi at gmail.com Sat Jun 2 19:44:53 2012 From: apishdadi at gmail.com (Ameen Pishdadi) Date: Sat, 2 Jun 2012 19:44:53 -0500 Subject: Comcast Paid Peer Pricing In-Reply-To: References: Message-ID: <7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com> Concast I love it!! Thanks, Ameen Pishdadi On Jun 2, 2012, at 6:57 PM, "Justin M. Streiner" wrote: > On Sat, 2 Jun 2012, Nabil Sharma wrote: > >> Dear NANOG: >> I seek pricing on Comcast AS7922 paid peer at following commit level: >> 1G >> 10G >> 100G >> Please reply in private and I will sum up on list. > > Perhaps these would be worth reviewing? > > http://www.concast.com/peering/ > http://www.comcast.com/dedicatedinternet/?SCRedirect=true > http://as7922.peeringdb.com/ > > Your best bet would be to hit up their sales contact if you want pricing on non-SFI peering. > > jms > From nabilsharma at hotmail.com Sat Jun 2 23:41:34 2012 From: nabilsharma at hotmail.com (Nabil Sharma) Date: Sun, 3 Jun 2012 04:41:34 +0000 Subject: Comcast Paid Peer Pricing In-Reply-To: <7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com> References: , , <7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com> Message-ID: I am not allowed to sign NDA, can someone please send me sample pricing in private mail? Sincerely, Nabil > From: apishdadi at gmail.com > Subject: Re: Comcast Paid Peer Pricing > Date: Sat, 2 Jun 2012 19:44:53 -0500 > To: streiner at cluebyfour.org > CC: nanog at nanog.org > > Concast I love it!! > > Thanks, > Ameen Pishdadi > > > On Jun 2, 2012, at 6:57 PM, "Justin M. Streiner" wrote: > > > On Sat, 2 Jun 2012, Nabil Sharma wrote: > > > >> Dear NANOG: > >> I seek pricing on Comcast AS7922 paid peer at following commit level: > >> 1G > >> 10G > >> 100G > >> Please reply in private and I will sum up on list. > > > > Perhaps these would be worth reviewing? > > > > http://www.concast.com/peering/ > > http://www.comcast.com/dedicatedinternet/?SCRedirect=true > > http://as7922.peeringdb.com/ > > > > Your best bet would be to hit up their sales contact if you want pricing on non-SFI peering. > > > > jms > > > From alter3d at alter3d.ca Sat Jun 2 23:45:38 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sun, 03 Jun 2012 00:45:38 -0400 Subject: Comcast Paid Peer Pricing In-Reply-To: References: , , <7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com> Message-ID: <4FCAEBF2.2060402@alter3d.ca> You're not allowed to sign an NDA, but you expect other people to violate the ones that they've signed by disclosing pricing to you? Yeah, I'm sure everyone will get right on that... - Pete On 6/3/2012 12:41 AM, Nabil Sharma wrote: > I am not allowed to sign NDA, can someone please send me sample pricing in private mail? > > Sincerely, > Nabil > >> From: apishdadi at gmail.com >> Subject: Re: Comcast Paid Peer Pricing >> Date: Sat, 2 Jun 2012 19:44:53 -0500 >> To: streiner at cluebyfour.org >> CC: nanog at nanog.org >> >> Concast I love it!! >> >> Thanks, >> Ameen Pishdadi >> >> >> On Jun 2, 2012, at 6:57 PM, "Justin M. Streiner" wrote: >> >>> On Sat, 2 Jun 2012, Nabil Sharma wrote: >>> >>>> Dear NANOG: >>>> I seek pricing on Comcast AS7922 paid peer at following commit level: >>>> 1G >>>> 10G >>>> 100G >>>> Please reply in private and I will sum up on list. >>> Perhaps these would be worth reviewing? >>> >>> http://www.concast.com/peering/ >>> http://www.comcast.com/dedicatedinternet/?SCRedirect=true >>> http://as7922.peeringdb.com/ >>> >>> Your best bet would be to hit up their sales contact if you want pricing on non-SFI peering. >>> >>> jms >>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4418 bytes Desc: S/MIME Cryptographic Signature URL: From alter3d at alter3d.ca Sun Jun 3 00:19:44 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sun, 03 Jun 2012 01:19:44 -0400 Subject: Comcast Paid Peer Pricing In-Reply-To: References: , , , , <7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com>, , <4FCAEBF2.2060402@alter3d.ca> Message-ID: <4FCAF3F0.8090406@alter3d.ca> If you believe that they have no legal right to keep the data private, then obviously any NDA surrounding that data is unenforceable, so you should have no problems signing it yourself and then completely ignoring its terms as you're asking others to do. I'm sure the judge at your civil suit will find your arguments interesting and will weigh them appropriately. Keep in mind that anyone who provides pricing data to you may not only be violating any Comcast NDA that they may have signed, but possibly the NDA they have with their employer as well. Even if there is no NDA covering the Comcast<->Employer relationship, any employee of Employer may be legally bound not to discuss the terms of ANY of Employer's contracts with third parties. - Pete On 6/3/2012 1:03 AM, Nabil Sharma wrote: > Yes sir. They're a cable monopoly, I don't think they have any legal > or moral right to keep the data private. > > > Date: Sun, 3 Jun 2012 00:45:38 -0400 > > From: alter3d at alter3d.ca > > To: nanog at nanog.org > > Subject: Re: Comcast Paid Peer Pricing > > > > You're not allowed to sign an NDA, but you expect other people to > > violate the ones that they've signed by disclosing pricing to you? > > Yeah, I'm sure everyone will get right on that... > > > > - Pete > > > > > > On 6/3/2012 12:41 AM, Nabil Sharma wrote: > > > I am not allowed to sign NDA, can someone please send me sample > pricing in private mail? > > > > > > Sincerely, > > > Nabil > > > > > >> From: apishdadi at gmail.com > > >> Subject: Re: Comcast Paid Peer Pricing > > >> Date: Sat, 2 Jun 2012 19:44:53 -0500 > > >> To: streiner at cluebyfour.org > > >> CC: nanog at nanog.org > > >> > > >> Concast I love it!! > > >> > > >> Thanks, > > >> Ameen Pishdadi > > >> > > >> > > >> On Jun 2, 2012, at 6:57 PM, "Justin M. > Streiner" wrote: > > >> > > >>> On Sat, 2 Jun 2012, Nabil Sharma wrote: > > >>> > > >>>> Dear NANOG: > > >>>> I seek pricing on Comcast AS7922 paid peer at following commit > level: > > >>>> 1G > > >>>> 10G > > >>>> 100G > > >>>> Please reply in private and I will sum up on list. > > >>> Perhaps these would be worth reviewing? > > >>> > > >>> http://www.concast.com/peering/ > > >>> http://www.comcast.com/dedicatedinternet/?SCRedirect=true > > >>> http://as7922.peeringdb.com/ > > >>> > > >>> Your best bet would be to hit up their sales contact if you want > pricing on non-SFI peering. > > >>> > > >>> jms > > >>> > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4418 bytes Desc: S/MIME Cryptographic Signature URL: From mark.tinka at seacom.mu Sun Jun 3 02:05:31 2012 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 3 Jun 2012 09:05:31 +0200 Subject: Comcast Paid Peer Pricing In-Reply-To: References: <7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com> Message-ID: <201206030905.31855.mark.tinka@seacom.mu> On Sunday, June 03, 2012 06:41:34 AM Nabil Sharma wrote: > I am not allowed to sign NDA, can someone please send me > sample pricing in private mail? Then find someone in your company who will and use that channel, Nabil. Alternatively, have you tried to find out whether Comcast could actually quote you without needing an NDA? They might have a provision for that (generic, poorly-discounted pricing, not to give themselves away until you're serious, e.t.c.). Just don't expect the folk here to do that work for you, Nabil. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From streiner at cluebyfour.org Sun Jun 3 04:33:53 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 3 Jun 2012 05:33:53 -0400 (EDT) Subject: Comcast Paid Peer Pricing In-Reply-To: References: , , <7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com> Message-ID: On Sun, 3 Jun 2012, Nabil Sharma wrote: > I am not allowed to sign NDA, can someone please send me sample pricing > in private mail? I didn't see any requirement to sign an NDA for their dedicated non-transit product, which is essentially what you were asking for. If you want to do SFI (assuming your network meets Comcast's criteria for SFI), then there would be an NDA. jms >> From: apishdadi at gmail.com >> Subject: Re: Comcast Paid Peer Pricing >> Date: Sat, 2 Jun 2012 19:44:53 -0500 >> To: streiner at cluebyfour.org >> CC: nanog at nanog.org >> >> Concast I love it!! >> >> Thanks, >> Ameen Pishdadi >> >> >> On Jun 2, 2012, at 6:57 PM, "Justin M. Streiner" wrote: >> >>> On Sat, 2 Jun 2012, Nabil Sharma wrote: >>> >>>> Dear NANOG: >>>> I seek pricing on Comcast AS7922 paid peer at following commit level: >>>> 1G >>>> 10G >>>> 100G >>>> Please reply in private and I will sum up on list. >>> >>> Perhaps these would be worth reviewing? >>> >>> http://www.concast.com/peering/ >>> http://www.comcast.com/dedicatedinternet/?SCRedirect=true >>> http://as7922.peeringdb.com/ >>> >>> Your best bet would be to hit up their sales contact if you want pricing on non-SFI peering. >>> >>> jms >>> >> > From streiner at cluebyfour.org Sun Jun 3 04:53:17 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 3 Jun 2012 05:53:17 -0400 (EDT) Subject: Comcast Paid Peer Pricing In-Reply-To: References: , , <7CE63E7C-9B7F-4FE9-8B5A-CF2B02891A92@gmail.com> Message-ID: On Sun, 3 Jun 2012, Nabil Sharma wrote: > I am not allowed to sign NDA, can someone please send me sample pricing > in private mail? Since it's not entirely clear if you're asking about SFI or not... Entering into something like an SFI agreement with a large national network is typically something that 1. your company's legal counsel would need to review, and 2. Someone pretty high up in your company would need to approve and sign, because it can potentially obligate your company to make significant ongoing infrastructure investments to remain in compliance with your SFI agreement. If your company has a network that's large enough to warrant SFI, it would also stand to reason that they already have business and legal processes in place for dealing with things like this - something a little more 'official' than hassling people on a public mailing list, from a Hotmail address ;) If anyone on this list is doing SFI with Comcast, they are not going to risk violating their NDA by providing what could be considered confidential and proprietary information to a third party, let alone a complete stranger. If you're not asking about SFI, call/email the sales contact that was listed on their dedicated internet access page, and get a quote. I saw no indication that you needed an NDA to get a quote for their paid peering product. All I saw was an order form that you would need to fill out and email to the sales contact. As others mave mentioned, Comcast might not provide the best pricing right off the bat, but it at least would get you a number that you can use for budgetary/planning purposes. jms From tom at dyn.com Sun Jun 3 06:06:10 2012 From: tom at dyn.com (Tom Daly) Date: Sun, 3 Jun 2012 07:06:10 -0400 (EDT) Subject: NANOG 55: Submit your Lightning Talks! In-Reply-To: <931573253.20924661.1338721212313.JavaMail.root@zmail-01.mht.dyndns.com> Message-ID: <587063757.20924696.1338721570015.JavaMail.root@zmail-01.mht.dyndns.com> Hello NANOG 55'ers, Welcome to Vancouver. On behalf of the NANOG Program Committee, I'm pleased to announce that we're accepting Lightning Talk submissions via our tool at https://pc.nanog.org/. Log in, submit a talk, and wait. We'll be announcing the first round of LTs late this evening. How does it work? - You come up with an idea for a 10 minute talk. You submit an abstract to the tool at https://pc.nanog.org. - The Program Committee reviews the talks in the tool, and each PC member rates their top 3 choices. - Around 10pm Sunday and Tuesday evenings, we'll select the top 3 rated talks in the tool, and include them in the following day's Lightning Talk session. - If you are selected to present a Lightning Talk, you'll be notified by email on how to submit your slides to the NANOG PC. No idea is too ridiculous for a talk! No topic is too crazy! Submit your talk now and enjoy the rush of a being a real, live, NANOG presenter! For the NANOG PC, Tom Daly -- Tom Daly @tomdyninc | tom at dyn.com | http://dyn.com Dyn | 150 Dow Street | Manchester, NH 03101, USA From ren.provo at gmail.com Sun Jun 3 10:44:14 2012 From: ren.provo at gmail.com (Ren Provo) Date: Sun, 3 Jun 2012 11:44:14 -0400 Subject: Comcast Paid Peer Pricing In-Reply-To: References: Message-ID: What is your ASN Nabil so I can find out what you submitted for a request, including scope and term. -ren On Sat, Jun 2, 2012 at 5:08 PM, Nabil Sharma wrote: > > Dear NANOG: > I seek pricing on Comcast AS7922 paid peer at following commit level: > 1G > 10G > 100G > Please reply in private and I will sum up on list. > Sincerely, > Nabil > From j at arpa.com Sun Jun 3 11:23:42 2012 From: j at arpa.com (jamie rishaw) Date: Sun, 3 Jun 2012 11:23:42 -0500 Subject: Comcast Paid Peer Pricing In-Reply-To: References: Message-ID: ..I was waiting for Ren to shut this thread Down. :) Nabil: reply to Ren directly, off list. You'll be in good hands. j On Jun 3, 2012 10:44 AM, "Ren Provo" wrote: > What is your ASN Nabil so I can find out what you submitted for a > request, including scope and term. -ren > > On Sat, Jun 2, 2012 at 5:08 PM, Nabil Sharma > wrote: > > > > Dear NANOG: > > I seek pricing on Comcast AS7922 paid peer at following commit level: > > 1G > > 10G > > 100G > > Please reply in private and I will sum up on list. > > Sincerely, > > Nabil > > > > From me at anuragbhatia.com Sun Jun 3 14:35:37 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Mon, 4 Jun 2012 01:05:37 +0530 Subject: Questions about anycasting setup In-Reply-To: <20120312082532.GD17726@h.detebe.org> References: <20120309081131.GC17726@h.detebe.org> <4F59C701.3090503@altadena.net> <2763367C-26BA-4330-812E-C5898E154D14@gibbard.org> <20120312082532.GD17726@h.detebe.org> Message-ID: Hello everyone Thought to re-open to this thread and discuss couple of doubts I have in mind regarding the same. I tried doing anycasting with 3 nodes, and seems like it didn't worked well at all. It seems like ISPs prefer their own or their customer route (which is our transit provider) and there is almost no "short/local route" effect. I am presently using Charter + Cogent/Gblx + Tinet for this setup. I was looking for some advise over this issue: 1. How to deal with ISPs not prefering local node on their peers network and going to far off node on their own/or customer network? Is it just normal and there's no fix by any BGP announcement method/conf file parameter? Should one prefer taking transit for all locations from same ISP? 2. I am using Quagga on all instances. Any advise on configuration file parameters specifically for anycasting instance? (I would be happy to share existing conf. is required). I did tried AS path prepending, but seems like it didn't helped much (or may be I fail to get it working). What are possible parameters one can have in conf for anycasting case (BGP MED's)? 3. Is putting singlehommed nodes with no peering and transit from single ISP was poor idea? I wonder how other small players do it? Do you take multiple upstreams for all anycasting DNS nodes? Though route pull off is pretty much instance, and I see no problems with it. Also, I have not got the node in EU up yet (which will be under colo's network which is under Telia). I guess since distance in EU with US is way higher then between our domestic US nodes, so probably I will see local/near routing effect with EU server. But still clueless on how to get it working in current setup. Appreciate everyone's comments and help. Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Linkedin | Twitter| Google+ From woody at pch.net Sun Jun 3 16:11:49 2012 From: woody at pch.net (Bill Woodcock) Date: Sun, 3 Jun 2012 14:11:49 -0700 Subject: Questions about anycasting setup In-Reply-To: References: <20120309081131.GC17726@h.detebe.org> <4F59C701.3090503@altadena.net> <2763367C-26BA-4330-812E-C5898E154D14@gibbard.org> <20120312082532.GD17726@h.detebe.org> Message-ID: <3C5E8697-8AFD-4A4B-9A4F-4AD48BE71F52@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Jun 3, 2012, at 12:35 PM, Anurag Bhatia wrote: > I tried doing anycasting with 3 nodes, and seems like it didn't worked well > at all. It seems like ISPs prefer their own or their customer route (which > is our transit provider) and there is almost no "short/local route" effect. Correct. That's why you need to use the same transit providers at each location. http://www.pch.net/resources/papers//dns-service-architecture/dns-service-architecture-v11.pdf Slides 20-29. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPy9MWAAoJEG+kcEsoi3+HJkkP/jP9ZVGlIs53qs93jWth6tjt M/zvVBs8EhJrn9RQ9VxfJ1VNmJ4cFILV52PGXarDhN7Gkc/fke0mh3Jbb8rOh9k9 jhFFV0QuiF/vda4QNskzXJGvWTkdl0vhq5BMqcKOLpk2zVMBvvNJziEoFgpxeXaz ghlgDxOGZ1Fq/sSgQndfx/bYPBOq/N5zkfsNQSW8CSrHwuuXIW3C/XgEbHLEbUGG r4w0vtrdtjrrlYs301YjTVXcFPw4Xs/byor+Sqf8XvIOiQbgAe0Ap9p3/kBHjAZf aKiTOncqCHgzgP4hJ3elvyd8agkLsGo2kvyReCxAho8lGjAbK/IYzj4npIh0JXj+ LPXjQgDpvq42ly3TJQsugiHHY98sqesDzKe6aQqruChDEqSctL3r8u5F19Nm39Pu 6WIGC6UbJVDol96BVqkTbfMKtbHuzRij2jsc+Dd0GkOLy2Zy095weT1xOh/TDQCj QIN8u4BDFTk+KxVb86a/mWKmcD4lfM6IbOOR8dg2DWmnNlTF2+4DRz2WjYhnqQwg NN1otUVVMrdIAOa5RJSVOJ5Q3R1AK93vCK4QGYrHCs8sw4GMtieqVS4Q1I8Hn28v gKm7POiArujZkzOcQHmyo28zClRrzKkL1Z1P2wJOvos2briuJhhyCeaDaWU0ux3R 5EmMxRpTvCsm6MzEvQkI =D+uQ -----END PGP SIGNATURE----- From jmaimon at ttec.com Sun Jun 3 20:38:58 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 03 Jun 2012 21:38:58 -0400 Subject: IPv6 day and tunnels Message-ID: <4FCC11B2.2090405@ttec.com> Well, IPv6 day isnt here yet, and my first casualty is the browser on the wife's machine, firefox now configured to not query AAAA. Now www.facebook.com loads again. Looks like a tunnel mtu issue. I have not as of yet traced the definitive culprit, who is (not) sending ICMP too big, who is (not) receiving them, etc. www.arin.net works and worked for years. www.facebook.com stopped June 1. So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? Or was the fix incorporating the breakage into the basic design? In IPv4 I can make tunneling just work nearly all of the time. So I have to munge a tcp mss header, or clear a df-bit, or fragment the encapsulated packet when all else fails, but at least the tools are there. And on the host, /proc/sys/net In IPv6, it seems my options are a total throwback, with the best one turning the sucker off. Nobody (on that station) needs it anyways. Joe From cb.list6 at gmail.com Sun Jun 3 20:59:13 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 3 Jun 2012 18:59:13 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCC11B2.2090405@ttec.com> References: <4FCC11B2.2090405@ttec.com> Message-ID: On Sun, Jun 3, 2012 at 6:38 PM, Joe Maimon wrote: > Well, IPv6 day isnt here yet, and my first casualty is the browser on the > wife's machine, firefox now configured to not query AAAA. > > Now www.facebook.com loads again. > > Looks like a tunnel mtu issue. I have not as of yet traced the definitive > culprit, who is (not) sending ICMP too big, who is (not) receiving them, > etc. > > www.arin.net works and worked for years. www.facebook.com stopped June 1. > > So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? > > Or was the fix incorporating the breakage into the basic design? > > In IPv4 I can make tunneling just work nearly all of the time. So I have to > munge a tcp mss header, or clear a df-bit, or fragment the encapsulated > packet when all else fails, but at least the tools are there. And on the > host, /proc/sys/net > > In IPv6, it seems my options are a total throwback, with the best one > turning the sucker off. Nobody (on that station) needs it anyways. > > Joe > #1 don't tunnel unless you really need to. #2 see #1 #3 use happy eyeballs, http://tools.ietf.org/html/rfc6555, Chrome has a good implementation, but this does not solve MTU issues. #4 MSS hacks work at the TCP layer and still work regardless of IPv4 or IPv6. #5 According to the IETF, MSS hacks do not exist and neither do MTU issues http://www.ietf.org/mail-archive/web/v6ops/current/msg12933.html PSA time: Please use http://test-ipv6.com/ and pass this good advice around to the people you know. Thanks, Cameron From jmaimon at ttec.com Sun Jun 3 21:05:40 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 03 Jun 2012 22:05:40 -0400 Subject: IPv6 day and tunnels In-Reply-To: <4FCC11B2.2090405@ttec.com> References: <4FCC11B2.2090405@ttec.com> Message-ID: <4FCC17F4.3020105@ttec.com> Joe Maimon wrote: > Looks like a tunnel mtu issue. I have not as of yet traced the > definitive culprit, who is (not) sending ICMP too big, who is (not) > receiving them, etc. > The culprit is the v6 tunnel, which wanders into v4 ipsec/gre tunnels, which means the best fix is ipv6 mtu 1280 on the tunnels, and possibly on the hosts. PMTUD works fine, just comes up with the wrong answer. 1280, the new 1500. > Joe From jmaimon at ttec.com Sun Jun 3 21:19:57 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Sun, 03 Jun 2012 22:19:57 -0400 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> Message-ID: <4FCC1B4D.8010204@ttec.com> Cameron Byrne wrote: >> > > #1 don't tunnel unless you really need to. Tunnels are ipv4 only now? > > #2 see #1 > > #3 use happy eyeballs, http://tools.ietf.org/html/rfc6555, Chrome has > a good implementation, but this does not solve MTU issues. Because the initial connections are made just fine. PMTUD with probing should work, but does not seem to. Probably a (lack of) deployment issue. > > #4 MSS hacks work at the TCP layer and still work regardless of IPv4 or IPv6. But the equipment needs to support it. Again IPv6 lags. > > #5 According to the IETF, MSS hacks do not exist and neither do MTU > issues http://www.ietf.org/mail-archive/web/v6ops/current/msg12933.html Thanks for that. I expect soon tunnels wont either. > > PSA time: Please use http://test-ipv6.com/ and pass this good advice > around to the people you know. Excellent site/tool. > > Thanks, > > Cameron > > Thank you. Joe From jmaslak at antelope.net Sun Jun 3 21:33:40 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Sun, 3 Jun 2012 20:33:40 -0600 Subject: IPv6 day and tunnels In-Reply-To: <4FCC11B2.2090405@ttec.com> References: <4FCC11B2.2090405@ttec.com> Message-ID: <1F6EFAED-340C-4659-A59D-58800C079A9A@antelope.net> On Jun 3, 2012, at 7:38 PM, Joe Maimon wrote: > www.arin.net works and worked for years. www.facebook.com stopped June 1. > > So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? It doesn't fix the fragmentation issues. It assumes working PMTU. For what it's worth, I also use a tunnel without issue to reach www.facebook.com via IPv6, with an MTU of 1476 (since it's running over a 1492 byte IPv4 PPoE tunnel...). From mysidia at gmail.com Sun Jun 3 21:49:47 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 3 Jun 2012 21:49:47 -0500 Subject: Wacky Weekend: The '.secure' gTLD In-Reply-To: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com> References: <15376026.6918.1338509096625.JavaMail.root@benjamin.baylink.com> <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com> Message-ID: On 5/31/12, Jay Ashworth wrote: > HTTP redirects funneling connections towards the appropriate TLS-encrypted > site), use DNSSEC, and deploy DomainKeys Identified Mail (DKIM) for spam The "Except for HTTP redirects" part is a gigantonormous hole. A MITM attacker on a LAN can intercept traffic to the non-HTTPS redirect site and proxy this traffic. The ".SECURE" in the TLD looks like a user interface declaration, the user will believe that the appearance of .SECURE means their connection is encrypted, even when it is not. The TLD should probably not be allowed, because it is confusing, it looks like a User Interface Declaration, that the site is proven to be secure, but none of the registry's proposed measures provide a reliable assurance; it may lead the user to believe that ".SECURE" is a technical indication that ensures the site is actually secure. Even HTTPS and EV+SSL do not provide such a strong UI declaration. A UI declaration should not be able to be made by the registration of a domain alone, the software displaying the URL should be responsible for UI declarations. This may result in mixed signals if a site on a SLD under .SECURE is actually compromised, which is more harmful than having no UI declaration. Absent a new RFC requirement for browsers to connect to .SECURE TLD sites using only HTTPS, their "Non-HTTPS Redirect to HTTPS pages" are just as susceptible to MITM hijacking as any non-HTTPS site. > prevention. In addition, Artemis would employ a rigorous screening process > to verify registrants' identities (including reviewing articles of incorporation > and human interviews), and routinely conduct security scans of registered > sites. The venture has $9.6 million (US) in funding provided by Artemis' This is expensive, a good way to keep the TLD out of use except by large corporations, and is therefore of very limited value to the community. Required to meet a generally accepted standard of security with third party auditing would be more useful. "Security scans" by one provider aren't really good enough. Automated scans cannot detect insidious exploitability issues; they typically detect and flag non-issues to justify their existence, and fail to detect glaring issues such as session tracking in a manner vulnerable to CSRF. More importantly; remote periodic scans cannot detect compromise of the site or ensure reasonable internal security practices, when the impact is information leak, intruders don't always insert malware on the front page for a scanner to pick up. -- -JH From cmorris at cs.odu.edu Sun Jun 3 22:06:09 2012 From: cmorris at cs.odu.edu (Charles Morris) Date: Sun, 3 Jun 2012 23:06:09 -0400 Subject: Wacky Weekend: The '.secure' gTLD In-Reply-To: <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com> References: <15376026.6918.1338509096625.JavaMail.root@benjamin.baylink.com> <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com> Message-ID: No. Let's go the opposite direction and make DNS a decentralized trust model. :) > Digress. From marka at isc.org Sun Jun 3 22:14:15 2012 From: marka at isc.org (Mark Andrews) Date: Mon, 04 Jun 2012 13:14:15 +1000 Subject: IPv6 day and tunnels In-Reply-To: Your message of "Sun, 03 Jun 2012 21:38:58 -0400." <4FCC11B2.2090405@ttec.com> References: <4FCC11B2.2090405@ttec.com> Message-ID: <20120604031416.0B4D02138073@drugs.dv.isc.org> In message <4FCC11B2.2090405 at ttec.com>, Joe Maimon writes: > Well, IPv6 day isnt here yet, and my first casualty is the browser on > the wife's machine, firefox now configured to not query AAAA. > > Now www.facebook.com loads again. > > Looks like a tunnel mtu issue. I have not as of yet traced the > definitive culprit, who is (not) sending ICMP too big, who is (not) > receiving them, etc. > > www.arin.net works and worked for years. www.facebook.com stopped June 1. > > So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? > > Or was the fix incorporating the breakage into the basic design? > > In IPv4 I can make tunneling just work nearly all of the time. So I have > to munge a tcp mss header, or clear a df-bit, or fragment the > encapsulated packet when all else fails, but at least the tools are > there. And on the host, /proc/sys/net > > In IPv6, it seems my options are a total throwback, with the best one > turning the sucker off. Nobody (on that station) needs it anyways. > > Joe If facebook isn't working for you over a tunnel, and other sites are, complain to the site. If they don't let through ICMPv6 PTB then the site needs to add "route change -inet6 change -mtu 1280" or equivalent to every box. This isn't rocket science. If you choose to break PMTU discovery then you can take the necessary steps to avoid requiring that PMTU Discovery works. This is practical for IPv6. For IPv4 it is impractical to do the same. The IPv6 Advanced Socket API even has controls so that you can make the PMTUD choice on a per socket basis. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bmanning at vacation.karoshi.com Sun Jun 3 22:26:20 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 4 Jun 2012 03:26:20 +0000 Subject: IPv6 day and tunnels In-Reply-To: <4FCC17F4.3020105@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC17F4.3020105@ttec.com> Message-ID: <20120604032620.GA14406@vacation.karoshi.com.> On Sun, Jun 03, 2012 at 10:05:40PM -0400, Joe Maimon wrote: > > > Joe Maimon wrote: > > >Looks like a tunnel mtu issue. I have not as of yet traced the > >definitive culprit, who is (not) sending ICMP too big, who is (not) > >receiving them, etc. > > > > The culprit is the v6 tunnel, which wanders into v4 ipsec/gre tunnels, > which means the best fix is ipv6 mtu 1280 on the tunnels, and possibly > on the hosts. PMTUD works fine, just comes up with the wrong answer. > > 1280, the new 1500. > > > >Joe actually, to be safe, 1220. /bill From jeroen at unfix.org Sun Jun 3 22:35:59 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 03 Jun 2012 20:35:59 -0700 Subject: IPv6 day and tunnels In-Reply-To: <20120604032620.GA14406@vacation.karoshi.com.> References: <4FCC11B2.2090405@ttec.com> <4FCC17F4.3020105@ttec.com> <20120604032620.GA14406@vacation.karoshi.com.> Message-ID: <4FCC2D1F.3020000@unfix.org> On 2012-06-03 20:26, bmanning at vacation.karoshi.com wrote: > On Sun, Jun 03, 2012 at 10:05:40PM -0400, Joe Maimon wrote: [..] > actually, to be safe, 1220. That will work really well with the minimum IPv6 MTU being 1280 ;) Greets, Jeroen From mysidia at gmail.com Sun Jun 3 22:40:02 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 3 Jun 2012 22:40:02 -0500 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> Message-ID: On 6/3/12, Cameron Byrne wrote: > On Sun, Jun 3, 2012 at 6:38 PM, Joe Maimon wrote: [snip] > #5 According to the IETF, MSS hacks do not exist and neither do MTU > issues http://www.ietf.org/mail-archive/web/v6ops/current/msg12933.html They couldn't be more wrong. MTU issues still exist, and not just with tunnelling, but tunneling should be an expected scenario for IP. The protocol IPv6 still handles it very poorly, by still requiring external ICMP messages, through the unreliable PTMUD scheme, matters are as bad if not worse than with IPv4. It's just so unfortunate that IPv6 couldn't provide a good solution to one of IP's more troublesome deficiencies. > Cameron -- -JH From jra at baylink.com Sun Jun 3 23:02:08 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 04 Jun 2012 00:02:08 -0400 Subject: Wacky Weekend: The '.secure' gTLD In-Reply-To: References: <15376026.6918.1338509096625.JavaMail.root@benjamin.baylink.com> <30056137.6920.1338509482343.JavaMail.root@benjamin.baylink.com> Message-ID: <4d6a09f8-31b6-41c7-8827-d73099dbb375@email.android.com> Note that you've misquoted; that was a reply to my post, possibly 2 levels deep. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Jimmy Hess wrote: On 5/31/12, Jay Ashworth wrote: > HTTP redirects funneling connections towards the appropriate TLS-encrypted > site), use DNSSEC, and deploy DomainKeys Identified Mail (DKIM) for spam The "Except for HTTP redirects" part is a gigantonormous hole. A MITM attacker on a LAN can intercept traffic to the non-HTTPS redirect site and proxy this traffic. The ".SECURE" in the TLD looks like a user interface declaration, the user will believe that the appearance of .SECURE means their connection is encrypted, even when it is not. The TLD should probably not be allowed, because it is confusing, it looks like a User Interface Declaration, that the site is proven to be secure, but none of the registry's proposed measures provide a reliable assurance; it may lead the user to believe that ".SECURE" is a technical indication that ensures the site is actually secure. Even HTTPS and EV+SSL do not provide such a strong UI declaration. A UI declaration should not be able to be made by the registration of a domain alone, the software displaying the URL should be responsible for UI declarations. This may result in mixed signals if a site on a SLD under .SECURE is actually compromised, which is more harmful than having no UI declaration. Absent a new RFC requirement for browsers to connect to .SECURE TLD sites using only HTTPS, their "Non-HTTPS Redirect to HTTPS pages" are just as susceptible to MITM hijacking as any non-HTTPS site. > prevention. In addition, Artemis would employ a rigorous screening process > to verify registrants' identities (including reviewing articles of incorporation > and human interviews), and routinely conduct security scans of registered > sites. The venture has $9.6 million (US) in funding provided by Artemis' This is expensive, a good way to keep the TLD out of use except by large corporations, and is therefore of very limited value to the community. Required to meet a generally accepted standard of security with third party auditing would be more useful. "Security scans" by one provider aren't really good enough. Automated scans cannot detect insidious exploitability issues; they typically detect and flag non-issues to justify their existence, and fail to detect glaring issues such as session tracking in a manner vulnerable to CSRF. More importantly; remote periodic scans cannot detect compromise of the site or ensure reasonable internal security practices, when the impact is information leak, intruders don't always insert malware on the front page for a scanner to pick up. -- -JH From kmedcalf at dessus.com Sun Jun 3 23:30:19 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 03 Jun 2012 22:30:19 -0600 Subject: Wacky Weekend: The '.secure' gTLD In-Reply-To: Message-ID: <1963017dea9e4841b7a83fb3cb3c9f86@mail.dessus.com> > This may result in mixed signals if a site on a SLD under .SECURE > is actually compromised, which is more harmful than having no UI > declaration. The greatest advantage of .SECURE is that it will help ensure that all the high-value targets are easy to find. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From jeroen at unfix.org Sun Jun 3 23:54:12 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 3 Jun 2012 21:54:12 -0700 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> Message-ID: <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> On 3 Jun 2012, at 20:40, Jimmy Hess wrote: > On 6/3/12, Cameron Byrne wrote: >> On Sun, Jun 3, 2012 at 6:38 PM, Joe Maimon wrote: > [snip] >> #5 According to the IETF, MSS hacks do not exist and neither do MTU >> issues http://www.ietf.org/mail-archive/web/v6ops/current/msg12933.html > > They couldn't be more wrong. MTU issues still exist, and not just > with tunnelling, > but tunneling should be an expected scenario for IP. > > The protocol IPv6 still handles it very poorly, by still requiring > external ICMP messages, > through the unreliable PTMUD scheme, matters are as bad if not worse > than with IPv4. As ICMPv6 is an integral part of IPv6 how exactly is ICMP "external"? You do realize what the function of ICMP is I hope? If one is so stupid to just block ICMP then one should also accept that one loses functionality. If the people in the IETF would have decided to inline the headers that are ICMPv6 into the IPv6 header then there for sure would have been people who would have blocked the equivalent of PacketTooBig in there too. As long as people can block stuff they will block stuff that they should not have blocked, nothing the IETF can do about, stupidity exists behind the keyboard. That said, pMTU discovery works awesomely in the 10+ years that I have been actively been using IPv6, if it does no work for you, find the issue and resolve it. (tracepath is a great tool for this btw) > It's just so unfortunate that IPv6 couldn't provide a good solution > to one of IP's more troublesome deficiencies. Did you ever bother to comment about your supposed issue in the IETF? Greets, Jeroen From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 00:41:03 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 04 Jun 2012 14:41:03 +0900 Subject: IPv6 day and tunnels In-Reply-To: <4FCC11B2.2090405@ttec.com> References: <4FCC11B2.2090405@ttec.com> Message-ID: <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> Joe Maimon wrote: > So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? Completely wrongly. > Or was the fix incorporating the breakage into the basic design? Yes. Because IPv6 requires ICMP packet too big generated against multicast, it is designed to cause ICMP implosions, which means ISPs must filter ICMP packet too big at least against multicast packets and, as distinguishing them from unicast ones is not very easy, often against unicast ones. For further details, see my presentation at APNIC32: http://meetings.apnic.net/32/program/apops How Path MTU Discovery Doesn't work Masataka Ohta > In IPv4 I can make tunneling just work nearly all of the time. So I have > to munge a tcp mss header, or clear a df-bit, or fragment the > encapsulated packet when all else fails, but at least the tools are > there. And on the host, /proc/sys/net FYI, IETF is trying to inhibit clearing DF bit explicitly with draft-ietf-intarea-ipv4-id-update-05.txt >> IPv4 datagram transit devices MUST NOT clear the DF bit. which is now under the last call. Masataka Ohta From mysidia at gmail.com Mon Jun 4 01:20:32 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 4 Jun 2012 01:20:32 -0500 Subject: IPv6 day and tunnels In-Reply-To: <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> Message-ID: On 6/3/12, Jeroen Massar wrote: > If one is so stupid to just block ICMP then one should also accept that one > loses functionality. ICMP tends to get blocked by firewalls by default; There are legitimate reasons to block ICMP, esp w V6. Security device manufacturers tend to indicate all the "lost functionality" is optional functionality not required for a working device. > If the people in the IETF would have decided to inline the headers that are > ICMPv6 into the IPv6 header then there for sure would have been people who > would have blocked the equivalent of PacketTooBig in there too. As long as Over reliance on "PacketTooBig" is a source of the problem; the idea that too large packets should be blindly generated under ordinary circumstances, carried many hops, and dropped with an error returned a potentially long distance that the sender in each direction is expected to see and act upon, at the expense of high latency for both peers, during initial connection establishment. Routers don't always know when a packet is too big to reach their next hop, especially in case of Broadcast traffic, so they don't know to return a PacketTooBig error, especially in the case of L2 tunneling PPPoE for example, there may be a L2 bridge on the network in between routers with a lower MRU than either of the router's immediate links, eg because PPP, 802.1p,q + MPLS labels, or other overhead are affixed to Ethernet frames, somewhere on the switched path between routers. The problem is not that "Tunneling is bad"; the problem is the IP protocol has issues. The protocol should be designed so that there will not be issues with tunnelling or different MRU Ethernet links. The real solution is for reverse path MTU (MRU) information to be discovered between L3 neighbors by L2 probing, and discovered MRU exchanged using NDP, so routers know the lowest MRU on each directly connected interface, then for the worst case reduction in reverse path MTU to be included in the routing information passed via L3 routing protocols both IGPs and EGPs to the next hop. That is, no router should be allowed to enter a route into its forwarding table, until the worst case reverse MTU is discovered, to reach that network, with the exception, that a device may be configured with a default route, and some directly connected networks. The need for "Too Big" messages is then restricted to nodes connected to terminal networks. And there should be no such thing as packet fragmentation. -- -JH From jeroen at unfix.org Mon Jun 4 01:27:04 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 3 Jun 2012 23:27:04 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> Message-ID: <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> On 3 Jun 2012, at 22:41, Masataka Ohta wrote: > Joe Maimon wrote: > >> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? > > Completely wrongly. Got a better solution? ;) >> Or was the fix incorporating the breakage into the basic design? > > Yes. > > Because IPv6 requires ICMP packet too big generated against > multicast, it is designed to cause ICMP implosions, which > means ISPs must filter ICMP packet too big at least against > multicast packets and, as distinguishing them from unicast > ones is not very easy, often against unicast ones. I do not see the problem that you are seeing, to adress the two issues in your slides: - for multicast just set your max packetsize to 1280, no need for pmtu and thus this "implosion" You think might happen. The sender controls the packetsize anyway and one does not want to frag packets for multicast thus 1280 solves all of it. - when doing IPv6 inside IPv6 the outer path has to be 1280+tunneloverhead, if it is not then you need to use a tunneling protocol that knows how to frag and reassemble as is acting as a medium with an mtu less than the minimum of 1280 Greets, Jeroen From jeroen at unfix.org Mon Jun 4 01:41:24 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 3 Jun 2012 23:41:24 -0700 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> Message-ID: <394D107E-46FE-44F2-A784-B07725C7E489@unfix.org> On 3 Jun 2012, at 23:20, Jimmy Hess wrote: > On 6/3/12, Jeroen Massar wrote: >> If one is so stupid to just block ICMP then one should also accept that one >> loses functionality. > ICMP tends to get blocked by firewalls by default Which firewall product does that? > ; There are > legitimate reasons to block ICMP, esp w V6. The moment one decides to block ICMPv6 you are likely breaking features of IPv6, chose wisely. There are several RFCs pointing out what one could and what one Must never block. Packet Too Big is a very well known one that one should not block. If you decide to block anyway then well, your problem that your network breaks. > Security device > manufacturers tend to indicate all the "lost functionality" is > optional functionality not required for a working device. I suggest that you vote with your money and chose a different vendor if they shove that through your throat. Upgrading braincells is another option though ;) >> If the people in the IETF would have decided to inline the headers that are >> ICMPv6 into the IPv6 header then there for sure would have been people who >> would have blocked the equivalent of PacketTooBig in there too. As long as > > Over reliance on "PacketTooBig" is a source of the problem; the idea > that too large packets should be blindly generated under ordinary > circumstances, carried many hops, and dropped with an error returned a > potentially long distance that the sender in each direction is > expected to see and act upon, at the expense of high latency for both > peers, during initial connection establishment. High latency? You do realize that it is only one roundtrip max that might happen and that there is no shorter way to inform your side of this situation? > Routers don't always know when a packet is too big to reach their next > hop, especially in case of Broadcast traffic, You do realize that IPv6 does not have the concept of broadcast do you?! ;) There is only: unicast, multicast and anycast (and anycast is just unicast as it is a routing trick) > so they don't know to > return a PacketTooBig error, especially in the case of L2 tunneling > PPPoE for example, there may be a L2 bridge on the network in between > routers with a lower MRU than either of the router's immediate links, > eg because PPP, 802.1p,q + MPLS labels, or other overhead are affixed > to Ethernet frames, somewhere on the switched path between routers. If you have a broken L2 network there is nothing that an L3 protocol can do about it. Please properly configure it, stuff tend to work better that way. > The problem is not that "Tunneling is bad"; the problem is the IP > protocol has issues. The protocol should be designed so that there > will not be issues with tunnelling or different MRU Ethernet links. There is no issue as long as you properly respond with PtB and process them when received. If your medium is <1280 then your medium has to solve the fragging of packets. > The real solution is for reverse path MTU (MRU) information to be > discovered between L3 neighbors by L2 probing, and discovered MRU > exchanged using NDP, so routers know the lowest MRU on each directly > connected interface, then for the worst case reduction in reverse path > MTU to be included in the routing information passed via L3 routing > protocols both IGPs and EGPs to the next hop. You do realize that NDP only works on the local link and not further?! ;) Also, carrying MTU and full routing info to end hosts is definitely not something a lot of operators would like to do let alone see in their networks. Similar to you not wanting ICMP in your network even though that is the agreed upon standard. > That is, no router should be allowed to enter a route into its > forwarding table, until the worst case reverse MTU is discovered, to > reach that network, with the exception, that a device may be > configured with a default route, and some directly connected networks. If you want this in your network just configure it everywhere to 1280 and then process and answer PtBs on the edge. Your network, your problem that you will never use jumbo frames. > The need for "Too Big" messages is then restricted to nodes connected > to terminal networks. And there should be no such thing as packet > fragmentation. The fun thing is though that this Internet thing is quite a bit larger than your imaginary network... Greets, Jeroen From owen at delong.com Mon Jun 4 02:01:34 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2012 00:01:34 -0700 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> Message-ID: On Jun 3, 2012, at 11:20 PM, Jimmy Hess wrote: > On 6/3/12, Jeroen Massar wrote: >> If one is so stupid to just block ICMP then one should also accept that one >> loses functionality. > ICMP tends to get blocked by firewalls by default; There are > legitimate reasons to block ICMP, esp w V6. Security device > manufacturers tend to indicate all the "lost functionality" is > optional functionality not required for a working device. > If you feel the need to block ICMP (I'm not convinced this is an actual need), then you should do so very selectively in IPv6. Blocking packet too big messages, especially is definitely harmful in IPv6 and PMTU-D is _NOT_ optional functionality. Any firewall/security device manufacturer that says it is will not get any business from me (or anyone else who considers their requirements properly before purchasing). >> If the people in the IETF would have decided to inline the headers that are >> ICMPv6 into the IPv6 header then there for sure would have been people who >> would have blocked the equivalent of PacketTooBig in there too. As long as > > Over reliance on "PacketTooBig" is a source of the problem; the idea > that too large packets should be blindly generated under ordinary > circumstances, carried many hops, and dropped with an error returned a > potentially long distance that the sender in each direction is > expected to see and act upon, at the expense of high latency for both > peers, during initial connection establishment. > Actually, this generally will NOT affect initial connection establishment and due to slow start usually adds a very small amount of latency about 3-5kb into the conversation. > Routers don't always know when a packet is too big to reach their next > hop, especially in case of Broadcast traffic, so they don't know to > return a PacketTooBig error, especially in the case of L2 tunneling > PPPoE for example, there may be a L2 bridge on the network in between > routers with a lower MRU than either of the router's immediate links, > eg because PPP, 802.1p,q + MPLS labels, or other overhead are affixed > to Ethernet frames, somewhere on the switched path between routers. That is a misconfiguration of the routers. Any routers in such a circumstance need their interface configured for the lower MTU or things are going to break with or without ICMP Packet Too Big messages because even if you didn't have the DF bit, the router has no way to know to fragment the packet. An L2 device should not be fragmenting L3 packets. > The problem is not that "Tunneling is bad"; the problem is the IP > protocol has issues. The protocol should be designed so that there > will not be issues with tunnelling or different MRU Ethernet links. And there are not issues so long as things are configured correctly. Misconfiguration will cause issues no matter how well the protocol is designed. The problem you are describing so far is not a problem with the protocol, it is a problem with misconfigured devices. > The real solution is for reverse path MTU (MRU) information to be > discovered between L3 neighbors by L2 probing, and discovered MRU > exchanged using NDP, so routers know the lowest MRU on each directly > connected interface, then for the worst case reduction in reverse path > MTU to be included in the routing information passed via L3 routing > protocols both IGPs and EGPs to the next hop. This could compensate for some amount of misconfiguration, but you're adding a lot of overhead and a whole bunch of layering violations in order to do it. I think it would be much easier to just fix the configuration errors. > That is, no router should be allowed to enter a route into its > forwarding table, until the worst case reverse MTU is discovered, to > reach that network, with the exception, that a device may be > configured with a default route, and some directly connected networks. I don't see how this would no cause more problems than you claim it will solve. > The need for "Too Big" messages is then restricted to nodes connected > to terminal networks. And there should be no such thing as packet > fragmentation. There should be no such thing as packet fragmentation in the current protocol. What is needed is for people to simply configure things correctly and allow PTB messages to pass as designed. Owen From mhuff at ox.com Mon Jun 4 05:38:55 2012 From: mhuff at ox.com (Matthew Huff) Date: Mon, 4 Jun 2012 06:38:55 -0400 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> Message-ID: <483E6B0272B0284BA86D7596C40D29F901928BC8AB18@PUR-EXCH07.ox.com> >> An L2 device should not be fragmenting L3 packets. Layer 2 fragmentation used (20+ years ago) to be a common thing with bridged topologies like token-ring to Ethernet source-routing. Obviously, no so much anymore (at least I hope not), but it can and does happen. I think part of the problem is that ISPs, CDN, hosting companies, etc. have assumed IPv6 is just IPv4 with longer addresses and haven't spent the time learning the differences like what was pointed out that ICMPv6 is a required protocol for IPv6 to work correctly. MTU issues are an annoyance with IPv4 but are a brokenness with IPv6. Knowledge with come, but it may take a bit of beating over the head for a while. From stefan at nordu.net Mon Jun 4 05:46:36 2012 From: stefan at nordu.net (=?ISO-8859-1?Q?Stefan_Listr=F6m?=) Date: Mon, 04 Jun 2012 12:46:36 +0200 Subject: NOC presentations Message-ID: <4FCC920C.3070805@nordu.net> Hi all, In TF-NOC we have been collecting information about NOCs for some time now[1]. Most of the NOCs are from research and educational organizations and we think it would also be very interesting to get the same kind of information from commercial NOCs. I understand that many commercial companies might not be able to share this information, but I thought it might be worth asking. If you would like to share information about your NOC please check out our presentation template[2] for inspiration and let me know. Even if you are not able to share information about your NOC the information we have gathered will hopefully still be interesting for you. [1] http://www.terena.org/activities/tf-noc/nocs.html [2] http://www.terena.org/activities/tf-noc/TF-NOC-flashpresentation-v2.ppt -- Best regards Stefan Listr?m From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 08:36:10 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 04 Jun 2012 22:36:10 +0900 Subject: IPv6 day and tunnels In-Reply-To: <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> Message-ID: <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> Jeroen Massar wrote: >>> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? >> >> Completely wrongly. > > Got a better solution? ;) IPv4 without PMTUD, of course. >> Because IPv6 requires ICMP packet too big generated against >> multicast, it is designed to cause ICMP implosions, which >> means ISPs must filter ICMP packet too big at least against >> multicast packets and, as distinguishing them from unicast >> ones is not very easy, often against unicast ones. > > I do not see the problem that you are seeing, to adress the two > issues in your slides: > - for multicast just set your max packetsize to 1280, no > need for pmtu and thus this "implosion" It is a sender of a multicast packet, not you as some ISP, who set max packet size to 1280B or 1500B. You can do nothing against a sender who consciously (not necessarily maliciously) set it to 1500B. The only protection is not to generate packet too big and to block packet too big at least against multicast packets. If you don't want to inspect packets so deeply (beyond first 64B, for example), packet too big against unicast packets are also blocked. That you don't enable multicast in your network does not mean you have nothing to do with packet too big against multicast, because you may be on a path of returning ICMPs. That is, you should still block them. > You think might happen. The sender controls the packetsize > anyway and one does not want > to frag packets for multicast thus 1280 solves all of it. That's what I said in IETF IPv6 WG more than 10 years ago, but all the other WG members insisted on having multicast PMTUD, ignoring the so obvious problem of packet implosions. Thus, RFC2463 requires: Sending a Packet Too Big Message makes an exception to one of the rules of when to send an ICMPv6 error message, in that unlike other messages, it is sent in response to a packet ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ received with an IPv6 multicast destination address, or a linklayer ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ multicast or link-layer broadcast address. They have not yet obsoleted the feature. So, you should assume some, if not all, of them still insist on using multicast PMTUD to make multicast packet size larger than 1280B. In addition, there should be malicious guys. > - when doing IPv6 inside IPv6 the outer path has to be > 1280+tunneloverhead, if it is not then Because PMTUD is not expected to work, you must assume MTU of outer path is 1280B, as is specified "simply restrict itself to sending packets no larger than 1280 octets" in RFC2460. > you need to use a tunneling protocol that knows how to > frag and reassemble as is acting as a > medium with an mtu less than the minimum of 1280 That's my point in my second last slide. Considering that many inner packet will be just 1280B long, many packets will be fragmented, as a result of stupid attempt to make multicast PMTUD work, unless you violate RFC2460 to blindly send packets a little larger than 1280B. Masataka Ohta From jfesler at yahoo-inc.com Mon Jun 4 08:50:58 2012 From: jfesler at yahoo-inc.com (Jason Fesler) Date: Mon, 4 Jun 2012 06:50:58 -0700 Subject: test-ipv6.com / omgipv6day.com down Message-ID: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> I know a lot of people are using / pointing to test-ipv6.com . The hardware picked a bad week to quit sniffing glue. I"ll be working on trying to get it back up today, I need to source hardware. Also looking at borrowing a VM for short term. (speaking only for @test-ipv6.com, not for $employer - my personal mail address is down too). From jeroen at unfix.org Mon Jun 4 09:07:52 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 4 Jun 2012 07:07:52 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> Message-ID: <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> On 4 Jun 2012, at 06:36, Masataka Ohta wrote: > Jeroen Massar wrote: > >>>> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? >>> >>> Completely wrongly. >> >> Got a better solution? ;) > > IPv4 without PMTUD, of course. We are (afaik) discussing IPv6 in this thread, I assume you typo'd here ;) >>> Because IPv6 requires ICMP packet too big generated against >>> multicast, it is designed to cause ICMP implosions, which >>> means ISPs must filter ICMP packet too big at least against >>> multicast packets and, as distinguishing them from unicast >>> ones is not very easy, often against unicast ones. >> >> I do not see the problem that you are seeing, to adress the two >> issues in your slides: >> - for multicast just set your max packetsize to 1280, no >> need for pmtu and thus this "implosion" > > It is a sender of a multicast packet, not you as some ISP, > who set max packet size to 1280B or 1500B. If a customer already miraculously has the rare capability of sending multicast packets in the rare case that a network is multicast enabled then they will also have been told to use a max packet size of 1280 to avoid any issues when it is expected that some endpoint might have that max MTU. I really cannot see the problem with this as multicast networks tend to be rare and very much closed. Heck, for that matter the m6bone is currently pretty much in a dead state for quite a while already.... :( > You can do nothing against a sender who consciously (not > necessarily maliciously) set it to 1500B. Of course you can, the first hop into your network can generate a single PtB and presto the issue becomes a problem of the sender. As the sender's intention is likely to reach folks they will adhere to that advice too instead of just sending packets which get rejected at the first hop. > The only protection is not to generate packet too big and > to block packet too big at least against multicast packets. No need, as above, reject and send PtB and all is fine. > If you don't want to inspect packets so deeply (beyond first > 64B, for example), packet too big against unicast packets > are also blocked. Routing (forwarding packets) is in no way "expection". > That you don't enable multicast in your network does not > mean you have nothing to do with packet too big against > multicast, because you may be on a path of returning ICMPs. > That is, you should still block them. Blocking returning ICMPv6 PtB where you are looking at the original packet which is echod inside the data of the ICMPv6 packet would indeed require one to look quite deep, but if one is so determined to firewall them well, then you would have to indeed. I do not see a reason to do so though. Please note that the src/dst of the packet itself is unicast even if the PtB will be for a multicast packet. I guess one should not be so scared of ICMP, there are easier ways to overload a network. Proper BCP38 goes a long way. >> You think might happen. The sender controls the packetsize >> anyway and one does not want >> to frag packets for multicast thus 1280 solves all of it. > > That's what I said in IETF IPv6 WG more than 10 years ago, but > all the other WG members insisted on having multicast PMTUD, > ignoring the so obvious problem of packet implosions. They did not ignore you, they realized that not everybody has the same requirements. With the current spec you can go your way and break pMTU requiring manual 1280 settings, while other networks can use pMTU in their networks. Everbody wins. > So, you should assume some, if not all, of them still insist > on using multicast PMTUD to make multicast packet size larger > than 1280B. As networks become more and more jumbo frame enabled, what exactly is the problem with this? > In addition, there should be malicious guys. > >> - when doing IPv6 inside IPv6 the outer path has to be >> 1280+tunneloverhead, if it is not then > > Because PMTUD is not expected to work, You assume it does not work, but as long as per the spec people do not filter it, it works. > you must assume MTU > of outer path is 1280B, as is specified "simply restrict > itself to sending packets no larger than 1280 octets" in > RFC2460. While for multicast enabled networks that might hit the minimum MTU this might be true-ish, it does not make it universally true. >> you need to use a tunneling protocol that knows how to >> frag and reassemble as is acting as a >> medium with an mtu less than the minimum of 1280 > > That's my point in my second last slide. Then you word it wrongly. It is not the problem of IPv6 that you chose to layer it inside so many stacks that the underlying medium cannot transport packets bigger as 1280, that medium has to take care of it. > Considering that many inner packet will be just 1280B long, > many packets will be fragmented, as a result of stupid attempt > to make multicast PMTUD work, unless you violate RFC2460 > to blindly send packets a little larger than 1280B. Your statement only works when: - you chose a medium unable to send packets with a minimum of 1280 Which thus makes the medium IPv6 incapable, the mediums issue to frag - someone filters ICMP PtB even though one should not - when in the rare case with the above someone actually uses interdomain multicast I hope you see how much of a non-issue this thus is. Please fix your network instead, kthx. Greets, Jeroen From jeroen at unfix.org Mon Jun 4 09:09:35 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 4 Jun 2012 07:09:35 -0700 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> Message-ID: <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> On 4 Jun 2012, at 06:50, Jason Fesler wrote: > I know a lot of people are using / pointing to test-ipv6.com . The hardware picked a bad week to quit sniffing glue. You got a bunch of mirrors for it right? Should not be to tricky to get someone to let their act as the real thing for a bit. Greets, Jeroen From jmaslak at antelope.net Mon Jun 4 09:16:32 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Mon, 4 Jun 2012 08:16:32 -0600 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> Message-ID: <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> On Jun 4, 2012, at 1:01 AM, Owen DeLong wrote: > Any firewall/security device manufacturer that says it is will not get any > business from me (or anyone else who considers their requirements > properly before purchasing). Unfortunately many technology people seem to have the idea, "If I don't understand it, it's a hacker" when it comes to network traffic. And often they don't understand ICMP (or at least PMTU). So anything not understood gets blocked. Then there is the Law of HTTP... The Law of HTTP is pretty simple: Anything that isn't required for *ALL* HTTP connections on day one of protocol implementation will never be able to be used universally. This includes, sadly, PMTU. If reaching all possible endpoints is important to your application, you better do it via HTTP and better not require PMTU. It's also why protocols typically can't be extended today at any layer other than the "HTTP" layer. As for the IETF trying to not have people reset DF...good luck with that one...besides, I think there is more broken ICMP handling than there are paths that would allow a segment to bounce around for 120 seconds... From jared at puck.nether.net Mon Jun 4 09:31:28 2012 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 4 Jun 2012 10:31:28 -0400 Subject: IPv6 day and tunnels In-Reply-To: <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> Message-ID: <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> On Jun 4, 2012, at 10:07 AM, Jeroen Massar wrote: > On 4 Jun 2012, at 06:36, Masataka Ohta wrote: > >> Jeroen Massar wrote: >> >>>>> So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? >>>> >>>> Completely wrongly. >>> >>> Got a better solution? ;) >> >> IPv4 without PMTUD, of course. > > We are (afaik) discussing IPv6 in this thread, I assume you typo'd here ;) He is comparing & contrasting with the behavior of IPv4 v IPv6. If your PMTU is broken for v4 because people do wholesale blocks of ICMP, there is a chance they will have the same problem with wholesale blocks of ICMPv6 packets. The interesting thing about IPv6 is it's "just close enough" to IPv4 in many ways that people don't realize all the technical details. People are still getting it wrong with IPv4 today, they will repeat their same mistakes in IPv6 as well. - I've observed that if you avoid providers that rely upon tunnels, you can sometimes observe significant performance improvements in IPv6 nitrates. Those that are tunneling are likely to take a software path at one end, whereas native (or native-like/6PE) tends to not see this behavior. Those doing native tend to have more experience debugging it as well as they already committed business resources to it. - Jared From Fred.L.Templin at boeing.com Mon Jun 4 09:39:58 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 4 Jun 2012 07:39:58 -0700 Subject: IPv6 day and tunnels In-Reply-To: <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> Message-ID: Hi, There was quite a bit discussion on IPv6 PMTUD on the v6ops list within the past couple of weeks. Studies have shown that PTB messages can be dropped due to filtering even for ICMPv6. There was also concern for the one (or more) RTTs required for PMTUD to work, and for dealing with bogus PTB messages. The concerns were explicitly linked to IPv6 tunnels, so I drafted a proposed solution: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ In this proposal the tunnel ingress performs the following treatment of packets of various sizes: 1) For IPv6 packets no larger than 1280, admit the packet into the tunnel w/o fragmentation. Assumption is that all IPv6 links have to support a 1280 MinMTU, so the packet will get through. 2) For IPv6 packets larger than 1500, admit the packet into the tunnel w/o fragmentation. Assumption is that the sender would only send a 1501+ packet if it has some way of policing the PMTU on its own, e.g. through the use of RC4821. 3) For IPv6 packets between 1281-1500, break the packet into two (roughly) equal-sized pieces and admit each piece into the tunnel. (In other words, intentionally violate the IPv6 deprecation of router fragmentation.) Assumption is that the final destination can reassemble at least 1500, and that the 32-bit Identification value inserted by the tunnel provides sufficient assurance against reassembly mis-associations. I presume no one here would object to clauses 1) and 2). Clause 3) is obviously a bit more controversial - but, what harm would it cause from an operational standpoint? Thanks - Fred fred.l.templin at boeing.com From jmaimon at ttec.com Mon Jun 4 10:09:27 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 04 Jun 2012 11:09:27 -0400 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> Message-ID: <4FCCCFA7.5070709@ttec.com> Owen DeLong wrote: > > There should be no such thing as packet fragmentation in the current > protocol. What is needed is for people to simply configure things > correctly and allow PTB messages to pass as designed. > > Owen You are absolutely correct. Are you talking about IPv4 or IPv6? Joe From jfesler at yahoo-inc.com Mon Jun 4 10:13:17 2012 From: jfesler at yahoo-inc.com (Jason Fesler) Date: Mon, 4 Jun 2012 08:13:17 -0700 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> Message-ID: <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> On Jun 4, 2012, at 7:09 AM, Jeroen Massar wrote: > You got a bunch of mirrors for it right? Should not be to tricky to get someone to let their act as the real thing for a bit. I've got redirects up now to spread the load across VMs. For the next couple of days, I don't expect a single VM to handle the load. Thanks to all who've sent me a response; and thanks to Host Virtual and to Network Design GmbH, for taking the immediate load. Once we're stable, and I get my *official* day job requirements met for World IPV6 Launch, I"ll come back to getting the original gear replaced. I've got a couple hardware offers in (Alex, Mark, thank you), and this might just be the reason to flat out refresh the hardware if ixSystems has something suitable already built. -jason From jra at baylink.com Mon Jun 4 10:15:50 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Jun 2012 11:15:50 -0400 (EDT) Subject: WaPo: SHODAN search engine exposes insecure SCADA Message-ID: <8205966.7504.1338822950068.JavaMail.root@benjamin.baylink.com> ... among other things. http://www.washingtonpost.com/investigations/cyber-search-engine-exposes-vulnerabilities/2012/06/03/gJQAIK9KCV_story.html If the gov is worried about 'cyber'-attacks on critical infrastructure, at least now we know what tool they can use to find the low hanging fruit. As I asked once before (:-), any black-sunglasses types hanging around? Don't answer; just go to work. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jeroen at unfix.org Mon Jun 4 10:26:37 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Jun 2012 08:26:37 -0700 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> Message-ID: <4FCCD3AD.5000104@unfix.org> On 2012-06-04 08:13, Jason Fesler wrote: > > On Jun 4, 2012, at 7:09 AM, Jeroen Massar wrote: > >> You got a bunch of mirrors for it right? Should not be to tricky to >> get someone to let their act as the real thing for a bit. > > I've got redirects up now to spread the load across VMs. For the > next couple of days, I don't expect a single VM to handle the load. I am actually not expecting that much of the hype to come out, just like last year it will easily be forgotten unless somebody is able to spin that PR engine really really really hard. > Thanks to all who've sent me a response; and thanks to Host Virtual > and to Network Design GmbH, for taking the immediate load. > > Once we're stable, and I get my *official* day job requirements met > for World IPV6 Launch, I"ll come back to getting the original gear > replaced. I've got a couple hardware offers in (Alex, Mark, thank > you), and this might just be the reason to flat out refresh the > hardware if ixSystems has something suitable already built. Awesome! Greets, Jeroen From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 10:34:34 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Jun 2012 00:34:34 +0900 Subject: IPv6 day and tunnels In-Reply-To: <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> Message-ID: <4FCCD58A.4040801@necom830.hpcl.titech.ac.jp> Jeroen Massar wrote: >> IPv4 without PMTUD, of course. > > We are (afaik) discussing IPv6 in this thread, That's your problem of insisting on very narrow solution space, which is why you can find no solution and are trying to ignore the problem. >> It is a sender of a multicast packet, not you as some ISP, >> who set max packet size to 1280B or 1500B. > > If a customer already miraculously has the rare capability > of sending multicast packets in the rare case that a > network is multicast enabled That is the case IPv6 WG insisted on. > then they will also have been told to use a max packet size > of 1280 to avoid any issues when it is expected that some > endpoint might have that max MTU. Those who insisted on the case won't tell so nor do so. > I really cannot see the problem with this because you insist on IPv6. >> You can do nothing against a sender who consciously (not >> necessarily maliciously) set it to 1500B. > > Of course you can, the first hop into your network can > generate a single PtB I can, but I can't expect others will do so. I, instead, know those who insisted on the case won't. > No need, as above, reject and send PtB and all is fine. As I wrote: >> That you don't enable multicast in your network does not >> mean you have nothing to do with packet too big against >> multicast, because you may be on a path of returning ICMPs. >> That is, you should still block them. you are wrong. >> If you don't want to inspect packets so deeply (beyond first >> 64B, for example), packet too big against unicast packets >> are also blocked. > > Routing (forwarding packets) is in no way "expection". What? > Blocking returning ICMPv6 PtB where you are looking at the > original packet which is echod inside the data of the > ICMPv6 packet would indeed require one to look quite deep, > but if one is so determined to firewall them well, then > you would have to indeed. As I already filter packets required by RFC2463, why, do you think, do I have to bother only to reduce performance? > I do not see a reason to do so though. Please note that the > src/dst of the packet itself is unicast even if the PtB > will be for a multicast packet. How can you ignore the implosion of unicast ICMP? > They did not ignore you, they realized that not everybody > has the same requirements. With the current spec you can > go your way and break pMTU requiring manual 1280 settings, > while other networks can use pMTU in their networks.Everbody wins. What? Their networks? The Internet is interconnected. >> So, you should assume some, if not all, of them still insist >> on using multicast PMTUD to make multicast packet size larger >> than 1280B. > > As networks become more and more jumbo frame enabled, > what exactly is the problem with this? That makes things worse. It will promote people try to multicast with jumbo frames. >> Because PMTUD is not expected to work, > > You assume it does not work, but as long as per the spec > people do not filter it, it works. Such operation leaves network vulnerable and should be corrected. >> you must assume MTU >> of outer path is 1280B, as is specified "simply restrict >> itself to sending packets no larger than 1280 octets" in >> RFC2460. > > While for multicast enabled networks that might hit the > minimum MTU this might be true-ish, it does not make > it universally true. The Internet is interconnected. >>> you need to use a tunneling protocol that knows how to >>> frag and reassemble as is acting as a >>> medium with an mtu less than the minimum of 1280 >> >> That's my point in my second last slide. > > Then you word it wrongly. It is not the problem of IPv6 You should read RFC2473, an example in my slide. > Please fix your network instead, kthx. It is a problem of RFC2463 and networks of people who insist on the current RFC2463 for multicast PMTUD. If you want the problem disappear, change RFC2463. Masataka Ohta From rbf+nanog at panix.com Mon Jun 4 11:35:03 2012 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Mon, 4 Jun 2012 11:35:03 -0500 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> Message-ID: <20120604163503.GA28331@panix.com> On Mon, Jun 04, 2012 at 07:39:58AM -0700, Templin, Fred L wrote: > > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > > 3) For IPv6 packets between 1281-1500, break the packet > into two (roughly) equal-sized pieces and admit each > piece into the tunnel. (In other words, intentionally > violate the IPv6 deprecation of router fragmentation.) > Assumption is that the final destination can reassemble > at least 1500, and that the 32-bit Identification value > inserted by the tunnel provides sufficient assurance > against reassembly mis-associations. Fragmenting the outer packet, rather than the inner packet, gets around the problem of router fragmentation of packets. The outer packet is a new packet and there's nothing wrong with the originator of that packet fragmenting it. Of course, that forces reassembly on the other tunnel endpoint, rather than on the ultimate end system, which might be problematic with some endpoints and traffic volumes. (With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte MTU on the tunnel, fragment the outer packet, let the other end of the tunnel do the reassembly. Not providing 1500 byte end-to-end (at least with in the network I control) for IPv4 has proven to consume lots of troubleshooting time; fragmenting the inner packet doesn't work unless you ignore the DF bit that is typically set by TCP endpoints who want to do PMTU discovery.) > I presume no one here would object to clauses 1) and 2). > Clause 3) is obviously a bit more controversial - but, > what harm would it cause from an operational standpoint? -- Brett From Fred.L.Templin at boeing.com Mon Jun 4 12:19:01 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 4 Jun 2012 10:19:01 -0700 Subject: IPv6 day and tunnels In-Reply-To: <20120604163503.GA28331@panix.com> References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> Message-ID: Hi Brett, > -----Original Message----- > From: Brett Frankenberger [mailto:rbf+nanog at panix.com] > Sent: Monday, June 04, 2012 9:35 AM > To: Templin, Fred L > Cc: nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > On Mon, Jun 04, 2012 at 07:39:58AM -0700, Templin, Fred L wrote: > > > > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > > > > 3) For IPv6 packets between 1281-1500, break the packet > > into two (roughly) equal-sized pieces and admit each > > piece into the tunnel. (In other words, intentionally > > violate the IPv6 deprecation of router fragmentation.) > > Assumption is that the final destination can reassemble > > at least 1500, and that the 32-bit Identification value > > inserted by the tunnel provides sufficient assurance > > against reassembly mis-associations. > > Fragmenting the outer packet, rather than the inner packet, gets around > the problem of router fragmentation of packets. The outer packet is a > new packet and there's nothing wrong with the originator of that packet > fragmenting it. > > Of course, that forces reassembly on the other tunnel endpoint, rather > than on the ultimate end system, which might be problematic with some > endpoints and traffic volumes. There are a number of issues with fragmenting the outer packet. First, as you say, fragmenting the outer packet requires the tunnel egress to perform reassembly. This may be difficult for tunnel egresses that are configured on core routers. Also, when IPv4 is used as the outer encapsulation layer, the 16-bit ID field can result in reassembly errors at high data rates [RFC4963]. Additionally, encapsulating a 1500 inner packet in an outer IP header results in a 1500+ outer packet - and the ingress has no way of knowing whether the egress is capable of reassembling larger than 1500. > (With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte > MTU on the tunnel, fragment the outer packet, let the other end of the > tunnel do the reassembly. Not providing 1500 byte end-to-end (at least > with in the network I control) for IPv4 has proven to consume lots of > troubleshooting time; fragmenting the inner packet doesn't work unless > you ignore the DF bit that is typically set by TCP endpoints who want > to do PMTU discovery.) Ignoring the (explicit) DF bit for IPv4 and ignoring the (implicit) DF bit for IPv6 is what I am suggesting. Thanks - Fred fred.l.templin at boeing.com > > I presume no one here would object to clauses 1) and 2). > > Clause 3) is obviously a bit more controversial - but, > > what harm would it cause from an operational standpoint? > > -- Brett From cb.list6 at gmail.com Mon Jun 4 12:26:15 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 4 Jun 2012 10:26:15 -0700 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> Message-ID: On Sun, Jun 3, 2012 at 11:20 PM, Jimmy Hess wrote: > On 6/3/12, Jeroen Massar wrote: >> If one is so stupid to just block ICMP then one should also accept that one >> loses functionality. > ICMP tends to get blocked by firewalls by default; There are > legitimate reasons to block ICMP, esp w V6. ? Security device > manufacturers tend to indicate all the ?"lost functionality" ?is > optional functionality ?not required for a working device. > In case security policy folks need a reference on what ICMPv6 functionality is required for IPv6 to work correctly, please reference http://www.ietf.org/rfc/rfc4890.txt CB From mehmet at akcin.net Mon Jun 4 12:37:10 2012 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 4 Jun 2012 10:37:10 -0700 Subject: Questions about anycasting setup In-Reply-To: <3C5E8697-8AFD-4A4B-9A4F-4AD48BE71F52@pch.net> References: <20120309081131.GC17726@h.detebe.org> <4F59C701.3090503@altadena.net> <2763367C-26BA-4330-812E-C5898E154D14@gibbard.org> <20120312082532.GD17726@h.detebe.org> <3C5E8697-8AFD-4A4B-9A4F-4AD48BE71F52@pch.net> Message-ID: <64E37D5B-33A8-43C7-A4CE-65151194FF84@akcin.net> On Jun 3, 2012, at 2:11 PM, Bill Woodcock wrote: > On Jun 3, 2012, at 12:35 PM, Anurag Bhatia wrote: >> I tried doing anycasting with 3 nodes, and seems like it didn't worked well >> at all. It seems like ISPs prefer their own or their customer route (which >> is our transit provider) and there is almost no "short/local route" effect. > > Correct. That's why you need to use the same transit providers at each location. It could be a nightmare to try to balance the traffic when you are using different providers. You can go ahead and try using path prepending but you will always find some strangeness going on regardless. As Bill mentioned using the same transit will help, especially if you use a transit provider that has some communities pre-defined which will allow you to automatically advertise or not (even geographically) , and path prepend by simply sending communities out , you will save lots of time. Mehmet From jon at smugmug.com Mon Jun 4 13:36:41 2012 From: jon at smugmug.com (jon Heise) Date: Mon, 4 Jun 2012 11:36:41 -0700 Subject: bgp best practice question Message-ID: <8E5EF620-F0CF-4288-9179-74D26AC5896F@smugmug.com> I need to make one of our data centers internet accessible, i plan to advertise a /24 out of our existing /22 network block at our new site. My question is for our main datacenter, is it a better idea to continue to advertise the full /22 or advertise the remaining /23 and /24 networks ? - Jon Heise From brunner at nic-naa.net Mon Jun 4 13:49:37 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 04 Jun 2012 14:49:37 -0400 Subject: Wacky Weekend: The '.secure' gTLD In-Reply-To: <1963017dea9e4841b7a83fb3cb3c9f86@mail.dessus.com> References: <1963017dea9e4841b7a83fb3cb3c9f86@mail.dessus.com> Message-ID: <4FCD0341.3040108@nic-naa.net> On 6/4/12 12:30 AM, Keith Medcalf wrote: > The greatest advantage of .SECURE is that it will help ensure that all the high-value targets are easy to find. one of the rationalizations for imposing a dnssec mandatory to implement requirement (by icann staff driven by dnssec evangelists) is that all slds are benefit equally from the semantic. restated, the value of protecting some bank.tld is indistinguishable from protecting some junk.tld. re-restated, no new tlds will offer no economic, or political, incentives to attack mitigated by dnssec. i differed from staff-and-dnssec-evangelists, and obviously lost. see also all possible locations for registries already have native v6, or can tunnel via avian carrier, another staff driven by ipv6 evangelists, who couldn't defer the v6 mandatory to implement requirement until availability was no longer hypothetical, or scheduled, for which difference again availed naught. as a marketing message, sld use of .secure as a tld may be sufficient to ensure that a sufficient density of high-value targets are indeed slds of that tld. staff has not discovered a stability and security requirement which is contra-indicated by such a common fate / point of failure. note also that the requirements for new tlds are significantly greater than for the existing set, so whatever the .com operator does, it is not driven by the contract compliance regime which contains either the dnssec or v6 manditory upon delegation bogies. -e p.s. the usual -sec and -6 evangelicals can ... assert their inerrant correctness as a matter of faith -- faith based policy seems to be the norm. From cgrundemann at gmail.com Mon Jun 4 13:55:01 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 4 Jun 2012 12:55:01 -0600 Subject: bgp best practice question In-Reply-To: <8E5EF620-F0CF-4288-9179-74D26AC5896F@smugmug.com> References: <8E5EF620-F0CF-4288-9179-74D26AC5896F@smugmug.com> Message-ID: Depends on a few things, but the main questions are probably: Are the data-centers connected on the backside (VPN, etc. - could the new dc failover through the main dc)? Yes - /22 Will that /24 ever be used in the main datacenter? Yes - /22 $0.02 ~Chris On Mon, Jun 4, 2012 at 12:36 PM, jon Heise wrote: > I need to make one of our data centers internet accessible, i plan to advertise a /24 out of our existing /22 network block at our new site. My question is for our main datacenter, is it a better idea to continue to advertise the full /22 or advertise the remaining /23 and /24 networks ? > > - Jon Heise -- @ChrisGrundemann http://chrisgrundemann.com From EWieling at nyigc.com Mon Jun 4 13:58:16 2012 From: EWieling at nyigc.com (Eric Wieling) Date: Mon, 4 Jun 2012 14:58:16 -0400 Subject: Cat Humor Message-ID: I'm not looking for help, just thought this was hilarious. "Mark called in from XO he stated a tech was on site and found out that client used a CAT 6 cable instead of a CAT 5 cable and XO doesn't have a "connecting piece" for the CAT 6 cable. he stated if client gets a wire/cable guy out there to fix issue, XO can send out a tech to make sure they hook up everything correctly." From saku at ytti.fi Mon Jun 4 14:02:34 2012 From: saku at ytti.fi (Saku Ytti) Date: Mon, 4 Jun 2012 22:02:34 +0300 Subject: bgp best practice question In-Reply-To: <8E5EF620-F0CF-4288-9179-74D26AC5896F@smugmug.com> References: <8E5EF620-F0CF-4288-9179-74D26AC5896F@smugmug.com> Message-ID: <20120604190234.GA6275@pob.ytti.fi> On (2012-06-04 11:36 -0700), jon Heise wrote: > I need to make one of our data centers internet accessible, i plan to advertise a /24 out of our existing /22 network block at our new site. My question is for our main datacenter, is it a better idea to continue to advertise the full /22 or advertise the remaining /23 and /24 networks ? 22 + 24. 23+24+24 makes no sense. There is no reason to fear getting extra traffic, as traffic will plummet once hosts stop responding. -- ++ytti From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 14:05:55 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Jun 2012 04:05:55 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> Message-ID: <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: > Also, when > IPv4 is used as the outer encapsulation layer, the 16-bit ID > field can result in reassembly errors at high data rates > [RFC4963]. As your proposal, too, gives up to have unique IDs, does that matter? Note that, with your draft, a route change between two tunnels with same C may cause block corruption. > Additionally, encapsulating a 1500 inner packet in > an outer IP header results in a 1500+ outer packet - and the > ingress has no way of knowing whether the egress is capable > of reassembling larger than 1500. Operators are responsible to have tunnel end points with sufficient capabilities. > >> (With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte >> MTU on the tunnel, fragment the outer packet, let the other end of the >> tunnel do the reassembly. Not providing 1500 byte end-to-end (at least >> with in the network I control) for IPv4 has proven to consume lots of >> troubleshooting time; fragmenting the inner packet doesn't work unless >> you ignore the DF bit that is typically set by TCP endpoints who want >> to do PMTU discovery.) > > Ignoring the (explicit) DF bit for IPv4 and ignoring the > (implicit) DF bit for IPv6 is what I am suggesting. > > Thanks - Fred > fred.l.templin at boeing.com > >>> I presume no one here would object to clauses 1) and 2). >>> Clause 3) is obviously a bit more controversial - but, >>> what harm would it cause from an operational standpoint? >> >> -- Brett > > > From Fred.L.Templin at boeing.com Mon Jun 4 14:26:04 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 4 Jun 2012 12:26:04 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Monday, June 04, 2012 12:06 PM > To: nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > > Also, when > > IPv4 is used as the outer encapsulation layer, the 16-bit ID > > field can result in reassembly errors at high data rates > > [RFC4963]. > > As your proposal, too, gives up to have unique IDs, does that > matter? This is taken care of by rate limiting at the tunnel ingress. For IPv4-in-(foo) tunnels, rate limit is 11Mbps which may be a bit limiting for some applications. For IPv6-in-(foo) tunnels, rate limit is 733Gbps which should be acceptable for most applications. > Note that, with your draft, a route change between two > tunnels with same C may cause block corruption. There are several built-in mitigations for this. First, the tunnel ingress does not assign Identification values sequentially but rather "skips around" to avoid synchronizing with some other node that is sending fragments to the same (src,dst) pair. Secondly, the ingress chooses random fragment sizes for the A and B portions of the packet so that the A portion of packet 1 does not match up properly with the B portion of packet 2 and hence will be dropped. Finally, even if the A portion of packet 1 somehow matches up with the B portion of packet 2 the Internet checksum provides an additional line of defense. > > Additionally, encapsulating a 1500 inner packet in > > an outer IP header results in a 1500+ outer packet - and the > > ingress has no way of knowing whether the egress is capable > > of reassembling larger than 1500. > > Operators are responsible to have tunnel end points with > sufficient capabilities. It is recommended that IPv4 nodes be able to reassemble as much as their connected interface MTUs. In the vast majority of cases that means that the nodes should be able to reassemble 1500. But, there is no assurance of anything more! Thanks - Fred fred.l.templin at boeing.com > >> (With IPv4 in IPv4 tunnels, this is what I've always done. 1500 byte > >> MTU on the tunnel, fragment the outer packet, let the other end of the > >> tunnel do the reassembly. Not providing 1500 byte end-to-end (at least > >> with in the network I control) for IPv4 has proven to consume lots of > >> troubleshooting time; fragmenting the inner packet doesn't work unless > >> you ignore the DF bit that is typically set by TCP endpoints who want > >> to do PMTU discovery.) > > > > Ignoring the (explicit) DF bit for IPv4 and ignoring the > > (implicit) DF bit for IPv6 is what I am suggesting. > > > > Thanks - Fred > > fred.l.templin at boeing.com > > > >>> I presume no one here would object to clauses 1) and 2). > >>> Clause 3) is obviously a bit more controversial - but, > >>> what harm would it cause from an operational standpoint? > >> > >> -- Brett > > > > > > > From asullivan at dyn.com Mon Jun 4 14:28:10 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Mon, 4 Jun 2012 15:28:10 -0400 Subject: Wacky Weekend: The '.secure' gTLD In-Reply-To: <4FCD0341.3040108@nic-naa.net> References: <1963017dea9e4841b7a83fb3cb3c9f86@mail.dessus.com> <4FCD0341.3040108@nic-naa.net> Message-ID: <20120604192809.GL614@dyn.com> On Mon, Jun 04, 2012 at 02:49:37PM -0400, Eric Brunner-Williams wrote: > > one of the rationalizations for imposing a dnssec mandatory to > implement requirement (by icann staff driven by dnssec evangelists) is Well, I note that at least the .secure promoters haven't decided it's a good idea: ; <<>> DiG 9.7.3-P3 <<>> @NS15.IXWEBHOSTING.COM -t DNSKEY dot-secure.co +dnssec +norec +noall +comment ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27872 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 Best, A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 15:07:50 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Jun 2012 05:07:50 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> Message-ID: <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: >> As your proposal, too, gives up to have unique IDs, does that >> matter? > > This is taken care of by rate limiting at the tunnel No, I'm talking about: Note that a possible conflict exists when IP fragmentation has already been performed by a source host before the fragments arrive at the tunnel ingress. >> Note that, with your draft, a route change between two >> tunnels with same C may cause block corruption. > > There are several built-in mitigations for this. First, > the tunnel ingress does not assign Identification values > sequentially but rather "skips around" to avoid synchronizing > with some other node that is sending fragments to the same I'm talking about two tunnels with same "skip" value. > Secondly, the ingress chooses random fragment > sizes for the A and B portions of the packet so that the A > portion of packet 1 does not match up properly with the B > portion of packet 2 and hence will be dropped. You can do so with outer fragment, too. Moreover, it does not have to be random but regular, which effectively extend ID length. > Finally, even > if the A portion of packet 1 somehow matches up with the B > portion of packet 2 the Internet checksum provides an > additional line of defense. Thus, don't insist on having unique IDs so much. > It is recommended that IPv4 nodes be able to reassemble > as much as their connected interface MTUs. In the vast > majority of cases that means that the nodes should be > able to reassemble 1500. But, there is no assurance > of anything more! I'm talking about not protocol recommendation but proper operation. Masataka Ohta From brunner at nic-naa.net Mon Jun 4 15:21:08 2012 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 04 Jun 2012 16:21:08 -0400 Subject: Wacky Weekend: The '.secure' gTLD In-Reply-To: <20120604192809.GL614@dyn.com> References: <1963017dea9e4841b7a83fb3cb3c9f86@mail.dessus.com> <4FCD0341.3040108@nic-naa.net> <20120604192809.GL614@dyn.com> Message-ID: <4FCD18B4.4020702@nic-naa.net> On 6/4/12 3:28 PM, Andrew Sullivan wrote: > Well, I note that at least the .secure promoters haven't decided it's > a good idea: the _known_ .secure-and-all-confusingly-similar-labels promoters. the reveal is weeks away, followed by the joys of contention set formation. there may be more than one .secure application, and who knows, perhaps a .sec in the bag, or a .cure, or a .seeker, or .sequre, or ... however, yeah, the requirement bites at contract / delegation time, so about a year in the future. -e From jeroen at unfix.org Mon Jun 4 15:31:15 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Jun 2012 13:31:15 -0700 Subject: IPv6 day and tunnels In-Reply-To: <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> Message-ID: <4FCD1B13.7080801@unfix.org> On 2012-06-04 07:31, Jared Mauch wrote: > > On Jun 4, 2012, at 10:07 AM, Jeroen Massar wrote: > >> On 4 Jun 2012, at 06:36, Masataka Ohta >> wrote: >> >>> Jeroen Massar wrote: >>> >>>>>> So IPv6 fixes the fragmentation and MTU issues of IPv4 by >>>>>> how exactly? >>>>> >>>>> Completely wrongly. >>>> >>>> Got a better solution? ;) >>> >>> IPv4 without PMTUD, of course. >> >> We are (afaik) discussing IPv6 in this thread, I assume you typo'd >> here ;) > > He is comparing & contrasting with the behavior of IPv4 v IPv6. > > If your PMTU is broken for v4 because people do wholesale blocks of > ICMP, there is a chance they will have the same problem with > wholesale blocks of ICMPv6 packets. Yep, people who act stupid will remain stupid... > The interesting thing about IPv6 is it's "just close enough" to IPv4 > in many ways that people don't realize all the technical details. > People are still getting it wrong with IPv4 today, they will repeat > their same mistakes in IPv6 as well. IMHO they should not have to need to know about technical details. But if one is configuring firewalls one should know what one is blocking and things might break. If one does block PtB you should realize that you are breaking connectivity in some cases and that that is your problem to resolve, not that of other peoples. There are various 'secure firewall' examples for people who are unable to think for themselves and figure out what kind of firewalling is appropriate for their environment. > I've observed that if you avoid providers that rely upon tunnels, you > can sometimes observe significant performance improvements in IPv6 > nitrates. Those that are tunneling are likely to take a software > path at one end, whereas native (or native-like/6PE) tends to not see > this behavior. Those doing native tend to have more experience > debugging it as well as they already committed business resources to > it. Tunnels therefor only should exist at the edge where native IPv6 cannot be made possible without significant investments in hardware and or other resources. Of course every tunnel should at one point in time be replaced by native where possible, thus hopefully the folks planning expenses and hardware upgrades have finally realized that they cannot get around it any more and have put this "ipv6" feature on the list for the next round of upgrades. Note that software-based tunnels can be extremely quick nowadays too, especially when given the fact that hardware can be so abundant. During tests for sixxsd v4 I've been able to stuff 10GE through it with ease, but the trick there is primarily also that we do not need to do an "expensive" full ipv6 address lookup as we know how the addresses are structured and thus instead of having to do a 128bit lookup we can restrict that to a 12 bit lookup for those tunnels, which is just a direct jump table, much cheaper than having generic silicon that needs to do it for 128bits, then again that same trick of course would be so much faster in hardware that is specifically built to apply that trick. The trick is much faster than using the software tunnels that you would normally find in eg a Linux or BSD kernel though, also because those tunnels look up tunnels based on the IPv4 address, thus the full 32-bit address space instead of using the knowledge that the 128bit one can be reduced to the 12bits that we use. The advantage of knowing one's field and being less generic ;) Greets, Jeroen From hthakkar at ucsc.edu Mon Jun 4 15:45:44 2012 From: hthakkar at ucsc.edu (Hiten J. Thakkar) Date: Mon, 04 Jun 2012 13:45:44 -0700 Subject: Recommendation for OOB management via IP Message-ID: <4FCD1E78.1040302@ucsc.edu> Hello! My work place is looking for an OOB management over IP. We have Lantronix KVM in our Datacenter with nearly 100% uptime and Lantronix SLC-8/16/48 ports with 2 NICs deployed across various MDFs on campus and remote locations (5). On our main campus we have a parallel net, but for the remote locations we are looking to access Lantronix SLCs' via the second NIC card using IP based solution. Can you kindly make suggestions. I supremely appreciate your time and inputs in advance. -- Thanks and regards, Hiten J. Thakkar From Fred.L.Templin at boeing.com Mon Jun 4 16:23:13 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 4 Jun 2012 14:23:13 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Monday, June 04, 2012 1:08 PM > To: Templin, Fred L; nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > >> As your proposal, too, gives up to have unique IDs, does that > >> matter? > > > > This is taken care of by rate limiting at the tunnel > > No, I'm talking about: > > Note that a possible conflict exists when IP fragmentation has > already been performed by a source host before the fragments arrive > at the tunnel ingress. > > >> Note that, with your draft, a route change between two > >> tunnels with same C may cause block corruption. > > > > There are several built-in mitigations for this. First, > > the tunnel ingress does not assign Identification values > > sequentially but rather "skips around" to avoid synchronizing > > with some other node that is sending fragments to the same > > I'm talking about two tunnels with same "skip" value. There are several factors to consider. First, each tunnel ingress chooses its initial Identification value (or values) randomly and independent of all other tunnel ingresses. Secondly, the packet arrival rates at the various tunnel ingresses are completely independent and in no way correlated. So, while an occasional reassembly collision is possible the 32-bit Identification value would make it extremely rare. And the variability of packet arrivals between the tunnel endpoints would make it such that a string of consecutive collisions would never happen. So, I'm not sure that a randomly-chosen "skip" value is even necessary. > > Secondly, the ingress chooses random fragment > > sizes for the A and B portions of the packet so that the A > > portion of packet 1 does not match up properly with the B > > portion of packet 2 and hence will be dropped. > > You can do so with outer fragment, too. Moreover, it does not > have to be random but regular, which effectively extend ID > length. Outer fragmentation cooks the tunnel egresses at high data rates. End systems are expected and required to reassemble on their own behalf. > > Finally, even > > if the A portion of packet 1 somehow matches up with the B > > portion of packet 2 the Internet checksum provides an > > additional line of defense. > > Thus, don't insist on having unique IDs so much. Non-overlapping fragments are disallowed for IPv6, but I think are still allowed for IPv4. So, IPv4 still needs the unique IDs by virtue of rate limiting. > > It is recommended that IPv4 nodes be able to reassemble > > as much as their connected interface MTUs. In the vast > > majority of cases that means that the nodes should be > > able to reassemble 1500. But, there is no assurance > > of anything more! > > I'm talking about not protocol recommendation but proper > operation. I don't see any operational guidance recommending the tunnel ingress to configure an MRU of 1520 or larger. Thanks - Fred fred.l.templin at boeing.com > Masataka Ohta From jmaimon at ttec.com Mon Jun 4 16:26:27 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 04 Jun 2012 17:26:27 -0400 Subject: IPv6 day and tunnels In-Reply-To: <4FCD1B13.7080801@unfix.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> Message-ID: <4FCD2803.9070206@ttec.com> Jeroen Massar wrote: > > Tunnels therefor only should exist at the edge where native IPv6 cannot > be made possible without significant investments in hardware and or > other resources. Of course every tunnel should at one point in time be > replaced by native where possible, thus hopefully the folks planning > expenses and hardware upgrades have finally realized that they cannot > get around it any more and have put this "ipv6" feature on the list for > the next round of upgrades. IPv4 is pretty mature. Are there more or less tunnels on it? Why do you think a maturing IPv6 means less tunnels as opposed to more? Does IPv6 contain elegant solutions to all the issues one would resort to tunnels with IPv4? Does successful IPv6 deployment require obsoleting tunneling? Fail. Today, most people cant even get IPv6 without tunnels. And tunnels are far from the only cause of MTU lower than what has become the only valid MTU of 1500, thanks in no small part to people who refuse to acknowledge operational reality and are quite satisfied with the state of things once they find a "them" to blame it on. I just want to know if we can expect IPv6 to devolve into 1280 standard mtu and at what gigabit rates. Joe From Fred.L.Templin at boeing.com Mon Jun 4 16:33:21 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 4 Jun 2012 14:33:21 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD2803.9070206@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> Message-ID: > I just want to know if we can expect IPv6 to devolve into 1280 standard > mtu and at what gigabit rates. The vast majority of hosts will still expect 1500, so we need to find a way to get them at least that much. Fred fred.l.templin at boeing.com From jesler at sourcefire.com Mon Jun 4 16:35:24 2012 From: jesler at sourcefire.com (Joel Esler) Date: Mon, 4 Jun 2012 17:35:24 -0400 Subject: Cat Humor In-Reply-To: References: Message-ID: <8C9F98822F794DF2A761B7C881B6092C@sourcefire.com> But a Cat 6 is one more isn't it? http://www.youtube.com/watch?v=EbVKWCpNFhY -- Joel Esler On Monday, June 4, 2012 at 2:58 PM, Eric Wieling wrote: > > I'm not looking for help, just thought this was hilarious. > > "Mark called in from XO he stated a tech was on site and found out that client used a CAT 6 cable instead of a CAT 5 cable and XO doesn't have a "connecting piece" for the CAT 6 cable. he stated if client gets a wire/cable guy out there to fix issue, XO can send out a tech to make sure they hook up everything correctly." From jeroen at unfix.org Mon Jun 4 16:47:00 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Jun 2012 14:47:00 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD2803.9070206@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> Message-ID: <4FCD2CD4.30307@unfix.org> On 2012-06-04 14:26, Joe Maimon wrote: > > > Jeroen Massar wrote: > >> >> Tunnels therefor only should exist at the edge where native IPv6 cannot >> be made possible without significant investments in hardware and or >> other resources. Of course every tunnel should at one point in time be >> replaced by native where possible, thus hopefully the folks planning >> expenses and hardware upgrades have finally realized that they cannot >> get around it any more and have put this "ipv6" feature on the list for >> the next round of upgrades. > > > IPv4 is pretty mature. Are there more or less tunnels on it? I would hazard to state that there are more IPv4 tunnels than IPv6 tunnels. This as "tunneling" is what most people simply call VPN and there are large swaths of those. > Why do you think a maturing IPv6 means less tunnels as opposed to more? More native instead of tunneling IPv6 over IPv6. Note that tunneling in this context is used for connecting locations that do not have IPv6 but have IPv4, not for connecting ala VPN networks where you need to gain access to a secured/secluded network. If people want to use a tunnel for the purpose of a VPN, then they will, be that IPv4 or IPv6 or both inside that tunnel. > Does IPv6 contain elegant solutions to all the issues one would resort > to tunnels with IPv4? Instead of having a custom VPN protocol one can do IPSEC properly now as there is no NAT that one has to get around. Microsoft's Direct Access does this btw and is an excellent example of doing it correctly. > Does successful IPv6 deployment require obsoleting tunneling? No why should it? But note that "IPv6 tunnels" (not VPNs) are a transition technique from IPv4 to IPv6 and thus should not remain around forever, the transition will end somewhere, sometime, likely far away in the future with the speed that IPv6 is being deployed ;) > Fail. > > Today, most people cant even get IPv6 without tunnels. In time that will change, that is simply transitional. > And tunnels are far from the only cause of MTU lower than what has > become the only valid MTU of 1500, thanks in no small part to people who > refuse to acknowledge operational reality and are quite satisfied with > the state of things once they find a "them" to blame it on. > > I just want to know if we can expect IPv6 to devolve into 1280 standard > mtu and at what gigabit rates. 1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept and process ICMPv6 Packet-Too-Big messages everything will just work. This whole thread is about people who cannot be bothered to know what they are filtering and that they might just randomly block PtB as they are doing with IPv4 today. Yes, in that case their network breaks if the packets are suddenly larger than a link somewhere else, that is the same as in IPv4 ;) Greets, Jeroen From Fred.L.Templin at boeing.com Mon Jun 4 16:55:10 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 4 Jun 2012 14:55:10 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD2CD4.30307@unfix.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> Message-ID: > > I just want to know if we can expect IPv6 to devolve into 1280 standard > > mtu and at what gigabit rates. > > 1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept > and process ICMPv6 Packet-Too-Big messages everything will just work. > > This whole thread is about people who cannot be bothered to know what > they are filtering and that they might just randomly block PtB as they > are doing with IPv4 today. Yes, in that case their network breaks if the > packets are suddenly larger than a link somewhere else, that is the same > as in IPv4 ;) But, it is not necessarily the person that filters the PTBs that suffers the breakage. It is the original source that may be many IP hops further down the line, who would have no way of knowing that the filtering is even happening. Thanks - Fred fred.l.templin at boeing.com > Greets, > Jeroen From jeroen at unfix.org Mon Jun 4 17:04:48 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Jun 2012 15:04:48 -0700 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> Message-ID: <4FCD3100.5030201@unfix.org> On 2012-06-04 14:55, Templin, Fred L wrote: >>> I just want to know if we can expect IPv6 to devolve into 1280 standard >>> mtu and at what gigabit rates. >> >> 1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept >> and process ICMPv6 Packet-Too-Big messages everything will just work. >> >> This whole thread is about people who cannot be bothered to know what >> they are filtering and that they might just randomly block PtB as they >> are doing with IPv4 today. Yes, in that case their network breaks if the >> packets are suddenly larger than a link somewhere else, that is the same >> as in IPv4 ;) > > But, it is not necessarily the person that filters the PTBs > that suffers the breakage. It is the original source that > may be many IP hops further down the line, who would have > no way of knowing that the filtering is even happening. It is not too tricky to figure that out actually: $ tracepath6 www.nanog.org 1?: [LOCALHOST] 0.078ms pmtu 1500 1: 2620:0:6b0:a::1 0.540ms 1: 2620:0:6b0:a::1 1.124ms 2: ge-4-35.car2.Chicago2.Level3.net 56.557ms asymm 13 3: vl-52.edge4.Chicago2.Level3.net 57.501ms asymm 13 4: 2001:1890:1fff:310:192:205:37:149 61.910ms asymm 10 5: cgcil21crs.ipv6.att.net 92.067ms asymm 12 6: sffca21crs.ipv6.att.net 94.720ms asymm 12 7: cr81.sj2ca.ip.att.net 90.068ms asymm 12 8: sj2ca401me3.ipv6.att.net 90.605ms asymm 11 9: 2001:1890:c00:3a00::11fb:8591 89.888ms asymm 12 10: no reply 11: no reply 12: no reply and you'll at least have a good guess where it happens. Not something for non-techy users, but good enough hopefully for people working in the various NOCs. Now the tricky part is where to complain to get that fixed though ;) Greets, Jeroen (tracepath6 is available on your favourite Linux, eg in the iputils-tracepath package for Debian, for the various *BSD's one can use scamper from: http://www.wand.net.nz/scamper/ ) From alex-lists-nanog at yuriev.com Mon Jun 4 17:08:47 2012 From: alex-lists-nanog at yuriev.com (alex-lists-nanog at yuriev.com) Date: Mon, 4 Jun 2012 18:08:47 -0400 Subject: Google Public DNS contact Message-ID: <20120604220847.GA16897@corp.zubrcom.net> Hello, If anyone has a contact in the Google Group that deals with Google's Public DNS servers ( i.e. the 8.8.8.8/8.8.4.4 creatures ) could that person kindly drop me an email off list? I believe there might be an issue with some of the servers. Thanks, Alex From owen at delong.com Mon Jun 4 17:08:02 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2012 15:08:02 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD2803.9070206@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> Message-ID: On Jun 4, 2012, at 2:26 PM, Joe Maimon wrote: > > > Jeroen Massar wrote: > >> >> Tunnels therefor only should exist at the edge where native IPv6 cannot >> be made possible without significant investments in hardware and or >> other resources. Of course every tunnel should at one point in time be >> replaced by native where possible, thus hopefully the folks planning >> expenses and hardware upgrades have finally realized that they cannot >> get around it any more and have put this "ipv6" feature on the list for >> the next round of upgrades. > > > IPv4 is pretty mature. Are there more or less tunnels on it? > There are dramatically fewer IPv4 tunnels than IPv6 tunnels to the best of my knowledge. > Why do you think a maturing IPv6 means less tunnels as opposed to more? > Because a maturing IPv6 eliminates many of the present day needs for IPv6 tunnels which is to span IPv4-only areas of the network when connecting IPv6 end points. > Does IPv6 contain elegant solutions to all the issues one would resort to tunnels with IPv4? Many of the issues I would resort to tunnels for involve working around NAT, so, yes, IPv6 provides a much more elegant solution -- End-to-end addressing. However, for some of the other cases, no, tunnels will remain valuable in IPv6. However, as IPv6 end-to-end native connectivity becomes more prevalent, much of the current need for IPv6 over IPv4 tunnels will become deprecated. > Does successful IPv6 deployment require obsoleting tunneling? No, it does not, but, it will naturally obsolete many of the tunnels which exist today. > Fail. > What, exactly are you saying is a failure? The single word here even in context is very ambiguous. > Today, most people cant even get IPv6 without tunnels. Anyone can get IPv6 without a tunnel if they are willing to bring a circuit to the right place. As IPv6 gets more ubiquitously deployed, the number of right places will grow and the cost of getting a circuit to one of them will thus decrease. > And tunnels are far from the only cause of MTU lower than what has become the only valid MTU of 1500, thanks in no small part to people who refuse to acknowledge operational reality and are quite satisfied with the state of things once they find a "them" to blame it on. Meh... Sour grapes really don't add anything useful to the discussion. Breaking PMTU-D is bad. People should stop doing so. Blocking PTB messages is bad in IPv4 and worse in IPv6. This has been well known for many years. If you're breaking PMTU-D, then stop that. If not, then you're not part of them. If you have a useful alternative solution to propose, put it forth and let's discuss the merits. > I just want to know if we can expect IPv6 to devolve into 1280 standard mtu and at what gigabit rates. I hope not. I hope that IPv6 will cause people to actually re-evaluate their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D allows not only 1500, but also 1280, and 9000 and >9000 octet datagrams to be possible and segments that support <1500 work almost as well as segments that support jumbo frames. Where jumbo frames offer an end-to-end advantage, that advantage can be realized. Where there is a segment with a 1280 MTU, that can also work with a relatively small performance penalty. Where PMTU-D is broken, nothing works unless the MTU end-to-end happens to coincide with the smallest MTU. For links that carry tunnels and clear traffic, life gets interesting if one of them is the one with the smallest MTU regardless of the MTU value chosen. Owen > > > Joe From nanog-post at rsuc.gweep.net Mon Jun 4 17:15:46 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Mon, 4 Jun 2012 18:15:46 -0400 Subject: Google Public DNS contact In-Reply-To: <20120604220847.GA16897@corp.zubrcom.net> References: <20120604220847.GA16897@corp.zubrcom.net> Message-ID: <20120604221545.GA85819@gweep.net> On Mon, Jun 04, 2012 at 06:08:47PM -0400, alex-lists-nanog at yuriev.com wrote: > Hello, > > If anyone has a contact in the Google Group that deals with Google's > Public DNS servers ( i.e. the 8.8.8.8/8.8.4.4 creatures ) could that person > kindly drop me an email off list? > > I believe there might be an issue with some of the servers. Have you already visited https://developers.google.com/speed/public-dns/ and contacted the public group mantioned? See also https://developers.google.com/speed/public-dns/faq#support ... -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From jmaimon at ttec.com Mon Jun 4 17:27:24 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 04 Jun 2012 18:27:24 -0400 Subject: IPv6 day and tunnels In-Reply-To: <4FCD2CD4.30307@unfix.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> Message-ID: <4FCD364C.5070001@ttec.com> Jeroen Massar wrote: > If people want to use a tunnel for the purpose of a VPN, then they will, > be that IPv4 or IPv6 or both inside that tunnel. > > Instead of having a custom VPN protocol one can do IPSEC properly now as > there is no NAT that one has to get around. Microsoft's Direct Access > does this btw and is an excellent example of doing it correctly. Microsoft has had this capability since win2k. I didnt see any enterprises use it, even those who used their globally unique and routed ipv4 /16 internally. NAT was not why they did not use it. They did not use it externally, they did not use it internally. In fact, most of them were involved in projects to switch to NAT internally. Enterprises also happen not to be thrilled with the absence of NAT in IPv6. Dont expect huge uptake there. > No why should it? But note that "IPv6 tunnels" (not VPNs) are a > transition technique from IPv4 to IPv6 and thus should not remain around > forever, the transition will end somewhere, sometime, likely far away in > the future with the speed that IPv6 is being deployed ;) So VPN is the _only_ acceptable use of sub 1500 encapsulation? >> Today, most people cant even get IPv6 without tunnels. > > In time that will change, that is simply transitional. If turning it on with a tunnel breaks things, it wont make native transition happen sooner. > > 1280 is the minimum IPv6 MTU. If people allow pMTU to work, aka accept > and process ICMPv6 Packet-Too-Big messages everything will just work. If things break with higher mtu's then 1280 but less then 1500, there really is no reason at all not to use 1280, the efficiency difference is trivial. And on the IPv4 internet, we generally cannot control what most of the rest of the people on it do. Looks like we are not going to be doing any better on the IPv6 internet. > > This whole thread is about people who cannot be bothered to know what > they are filtering and that they might just randomly block PtB as they > are doing with IPv4 today. Yes, in that case their network breaks if the > packets are suddenly larger than a link somewhere else, that is the same > as in IPv4 ;) > > Greets, > Jeroen > This whole thread is all about how IPv6 has not improved any of the issues that are well known with IPv4 and in many cases makes them worse. This whole thread is all about showcasing how IPv6 makes them worse, simply because it is designed with "this time they will do what we want" mentality. Joe From jmaimon at ttec.com Mon Jun 4 17:34:31 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 04 Jun 2012 18:34:31 -0400 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> Message-ID: <4FCD37F7.2050201@ttec.com> Owen DeLong wrote: > >> Fail. >> > > What, exactly are you saying is a failure? The single word here even in context is > very ambiguous. The failure is that even now, when tunnels are critical to transition, a proper solution that improves on the IPv4 problems does not exist And if tunnels do become less prevalent there will be even less impetus than now to make things work better. > >> Today, most people cant even get IPv6 without tunnels. > > Anyone can get IPv6 without a tunnel if they are willing to bring a circuit to the right place. Today most people cant even get IPv6 without tunnels, or without paying excessively more for their internet connection, or without having their pool of vendors shrink dramatically, sometimes to the point of none. > > Breaking PMTU-D is bad. People should stop doing so. > > Blocking PTB messages is bad in IPv4 and worse in IPv6. It has always been bad and people have not stopped doing it. And intentional blocking is not the sole cause of pmtud breaking. > > If you have a useful alternative solution to propose, put it forth and let's discuss the merits. PMTU-d probing, as recently standardizes seems a more likely solution. Having CPE capable of TCP mss adjustment on v6 is another one. Being able to fragment when you want to is another good one as well. > I hope not. I hope that IPv6 will cause people to actually re-evaluate their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D allows not only 1500, but also 1280, and 9000 and>9000 octet datagrams to be possible and segments that support<1500 work almost as well as segments that support jumbo frames. Where jumbo frames offer an end-to-end advantage, that advantage can be realized. Where there is a segment with a 1280 MTU, that can also work with a relatively small performance penalty. > > Where PMTU-D is broken, nothing works unless the MTU end-to-end happens to coincide with the smallest MTU. > > For links that carry tunnels and clear traffic, life gets interesting if one of them is the one with the smallest MTU regardless of the MTU value chosen. > > Owen > I dont share your optimism that it will go any better this time around than last. If it goes at all. Joe From Fred.L.Templin at boeing.com Mon Jun 4 17:43:54 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 4 Jun 2012 15:43:54 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD37F7.2050201@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD37F7.2050201@ttec.com> Message-ID: > PMTU-d probing, as recently standardizes seems a more likely solution. > Having CPE capable of TCP mss adjustment on v6 is another one. Being > able to fragment when you want to is another good one as well. I'll take a) and c), but don't care so much for b). About fragmenting, any tunnel ingress (VPNs included) can do inner fragmentation today independently of all other ingresses and with no changes necessary on the egress. It's just that they need to take precautions to avoid messing up the final destination's reassembly buffers. Fred fred.l.templin at boeing.com From mjl at caida.org Mon Jun 4 17:49:01 2012 From: mjl at caida.org (Matthew Luckie) Date: Mon, 04 Jun 2012 15:49:01 -0700 Subject: IPv6 evolution Message-ID: <4FCD3B5D.4050801@caida.org> IPv6 paths that are the same as an IPv4-level path are correlated with better IPv6 performance according to: "Assessing IPv6 Through Web Access - A Measurement Study and Its Findings" http://repository.upenn.edu/ese_papers/602/ At the Feb NANOG I gave a lightning talk on trends involving dual-stack ASes, beginning with the fraction of AS-level paths that are the same in IPv4 and IPv6. As of Jan 2012, 40-50% of AS-level paths are the same in v4 and v6 for dual-stacked origin ASes. http://www.nanog.org/meetings/nanog54/presentations/Monday/Luckie_LT.pdf We've looked further into the evolution of IPv6 since then. In particular we looked at "what could be". We find that 95% of AS-level paths could be the same today: where an IPv4 path contains ASes that are not found in an IPv6 path to the same dual-stacked origin, we check to see if the AS is observed in an IPv6 BGP path, and thus the AS is IPv6 capable at a minimum. A brief blog post on this is at: http://blog.caida.org/best_available_data/2012/06/04/ipv6-what-could-be-but-isnt-yet/ Matthew From owen at delong.com Mon Jun 4 17:59:33 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2012 15:59:33 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD37F7.2050201@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD37F7.2050201@ttec.com> Message-ID: On Jun 4, 2012, at 3:34 PM, Joe Maimon wrote: > > > Owen DeLong wrote: > >> >>> Fail. >>> >> >> What, exactly are you saying is a failure? The single word here even in context is >> very ambiguous. > > The failure is that even now, when tunnels are critical to transition, a proper solution that improves on the IPv4 problems does not exist > A proper solution does exist... Stop blocking PTB messages. That's the proper solution. It was the proper solution in IPv4 and it is the proper solution in IPv6. > And if tunnels do become less prevalent there will be even less impetus than now to make things work better. True, perhaps, but, I don't buy that tunnels are the only sub-1500 octet MTU out there, so, I think your premise here is somewhat flawed. > > >> >>> Today, most people cant even get IPv6 without tunnels. >> >> Anyone can get IPv6 without a tunnel if they are willing to bring a circuit to the right place. > > Today most people cant even get IPv6 without tunnels, or without paying excessively more for their internet connection, or without having their pool of vendors shrink dramatically, sometimes to the point of none. It never shrinks to none, but, yes, the cost can go up dramatically. You can, generally, get a circuit to somewhere that HE has presence from almost anywhere in the world if you are willing to pay for it. Any excessive costs would be what the circuit vendor charges. HE sells transit pretty cheap and everywhere we sell, it's dual-stack native. Sure, we wish we could magically have POPs everywhere and serve every customer with a short local loop. Unfortunately, that's not economically viable at this time, so, we build out where we can when there is sufficient demand to cover our costs. Pretty much like any other provider, I would imagine. Difference is, we've been building everything native dual stack for years. IPv6 is what we do. We're also pretty good at IPv4, so we deliver legacy connectivity to those that want it as well. >> >> Breaking PMTU-D is bad. People should stop doing so. >> >> Blocking PTB messages is bad in IPv4 and worse in IPv6. > > It has always been bad and people have not stopped doing it. And intentional blocking is not the sole cause of pmtud breaking. > I guess that depends on how you define the term intentional. I don't care whether it was the administrators intent, or a default intentionally placed there by the firewall vendor or what, it was someone's intent, therefore, yes, it is intentional. If you can cite an actual case of accidental dropping of PTB messages that was not the result of SOMEONE's intent, then, OK. However, at least on IPv6, I believe that intentional blocking (regardless of whose intent) is, in fact, the only source of PMTUD breakage at this point. In IPv4, there is some breakage in older software that didn't do PMTUD right even if it received the correct packets, but, that's not relevant to IPv6. >> >> If you have a useful alternative solution to propose, put it forth and let's discuss the merits. > > PMTU-d probing, as recently standardizes seems a more likely solution. Having CPE capable of TCP mss adjustment on v6 is another one. Being able to fragment when you want to is another good one as well. > Fragments are horrible from a security perspective and worse from a network processing perspective. Having a way to signal path MTU is much better. Probing is fine, but, it's not a complete solution and doesn't completely compensate for the lack of PTB message transparency. >> I hope not. I hope that IPv6 will cause people to actually re-evaluate their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D allows not only 1500, but also 1280, and 9000 and>9000 octet datagrams to be possible and segments that support<1500 work almost as well as segments that support jumbo frames. Where jumbo frames offer an end-to-end advantage, that advantage can be realized. Where there is a segment with a 1280 MTU, that can also work with a relatively small performance penalty. >> >> Where PMTU-D is broken, nothing works unless the MTU end-to-end happens to coincide with the smallest MTU. >> >> For links that carry tunnels and clear traffic, life gets interesting if one of them is the one with the smallest MTU regardless of the MTU value chosen. >> >> Owen >> > > I dont share your optimism that it will go any better this time around than last. If it goes at all. > It is clearly going, so, the if it goes at all question is already answered. We're already seeing a huge ramp in IPv6 traffic leading up to ISOC's big celebration of my birthday (aka World IPv6 Launch) since early last week. I have no reason to expect that that traffic won't remain at the new higher levels after June 6. There are too many ISPs, Mobile operators, Web site operators and others committed at this point for it not to actually go. Also, since there's no viable alternative if it doesn't go, that pretty well insures that it will go one way or another. As to my optimism, please don't mistake my statement of hope for any form of expectation. I _KNOW_ how bad it is. I live behind tunnels for IPv4 and IPv6 and have these issues on a regular basis. Usually I'm able to work around them. Sometimes I'm even able to get people to actually fix their firewalls. The good news is... + If we can get people to stop deploying bad filters + And we keep fixing the existing bad filters Eventually, bad filters disappear. Yes, that's two big ifs, but, it's worth a try. Owen > Joe From Fred.L.Templin at boeing.com Mon Jun 4 18:13:06 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Mon, 4 Jun 2012 16:13:06 -0700 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD37F7.2050201@ttec.com> Message-ID: Hi Owen, I am 100% with you on wanting to see an end to filtering of ICMPv6 PTBs. But, tunnels can take matters into their own hands today to make sure that 1500 and smaller gets through no matter if PTBs are delivered or not. There doesn't really even need to be a spec as long as each tunnel takes the necessary precautions to avoid messing up the final destination. The next thing is to convince the hosts to implement RFC4821... Thanks - Fred fred.l.templin at boeing.com > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, June 04, 2012 4:00 PM > To: Joe Maimon > Cc: nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > > On Jun 4, 2012, at 3:34 PM, Joe Maimon wrote: > > > > > > > Owen DeLong wrote: > > > >> > >>> Fail. > >>> > >> > >> What, exactly are you saying is a failure? The single word here even in > context is > >> very ambiguous. > > > > The failure is that even now, when tunnels are critical to transition, a > proper solution that improves on the IPv4 problems does not exist > > > > A proper solution does exist... Stop blocking PTB messages. That's the > proper solution. It was the proper solution in IPv4 and it is the proper > solution in IPv6. > > > And if tunnels do become less prevalent there will be even less impetus > than now to make things work better. > > True, perhaps, but, I don't buy that tunnels are the only sub-1500 octet > MTU out there, so, I think your premise here is somewhat flawed. > > > > > > >> > >>> Today, most people cant even get IPv6 without tunnels. > >> > >> Anyone can get IPv6 without a tunnel if they are willing to bring a > circuit to the right place. > > > > Today most people cant even get IPv6 without tunnels, or without paying > excessively more for their internet connection, or without having their > pool of vendors shrink dramatically, sometimes to the point of none. > > It never shrinks to none, but, yes, the cost can go up dramatically. You > can, generally, get a circuit to somewhere that HE has presence from > almost anywhere in the world if you are willing to pay for it. Any > excessive costs would be what the circuit vendor charges. HE sells transit > pretty cheap and everywhere we sell, it's dual-stack native. Sure, we wish > we could magically have POPs everywhere and serve every customer with a > short local loop. Unfortunately, that's not economically viable at this > time, so, we build out where we can when there is sufficient demand to > cover our costs. Pretty much like any other provider, I would imagine. > Difference is, we've been building everything native dual stack for years. > IPv6 is what we do. We're also pretty good at IPv4, so we deliver legacy > connectivity to those that want it as well. > > >> > >> Breaking PMTU-D is bad. People should stop doing so. > >> > >> Blocking PTB messages is bad in IPv4 and worse in IPv6. > > > > It has always been bad and people have not stopped doing it. And > intentional blocking is not the sole cause of pmtud breaking. > > > > I guess that depends on how you define the term intentional. I don't care > whether it was the administrators intent, or a default intentionally > placed there by the firewall vendor or what, it was someone's intent, > therefore, yes, it is intentional. If you can cite an actual case of > accidental dropping of PTB messages that was not the result of SOMEONE's > intent, then, OK. However, at least on IPv6, I believe that intentional > blocking (regardless of whose intent) is, in fact, the only source of > PMTUD breakage at this point. In IPv4, there is some breakage in older > software that didn't do PMTUD right even if it received the correct > packets, but, that's not relevant to IPv6. > > >> > >> If you have a useful alternative solution to propose, put it forth and > let's discuss the merits. > > > > PMTU-d probing, as recently standardizes seems a more likely solution. > Having CPE capable of TCP mss adjustment on v6 is another one. Being able > to fragment when you want to is another good one as well. > > > > Fragments are horrible from a security perspective and worse from a > network processing perspective. Having a way to signal path MTU is much > better. Probing is fine, but, it's not a complete solution and doesn't > completely compensate for the lack of PTB message transparency. > > >> I hope not. I hope that IPv6 will cause people to actually re-evaluate > their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D > allows not only 1500, but also 1280, and 9000 and>9000 octet datagrams to > be possible and segments that support<1500 work almost as well as segments > that support jumbo frames. Where jumbo frames offer an end-to-end > advantage, that advantage can be realized. Where there is a segment with a > 1280 MTU, that can also work with a relatively small performance penalty. > >> > >> Where PMTU-D is broken, nothing works unless the MTU end-to-end happens > to coincide with the smallest MTU. > >> > >> For links that carry tunnels and clear traffic, life gets interesting > if one of them is the one with the smallest MTU regardless of the MTU > value chosen. > >> > >> Owen > >> > > > > I dont share your optimism that it will go any better this time around > than last. If it goes at all. > > > > It is clearly going, so, the if it goes at all question is already > answered. We're already seeing a huge ramp in IPv6 traffic leading up to > ISOC's big celebration of my birthday (aka World IPv6 Launch) since early > last week. I have no reason to expect that that traffic won't remain at > the new higher levels after June 6. There are too many ISPs, Mobile > operators, Web site operators and others committed at this point for it > not to actually go. Also, since there's no viable alternative if it > doesn't go, that pretty well insures that it will go one way or another. > > As to my optimism, please don't mistake my statement of hope for any form > of expectation. I _KNOW_ how bad it is. I live behind tunnels for IPv4 and > IPv6 and have these issues on a regular basis. > > Usually I'm able to work around them. Sometimes I'm even able to get > people to actually fix their firewalls. > > The good news is... > > + If we can get people to stop deploying bad filters > + And we keep fixing the existing bad filters > > Eventually, bad filters disappear. > > Yes, that's two big ifs, but, it's worth a try. > > Owen > > > Joe From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 18:40:01 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Jun 2012 08:40:01 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> Message-ID: <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: > I'm not sure that a randomly-chosen "skip" value is even > necessary. It is not necessary, because, for ID uniqueness fundamentalists, single event is bad enough and for most operators, slight possibility is acceptable. > Outer fragmentation cooks the tunnel egresses at high > data rates. Have egresses with proper performance. That's the proper operation. > End systems are expected and required to > reassemble on their own behalf. That is not a proper operation of tunnels. >> Thus, don't insist on having unique IDs so much. > > Non-overlapping fragments are disallowed for IPv6, but > I think are still allowed for IPv4. So, IPv4 still needs > the unique IDs by virtue of rate limiting. Even though there is no well defined value of MSL? >> I'm talking about not protocol recommendation but proper >> operation. > > I don't see any operational guidance recommending the > tunnel ingress to configure an MRU of 1520 or larger. I'm talking about not operation guidance but proper operation. Proper operators can, without any guidance, perform proper operation. Masataka Ohta From jeroen at unfix.org Mon Jun 4 18:50:48 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Jun 2012 16:50:48 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD364C.5070001@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> Message-ID: <4FCD49D8.30704@unfix.org> On 2012-06-04 15:27, Joe Maimon wrote: > > > Jeroen Massar wrote: > > >> If people want to use a tunnel for the purpose of a VPN, then they will, >> be that IPv4 or IPv6 or both inside that tunnel. >> > > >> Instead of having a custom VPN protocol one can do IPSEC properly now as >> there is no NAT that one has to get around. Microsoft's Direct Access >> does this btw and is an excellent example of doing it correctly. > > Microsoft has had this capability since win2k. I didnt see any > enterprises use it, even those who used their globally unique and routed > ipv4 /16 internally. NAT was not why they did not use it. > > They did not use it externally, they did not use it internally. > > In fact, most of them were involved in projects to switch to NAT > internally. > > Enterprises also happen not to be thrilled with the absence of NAT in IPv6. What I read that you are saying is that you know a lot of folks who do not understand the concept of end-to-end reachability and think that NAT is a security feature and that ICMP is evil. That indeed matches most of the corporate world quite well. That they are heavily misinformed does not make it the correct answer though. > Dont expect huge uptake there. Every problem has it's own solution depending on the situation. Direct Access is a just another possible solution to a problem. If NATs would not have existed and the IPSEC key infra was better integrated into Operating Systems the uptake for IPSEC based VPNs would have likely been quite a bit higher by now. But all guess work. >> No why should it? But note that "IPv6 tunnels" (not VPNs) are a >> transition technique from IPv4 to IPv6 and thus should not remain around >> forever, the transition will end somewhere, sometime, likely far away in >> the future with the speed that IPv6 is being deployed ;) > > > So VPN is the _only_ acceptable use of sub 1500 encapsulation? Why would anything be 'acceptable'? If you have a medium that only can carry X bytes per packet, then that is the way it is, you'll just have to be able to frag IPv6 packets on that medium if you want to support IPv6. And the good thing is that if you can support jumbo frames, just turn it on and let pMTU do it's work. Happy 9000's ;) >>> Today, most people cant even get IPv6 without tunnels. >> >> In time that will change, that is simply transitional. > > > If turning it on with a tunnel breaks things, it wont make native > transition happen sooner. Using tunnels does not break things. Filtering PTB's (which can happen anywhere in the network, thus also remotely) can break things though. Or better said: mis-configuring systems break things. > This whole thread is all about how IPv6 has not improved any of the > issues that are well known with IPv4 and in many cases makes them worse. You cannot unteach stupid people to do stupid things. Protocol changes will not suddenly make people understand that what they want to do is wrong and breaks said protocol. Greets, Jeroen From marka at isc.org Mon Jun 4 18:54:24 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 05 Jun 2012 09:54:24 +1000 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: Your message of "Mon, 04 Jun 2012 08:26:37 MST." <4FCCD3AD.5000104@unfix.org> References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> <4FCCD3AD.5000104@unfix.org> Message-ID: <20120604235424.DE87E213E823@drugs.dv.isc.org> What's really needed is a service that looks up a given web page over IPv6 from behind a 1280 byte MTU link and reports if all the elements load or not. It dumps a list of elements with success/fail. This would be useful to send the idiots that block ICMPv6 PTB yet send packets bigger than 1280 bytes out too. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From frnkblk at iname.com Mon Jun 4 18:58:16 2012 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 4 Jun 2012 18:58:16 -0500 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: <20120604235424.DE87E213E823@drugs.dv.isc.org> References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> <4FCCD3AD.5000104@unfix.org> <20120604235424.DE87E213E823@drugs.dv.isc.org> Message-ID: <00b301cd42ad$e886b490$b9941db0$@iname.com> Much of that can be found here: http://www.wand.net.nz/pmtud/ Frank -----Original Message----- From: Mark Andrews [mailto:marka at isc.org] Sent: Monday, June 04, 2012 6:54 PM To: Jeroen Massar Cc: nanog at nanog.org Subject: Re: test-ipv6.com / omgipv6day.com down What's really needed is a service that looks up a given web page over IPv6 from behind a 1280 byte MTU link and reports if all the elements load or not. It dumps a list of elements with success/fail. This would be useful to send the idiots that block ICMPv6 PTB yet send packets bigger than 1280 bytes out too. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Mon Jun 4 18:58:25 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2012 16:58:25 -0700 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: <20120604235424.DE87E213E823@drugs.dv.isc.org> References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> <4FCCD3AD.5000104@unfix.org> <20120604235424.DE87E213E823@drugs.dv.isc.org> Message-ID: http://ipv6chicken.net Owen On Jun 4, 2012, at 4:54 PM, Mark Andrews wrote: > > What's really needed is a service that looks up a given web page > over IPv6 from behind a 1280 byte MTU link and reports if all the > elements load or not. It dumps a list of elements with success/fail. > > This would be useful to send the idiots that block ICMPv6 PTB yet > send packets bigger than 1280 bytes out too. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Mon Jun 4 19:13:23 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 05 Jun 2012 10:13:23 +1000 Subject: IPv6 day and tunnels In-Reply-To: Your message of "Mon, 04 Jun 2012 16:50:48 MST." <4FCD49D8.30704@unfix.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> Message-ID: <20120605001323.A974E213E947@drugs.dv.isc.org> What we need is World 1280 MTU day where *all* peering links are set to 1280 bytes for IPv4 and IPv6 and are NOT raised for 24 hours regardless of the complaints. This needs to be done annually. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jeroen at unfix.org Mon Jun 4 19:14:26 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Jun 2012 17:14:26 -0700 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> <4FCCD3AD.5000104@unfix.org> <20120604235424.DE87E213E823@drugs.dv.isc.org> Message-ID: <4FCD4F62.8000100@unfix.org> On 2012-06-04 16:58, Owen DeLong wrote: > http://ipv6chicken.net $ dig -t any ipv6chicken.net ; <<>> DiG 9.8.1-P1 <<>> -t any ipv6chicken.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16935 The chicken cannot cross the road as the chicken does not exist. Greets, Jeroen From marka at isc.org Mon Jun 4 19:15:27 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 05 Jun 2012 10:15:27 +1000 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: Your message of "Mon, 04 Jun 2012 16:58:25 MST." References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> <4FCCD3AD.5000104@unfix.org> <20120604235424.DE87E213E823@drugs.dv.isc.org> Message-ID: <20120605001527.8FE09213EA05@drugs.dv.isc.org> In message , Owen DeLong writes: > http://ipv6chicken.net > > Owen doesn't exist. ; <<>> DiG 9.9.1 <<>> ipv6chicken.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5059 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ipv6chicken.net. IN A ;; AUTHORITY SECTION: net. 879 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1338855235 1800 900 604800 86400 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jun 5 10:14:40 2012 ;; MSG SIZE rcvd: 117 > > On Jun 4, 2012, at 4:54 PM, Mark Andrews wrote: > > > > > What's really needed is a service that looks up a given web page > > over IPv6 from behind a 1280 byte MTU link and reports if all the > > elements load or not. It dumps a list of elements with success/fail. > > > > This would be useful to send the idiots that block ICMPv6 PTB yet > > send packets bigger than 1280 bytes out too. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Mon Jun 4 19:18:07 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2012 17:18:07 -0700 Subject: IPv6 day and tunnels In-Reply-To: <20120605001323.A974E213E947@drugs.dv.isc.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <20120605001323.A974E213E947@drugs.dv.isc.org> Message-ID: I kind of like the idea. I suspect that $DAYJOB would be less enthusiastic. Owen On Jun 4, 2012, at 5:13 PM, Mark Andrews wrote: > > What we need is World 1280 MTU day where *all* peering links are > set to 1280 bytes for IPv4 and IPv6 and are NOT raised for 24 hours > regardless of the complaints. This needs to be done annually. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jmaimon at ttec.com Mon Jun 4 19:21:41 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 04 Jun 2012 20:21:41 -0400 Subject: IPv6 day and tunnels In-Reply-To: <4FCD49D8.30704@unfix.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> Message-ID: <4FCD5115.7090003@ttec.com> Jeroen Massar wrote: > > That indeed matches most of the corporate world quite well. That they > are heavily misinformed does not make it the correct answer though. Either you are correct and they are all wrong, or they have a perspective that you dont or wont see. Either way I dont see them changing their mind anytime soon. So how about we both accept that they exist and start designing the network to welcome rather than ostracize them, unless that is your intent. > And the good thing is that if you can support jumbo frames, just turn it > on and let pMTU do it's work. Happy 9000's ;) pMTU has been broken in IPv4 since the early days. It is still broken. It is also broken in IPv6. It will likely still be broken for the forseeable future. This is a) a problem that should not be ignored b) a failure in imagination when designing the protocol c) a missed opportunity to correct a systemic issue with IPv4 > > Or better said: mis-configuring systems break things. Why do switches auto-mdix these days? Because insisting that things will work properly if you just configure them correctly turns out to be inferior to designing a system that requires less configuration to achieve the same goal. Automate. > >> This whole thread is all about how IPv6 has not improved any of the >> issues that are well known with IPv4 and in many cases makes them worse. > > You cannot unteach stupid people to do stupid things. > > Protocol changes will not suddenly make people understand that what they > want to do is wrong and breaks said protocol. > > Greets, > Jeroen > You also cannot teach protocol people that there is protocol and then there is reality. Relying on ICMP exception messages was always wrong for normal network operation. Best, Joe From sparctacus at gmail.com Mon Jun 4 19:24:45 2012 From: sparctacus at gmail.com (Bryan Irvine) Date: Mon, 4 Jun 2012 17:24:45 -0700 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: <20120605001527.8FE09213EA05@drugs.dv.isc.org> References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> <4FCCD3AD.5000104@unfix.org> <20120604235424.DE87E213E823@drugs.dv.isc.org> <20120605001527.8FE09213EA05@drugs.dv.isc.org> Message-ID: 's/net/com' On Mon, Jun 4, 2012 at 5:15 PM, Mark Andrews wrote: > > In message , Owen DeLong writes: >> http://ipv6chicken.net >> >> Owen > > doesn't exist. > > ; <<>> DiG 9.9.1 <<>> ipv6chicken.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5059 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;ipv6chicken.net. ? ? ? ? ? ? ? IN ? ? ?A > > ;; AUTHORITY SECTION: > net. ? ? ? ? ? ? ? ? ? ?879 ? ? IN ? ? ?SOA ? ? a.gtld-servers.net. nstld.verisign-grs.com. 1338855235 1800 900 604800 86400 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Tue Jun ?5 10:14:40 2012 > ;; MSG SIZE ?rcvd: 117 > >> >> On Jun 4, 2012, at 4:54 PM, Mark Andrews wrote: >> >> > >> > What's really needed is a service that looks up a given web page >> > over IPv6 from behind a 1280 byte MTU link and reports if all the >> > elements load or not. ? It dumps a list of elements with success/fail. >> > >> > This would be useful to send the idiots that block ICMPv6 PTB yet >> > send packets bigger than 1280 bytes out too. >> > >> > Mark >> > -- >> > Mark Andrews, ISC >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia >> > PHONE: +61 2 9871 4742 ? ? ? ? ? ? ? ? INTERNET: marka at isc.org >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 ? ? ? ? ? ? ? ? INTERNET: marka at isc.org > From owen at delong.com Mon Jun 4 19:28:57 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2012 17:28:57 -0700 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: <4FCD4F62.8000100@unfix.org> References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> <4FCCD3AD.5000104@unfix.org> <20120604235424.DE87E213E823@drugs.dv.isc.org> <4FCD4F62.8000100@unfix.org> Message-ID: <19C2AC63-198F-4B5C-A853-E776CF1E7511@delong.com> My bad... It's .com not .net. http://www.ipv6chicken.com Owen On Jun 4, 2012, at 5:14 PM, Jeroen Massar wrote: > On 2012-06-04 16:58, Owen DeLong wrote: >> http://ipv6chicken.net > > $ dig -t any ipv6chicken.net > > ; <<>> DiG 9.8.1-P1 <<>> -t any ipv6chicken.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16935 > > The chicken cannot cross the road as the chicken does not exist. > > Greets, > Jeroen From mohta at necom830.hpcl.titech.ac.jp Mon Jun 4 19:33:01 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Jun 2012 09:33:01 +0900 Subject: IPv6 day and tunnels In-Reply-To: <4FCD5115.7090003@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> Message-ID: <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> Joe Maimon wrote: > pMTU has been broken in IPv4 since the early days. > It is still broken. It is also broken in IPv6. It will likely > still be broken for the forseeable future. This is > Relying on ICMP exception messages was always wrong for normal network operation. Agreed. The proper solution is to have a field in IPv7 header to measure PMTU. It can be a 8 bit field, if fragment granularity is 256B. Masataka Ohta From shortdudey123 at gmail.com Mon Jun 4 19:35:47 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Mon, 4 Jun 2012 19:35:47 -0500 Subject: ATT DSL IPv6 Message-ID: Hi Everyone, Does anyone know about IPv6 on ATT residential DSL circuits? About 8 or 9 months ago i ran through several IPv6 tests (http://test-ipv6.iad.vr.org/) and they all passed. With all the talk of IPv6 day over the past week i decided to run it again just out of curiosity. However to my surprise, it is returning the result of IPv4 only now. Any ideas why they would have rolled back IPv6? Thanks, Grant From marka at isc.org Mon Jun 4 19:44:01 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 05 Jun 2012 10:44:01 +1000 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: Your message of "Mon, 04 Jun 2012 17:24:45 MST." References: <74F38EF5-6B3A-4970-A72F-C0B29A483D15@yahoo-inc.com> <12BA1049-475C-4A77-BEF0-A490A1426179@unfix.org> <62475C28-453B-4E0F-A184-7E9ABDF9769D@yahoo-inc.com> <4FCCD3AD.5000104@unfix.org> <20120604235424.DE87E213E823@drugs.dv.isc.org> <20120605001527.8FE09213EA05@drugs.dv.isc.org> Message-ID: <20120605004401.3736E213EE08@drugs.dv.isc.org> http://ipv6chicken.com/ tests the path to me. It doesn't check the path back to the sites I want to reach though it does provide a independent third party if there is complainst that PTB's are not being generated. It would be useful if it reported the MTU that was eventually used. Most OS's have a hook to retrieve this. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mjl at caida.org Mon Jun 4 19:55:11 2012 From: mjl at caida.org (Matthew Luckie) Date: Mon, 4 Jun 2012 17:55:11 -0700 Subject: test-ipv6.com / omgipv6day.com down In-Reply-To: <20120604235424.DE87E213E823@drugs.dv.isc.org> Message-ID: <20120605005511.GA11403@sorcerer.caida.org> > What's really needed is a service that looks up a given web page > over IPv6 from behind a 1280 byte MTU link and reports if all the > elements load or not. It dumps a list of elements with success/fail. > > This would be useful to send the idiots that block ICMPv6 PTB yet > send packets bigger than 1280 bytes out too. http://www.wand.net.nz/scamper/ Works on MacOS X and FreeBSD. It uses IPFW and rules 1-500 as necessary. Example below, showing a website sending > 1280 but ignoring PTBs sent to it. $ sudo scamper -F ipfw -I "tbit -t pmtud -u 'http://www.sapo.pt/' 2001:8a0:2104:ff:213:13:146:140" tbit from 2001:470:d:4de:21f:3cff:fe20:bf4e to 2001:8a0:2104:ff:213:13:146:140 server-mss 1460, result: pmtud-fail app: http, url: http://www.sapo.pt/ [ 0.048] TX SYN 64 seq = 0:0 [ 0.254] RX SYN/ACK 64 seq = 0:1 [ 0.255] TX 60 seq = 1:1 [ 0.255] TX 230 seq = 1:1(170) [ 0.450] RX 60 seq = 1:171 [ 0.469] RX 1460 seq = 1:171(1400) [ 0.469] TX PTB 1280 mtu = 1280 [ 0.470] RX 1460 seq = 1401:171(1400) [ 3.467] RX 1460 seq = 1:171(1400) [ 3.467] TX PTB 1280 mtu = 1280 [ 9.468] RX 1460 seq = 1:171(1400) [ 9.468] TX PTB 1280 mtu = 1280 [ 21.471] RX 1460 seq = 1:171(1400) [ 21.471] TX PTB 1280 mtu = 1280 [ 31.933] RX RST 60 seq = 1:4294923802 From apishdadi at gmail.com Mon Jun 4 20:01:48 2012 From: apishdadi at gmail.com (Ameen Pishdadi) Date: Mon, 4 Jun 2012 20:01:48 -0500 Subject: Recommendation for OOB management via IP In-Reply-To: <4FCD1E78.1040302@ucsc.edu> References: <4FCD1E78.1040302@ucsc.edu> Message-ID: <5F5EC410-8F7B-42AC-9847-649941B318B5@gmail.com> What's wrong with a dsl connection doesn't need to be anything fancy just reliable enough to be up when your other stuff is down Thanks, Ameen Pishdadi On Jun 4, 2012, at 3:45 PM, "Hiten J. Thakkar" wrote: > Hello! > > My work place is looking for an OOB management over IP. We have Lantronix KVM in our Datacenter with nearly 100% uptime and Lantronix SLC-8/16/48 ports with 2 NICs deployed across various MDFs on campus and remote locations (5). On our main campus we have a parallel net, but for the remote locations we are looking to access Lantronix SLCs' via the second NIC card using IP based solution. Can you kindly make suggestions. I supremely appreciate your time and inputs in advance. > > -- > > Thanks and regards, > Hiten J. Thakkar > > From owen at delong.com Mon Jun 4 19:57:06 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2012 17:57:06 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> Message-ID: <0E60355A-88A1-4A8B-BF5E-248011FF7711@delong.com> On Jun 4, 2012, at 5:33 PM, Masataka Ohta wrote: > Joe Maimon wrote: > >> pMTU has been broken in IPv4 since the early days. > >> It is still broken. It is also broken in IPv6. It will likely >> still be broken for the forseeable future. This is > >> Relying on ICMP exception messages was always wrong for normal network operation. > > Agreed. > > The proper solution is to have a field in IPv7 header to > measure PMTU. It can be a 8 bit field, if fragment granularity > is 256B. > > Masataka Ohta If you're going to redesign the header, I'd be much more interested in having 32 bits for the destination ASN so that IDR can ignore IP prefixes altogether. Owen From owen at delong.com Mon Jun 4 19:57:55 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2012 17:57:55 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD5115.7090003@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> Message-ID: <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> On Jun 4, 2012, at 5:21 PM, Joe Maimon wrote: > > > Jeroen Massar wrote: > > >> >> That indeed matches most of the corporate world quite well. That they >> are heavily misinformed does not make it the correct answer though. > > Either you are correct and they are all wrong, or they have a perspective that you dont or wont see. > He is correct. I have seen their perspective and it is, in fact, misinformed and based largely on superstition. > Either way I dont see them changing their mind anytime soon. Very likely true, unfortunately. Zealots are rarely persuaded by facts, science, or anything based in reality, choosing instead to maintain their bubble of belief even to the point of historically killing those that could not accept their misguided viewpoint. Nonetheless, over time, even humans eventually figured out that Galileo was right and the world is, indeed round, does, in fact orbit the sun (and not the other way around) and is not, in fact, at the center of the universe. Given that we were able to overcome the catholic church with those facts eventually, I suspect that overcoming corporate IT mythology over time will be somewhat sooner and easier. It might eve take less than 100 years instead of several hundred. > So how about we both accept that they exist and start designing the network to welcome rather than ostracize them, unless that is your intent. I would rather educate them and let them experience the errs of their ways until they learn than damage the network in the pursuit of inclusion in this case. If you reward bad behavior with adaptation to that behavior and accommodation, you get more bad behavior. This was proven with appeasement of hitler in the 40s (hey, someone had to feed Godwin's law, right?) and has been confirmed with the recent corporate bail-outs, bank bail-outs and the mortgage crisis. One could even argue that the existing corporate attitudes about NAT are a reflection of this behavior being rewarded with ALGs and other code constructs aimed at accommodating that bad behavior. > > >> And the good thing is that if you can support jumbo frames, just turn it >> on and let pMTU do it's work. Happy 9000's ;) > > pMTU has been broken in IPv4 since the early days. > PMTUD is broken in IPv4 since the early days because it didn't exist in the early days. PMTUD is a relatively recent feature for IPv4. PMTUD has been getting progressively less broken in IPv4 since it was introduced. > It is still broken. It is also broken in IPv6. It will likely still be broken for the forseeable future. This is > PMTU-D itself is not broken in IPv6, but some networks do break PMTU-D. > a) a problem that should not be ignored True. Ignoring ignorance is no better than accommodating it. The correct answer to ignorance is education. > b) a failure in imagination when designing the protocol Not really. In reality, it is a failure of implementers to follow the published standards. The protocol, as designed, works as expected if deployed in accordance with the specifications. > c) a missed opportunity to correct a systemic issue with IPv4 There are many of those (the most glaring being the failure to address scalability of the routing system). However, since, as near as I can tell, PMTU-D was a new feature for IPv6 which was subsequently back-ported to IPv4, I am not sure that statement really applies in this case. Many of the features we take for granted in IPv4 today were actually introduced as part of IPv6 development, including IPSEC, PMTU-D, CIDR notation for prefix length, and more. >> Or better said: mis-configuring systems break things. > > Why do switches auto-mdix these days? Because it makes correct configuration easier. You can turn this off on most switches, in fact, and if you do, you can still misconfigure them. Any device with a non-buggy IPv6 implementation, by default does not block ICMPv6 PTB messages. If you subsequently deliberately misconfigure it to block them, then, you have taken deliberate action to misconfigure your network. > Because insisting that things will work properly if you just configure them correctly turns out to be inferior to designing a system that requires less configuration to achieve the same goal. Breaking PMTU-D in IPv6 requires configuration unless the implementation is buggy. Don't get me started on how bad a buggy Auto MDI/X implementation can make your life. Believe me, it is far worse than PMTU-D blocking. > Automate. Already done. Most PMTU-D blocks in IPv6 are the result of operators taking deliberate configuration action to block packets that should not be blocked. That is equivalent to turning off Auto-MDI/X or Autonegotiation on the port. >>> This whole thread is all about how IPv6 has not improved any of the >>> issues that are well known with IPv4 and in many cases makes them worse. >> >> You cannot unteach stupid people to do stupid things. >> I disagree. People can be educated. It may take more effort than working around them, but, it can be done. >> Protocol changes will not suddenly make people understand that what they >> want to do is wrong and breaks said protocol. Nope... This requires education. >> >> Greets, >> Jeroen >> > > > You also cannot teach protocol people that there is protocol and then there is reality. Huh? This seems nonsensical to me, so I am unsure what you mean. > Relying on ICMP exception messages was always wrong for normal network operation. Here we must disagree. What else can you rely on? In order to characterize the path to a given destination, you must either get an exception back for packets that are too large, or, you must get confirmation back that your packet arrived. The absent of arrival confirmation does not tell you anything about why the packet did not arrive, so, assuming that it is due to size requires a rather lengthy conversation searching for the largest size of packet that will pass through the path. For example, consider that you are on an ethernet segment with jumbo frames. PMTU-D is relatively efficient. You send a 9000 octet datagram and you get back an ICMP message telling you the largest size datagram that will pass. If there are several points where the PMTU is reduced along the way, you will have 1 round trip of this type for each of those points. Notice there are no waits for timeouts involved here. Probing as you have proposed requires you to essentially do a binary search to arrive at some number n where 1280?n?9000, so, you end up doing something like this: Send 5140 octet datagram, wait for reply (how long?) Send 3210 octet datagram, wait for reply (how long?) Send 2245 octet datagram, wait for reply (how long?) Send 1762 octet datagram, wait for reply (how long?) Send 1521 octet datagram, wait for reply (how long?) Send 1400 octet datagram, wait for reply (how long?) Send 1340 octet datagram, wait for reply (how long?) Send 1310 octet datagram, wait for reply (how long?) Send 1296 octet datagram, wait for reply (how long?) Send 1288 octet datagram, wait for reply (how long?) Send 1284 octet datagram, wait for reply (how long?) Send 1282 octet datagram, wait for reply (how long?) Send 1281 octet datagram, wait for reply (how long?) Settle on 1280 MTU... So, you waited for 13 timeouts before you actually passed useful traffic? Or, perhaps you putter along at the lowest possible MTU until you find some higher value you know works so you're sending lots of extra traffic? That's fantastic for modern short-lived flows. You send more traffic for PMTU discovery than you receive in the entire life of the flow in some cases. Owen From jeroen at unfix.org Mon Jun 4 20:11:56 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Jun 2012 18:11:56 -0700 Subject: IPv6 day and tunnels In-Reply-To: <0E60355A-88A1-4A8B-BF5E-248011FF7711@delong.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> <0E60355A-88A1-4A8B-BF5E-248011FF7711@delong.com> Message-ID: <4FCD5CDC.3060209@unfix.org> On 2012-06-04 17:57, Owen DeLong wrote: [..] > If you're going to redesign the header, I'd be much more interested > in having 32 bits for the destination ASN so that IDR can ignore IP > prefixes altogether. One can already do that: route your IPv6 over IPv4.... IPv4 has 32bit destination addresses remember? :) It is also why it is fun if somebody uses a 32-bit ASN to route IPv4, as one is not making the problem smaller that way. ASNs are more used as identifiers to avoid routing loops than as actual routing parameters. Greets, Jeroen From mysidia at gmail.com Mon Jun 4 21:47:41 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 4 Jun 2012 21:47:41 -0500 Subject: IPv6 day and tunnels In-Reply-To: <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> Message-ID: On 6/4/12, Owen DeLong wrote: [snip] > Probing as you have proposed requires you to essentially do a binary search > to arrive > at some number n where 1280?n?9000, so, you end up doing something like > this: [snip] > So, you waited for 13 timeouts before you actually passed useful > traffic? Or, perhaps you putter along at the lowest possible MTU until you [snip] Instead of waiting for 13 timeouts, start with 4 initial probes in parallel, and react rapidly to the responses you receive; say 9000,2200, 1500, 830. Don't wait until any timeouts until the possible MTUs are narrowed. FindLocalMTU(B,T) Let B := Minimum_MTU Let T := Maximum_MTU Let D := Max(1, Floor( ( (T - 1) - (B+1) ) / 4 )) Let R := T Let Attempted_Probes := [] While ( ( (B + D) < T ) or Attempted_Probes is not Empty ) do If R is not a member of Attempted_Probes or Retries < 1 then AsynchronouslySendProbeOfSize (R) Append (R,Tries) to list of Attempted_Probes if not exists or if (R,Tries) already in list then increment Retries. else T := R - 1 Delete from Attempted_Probes (R) end if ( (B + D) < T ) AsynchronouslySendProbeOfSize (B+ D) if ( (B + 2*D) < T ) AsynchronouslySendProbeOfSize (B+ 2*D) if ( (B + 3*D) < T ) AsynchronouslySendProbeOfSize (B+ 3*D) if ( (B + 4*D) < T ) AsynchronouslySendProbeOfSize (B+ 4*D) Wait_For_Next_Probe_Response_To_Arrive() Wait_For_Additional_Probe_Response_Or_Short_Subsecond_Delay() Add_Probe_Responses_To_Queue(Q) R := Get_Largest_Received_Probe_Size(Q) If ( R > T ) then T := R end If ( R > B ) then B := R D := Max(1, Floor( ( (R - 1) - (B+1) ) / 4 )) end done Result := B # If you receive the response at n=830 first, then wait 1ms and send the next 4 probes 997 1164 1331 1498, and resend the n=1500 probe If 1280 is what the probe needs to detect. You'll receive a response for 1164 , so wait 1ms then retry n=1498 next 4 probes are 1247 1330 1413 1496 if 1280 is what the probe needs to detect, You'll receive a response for 1247, so wait 1ms resend n=1496 next 4 probes are 1267 1307 1327 1347 if 1280 is what you neet to detect, you'll receive response for 1267, so retry n=1347 wait 1ms next 4 probes are: 1276 1285 1294 1303 next 4 probes are: 1277 1278 1279 1280 next 2 parallel probes are: 1281 1282 You hit after 22 probes, but you only needed to wait for n=1281 n=1282 and their retry to time out. -- -JH From owen at delong.com Tue Jun 5 01:06:31 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2012 23:06:31 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD5CDC.3060209@unfix.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> <0E60355A-88A1-4A8B-BF5E-248011FF7711@delong.com> <4FCD5CDC.3060209@unfix.org> Message-ID: On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote: > On 2012-06-04 17:57, Owen DeLong wrote: > [..] >> If you're going to redesign the header, I'd be much more interested >> in having 32 bits for the destination ASN so that IDR can ignore IP >> prefixes altogether. > > One can already do that: route your IPv6 over IPv4.... IPv4 has 32bit > destination addresses remember? :) > > It is also why it is fun if somebody uses a 32-bit ASN to route IPv4, as > one is not making the problem smaller that way. ASNs are more used as > identifiers to avoid routing loops than as actual routing parameters. > > Greets, > Jeroen While this is true today (to some extent), it doesn't have to always be true. If we provided a reliable scaleable mechanism to distribute and cache prefix->ASN mappings and could reliably populate a DEST-AS field in the packet header, stub networks would no longer need separate ASNs to multihome and IDR routing could be based solely on best path to the applicable DEST-AS and we wouldn't even need to carry prefixes beyond the local AS border. While I don't think DNS is up to the task of reliable distribution and caching (though something somewhat similar to DNS could do the job rather well), DNS-style resource records could be used. For example, instead of using my own AS1734 as I do today, my multi-homed household could be placed in the database with pointers to my two upstream ASNs as follows: 2620:0:930::/48 AS 10 6939 AS 10 8121 192.124.40.0/23 AS 10 6939 AS 10 8121 192.159.10.0/24 AS 10 6939 AS 10 8121 Or, if I wanted to do some traffic engineering, I could tweak the preferences to be non-equal values. The router doing the DEST-AS insertion into the packet would grab the most preferred AS to which it has a valid feasible successor. I believe that the number of transit autonomous systems on the planet is much smaller than the minimum number of prefixes to represent all multi-homed organizations with independent routing policies. As such, I believe this could produce much more scalable routing with relatively little additional overhead. Owen From owen at delong.com Tue Jun 5 01:18:16 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Jun 2012 23:18:16 -0700 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> Message-ID: On Jun 4, 2012, at 7:47 PM, Jimmy Hess wrote: > On 6/4/12, Owen DeLong wrote: > [snip] >> Probing as you have proposed requires you to essentially do a binary search >> to arrive >> at some number n where 1280?n?9000, so, you end up doing something like >> this: > [snip] >> So, you waited for 13 timeouts before you actually passed useful >> traffic? Or, perhaps you putter along at the lowest possible MTU until you > [snip] > Instead of waiting for 13 timeouts, start with 4 initial probes in > parallel, and react rapidly to the responses you receive; say > 9000,2200, 1500, 830. > What's the point of an 830 probe when the minimum valid MTU is 1280? > Don't wait until any timeouts until the possible MTUs are narrowed. > > > FindLocalMTU(B,T) > Let B := Minimum_MTU > Let T := Maximum_MTU > Let D := Max(1, Floor( ( (T - 1) - (B+1) ) / 4 )) > Let R := T > Let Attempted_Probes := [] > > While ( ( (B + D) < T ) or Attempted_Probes is not Empty ) do > If R is not a member of Attempted_Probes or Retries < 1 then > AsynchronouslySendProbeOfSize (R) > Append (R,Tries) to list of Attempted_Probes if not exists > or if (R,Tries) already in list then increment Retries. Did I miss the definition of Tries and/or Retries somewhere? ;-) > else > T := R - 1 > Delete from Attempted_Probes (R) > end > > if ( (B + D) < T ) AsynchronouslySendProbeOfSize (B+ D) > if ( (B + 2*D) < T ) AsynchronouslySendProbeOfSize (B+ 2*D) > if ( (B + 3*D) < T ) AsynchronouslySendProbeOfSize (B+ 3*D) > if ( (B + 4*D) < T ) AsynchronouslySendProbeOfSize (B+ 4*D) > Shouldn't all of those be <= T? > Wait_For_Next_Probe_Response_To_Arrive() > Wait_For_Additional_Probe_Response_Or_Short_Subsecond_Delay() > Add_Probe_Responses_To_Queue(Q) Not really a Queue, more of a list. In fact, no real need to maintain a list at all, you could simply keep a variable Q and let Q=max(Q,Probe_response) > R := Get_Largest_Received_Probe_Size(Q) Which would allow you to eliminate this line altogether and replace R below with Q. > If ( R > T ) then > T := R > end > > If ( R > B ) then > B := R > D := Max(1, Floor( ( (R - 1) - (B+1) ) / 4 )) > end > done > > Result := B > > > # > > If you receive the response at n=830 first, then wait 1ms and send the > next 4 probes 997 1164 1331 1498, and resend the n=1500 probe > If 1280 is what the probe needs to detect. You'll receive a > response for 1164 , so wait 1ms then retry n=1498 > next 4 probes are 1247 1330 1413 1496 > if 1280 is what the probe needs to detect, You'll receive a > response for 1247, so wait 1ms resend n=1496 > next 4 probes are 1267 1307 1327 1347 > if 1280 is what you neet to detect, you'll receive > response for 1267, so > retry n=1347 wait 1ms > next 4 probes are: 1276 1285 1294 1303 > next 4 probes are: 1277 1278 1279 1280 > next 2 parallel probes are: 1281 1282 > > You hit after 22 probes, but you only needed to wait for n=1281 n=1282 > and their retry to time out. > But that's a whole lot more packets than working PMTU-D to get there and you're also waiting for all those round trips, not just the 4 timeouts. The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at 100ms is 2.2 seconds. That's a long time to go without first data packet passed, Owen From stefan at nordu.net Tue Jun 5 04:04:10 2012 From: stefan at nordu.net (=?ISO-8859-1?Q?Stefan_Listr=F6m?=) Date: Tue, 05 Jun 2012 11:04:10 +0200 Subject: NOC presentations In-Reply-To: <4FCC920C.3070805@nordu.net> References: <4FCC920C.3070805@nordu.net> Message-ID: <4FCDCB8A.4000300@nordu.net> On 2012-06-04 12.46, Stefan Listr?m wrote: > Hi all, > > In TF-NOC we have been collecting information about NOCs for some time > now[1]. Most of the NOCs are from research and educational organizations > and we think it would also be very interesting to get the same kind of > information from commercial NOCs. I understand that many commercial > companies might not be able to share this information, but I thought it > might be worth asking. > > If you would like to share information about your NOC please check out > our presentation template[2] for inspiration and let me know. > > Even if you are not able to share information about your NOC the > information we have gathered will hopefully still be interesting for you. > > [1] http://www.terena.org/activities/tf-noc/nocs.html > [2] http://www.terena.org/activities/tf-noc/TF-NOC-flashpresentation-v2.ppt > Hi again, Got an off list reminder about the great NOC list at Puck: http://puck.nether.net/netops/nocs.cgi I forgot to mention that if you know any other groups of people that collect and publish information about NOCs I'd love to hear about it. But I also wanted to clarify that we are not trying to create a contact list for NOCs. We are more aiming at getting to know how different NOCs work. E.g. if you are responsible for a hybrid network a certain size or a distributed NOC what kind of tools and procedures do you find useful. So that other NOCs in a similar situation can be inspired and get useful tips on how they could improve their network operations. -- Best regards Stefan Listr?m From jmaimon at ttec.com Tue Jun 5 07:21:36 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 05 Jun 2012 08:21:36 -0400 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> Message-ID: <4FCDF9D0.1020004@ttec.com> Owen DeLong wrote: > > But that's a whole lot more packets than working PMTU-D to get there and > you're also waiting for all those round trips, not just the 4 timeouts. > > The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at > 100ms is 2.2 seconds. That's a long time to go without first data packet > passed, > > Owen Yes, it is quite nice when ICMP helpfully informs you what your MTU is. However, we have known for quite some time that is simply not reliable on the IPv4 internet, for a multitude of reasons, with intentional ICMP blocking just one of them. I have no reason to expect it to work better in IPv6. This is why more reliable methods are a good idea, even if they work slower or add more overhead, because as I see it they are intended to be used concurrently with ICMP. Also, as I understand the probing, getting data through happens much faster then arriving at the optimal mtu size might take. Perhaps short flows should just be sticking to the min-mtu anyways. Joe From mailing-lists at brianraaen.com Tue Jun 5 09:06:24 2012 From: mailing-lists at brianraaen.com (Brian Christopher Raaen) Date: Tue, 5 Jun 2012 10:06:24 -0400 Subject: ATT DSL IPv6 In-Reply-To: References: Message-ID: Probably, you were using Teredo or some other method to use IPv6. BTW if you have a Cisco gateway I have a blog post on how to set up a dynamic tunnel with HE. While native IPv6 would be best, the tunnel should work for you as I also have Bellsouth/AT&T DSL. http://www.brianraaen.com/2011/10/21/dynamic-he-tunnel-and-dyndns/ Brian Raaen Zcorum Network Architect On Mon, Jun 4, 2012 at 8:35 PM, Grant Ridder wrote: > Hi Everyone, > > Does anyone know about IPv6 on ATT residential DSL circuits? ?About 8 or 9 > months ago i ran through several IPv6 tests (http://test-ipv6.iad.vr.org/) > and they all passed. ?With all the talk of IPv6 day over the past week i > decided to run it again just out of curiosity. ?However to my surprise, it > is returning the result of IPv4 only now. ?Any ideas why they would have > rolled back IPv6? > > Thanks, > Grant From Jason_Livingood at cable.comcast.com Tue Jun 5 09:10:39 2012 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Tue, 5 Jun 2012 14:10:39 +0000 Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: Message-ID: In preparation for the World IPv6 Launch, inbound (SMTP) email to the comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. Roughly one minute later, at 9:35:30 UTC we received our first inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail was spam, and was caught by our Cloudmark messaging anti-abuse platform (the sender attempted a range of standard spam tactics in subsequent connections). In the past several hours we have of course seen other messages from a range of hosts, many of which were legitimate email ? so it wasn't just spam! ;-) Since the Internet is of course more than just the web, we encourage others to start making non-HTTP services available via IPv6 as well. Jason Livingood Comcast From raymond at prolocation.net Tue Jun 5 09:22:07 2012 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 5 Jun 2012 16:22:07 +0200 (CEST) Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: References: Message-ID: Jason, > In preparation for the World IPv6 Launch, inbound (SMTP) email to the > comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. > Roughly one minute later, at 9:35:30 UTC we received our first > inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail > was spam, and was caught by our Cloudmark messaging anti-abuse platform > (the sender attempted a range of standard spam tactics in subsequent > connections). You specificly tell 'inbound' ... by that you mean the MX record was added. But just to be sure. Comcast is also sending out over IPv6 now right? And if so, what protocol is preferred by default? Outgoing mail over IPv4 or over IPv6? > Since the Internet is of course more than just the web, we encourage > others to start making non-HTTP services available via IPv6 as well. Watching logs here to see if things (at least mail for me now) will raise the next few days... Bye, Raymond. From raymond at prolocation.net Tue Jun 5 09:29:24 2012 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 5 Jun 2012 16:29:24 +0200 (CEST) Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: References: Message-ID: Hi! > In preparation for the World IPv6 Launch, inbound (SMTP) email to the > comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. > Roughly one minute later, at 9:35:30 UTC we received our first > inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail > was spam, and was caught by our Cloudmark messaging anti-abuse platform > (the sender attempted a range of standard spam tactics in subsequent > connections). > > In the past several hours we have of course seen other messages from a > range of hosts, many of which were legitimate email ? so it wasn't just > spam! ;-) > > Since the Internet is of course more than just the web, we encourage > others to start making non-HTTP services available via IPv6 as well. Looking more closely... Is this still work in progress? ;; ANSWER SECTION: comcast.net. 358 IN MX 5 mx3.comcast.net. comcast.net. 358 IN MX 10 mx1.comcast.net. comcast.net. 358 IN MX 5 mx2.comcast.net. ;; ADDITIONAL SECTION: mx2.comcast.net. 6958 IN A 76.96.30.116 mx3.comcast.net. 358 IN A 68.87.26.147 mx1.comcast.net. 358 IN AAAA 2001:558:fe14:70::22 You are now only accepting IPv6 if all IPv4 fails? Or will AAAA records for mx2 and mx3 added later? Bye, Raymond. From dhubbard at dino.hostasaurus.com Tue Jun 5 09:29:57 2012 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 5 Jun 2012 10:29:57 -0400 Subject: ipv6 book recommendations? Message-ID: Does anyone have suggestions on good books to really get a thorough understanding of v6, subnetting, security practices, etc. Or a few books. Just turned up dual stack with our peers and a test network but I'd like to be a lot more comfortable with it before looking at our customer network. Thanks, David From jeroen at unfix.org Tue Jun 5 09:33:19 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 05 Jun 2012 07:33:19 -0700 Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: References: Message-ID: <4FCE18AF.80307@unfix.org> On 2012-06-05 07:29, Raymond Dijkxhoorn wrote: [..] > ;; ANSWER SECTION: > comcast.net. 358 IN MX 5 mx3.comcast.net. > comcast.net. 358 IN MX 10 mx1.comcast.net. > comcast.net. 358 IN MX 5 mx2.comcast.net. > > ;; ADDITIONAL SECTION: > mx2.comcast.net. 6958 IN A 76.96.30.116 > mx3.comcast.net. 358 IN A 68.87.26.147 > mx1.comcast.net. 358 IN AAAA 2001:558:fe14:70::22 > > You are now only accepting IPv6 if all IPv4 fails? > Or will AAAA records for mx2 and mx3 added later? Though it can work, it used to be a really bad idea as there where a couple of SMTP systems (Communigate Pro being one of them I recall) which just failed when not seeing an "A" on an MX, this as they did not understand IPv6... There is bound to be other systems that are broken like that that will not failover to the secondary MX, as such, you might want to add an IPv4 address there too just in case. Greets, Jeroen From rdobbins at arbor.net Tue Jun 5 09:33:54 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Jun 2012 14:33:54 +0000 Subject: ipv6 book recommendations? In-Reply-To: References: Message-ID: <74209A07-944E-4758-9CFF-7102DFE53787@arbor.net> On Jun 5, 2012, at 9:29 PM, David Hubbard wrote: > security practices ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From Fred.L.Templin at boeing.com Tue Jun 5 09:38:25 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 5 Jun 2012 07:38:25 -0700 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> Message-ID: A quick comment on probes. Making the tunnel ingress probe is tempting but fraught with difficulties; believe me, I have tried. So, having the tunnel ingress fragment when necessary in conjunction with the original source probing is the way forward, and we should advocate both approaches. RFC4821 specifies how the original source can probe with or without tunnels in the path. It does not have any RTT delays, because it starts small and then tries for larger sizes in parallel with getting the valuable data through without loss. Thanks - Fred fred.l.templin at boeing.com From seth.mos at dds.nl Tue Jun 5 09:42:43 2012 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 05 Jun 2012 16:42:43 +0200 Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: References: Message-ID: <4FCE1AE3.5030605@dds.nl> Op 5-6-2012 16:10, Livingood, Jason schreef: > In preparation for the World IPv6 Launch, inbound (SMTP) email to the > comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. > Roughly one minute later, at 9:35:30 UTC we received our first > inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail > was spam, and was caught by our Cloudmark messaging anti-abuse platform > (the sender attempted a range of standard spam tactics in subsequent > connections). > > In the past several hours we have of course seen other messages from a > range of hosts, many of which were legitimate email ? so it wasn't just > spam! ;-) > > Since the Internet is of course more than just the web, we encourage > others to start making non-HTTP services available via IPv6 as well. I always wondered why (ISPs) never started with rolling out IPv6 email servers first, the fallback from 6 to 4 is transparent and invisible to the end user at a delay of a maximum of 30 seconds. I enabled v6 for my email before my website since the impact if it didn't work on the 1st try was almost nil. Still waiting for the 1st Country to top Romania' 6% deployment. I'm sure we can do better then 0.21. IMHO Asking users if they want IPv6 is the wrong way round, you enable IPv6 and then allow for opt-out in the service portal. That's basically what the Romanian ISP did. They have not gone bankrupt either, so maybe it's not all as bad as we think. Cheers, Seth From seth.mos at dds.nl Tue Jun 5 09:45:07 2012 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 05 Jun 2012 16:45:07 +0200 Subject: ipv6 book recommendations? In-Reply-To: References: Message-ID: <4FCE1B73.9080102@dds.nl> Op 5-6-2012 16:29, David Hubbard schreef: > Does anyone have suggestions on good books to really get > a thorough understanding of v6, subnetting, security practices, > etc. Or a few books. Just turned up dual stack with our > peers and a test network but I'd like to be a lot more > comfortable with it before looking at our customer network. I liked the O'reilly IPv6 essentials. I've read a few chapters when I needed it. Cheers, Seth From cgrundemann at gmail.com Tue Jun 5 09:44:34 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 5 Jun 2012 08:44:34 -0600 Subject: ipv6 book recommendations? In-Reply-To: <74209A07-944E-4758-9CFF-7102DFE53787@arbor.net> References: <74209A07-944E-4758-9CFF-7102DFE53787@arbor.net> Message-ID: I believe that Silvia Hagan's book [1] is still the primary reference available, but there are others reviewed here: http://getipv6.info/index.php/Book_Reviews. Cheers, ~Chris PS - Shameless plug: If you're running Juniper, I wrote two books for them that you can get for free [2][3]. And I have an intro to IPv6 done in four parts on my blog as well (read from the bottom up) [4]. [1] - http://shop.oreilly.com/product/9780596100582.do [2] - http://chrisgrundemann.com/index.php/2010/day-exploring-ipv6/ [3] - http://chrisgrundemann.com/index.php/2011/day-advanced-ipv6-configuration/ [4] - http://chrisgrundemann.com/index.php/category/ipv6/introducing-ipv6/ On Tue, Jun 5, 2012 at 8:33 AM, Dobbins, Roland wrote: > > On Jun 5, 2012, at 9:29 PM, David Hubbard wrote: > >> security practices > > > > > > ----------------------------------------------------------------------- > Roland Dobbins // > > ? ? ? ? ?Luck is the residue of opportunity and design. > > ? ? ? ? ? ? ? ? ? ? ? -- John Milton > > -- @ChrisGrundemann http://chrisgrundemann.com From jeroen at unfix.org Tue Jun 5 09:44:27 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 05 Jun 2012 07:44:27 -0700 Subject: New routing systems (Was: IPv6 day and tunnels) In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> <0E60355A-88A1-4A8B-BF5E-248011FF7711@delong.com> <4FCD5CDC.3060209@unfix.org> Message-ID: <4FCE1B4B.8060602@unfix.org> On 2012-06-04 23:06, Owen DeLong wrote: > > On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote: > >> On 2012-06-04 17:57, Owen DeLong wrote: [..] >>> If you're going to redesign the header, I'd be much more >>> interested in having 32 bits for the destination ASN so that IDR >>> can ignore IP prefixes altogether. >> >> One can already do that: route your IPv6 over IPv4.... IPv4 has >> 32bit destination addresses remember? :) >> >> It is also why it is fun if somebody uses a 32-bit ASN to route >> IPv4, as one is not making the problem smaller that way. ASNs are >> more used as identifiers to avoid routing loops than as actual >> routing parameters. >> >> Greets, Jeroen > > While this is true today (to some extent), it doesn't have to always > be true. > > If we provided a reliable scaleable mechanism to distribute and cache > prefix->ASN mappings and could reliably populate a DEST-AS field in > the packet header, stub networks would no longer need separate ASNs > to multihome and IDR routing could be based solely on best path to > the applicable DEST-AS and we wouldn't even need to carry prefixes > beyond the local AS border. The problem here does not lie with the fact that various of these systems (LISP comes to mind amongst others) have been well researched and implemented already, but with the fact that the general operator community will not change to such a new system as it is not what they are used to. Greets, Jeroen From Jason_Livingood at cable.comcast.com Tue Jun 5 09:45:41 2012 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Tue, 5 Jun 2012 14:45:41 +0000 Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: Message-ID: On 6/5/12 10:22 AM, "Raymond Dijkxhoorn" wrote: >You specificly tell 'inbound' ... by that you mean the MX record was >added. But just to be sure. Comcast is also sending out over IPv6 now >right? And if so, what protocol is preferred by default? Outgoing mail >over IPv4 or over IPv6? Outbound SMTP will be enabled very soon (likely within 24 hours). - Jason From Fred.L.Templin at boeing.com Tue Jun 5 09:45:58 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 5 Jun 2012 07:45:58 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Monday, June 04, 2012 4:40 PM > To: Templin, Fred L; nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > > I'm not sure that a randomly-chosen "skip" value is even > > necessary. > > It is not necessary, because, for ID uniqueness fundamentalists, > single event is bad enough and for most operators, slight > possibility is acceptable. > > > Outer fragmentation cooks the tunnel egresses at high > > data rates. > > Have egresses with proper performance. That's the proper > operation. How many core routers would be happy to reassemble at line rates without a forklift upgrade and/or strong administrative tuning? > > End systems are expected and required to > > reassemble on their own behalf. > > That is not a proper operation of tunnels. Why not? > >> Thus, don't insist on having unique IDs so much. > > > > Non-overlapping fragments are disallowed for IPv6, but > > I think are still allowed for IPv4. So, IPv4 still needs > > the unique IDs by virtue of rate limiting. > > Even though there is no well defined value of MSL? MSL is well defined. For TCP, it is defined in RFC793. For IPv4 reassembly, it is defined in RFC1122. For IPv6 reassembly, it is defined in RFC2460. > >> I'm talking about not protocol recommendation but proper > >> operation. > > > > I don't see any operational guidance recommending the > > tunnel ingress to configure an MRU of 1520 or larger. > > I'm talking about not operation guidance but proper > operation. The tunnel ingress cannot count on administrative tuning on the egress - all it can count on is reassembly of 1500 or smaller and it can't count on good performance even at those levels. > Proper operators can, without any guidance, perform proper > operation. No amount of proper operation can fix a platform that does not have adequate performance. And, there is no way for the tunnel ingress to tell what, if any, mitigations have been applied at the egress. Thanks - Fred fred.l.templin at boeing.com > Masataka Ohta From raymond at prolocation.net Tue Jun 5 09:46:08 2012 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 5 Jun 2012 16:46:08 +0200 (CEST) Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: <4FCE1AE3.5030605@dds.nl> References: <4FCE1AE3.5030605@dds.nl> Message-ID: Hi! Seth, >> In the past several hours we have of course seen other messages from a >> range of hosts, many of which were legitimate email ? so it wasn't just >> spam! ;-) >> >> Since the Internet is of course more than just the web, we encourage >> others to start making non-HTTP services available via IPv6 as well. > I always wondered why (ISPs) never started with rolling out IPv6 email > servers first, the fallback from 6 to 4 is transparent and invisible to the > end user at a delay of a maximum of 30 seconds. > > I enabled v6 for my email before my website since the impact if it didn't > work on the 1st try was almost nil. > > Still waiting for the 1st Country to top Romania' 6% deployment. I'm sure we > can do better then 0.21. > > IMHO Asking users if they want IPv6 is the wrong way round, you enable IPv6 > and then allow for opt-out in the service portal. > > That's basically what the Romanian ISP did. They have not gone bankrupt > either, so maybe it's not all as bad as we think. I think its pretty simple. Many do this, but protection is little. Abuse also but that may change. To get to the point. There are no widely available IPv6 blacklists. Like you are used to have on IPv4. Might be a legitimate reason ... Lets see how Comcast does. Bye, Raymond. From Jason_Livingood at cable.comcast.com Tue Jun 5 09:47:41 2012 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Tue, 5 Jun 2012 14:47:41 +0000 Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: <4FCE18AF.80307@unfix.org> Message-ID: On 6/5/12 10:33 AM, "Jeroen Massar" wrote: >Though it can work, it used to be a really bad idea as there where a >couple of SMTP systems (Communigate Pro being one of them I recall) >which just failed when not seeing an "A" on an MX, this as they did not >understand IPv6... > >There is bound to be other systems that are broken like that that will >not failover to the secondary MX, as such, you might want to add an IPv4 >address there too just in case. Thanks for the advice. You are seeing inbound records in the very first stage. More AAAA RRs are coming. The next 24-48 hours around World IPv6 Launch will be interesting. Jason From Fred.L.Templin at boeing.com Tue Jun 5 09:49:27 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 5 Jun 2012 07:49:27 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> Message-ID: > The proper solution is to have a field in IPv7 header to > measure PMTU. It can be a 8 bit field, if fragment granularity > is 256B. We tried that for IPv4 and it didn't work very well [RFC1063]. You are welcome to try again in IPv7 when we have a green field. Fred fred.l.templin at boeing.com From Timothy.Green at ManTech.com Tue Jun 5 09:52:54 2012 From: Timothy.Green at ManTech.com (Green, Timothy) Date: Tue, 5 Jun 2012 10:52:54 -0400 Subject: Penetration Test Assistance Message-ID: Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a "complete" network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Thanks, Tim ________________________________ This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments. From marka at isc.org Tue Jun 5 09:55:06 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 06 Jun 2012 00:55:06 +1000 Subject: IPv6 day and tunnels In-Reply-To: Your message of "Tue, 05 Jun 2012 07:38:25 MST." References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> Message-ID: <20120605145506.D3BED2148E7B@drugs.dv.isc.org> In message , "Templin, Fred L" writes: > A quick comment on probes. Making the tunnel ingress probe > is tempting but fraught with difficulties; believe me, I > have tried. So, having the tunnel ingress fragment when > necessary in conjunction with the original source probing > is the way forward, and we should advocate both approaches. > > RFC4821 specifies how the original source can probe with > or without tunnels in the path. It does not have any RTT > delays, because it starts small and then tries for larger > sizes in parallel with getting the valuable data through > without loss. It's useful for TCP but it is not a general solution. PTB should not be being blocked and for some applications one should just force minimum mtu use. > Thanks - Fred > fred.l.templin at boeing.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From Fred.L.Templin at boeing.com Tue Jun 5 10:00:59 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 5 Jun 2012 08:00:59 -0700 Subject: IPv6 day and tunnels In-Reply-To: <20120605145506.D3BED2148E7B@drugs.dv.isc.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> <20120605145506.D3BED2148E7B@drugs.dv.isc.org> Message-ID: > -----Original Message----- > From: Mark Andrews [mailto:marka at isc.org] > Sent: Tuesday, June 05, 2012 7:55 AM > To: Templin, Fred L > Cc: Owen DeLong; Jimmy Hess; nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > > In message 01V.nw.nos.boeing > .com>, "Templin, Fred L" writes: > > A quick comment on probes. Making the tunnel ingress probe > > is tempting but fraught with difficulties; believe me, I > > have tried. So, having the tunnel ingress fragment when > > necessary in conjunction with the original source probing > > is the way forward, and we should advocate both approaches. > > > > RFC4821 specifies how the original source can probe with > > or without tunnels in the path. It does not have any RTT > > delays, because it starts small and then tries for larger > > sizes in parallel with getting the valuable data through > > without loss. > > It's useful for TCP but it is not a general solution. PTB should > not be being blocked and for some applications one should just force > minimum mtu use. Any packetization layer that is capable of getting duplicate ACKs from the peer can do it. Plus, support for just TCP is all that is needed for the vast majority of end systems at the current time. Thanks - Fred fred.l.templin at boeing.com > > Thanks - Fred > > fred.l.templin at boeing.com > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From galu at packetdam.com Tue Jun 5 10:20:17 2012 From: galu at packetdam.com (Vlad Galu) Date: Tue, 5 Jun 2012 16:20:17 +0100 Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: <4FCE1AE3.5030605@dds.nl> References: <4FCE1AE3.5030605@dds.nl> Message-ID: <58531452365244BFB67F44DB28B69B51@packetdam.com> On Tuesday, June 5, 2012 at 3:42 PM, Seth Mos wrote: > Op 5-6-2012 16:10, Livingood, Jason schreef: > > I enabled v6 for my email before my website since the impact if it > didn't work on the 1st try was almost nil. > > Still waiting for the 1st Country to top Romania' 6% deployment. I'm > sure we can do better then 0.21. > > IMHO Asking users if they want IPv6 is the wrong way round, you enable > IPv6 and then allow for opt-out in the service portal. > > That's basically what the Romanian ISP did. They have not gone bankrupt > either, so maybe it's not all as bad as we think. > It is actually opt-in. But they've advertised it a lot in the months before mass deployment and their user base was educated and willing enough to toggle the knob. -- PacketDam: a cost-effective software solution against DDoS From lathama at gmail.com Tue Jun 5 10:32:20 2012 From: lathama at gmail.com (Andrew Latham) Date: Tue, 5 Jun 2012 11:32:20 -0400 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: On Tue, Jun 5, 2012 at 10:52 AM, Green, Timothy wrote: > Howdy all, > > I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. ?We don't have a "complete" network diagram that shows everything and everywhere we are. ?At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. > > I've never been in this situation before. ?Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; ?find everything else? ?How would they access those areas that we haven't identified? ? How can I give them access to stuff that I didn't know existed? > > What do you all do with your large networks? ?One huge network diagram, a bunch of network diagrams separated by region, or both? ?Any pentest horror stories? > > Thanks, > > Tim Any penetration test should only require your networks and masks. As far as a diagram it is of value to keep a staff member with the singular task of documentation and auditing or an optional contract basis. Small things like typographical errors can cause great confusion in emergency situations. Take the time and do it right. I personally prefer the flexibility and ease of use that Mediawiki offers but other free and pay solutions exist. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From streiner at cluebyfour.org Tue Jun 5 10:52:33 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 5 Jun 2012 11:52:33 -0400 (EDT) Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: On Tue, 5 Jun 2012, Green, Timothy wrote: > I'm a Security Manager of a large network, we are conducting a Pentest > next month and the testers are demanding a complete network diagram of > the entire network. We don't have a "complete" network diagram that > shows everything and everywhere we are. At most we have a bunch of > network diagrams that show what we have in various areas throughout the > country. I've been asking the network engineers for over a month and > they seem to be too lazy to put it together or they have no idea where > everything is. As someone who is charged with both engineering and maintaining the records and diagrams of a large network, I take exception to the word 'lazy' ;) Network engineers tend to be an over-worked lot, and their work is often interrupt-driven, so large blocks of time to work on a single task are often a rarity. The issue is that if they haven't kept their diagrams up to date (many people don't, unfortunately), then getting them up to date turns into a much more labor-intensive job. If they have kept the diagrams up to date and they're just not getting them to you, then take the issue up with their manager. There might also be the question of how much information they are allowed to release to third parties, even if it is for a pentest. This could mean that some information might need to be removed or redacted from the diagrams. Again, the engineering manager/director/CIO/CTO might be able to provide clarification on this. > I've never been in this situation before. Should I be honest to the > testers and tell them here is what we have, we aren't sure if it's > accurate; find everything else? How would they access those areas that > we haven't identified? How can I give them access to stuff that I > didn't know existed? >From what I've seen, in-depth pentests are often done in coordination with other groups, such as engineering/ops. In a large network, that's often done out of necessity, if for no other reason than dealing with issues like the ones you've raised (logistics, communication, etc...). > What do you all do with your large networks? One huge network diagram, > a bunch of network diagrams separated by region, or both? Any pentest > horror stories? I don't have any pentest horror stories, but sometimes large network diagrams have to be broken up into pieces, to maintain some degree of readability. Large diagrams can get cluttered very quickly if you try to put every minute piece of detail on them. I tend to treat the main diagram as a high-level view of the network, and then either break out sections that need more detail as a separate drawing, or as a link to our internal knowledge base that can go into very high detail, including pictures, access information, etc. There is no right way to diagram every network. It depends on what best suits your needs, and what established proceures are already in place. jms From matthew at matthew.at Tue Jun 5 11:06:54 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 05 Jun 2012 09:06:54 -0700 Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: <4FCE1AE3.5030605@dds.nl> References: <4FCE1AE3.5030605@dds.nl> Message-ID: <4FCE2E9E.8080504@matthew.at> On 6/5/2012 7:42 AM, Seth Mos wrote: > Op 5-6-2012 16:10, Livingood, Jason schreef: >> In preparation for the World IPv6 Launch, inbound (SMTP) email to the >> comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. >> Roughly one minute later, at 9:35:30 UTC we received our first >> inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit >> of mail >> was spam, and was caught by our Cloudmark messaging anti-abuse platform >> (the sender attempted a range of standard spam tactics in subsequent >> connections). >> >> In the past several hours we have of course seen other messages from a >> range of hosts, many of which were legitimate email ? so it wasn't just >> spam! ;-) >> >> Since the Internet is of course more than just the web, we encourage >> others to start making non-HTTP services available via IPv6 as well. > > I always wondered why (ISPs) never started with rolling out IPv6 email > servers first, the fallback from 6 to 4 is transparent and invisible > to the end user at a delay of a maximum of 30 seconds. My email will come in via IPv6 as soon as Postini has IPv6 inbound and outbound. As far as I can tell, they still have neither, despite requests going back to 2009. Matthew Kaufman From deleskie at gmail.com Tue Jun 5 11:07:36 2012 From: deleskie at gmail.com (jim deleskie) Date: Tue, 5 Jun 2012 13:07:36 -0300 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: A complete diagram makes their life easier, may make for a more complete test, but they are working for you, so if you don't have it, you don't have. I'm not a big fan of having a single diagram with everything laid out anyway, but I'm from the old shcool. -jim On Tue, Jun 5, 2012 at 11:52 AM, Green, Timothy wrote: > Howdy all, > > I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. ?We don't have a "complete" network diagram that shows everything and everywhere we are. ?At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. > > I've never been in this situation before. ?Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; ?find everything else? ?How would they access those areas that we haven't identified? ? How can I give them access to stuff that I didn't know existed? > > What do you all do with your large networks? ?One huge network diagram, a bunch of network diagrams separated by region, or both? ?Any pentest horror stories? > > Thanks, > > Tim > > ________________________________ > This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments. From joelja at bogus.com Tue Jun 5 11:09:51 2012 From: joelja at bogus.com (Joel jaeggli) Date: Tue, 05 Jun 2012 09:09:51 -0700 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: <4FCE2F4F.2030209@bogus.com> On 6/5/12 07:52 , Green, Timothy wrote: > Howdy all, > > I'm a Security Manager of a large network, we are conducting a > Pentest next month and the testers are demanding a complete network > diagram of the entire network. We don't have a "complete" network > diagram that shows everything and everywhere we are. At most we have > a bunch of network diagrams that show what we have in various areas > throughout the country. I've been asking the network engineers for > over a month and they seem to be too lazy to put it together or they > have no idea where everything is. > > I've never been in this situation before. Should I be honest to the > testers and tell them here is what we have, we aren't sure if it's > accurate; find everything else? How would they access those areas > that we haven't identified? How can I give them access to stuff > that I didn't know existed? > > What do you all do with your large networks? One huge network > diagram, a bunch of network diagrams separated by region, or both? > Any pentest horror stories? Logical diagrams tend to elide the information consider unnecessary for them to be suitably informative. An ethernet switch with 560 network segments radiating out from it may be accurate but not all that easy to parse or use. Documentation needs to be sufficiently accurate and appropiate to the tasks at hand, so it may be that you don't have what you need or perhaps you do. > Thanks, > > Tim > > ________________________________ This e-mail and any attachments are > intended only for the use of the addressee(s) named herein and may > contain proprietary information. If you are not the intended > recipient of this e-mail or believe that you received this email in > error, please take immediate action to notify the sender of the > apparent error by reply e-mail; permanently delete the e-mail and any > attachments from your computer; and do not disseminate, distribute, > use, or copy this message and any attachments. > From listas at esds.com.br Tue Jun 5 11:17:40 2012 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 5 Jun 2012 13:17:40 -0300 Subject: IPv6 Facebook In-Reply-To: References: Message-ID: Hello, Somewhere from GlobalCrossing/Level3 here to contact me off list? Here from Brazil we are going thru Europe to reach the Facebook on USA. # mtr -c 100 -wr www.facebook.com HOST: border02.scr Loss% Snt Last Avg Best Wrst StDev 1.|-- 2.|-- 3.|-- 2804:1b0:1000:4e05:: 0.0% 100 4.0 7.3 3.1 202.1 24.7 4.|-- 2001:450:2002:448::1 0.0% 100 68.5 63.8 59.4 79.5 5.4 5.|-- 2001:450:2001:800a::2 0.0% 100 143.0 153.3 143.0 336.8 31.8 6.|-- 2001:1900:5:3::12d 1.0% 100 323.6 328.0 323.1 427.2 14.6 7.|-- vl-4080.edge3.*Paris1*.Level3.net 0.0% 100 322.3 323.7 321.9 352.9 5.1 8.|-- vl-4086.car1.Washington1.Level3.net 1.0% 100 348.0 356.8 341.0 570.6 36.0 9.|-- vl-60.edge3.Washington4.Level3.net 0.0% 100 337.1 339.6 336.5 373.2 6.9 10.|-- FACEBOOK-IN.edge3.Washington4.Level3.net 0.0% 100 341.1 344.6 340.7 400.8 12.0 11.|-- ae1.bb02.iad2.tfbnw.net 1.0% 100 337.9 339.3 336.3 385.1 8.3 12.|-- ae8.bb04.prn1.tfbnw.net 1.0% 100 403.7 404.8 403.1 445.0 5.7 13.|-- ae3.dr05.prn1.tfbnw.net 1.0% 100 403.4 404.5 402.7 455.8 6.9 14.|-- 2620:0:1cff:dead:beee::149 1.0% 100 410.6 406.5 404.4 454.2 6.3 15.|-- www6-10-08-prn1.facebook.com 1.0% 100 403.5 402.8 401.8 406.5 0.8 Regards, -- Eduardo Schoedler From lostinmoscow at gmail.com Tue Jun 5 11:34:59 2012 From: lostinmoscow at gmail.com (Quinn Kuzmich) Date: Tue, 5 Jun 2012 10:34:59 -0600 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: It's not much of a penetration test, imho, if the "attackers" have detailed knowledge of your network and systems before the attack. You should determine what kind of a scenario you are trying to simulate, and how the results will be used to improve security. Is this a "black box" situation, where you want to see what potential attackers can discover about your systems without insider information? Or will this be a step by step, examine each part of the system and then step back to see what's going on from a high level scenario? If you're trying to both reduce vulnerabilities and your attack profile, I would go for the black box approach and see what your pentesters can come up with themselves. Man is a resourceful creature, and you never know what they could turn up. Q On Tue, Jun 5, 2012 at 8:52 AM, Green, Timothy wrote: > Howdy all, > > I'm a Security Manager of a large network, we are conducting a Pentest > next month and the testers are demanding a complete network diagram of the > entire network. We don't have a "complete" network diagram that shows > everything and everywhere we are. At most we have a bunch of network > diagrams that show what we have in various areas throughout the country. > I've been asking the network engineers for over a month and they seem to be > too lazy to put it together or they have no idea where everything is. > > I've never been in this situation before. Should I be honest to the > testers and tell them here is what we have, we aren't sure if it's > accurate; find everything else? How would they access those areas that we > haven't identified? How can I give them access to stuff that I didn't > know existed? > > What do you all do with your large networks? One huge network diagram, a > bunch of network diagrams separated by region, or both? Any pentest horror > stories? > > Thanks, > > Tim > > ________________________________ > This e-mail and any attachments are intended only for the use of the > addressee(s) named herein and may contain proprietary information. If you > are not the intended recipient of this e-mail or believe that you received > this email in error, please take immediate action to notify the sender of > the apparent error by reply e-mail; permanently delete the e-mail and any > attachments from your computer; and do not disseminate, distribute, use, or > copy this message and any attachments. > From mohta at necom830.hpcl.titech.ac.jp Tue Jun 5 11:37:17 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Jun 2012 01:37:17 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> Message-ID: <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: >> Have egresses with proper performance. That's the proper >> operation. > How many core routers would be happy to reassemble at > line rates without a forklift upgrade and/or strong > administrative tuning? You don't have to do it with core routers. >>> End systems are expected and required to >>> reassemble on their own behalf. >> >> That is not a proper operation of tunnels. > Why not? Lack of transparency. >> Even though there is no well defined value of MSL? > > MSL is well defined. For TCP, it is defined in RFC793. > For IPv4 reassembly, it is defined in RFC1122. For IPv6 > reassembly, it is defined in RFC2460. As you can see, they are different values. >> I'm talking about not operation guidance but proper >> operation. > > The tunnel ingress cannot count on administrative tuning > on the egress I'm afraid you don't understand tunnel operation at all. > No amount of proper operation can fix a platform that > does not have adequate performance. Choosing a proper platform is a part of proper operation. Masataka Ohta From BaklarR at amtrak.com Tue Jun 5 11:41:38 2012 From: BaklarR at amtrak.com (Baklarz, Ron) Date: Tue, 5 Jun 2012 12:41:38 -0400 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: Not discounting the need for network diagrams, there are also differing approaches to pen testing. One alternative is a sort of black-box approach where the pen testers are given little or no advanced knowledge of the network. It is up to them to 'discover' what they can through open source means and commence their attacks from what they glean from their intelligence gathering. This way they are realistically mimicking the hacker methodology. Ron Baklarz C|CISO, CISSP, CISA, CISM, NSA-IAM/IEM Chief Information Security Officer Export Control Compliance Officer National Passenger Railroad Corporation (AMTRAK) 10 G Street, NE Office 6E606 Washington, DC 20002 BaklarR at Amtrak.com -----Original Message----- From: Green, Timothy [mailto:Timothy.Green at ManTech.com] Sent: Tuesday, June 05, 2012 10:53 AM To: nanog at nanog.org Subject: Penetration Test Assistance Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a "complete" network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Thanks, Tim ________________________________ This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments. From sparctacus at gmail.com Tue Jun 5 11:43:15 2012 From: sparctacus at gmail.com (Bryan Irvine) Date: Tue, 5 Jun 2012 09:43:15 -0700 Subject: ipv6 book recommendations? In-Reply-To: References: Message-ID: On Tue, Jun 5, 2012 at 7:29 AM, David Hubbard wrote: > Does anyone have suggestions on good books to really get > a thorough understanding of v6, subnetting, security practices, > etc. ?Or a few books. ?Just turned up dual stack with our > peers and a test network but I'd like to be a lot more > comfortable with it before looking at our customer network. Network Warrior. Sounds a bit silly since it's a bit of an overview of lots of different things, however it's chapters on IPV6 get right to the point and helped clear up a lot of things for me. -B From mohta at necom830.hpcl.titech.ac.jp Tue Jun 5 11:43:09 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Jun 2012 01:43:09 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> Message-ID: <4FCE371D.40708@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: >> The proper solution is to have a field in IPv7 header to >> measure PMTU. It can be a 8 bit field, if fragment granularity >> is 256B. > We tried that for IPv4 and it didn't work very well [RFC1063]. IP option is a bad idea, which is partly why IPv6 sucks. Masataka Ohta From alter3d at alter3d.ca Tue Jun 5 11:52:29 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 05 Jun 2012 12:52:29 -0400 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: <4FCE394D.4040102@alter3d.ca> On 12-06-05 11:32 AM, Andrew Latham wrote: > On Tue, Jun 5, 2012 at 10:52 AM, Green, Timothy > wrote: >> Howdy all, >> >> I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a "complete" network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. >> >> I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? >> >> What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? >> >> Thanks, >> >> Tim > Any penetration test should only require your networks and masks. As > far as a diagram it is of value to keep a staff member with the > singular task of documentation and auditing or an optional contract > basis. Small things like typographical errors can cause great > confusion in emergency situations. Take the time and do it right. I > personally prefer the flexibility and ease of use that Mediawiki > offers but other free and pay solutions exist. > Yup, a list of subnets in use on your network is all I've ever needed to provide to pen testers in the past on the few occasions I've worked with them. A good pen test should scan everything on your network anyways, with a reasonable chance of figuring out what everything is. As far as horror stories... yeah. My most memorable experience was a guy (with a CISSP designation, working for a company who came highly recommended) who: - Spent a day trying to get his Backtrack CD to "work properly". When I looked at it, it was just a color depth issue in X that took about 45 seconds from "why is this broken?" to "hey look, I fixed it!". - Completely missed the honeypot machine I set up for the test. I had logs from the machine showing that his scanning had hit the machine and had found several of the vulnerabilities, but the entire machine was absent from the report. - Called us complaining that a certain behavior that "he'd never seen before" was happening when he tried to nmap our network. The "certain behavior" was a firewall with some IPS functionality, along with him not knowing how to read nmap output. - Completely messed up the report -- three times. His report had the wrong ports & vulnerabilities listed on the wrong IPs, so according to the report, we apparently had FreeBSD boxes running IOS or MS SQL... - Stopped taking our calls when we asked why the honeypot machine was completely missing from the report. In general, my experience with most "pen testers" is a severe disappointment, and isn't anything that couldn't be done in-house by taking the person in your department who has the most ingrained hacker/geek personality, giving them Nessus/Metasploit/nmap/etc, pizza and a big ass pot of coffee, and saying "Find stuff we don't know about. Go.". There is the occasional pen tester who is absolutely phenomenal and does the job properly (i.e. the guys who actually write their own shellcode, etc), but the vast majority of "pen testers" just use automated tools and call it a day. Like everything else in IT, security has been "commercialized" to the point where finding really good vendors/people is hard, because everyone and their mom has CEH, CISSP, and whatever other alphabet soup certifications you can imagine. From isabeldias1 at yahoo.com Tue Jun 5 12:07:55 2012 From: isabeldias1 at yahoo.com (isabel dias) Date: Tue, 5 Jun 2012 10:07:55 -0700 (PDT) Subject: ipv6 book recommendations? In-Reply-To: <4FCE1B73.9080102@dds.nl> References: <4FCE1B73.9080102@dds.nl> Message-ID: <1338916075.13606.YahooMailNeo@web121602.mail.ne1.yahoo.com> http://long.ccaba.upc.es/long/070Related_Activities/020Documents/IPv6_An_Internet_Revolution.pdf ? ? worth going through certification................ ________________________________ From: Seth Mos To: nanog at nanog.org Sent: Tuesday, June 5, 2012 3:45 PM Subject: Re: ipv6 book recommendations? Op 5-6-2012 16:29, David Hubbard schreef: > Does anyone have suggestions on good books to really get > a thorough understanding of v6, subnetting, security practices, > etc.? Or a few books.? Just turned up dual stack with our > peers and a test network but I'd like to be a lot more > comfortable with it before looking at our customer network. I liked the O'reilly IPv6 essentials. I've read a few chapters when I needed it. Cheers, Seth From mysidia at gmail.com Tue Jun 5 12:15:26 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 5 Jun 2012 12:15:26 -0500 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> Message-ID: On 6/5/12, Owen DeLong wrote: [snip] > But that's a whole lot more packets than working PMTU-D to get there and > you're also waiting for all those round trips, not just the 4 timeouts. > The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at > 100ms is 2.2 seconds. That's a long time to go without first data packet I'm only suggesting probing to discover the MTU between neighboring endpoints directly connected to the same subnet -- Layer 2 interconnect. PTMU doesn't work, because devices know the MTU of _their link_, but not necessarily the MTU of every intervening bridge or L2 tunnel, Not for IP end-end-to-end MTU discovery. The "too big packet" forwarded is just discarded by the L2 bridge, there's no ICMP packet that can result from that, the L2 bridge might not even have an IP address to source one from, so the PMTU method which relies on ICMP alone cannot possibly work. The router after discovering the local MTU constraints to its neighbors would then be responsible for sending TooBig messages as needed or passing on the MTU constraint. You've got an issue if there are 100ms between two peers on your LAN. You're right, you don't need to probe for possible MTUs below 1280. -- -JH From bill at herrin.us Tue Jun 5 12:23:32 2012 From: bill at herrin.us (William Herrin) Date: Tue, 5 Jun 2012 13:23:32 -0400 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: On 6/5/12, Green, Timothy wrote: > I'm a Security Manager of a large network, we are conducting a Pentest next > month and the testers are demanding a complete network diagram of the entire > network. We don't have a "complete" network diagram that shows everything > and everywhere we are. At most we have a bunch of network diagrams that > show what we have in various areas throughout the country. I've been asking > the network engineers for over a month and they seem to be too lazy to put > it together or they have no idea where everything is. > > I've never been in this situation before. Should I be honest to the testers > and tell them here is what we have, we aren't sure if it's accurate; find > everything else? Tim, Your system is what it is, including any defects in configuration management. Provide the testers with what you have, give them contact info for the engineers so they can ask questions and specify that you expect strengths and weaknesses in configuration management which impact system security to be reflected in their report. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Tue Jun 5 12:40:37 2012 From: jcurran at arin.net (John Curran) Date: Tue, 5 Jun 2012 17:40:37 +0000 Subject: Fwd: [arin-announce] IPv4 Countdown Plan Update References: <4FCE3CA6.1030604@arin.net> Message-ID: <240DC556-0172-49F9-877A-05EE2FA8B8B8@corp.arin.net> NANOG Folks - Apologies for cross-posting, but this is very important information for all organizations about how requests for IPv4 address space will be handled as we approach runout in this region. FYI (& Thanks!) /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] IPv4 Countdown Plan Update Date: June 5, 2012 10:06:46 AM PDT To: > On 23 April 2012 during ARIN XXIX in Vancouver, Leslie Nobile, Director of Registration Services gave a presentation on ARIN's plan to manage the distribution of its remaining IPv4 address pool. You can view the presentation at: https://www.arin.net/participate/meetings/reports/ARIN_XXIX/webcast/nobile_ipv4_countdown.mov We received some great input and in response have made a few adjustments to the Countdown Plan. * The time window to complete payment and the RSA have been extended from 45 to 60 days. * Reinstatement of a 30 day hold period for returned, revoked and reclaimed resources during the final phase of the countdown, when ARIN supply is at or below one /8 equivalent. * The block size distribution of ARIN's remaining IPv4 inventory is now available on the page and will be updated daily. The ARIN community has worked together over the last several years in developing policy to manage how ARIN allocates and assigns IPv4 addresses. ARIN has reviewed and refined its procedures to create an IPv4 Countdown Plan explaining how IPv4 requests will be processed as the remaining IPv4 address pool is distributed. We have posted the details of the plan at: https://www.arin.net/resources/request/ipv4_countdown.html The IPv4 Countdown is a dynamic process and we will notify the community as we approach and reach the trigger points for each new phase of the plan. ARIN will be updating and adding more information to the IPv4 Countdown page as we move through this process, so we strongly encourage you to pay attention to announcements and keep track of the current IPv4 inventory by monitoring the counter on the ARIN homepage. Because the IPv4 inventory may fluctuate on a daily basis, it is not intended as a tool to guide the timing of your IPv4 resource requests. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From Fred.L.Templin at boeing.com Tue Jun 5 12:46:08 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 5 Jun 2012 10:46:08 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Tuesday, June 05, 2012 9:37 AM > To: Templin, Fred L > Cc: nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > >> Have egresses with proper performance. That's the proper > >> operation. > > > How many core routers would be happy to reassemble at > > line rates without a forklift upgrade and/or strong > > administrative tuning? > > You don't have to do it with core routers. Tunnel endpoints can be located either nearer the edges or nearer the middle. Tunnel endpoints that are located nearer the edges might be able to do reassembly at nominal data rates, but there is no assurance of a maximum MRU greater than 1500 (which is too small to reassemble a 1500+20 packet). Tunnel endpoints that are located nearer the middle can be swamped trying to keep up with reassembly at high data rates - again, with no MRU assurances. > >>> End systems are expected and required to > >>> reassemble on their own behalf. > >> > >> That is not a proper operation of tunnels. > > > Why not? > > Lack of transparency. Huh? > >> Even though there is no well defined value of MSL? > > > > MSL is well defined. For TCP, it is defined in RFC793. > > For IPv4 reassembly, it is defined in RFC1122. For IPv6 > > reassembly, it is defined in RFC2460. > > As you can see, they are different values. RFC793 sets MSL to 120 seconds. RFC1122 uses MSL as the upper bound for reassembly buffer timeouts. IPv6 doesn't reference MSL but sets reassembly buffer timeouts to 60 seconds. Personally, I can't imagine a reassembly that takes even as long as 30seconds being of any use to the final destination even if it were to finally complete. But, if we set 60 sec as the reassembly timeout value for IPv* I'm sure we'd be OK. > >> I'm talking about not operation guidance but proper > >> operation. > > > > The tunnel ingress cannot count on administrative tuning > > on the egress > > I'm afraid you don't understand tunnel operation at all. I don't? Are you sure? > > No amount of proper operation can fix a platform that > > does not have adequate performance. > > Choosing a proper platform is a part of proper operation. This is getting tiresome. Fred fred.l.temlin at boeing.com > Masataka Ohta From aledm at qix.co.uk Tue Jun 5 12:47:05 2012 From: aledm at qix.co.uk (Aled Morris) Date: Tue, 5 Jun 2012 18:47:05 +0100 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: On 5 June 2012 15:52, Green, Timothy wrote: > Howdy all, > > I'm a Security Manager of a large network, we are conducting a Pentest > next month and the testers are demanding a complete network diagram of the > entire network. > > I'd treat this as the first of their pen tests - a social engineering attack to obtain secret information about the network, and refuse. Aled From xenophage at godshell.com Tue Jun 5 13:05:06 2012 From: xenophage at godshell.com (Jason 'XenoPhage' Frisvold) Date: Tue, 5 Jun 2012 14:05:06 -0400 Subject: Penetration Test Assistance In-Reply-To: <4FCE394D.4040102@alter3d.ca> References: <4FCE394D.4040102@alter3d.ca> Message-ID: <25238AB7-773B-443F-A45E-BAC3635789D3@godshell.com> On Jun 5, 2012, at 12:52 PM, Peter Kristolaitis wrote: > In general, my experience with most "pen testers" is a severe disappointment, and isn't anything that couldn't be done in-house by taking the person in your department who has the most ingrained hacker/geek personality, giving them Nessus/Metasploit/nmap/etc, pizza and a big ass pot of coffee, and saying "Find stuff we don't know about. Go.". There is the occasional pen tester who is absolutely phenomenal and does the job properly (i.e. the guys who actually write their own shellcode, etc), but the vast majority of "pen testers" just use automated tools and call it a day. Like everything else in IT, security has been "commercialized" to the point where finding really good vendors/people is hard, because everyone and their mom has CEH, CISSP, and whatever other alphabet soup certifications you can imagine. There are definitely a number of incredible pen-testers out there. But I agree with Peter? If you end up with a "report" that's nothing more than an executive statement pasted at the top of a Nessus report, then you've wasted your money. To be honest, I'd recommend getting a sample report from the company and quiz them on it before committing to a contract with them. --------------------------- Jason 'XenoPhage' Frisvold xenophage at godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law From bgreene at senki.org Tue Jun 5 13:06:46 2012 From: bgreene at senki.org (Barry Greene) Date: Tue, 5 Jun 2012 11:06:46 -0700 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: Hi Tim, A _good_ pen test team would not need a network diagram. Their first round of penetration test would have them build their own network diagram from their analysis of your network. Barry On Jun 5, 2012, at 7:52 AM, Green, Timothy wrote: > Howdy all, > > I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a "complete" network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. > > I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? > > What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? > > Thanks, > > Tim > > ________________________________ > This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments. From darden at armc.org Tue Jun 5 13:33:07 2012 From: darden at armc.org (Darden, Patrick S.) Date: Tue, 5 Jun 2012 14:33:07 -0400 Subject: Penetration Test Assistance In-Reply-To: Message-ID: Seriously. --p -----Original Message----- From: Aled Morris [mailto:aledm at qix.co.uk] I'd treat this as the first of their pen tests - a social engineering attack to obtain secret information about the network, and refuse. Aled From darden at armc.org Tue Jun 5 13:34:29 2012 From: darden at armc.org (Darden, Patrick S.) Date: Tue, 5 Jun 2012 14:34:29 -0400 Subject: Penetration Test Assistance In-Reply-To: Message-ID: I'm with Barry--a network diagram showing everything from the pov of the pen team should be part of the end report. --p -----Original Message----- From: Barry Greene [mailto:bgreene at senki.org] Hi Tim, A _good_ pen test team would not need a network diagram. Their first round of penetration test would have them build their own network diagram from their analysis of your network. Barry From hhoffman at ip-solutions.net Tue Jun 5 13:37:37 2012 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 05 Jun 2012 14:37:37 -0400 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: <4FCE51F1.2060601@ip-solutions.net> There are lots of reasons why a pentester would want a network diagram. The foremost being a point to which they can say, these are the networks that I was given as a point of reference to pentest. This is often a CYA policy for when people start complaining about the scanning that is going to occur and potentially break their systems. Cheers, Harry On 06/05/2012 02:34 PM, Darden, Patrick S. wrote: > > I'm with Barry--a network diagram showing everything from the pov of the pen team should be part of the end report. > > --p > > -----Original Message----- > From: Barry Greene [mailto:bgreene at senki.org] > > Hi Tim, > > A _good_ pen test team would not need a network diagram. Their first round of penetration test would have them build their own network diagram from their analysis of your network. > > Barry > > From mohta at necom830.hpcl.titech.ac.jp Tue Jun 5 13:36:29 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Jun 2012 03:36:29 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> Message-ID: <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: >> You don't have to do it with core routers. > > Tunnel endpoints can be located either nearer the edges > or nearer the middle. Tunnel endpoints that are located > nearer the edges might be able to do reassembly at nominal > data rates, but there is no assurance of a maximum MRU > greater than 1500 (which is too small to reassemble a > 1500+20 packet). Tunnel endpoints that are located nearer > the middle can be swamped trying to keep up with reassembly > at high data rates - again, with no MRU assurances. As operators know outer fragmentation is used to carry inner 1500B packets, the proper operation is to have equipments with large enough MRU. As core routers may be good at fragmentation but not particularly good at reassembly, operators do not have to insist on using core routers. >> I'm afraid you don't understand tunnel operation at all. > > I don't? Are you sure? See above. Masataka Ohta From bicknell at ufp.org Tue Jun 5 13:39:22 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 5 Jun 2012 11:39:22 -0700 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: <20120605183922.GA39392@ussenterprise.ufp.org> The bit of information that's missing here is what are you trying to pentest, and by extension how much do you want to pay your pentest firm? For some folks a pentest means starting with zero information and trying to get IP packets passed a firewall or IDS's undetected. Basically pentesting layer 3 infrastructure. For other folks a pentest is purely an application level exercise, you give the pentester an account on your customer portal for instance, a full network diagram, and let them try things like SQL injection or cross site scripting at the applications layer. Your pentest firm can start with zero information and work all the way up to an application level attack, but that's costly and time consuming. Providing them some information is a way to short circuit the process. If you (or appropriate company representative) haven't already discussed the pros and cons with your pentest firm you're off on the wrong foot. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From massey at cs.colostate.edu Tue Jun 5 13:42:45 2012 From: massey at cs.colostate.edu (Daniel Massey) Date: Tue, 5 Jun 2012 12:42:45 -0600 Subject: ROVER routing security - its not enumeration Message-ID: 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 From owen at delong.com Tue Jun 5 13:44:24 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 11:44:24 -0700 Subject: New routing systems (Was: IPv6 day and tunnels) In-Reply-To: <4FCE1B4B.8060602@unfix.org> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> <0E60355A-88A1-4A8B-BF5E-248011FF7711@delong.com> <4FCD5CDC.3060209@unfix.org> <4FCE1B4B.8060602@unfix.org> Message-ID: On Jun 5, 2012, at 7:44 AM, Jeroen Massar wrote: > On 2012-06-04 23:06, Owen DeLong wrote: >> >> On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote: >> >>> On 2012-06-04 17:57, Owen DeLong wrote: [..] >>>> If you're going to redesign the header, I'd be much more >>>> interested in having 32 bits for the destination ASN so that IDR >>>> can ignore IP prefixes altogether. >>> >>> One can already do that: route your IPv6 over IPv4.... IPv4 has >>> 32bit destination addresses remember? :) >>> >>> It is also why it is fun if somebody uses a 32-bit ASN to route >>> IPv4, as one is not making the problem smaller that way. ASNs are >>> more used as identifiers to avoid routing loops than as actual >>> routing parameters. >>> >>> Greets, Jeroen >> >> While this is true today (to some extent), it doesn't have to always >> be true. >> >> If we provided a reliable scaleable mechanism to distribute and cache >> prefix->ASN mappings and could reliably populate a DEST-AS field in >> the packet header, stub networks would no longer need separate ASNs >> to multihome and IDR routing could be based solely on best path to >> the applicable DEST-AS and we wouldn't even need to carry prefixes >> beyond the local AS border. > > The problem here does not lie with the fact that various of these > systems (LISP comes to mind amongst others) have been well researched > and implemented already, but with the fact that the general operator > community will not change to such a new system as it is not what they > are used to. > > Greets, > Jeroen LISP et. al requires a rather complicated deployment and would be even more complex to troubleshoot when it fails. What I am proposing could, literally, be deployed with the existing system still running as it does. The difference would be that for packets containing a dest-as field, we would (initially) have the option of routing to destination based on that field and ignoring the prefix. Later, the distribution of prefixes in BGP could be deprecated, but that would be several years off. What I am proposing is much much simpler to implement and much closer to what operators are used to than the map/encap solutions proposed to date. What I am proposing, however, requires us to add fields to the packet header (at the source), so it will take a long time to get implemented even if it ever did. Deploying it would require code updates to every router and end host and would require a new IP version number. However, the code changes at the host level would be pretty minor. Add some bits to the header and set them all to zero. The first router with "full" routing information and access to a populated cache or the ability to resolve dest-as for the destination prefix would populate the dest-as field. From that point until it arrived at the actual destination AS, the packet would be routed based on the best path to the AS in question. True, this would mean operators would have to revert to using an ASN to represent a common routing policy, but at most that would require some larger operators to deploy a few more ASNs. ASNs would no longer be required for what are now stub AS. It's truly unfortunate that IETF chose to drop the ball on this when IPv6 was being developed. Owen From owen at delong.com Tue Jun 5 13:57:05 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 11:57:05 -0700 Subject: ipv6 book recommendations? In-Reply-To: <1338916075.13606.YahooMailNeo@web121602.mail.ne1.yahoo.com> References: <4FCE1B73.9080102@dds.nl> <1338916075.13606.YahooMailNeo@web121602.mail.ne1.yahoo.com> Message-ID: Shameless plug: Certification wise, the IPv6 Sage certification at Hurricane Electric (http://www.tunnelbroker.net) uses a practical step-by-step approach where you actually have to deploy IPv6 and make it work to progress through the steps. Owen On Jun 5, 2012, at 10:07 AM, isabel dias wrote: > http://long.ccaba.upc.es/long/070Related_Activities/020Documents/IPv6_An_Internet_Revolution.pdf > > > worth going through certification................ > > > ________________________________ > From: Seth Mos > To: nanog at nanog.org > Sent: Tuesday, June 5, 2012 3:45 PM > Subject: Re: ipv6 book recommendations? > > Op 5-6-2012 16:29, David Hubbard schreef: >> Does anyone have suggestions on good books to really get >> a thorough understanding of v6, subnetting, security practices, >> etc. Or a few books. Just turned up dual stack with our >> peers and a test network but I'd like to be a lot more >> comfortable with it before looking at our customer network. > > I liked the O'reilly IPv6 essentials. I've read a few chapters when I needed it. > > Cheers, > > Seth From Fred.L.Templin at boeing.com Tue Jun 5 14:09:38 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 5 Jun 2012 12:09:38 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <850906FA-50AB-4A5F-BFE6-84EA85E975A4@unfix.org> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Tuesday, June 05, 2012 11:36 AM > To: Templin, Fred L; nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > >> You don't have to do it with core routers. > > > > Tunnel endpoints can be located either nearer the edges > > or nearer the middle. Tunnel endpoints that are located > > nearer the edges might be able to do reassembly at nominal > > data rates, but there is no assurance of a maximum MRU > > greater than 1500 (which is too small to reassemble a > > 1500+20 packet). Tunnel endpoints that are located nearer > > the middle can be swamped trying to keep up with reassembly > > at high data rates - again, with no MRU assurances. > > As operators know outer fragmentation is used to carry > inner 1500B packets, the proper operation is to have > equipments with large enough MRU. > > As core routers may be good at fragmentation but not > particularly good at reassembly, operators do not > have to insist on using core routers. I am making a general statement that applies to all tunnels everywhere. For those, specs say that all that is required for MRU is 1500 and not 1500+20. *Unless there is some explicit pre-arrangement between the tunnel endpoints*, the ingress has no way of knowing whether the egress can do better than 1500 outer packet (meaning 1480 inner packet). That is certainly the case for point-to-multipoint "automatic" tunnels as many of these IPv6 transition technologies are. Fred fred.l.templin at boeing.com > >> I'm afraid you don't understand tunnel operation at all. > > > > I don't? Are you sure? > > See above. > > Masataka Ohta From james at smithwaysecurity.com Tue Jun 5 14:12:30 2012 From: james at smithwaysecurity.com (James Smith) Date: Tue, 05 Jun 2012 16:12:30 -0300 Subject: Drupal-GEO maping Message-ID: <4FCE5A1E.5000305@smithwaysecurity.com> Hello, I am looking for advise on mapping data in Drupal. We are building a Portal using the Drupal core. i am looking for a way to be able to map ip addresses to countries etc. Is anyone aware of any modules available that could accomplish this task. -- Sincerely; James Smith CEO, CEH, Security Analyst Email: james at smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve - From me at anuragbhatia.com Tue Jun 5 14:19:12 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 6 Jun 2012 00:49:12 +0530 Subject: Drupal-GEO maping In-Reply-To: <4FCE5A1E.5000305@smithwaysecurity.com> References: <4FCE5A1E.5000305@smithwaysecurity.com> Message-ID: Hi James Nice question. I am interested if someone can suggest some similar extension or some code to integrate it within Joomla too. Thanks. On Wed, Jun 6, 2012 at 12:42 AM, James Smith wrote: > Hello, > > I am looking for advise on mapping data in Drupal. > We are building a Portal using the Drupal core. > i am looking for a way to be able to map ip addresses to countries etc. > Is anyone aware of any modules available that could accomplish this task. > > > -- > Sincerely; > > > James Smith > CEO, CEH, Security Analyst > Email: james at smithwaysecurity.com > Phone: 1877-760-1953 > Cell Phone:1506-650-6500 > Website: www.SmithwaySecurity.com > Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 > > > CONFIDENTIALITY NOTICE: This communication with its contents may > contain confidential and/or legally privileged information. It is > solely > for the use of the intended recipient(s). Unauthorized interception, > review, use or disclosure is prohibited and may violate applicable laws > including the Electronic Communications Privacy Act. If you are not the > intended recipient, please contact the sender and destroy all copies of > the communication. > > - This communication is confidential to the parties it was intended to > serve - > > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Linkedin | Twitter| Google+ From owen at delong.com Tue Jun 5 14:18:01 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 12:18:01 -0700 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> Message-ID: <90A5DA13-6AEA-4EF2-AA7B-9A3559717A90@delong.com> On Jun 5, 2012, at 10:15 AM, Jimmy Hess wrote: > On 6/5/12, Owen DeLong wrote: > [snip] >> But that's a whole lot more packets than working PMTU-D to get there and >> you're also waiting for all those round trips, not just the 4 timeouts. >> The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at >> 100ms is 2.2 seconds. That's a long time to go without first data packet > > I'm only suggesting probing to discover the MTU between neighboring > endpoints directly connected to the same subnet -- Layer 2 > interconnect. PTMU doesn't work, because devices know the MTU of > _their link_, but not necessarily the MTU of every intervening bridge > or L2 tunnel, Not for IP end-end-to-end MTU discovery. > This is a horrible misconfiguration of the devices on that link. If your MTU setting on your interface is larger than the smallest MTU of any L2 forwarder on the link, then, you have badly misconfigured your system(s). Adding probing to compensate for this misconfiguration merely serves to perpetuate such errant configurations. > The "too big packet" forwarded is just discarded by the L2 bridge, > there's no ICMP packet that can result from that, the L2 bridge might > not even have an IP address to source one from, so the PMTU method > which relies on ICMP alone cannot possibly work. Sure... PMTU-D isn't designed to compensate for misconfigured links, it's designed to detect the path MTU based on the smallest correctly configured L3 MTU in the path. > The router after discovering the local MTU constraints to its > neighbors would then be responsible for sending TooBig messages as > needed or passing on the MTU constraint. So you want to add an MTU setting for each L2 destination to the L2 adjacency table? This seems like a really bad idea. The better solution would be to correctly configure your link MTUs in the first place. > You've got an issue if there are 100ms between two peers on your LAN. > You're right, you don't need to probe for possible MTUs below 1280. LAN, sure. However, consider that there are intercontinental L2 links. Owen From shane at castlepoint.net Tue Jun 5 14:26:32 2012 From: shane at castlepoint.net (Shane Amante) Date: Tue, 5 Jun 2012 13:26:32 -0600 Subject: ROVER routing security - its not enumeration In-Reply-To: References: Message-ID: One correction below. On Jun 5, 2012, at 12:42 PM, Daniel Massey wrote: [--snip--] > 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. To clarify the above, the IRR _does_ provide an enumerated list of "Candidate" (IP prefix + Origin_AS) pairs. The second step is to walk through those "Candidate" pairs and ask DNSSEC, in question/answer process, to validate that the "Candidate" IRR (IP prefix, Origin_AS) pairs are authentic, or not. So, considering each step independently: the former (IRR data) is enumeration, the second is not. However, in the context of this specific operational model, the end result is an enumerated list of validated (IP Prefix, Origin_AS) pairs. -shane From morrowc.lists at gmail.com Tue Jun 5 14:28:18 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 5 Jun 2012 15:28:18 -0400 Subject: ROVER routing security - its not enumeration In-Reply-To: References: Message-ID: On Tue, Jun 5, 2012 at 2:42 PM, Daniel Massey wrote: > 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. which are? I can see a use-case for something like: "Build me a prefix list from the RIR data" which is essentially: 1) pull IRR data for customer-X 2) validate all entries with 'resource certification' data 3) deploy new filter to edge-link-to-customer-X (only if changes occur) (shane seems to point at this as the method in question...) I think this means that the customer here has to keep updated their DNS data and their IRR data, and in the case (today) of 'ROVER' getting no-answer, the customer skates... (no validation is possible). I'm not sure you can extend usage of 'ROVER' to things which are not 'offline processed' though, and it's not clear to me that the fail-open answer is good for us, absent some signal that 'customer-x will not be playing today'. >> - 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. caching implies that: 1) the cache is filled 2) the timeout on records is longer than the outage(s) 3) the timeout is still short-enough to meet user change requirements >> - 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 in somewhat real-time on the router (get update, lookup dns records, decide)? or via offline compute and peer filter-updates? >> - 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 1.23.45.10.in-addr.arpa. that's 2 copies... what about: 1.23.45.10.in-addr-arpa. that's 4 copies. > between a prefix and a DNS name. ?The resolver simply finds the data and has no need to > understand where zone cuts occur. don't I have to walk up the tree a few times in the above example though? "Is this the covering route? the customer route? the customer-of-customer-route? the-hijack? Wait, no RLOCK, so this was a giant waste of time..." > 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. 'resolver' here is what? router? unix-y-box-thing doing filter-generation? near-line-query/response-box for router-real-time-lookup? > The convention is also useful for storing data at prefixes; geolocations is one example. not to nit-pick, but near as I can tell no one uses the geoloc entries in dns... also they aren't very well kept up to date by those few who actually do put them into dns :( >> (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. 10.45.23.0/24 10.45.16.0/19 10.45.0.0/16 10.0.0.0/8 > 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 you referenced this a few times: doesn't mention a talk from L3 on 6/4 ... got link? -chris From richard.barnes at gmail.com Tue Jun 5 14:36:07 2012 From: richard.barnes at gmail.com (Richard Barnes) Date: Tue, 5 Jun 2012 15:36:07 -0400 Subject: Drupal-GEO maping In-Reply-To: References: <4FCE5A1E.5000305@smithwaysecurity.com> Message-ID: http://lmgtfy.com/?q=drupal+geo+ip http://lmgtfy.com/?q=joomla+geo+ip On Tue, Jun 5, 2012 at 3:19 PM, Anurag Bhatia wrote: > Hi James > > > Nice question. I am interested if someone can suggest some similar > extension or some code to integrate it within Joomla too. > > > > Thanks. > > On Wed, Jun 6, 2012 at 12:42 AM, James Smith wrote: > >> Hello, >> >> I am looking for advise on mapping data in Drupal. >> We are building a Portal using the Drupal core. >> i am looking for a way to be able to ?map ip addresses to countries etc. >> Is anyone aware of any modules available that could accomplish this task. >> >> >> -- >> Sincerely; >> >> >> James Smith >> CEO, CEH, Security Analyst >> Email: james at smithwaysecurity.com >> Phone: 1877-760-1953 >> Cell Phone:1506-650-6500 >> Website: www.SmithwaySecurity.com >> Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 >> >> >> CONFIDENTIALITY NOTICE: This communication with its contents may >> contain confidential and/or legally privileged information. It is >> solely >> for the use of the intended recipient(s). Unauthorized interception, >> review, use or disclosure is prohibited and may violate applicable laws >> including the Electronic Communications Privacy Act. If you are not the >> intended recipient, please contact the sender and destroy all copies of >> the communication. >> >> - This communication is confidential to the parties it was intended to >> serve - >> >> >> > > > -- > > Anurag Bhatia > anuragbhatia.com > or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected > network! > > Linkedin | > Twitter| > Google+ From weiler+lists.nanog at watson.org Tue Jun 5 14:39:12 2012 From: weiler+lists.nanog at watson.org (Samuel Weiler) Date: Tue, 5 Jun 2012 15:39:12 -0400 (EDT) Subject: rpki vs. secure dns? In-Reply-To: References: <4F9B181D.30606@isc.org> <20120428101710.GA26852@pob.ytti.fi> Message-ID: On Mon, 28 May 2012, David Conrad wrote: > As far as I can tell, ROVER is simply Yet Another RPKI Access Method > like rsync and bittorrent with its own positives and negatives. Not quite. ROVER's SRO & RLOCK statements have different semantics than RPKI ROAs, and there are semantics that may not be (practically) expressible in ROVER. ROVER's semantics depend on DNS zone structure. The protection offered by the RLOCK statement stops when a zone cut is reached -- longer routes are allowed unless there's an RLOCK in every descendant zone. Having DNS users care about zone structure is, to quote Rob Austein, "not normal". -- Sam Weiler From james at smithwaysecurity.com Tue Jun 5 14:39:25 2012 From: james at smithwaysecurity.com (James Smith) Date: Tue, 05 Jun 2012 16:39:25 -0300 Subject: Drupal-GEO maping In-Reply-To: References: <4FCE5A1E.5000305@smithwaysecurity.com> Message-ID: <4FCE606D.60103@smithwaysecurity.com> Hi Anrag, FYI:Depending on the type of information you running joomla is not always safest bet. But I do know Drupal works well for data maping. On 12-06-05 04:36 PM, Richard Barnes wrote: > http://lmgtfy.com/?q=drupal+geo+ip > http://lmgtfy.com/?q=joomla+geo+ip > > On Tue, Jun 5, 2012 at 3:19 PM, Anurag Bhatia wrote: >> Hi James >> >> >> Nice question. I am interested if someone can suggest some similar >> extension or some code to integrate it within Joomla too. >> >> >> >> Thanks. >> >> On Wed, Jun 6, 2012 at 12:42 AM, James Smithwrote: >> >>> Hello, >>> >>> I am looking for advise on mapping data in Drupal. >>> We are building a Portal using the Drupal core. >>> i am looking for a way to be able to map ip addresses to countries etc. >>> Is anyone aware of any modules available that could accomplish this task. >>> >>> >>> >>> >>> CONFIDENTIALITY NOTICE: This communication with its contents mayEric.Morin at corp.xplornet.com >>> contain confidential and/or legally privileged information. It is >>> solely >>> for the use of the intended recipient(s). Unauthorized interception, >>> review, use or disclosure is prohibited and may violate applicable laws >>> including the Electronic Communications Privacy Act. If you are not the >>> intended recipient, please contact the sender and destroy all copies of >>> the communication. >>> >>> - This communication is confidential to the parties it was intended to >>> serve - >>> >>> >>> >> >> -- >> >> Anurag Bhatia >> anuragbhatia.com >> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected >> network! >> >> Linkedin | >> Twitter| >> Google+ -- Sincerely; James Smith CEO, CEH, Security Analyst Email: james at smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve - From randy at psg.com Tue Jun 5 14:40:52 2012 From: randy at psg.com (Randy Bush) Date: Tue, 05 Jun 2012 12:40:52 -0700 Subject: ROVER routing security - its not enumeration In-Reply-To: References: Message-ID: >> There are number of operational models that provide the needed >> routing protection without enumeration. > I can see a use-case for something like: > "Build me a prefix list from the RIR data" this requires a full data fetch, not doable in dns. and, at the other end of the spectrum, for any dynamic lookup on receiving a bgp announcement, the data had best be already in the router. a full data set on an in-rack cache will go nuts on any significant bgp load. beyond that, you are in non-op space. randy From esuarez at fcaglp.fcaglp.unlp.edu.ar Tue Jun 5 14:41:34 2012 From: esuarez at fcaglp.fcaglp.unlp.edu.ar (Eduardo A. =?iso-8859-1?b?U3XhcmV6?=) Date: Tue, 05 Jun 2012 16:41:34 -0300 Subject: Drupal-GEO maping In-Reply-To: <4FCE5A1E.5000305@smithwaysecurity.com> References: <4FCE5A1E.5000305@smithwaysecurity.com> Message-ID: <20120605164134.wsnnjvqv2848cs0c@fcaglp.fcaglp.unlp.edu.ar> Hello, Generic Mapping Tools http://gmt.soest.hawaii.edu/ PostGIS http://postgis.refractions.net/ Eduardo.- Quoting James Smith : > Hello, > > I am looking for advise on mapping data in Drupal. > We are building a Portal using the Drupal core. > i am looking for a way to be able to map ip addresses to countries > etc. Is anyone aware of any modules available that could accomplish > this task. > > > -- > Sincerely; > > > James Smith > CEO, CEH, Security Analyst > Email: james at smithwaysecurity.com > Phone: 1877-760-1953 > Cell Phone:1506-650-6500 > Website: www.SmithwaySecurity.com > Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 > > > CONFIDENTIALITY NOTICE: This communication with its contents may > contain confidential and/or legally privileged information. It is > solely > for the use of the intended recipient(s). Unauthorized interception, > review, use or disclosure is prohibited and may violate applicable laws > including the Electronic Communications Privacy Act. If you are not the > intended recipient, please contact the sender and destroy all copies of > the communication. > > - This communication is confidential to the parties it was intended to > serve - -- Eduardo A. Suarez Facultad de Ciencias Astron?micas y Geof?sicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From mohta at necom830.hpcl.titech.ac.jp Tue Jun 5 14:41:47 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Jun 2012 04:41:47 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> Message-ID: <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: > I am making a general statement that applies to all tunnels > everywhere. General statement? Even though you assume tunnel MTU 1500B and tunnel overhead 20B? > For those, specs say that all that is required > for MRU is 1500 and not 1500+20. That is a requirement for hosts with Ethernet interface, which is, by no means, general and has nothing to do with tunnels. For the general argument on tunnels, see, for example, RFC2473 "Generic Packet Tunneling in IPv6", where there is no requirement of 1500. Note that the RFC uses outer fragmentation: (b) if the original IPv6 packet is equal or smaller than the IPv6 minimum link MTU, the tunnel entry-point node encapsulates the original packet, and subsequently fragments the resulting IPv6 tunnel packet into IPv6 fragments that do not exceed the Path MTU to the tunnel exit-point. Masataka Ohta From morrowc.lists at gmail.com Tue Jun 5 14:44:21 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 5 Jun 2012 15:44:21 -0400 Subject: ROVER routing security - its not enumeration In-Reply-To: References: Message-ID: On Tue, Jun 5, 2012 at 3:40 PM, Randy Bush wrote: >>> There are number of operational models that provide the needed >>> routing protection without enumeration. >> I can see a use-case for something like: >> ? "Build me a prefix list from the RIR data" > > this requires a full data fetch, not doable in dns. does it? shane implied (and it doesn't seem UNREASONABLE, modulo some 'doing lots of spare queries') to query for each filter entry at filter creation time, no? get-as-GOOGLE = 216.239.32.0/19 lookup-in-dns = + + ..... that could be optimized I bet, but it SEEMS doable, cumbersome, but doable. the 'fail open' answer also seems a bit rough in this case (but no worse than 'download irr, upload to router, win!' which is today's model). -chris From brett at the-watsons.org Tue Jun 5 14:48:07 2012 From: brett at the-watsons.org (Brett Watson) Date: Tue, 5 Jun 2012 12:48:07 -0700 Subject: Penetration Test Assistance In-Reply-To: <4FCE394D.4040102@alter3d.ca> References: <4FCE394D.4040102@alter3d.ca> Message-ID: <268BCFA8-24DD-4794-8DDF-FA7833C328A2@the-watsons.org> On Jun 5, 2012, at 9:52 AM, Peter Kristolaitis wrote: > > As far as horror stories... yeah. My most memorable experience was a guy (with a CISSP designation, working for a company who came highly recommended) who: > - Spent a day trying to get his Backtrack CD to "work properly". When I looked at it, it was just a color depth issue in X that took about 45 seconds from "why is this broken?" to "hey look, I fixed it!". > - Completely missed the honeypot machine I set up for the test. I had logs from the machine showing that his scanning had hit the machine and had found several of the vulnerabilities, but the entire machine was absent from the report. > - Called us complaining that a certain behavior that "he'd never seen before" was happening when he tried to nmap our network. The "certain behavior" was a firewall with some IPS functionality, along with him not knowing how to read nmap output. > - Completely messed up the report -- three times. His report had the wrong ports & vulnerabilities listed on the wrong IPs, so according to the report, we apparently had FreeBSD boxes running IOS or MS SQL... > - Stopped taking our calls when we asked why the honeypot machine was completely missing from the report. > > In general, my experience with most "pen testers" is a severe disappointment, and isn't anything that couldn't be done in-house by taking the person in your department who has the most ingrained hacker/geek personality, giving them Nessus/Metasploit/nmap/etc, pizza and a big ass pot of coffee, and saying "Find stuff we don't know about. Go.". There is the occasional pen tester who is absolutely phenomenal and does the job properly (i.e. the guys who actually write their own shellcode, etc), but the vast majority of "pen testers" just use automated tools and call it a day. Like everything else in IT, security has been "commercialized" to the point where finding really good vendors/people is hard, because everyone and their mom has CEH, CISSP, and whatever other alphabet soup certifications you can imagine. I agree with a lot of what you've said, but there are absolutely good security guys (pen tester, vulnerability assessors, etc) that use both open source and commercial automated tools, but still do a fantastic job because they understand the underlying technologies and protocols. I used to do a lot of this in the past, had lots of automated tools, and only occasionally wrote some assessment modules or exploit code if necessary. But again, a person in that position has to understand technology holistically (network, systems, software, protocols, etc). -b From james at smithwaysecurity.com Tue Jun 5 15:07:18 2012 From: james at smithwaysecurity.com (James Smith) Date: Tue, 05 Jun 2012 17:07:18 -0300 Subject: Drupal-GEO maping In-Reply-To: References: <4FCE5A1E.5000305@smithwaysecurity.com> Message-ID: <4FCE66F6.4050708@smithwaysecurity.com> The overall goal is to look similar to this but inside Drupal. ( http://wildkatzenwegeplan.geops.de/) But thanks everyone for for your input. On 12-06-05 04:36 PM, Richard Barnes wrote: > http://lmgtfy.com/?q=drupal+geo+ip > http://lmgtfy.com/?q=joomla+geo+ip > > On Tue, Jun 5, 2012 at 3:19 PM, Anurag Bhatia wrote: >> Hi James >> >> >> Nice question. I am interested if someone can suggest some similar >> extension or some code to integrate it within Joomla too. >> >> >> >> Thanks. >> >> On Wed, Jun 6, 2012 at 12:42 AM, James Smithwrote: >> >>> Hello, >>> >>> I am looking for advise on mapping data in Drupal. >>> We are building a Portal using the Drupal core. >>> i am looking for a way to be able to map ip addresses to countries etc. >>> Is anyone aware of any modules available that could accomplish this task. >>> >>> >>> -- >>> Sincerely; >>> >>> >>> James Smith >>> CEO, CEH, Security Analyst >>> Email: james at smithwaysecurity.com >>> Phone: 1877-760-1953 >>> Cell Phone:1506-650-6500 >>> Website: www.SmithwaySecurity.com >>> Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 >>> >>> >>> CONFIDENTIALITY NOTICE: This communication with its contents may >>> contain confidential and/or legally privileged information. It is >>> solely >>> for the use of the intended recipient(s). Unauthorized interception, >>> review, use or disclosure is prohibited and may violate applicable laws >>> including the Electronic Communications Privacy Act. If you are not the >>> intended recipient, please contact the sender and destroy all copies of >>> the communication. >>> >>> - This communication is confidential to the parties it was intended to >>> serve - >>> >>> >>> >> >> -- >> >> Anurag Bhatia >> anuragbhatia.com >> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected >> network! >> >> Linkedin | >> Twitter| >> Google+ -- Sincerely; James Smith CEO, CEH, Security Analyst Email: james at smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve - From Fred.L.Templin at boeing.com Tue Jun 5 15:09:26 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 5 Jun 2012 13:09:26 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <248BC338-ACD5-4CB7-BC5E-DAE548625CE3@antelope.net> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Tuesday, June 05, 2012 12:42 PM > To: Templin, Fred L > Cc: nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > > I am making a general statement that applies to all tunnels > > everywhere. > > General statement? General statement for IPv6-in-IPv4 tunneling, yes. But inner fragmentation applies equally for *-in-* tunneling. > Even though you assume tunnel MTU 1500B What I am after is a tunnel MTU of infinity. 1500 is the minimum packet size that MUST get through. 1501+ packets are admitted into the tunnel unconditionally in hopes that they MIGHT get through. > and tunnel overhead 20B? The size "20" represents the size of the IPv4 encaps header. The size "40" would represent the size of an IPv6 encaps header. The size "foo" would represent the size of some other encapsulation overhead, e.g., for IPsec tunnels, IP/UDP tunnels, etc. So, let the size of the encaps header(s) be "X", substitute X for 20 everywhere and you will see that the approach is fully generally applicable. > > For those, specs say that all that is required > > for MRU is 1500 and not 1500+20. > > That is a requirement for hosts with Ethernet interface, which > is, by no means, general and has nothing to do with tunnels. RFC2460 says the MinMRU for IPv6 nodes is 1500. RFC1122 says that IPv4 hosts should reassemble as much as their connected interfaces (1500 for Ethernet). RFC1812 says the MinMRU for IPv4 routers is 576. > For the general argument on tunnels, see, for example, > RFC2473 "Generic Packet Tunneling in IPv6", where there > is no requirement of 1500. > > Note that the RFC uses outer fragmentation: > > (b) if the original IPv6 packet is equal or smaller than the > IPv6 minimum link MTU, the tunnel entry-point node > encapsulates the original packet, and subsequently > fragments the resulting IPv6 tunnel packet into IPv6 > fragments that do not exceed the Path MTU to the tunnel > exit-point. Wow - that is an interesting quote out of context. The text you quoted is describing the limiting condition to make sure that 1280 and smaller get through even if the path MTU is deficient. In that case alone, outer fragmentation is needed. My document also allows for outer fragmentation on the inner fragments. But, like the RFC4213-derived IPv6 transition mechanisms treats outer fragmentation as an anomalous condition to be avoided if possible - not a steady state operational approach. See Section 3.2 of RFC4213. Thanks - Fred fred.l.templin at boeing.com > Masataka Ohta From baconzombie at gmail.com Tue Jun 5 15:13:11 2012 From: baconzombie at gmail.com (Bacon Zombie) Date: Tue, 5 Jun 2012 21:13:11 +0100 Subject: Penetration Test Assistance In-Reply-To: <268BCFA8-24DD-4794-8DDF-FA7833C328A2@the-watsons.org> References: <4FCE394D.4040102@alter3d.ca> <268BCFA8-24DD-4794-8DDF-FA7833C328A2@the-watsons.org> Message-ID: You should have a look at the Pentest Standards page, it was created by some very skilled Pen Testers how are trying to create a minimum standard for all tests and reporting. http://www.pentest-standard.org/index.php/Main_Page Also you should just have to give them your external net-block allocation that is in scope unless it is a more forced test and not a general external test. On 5 June 2012 20:48, Brett Watson wrote: > > On Jun 5, 2012, at 9:52 AM, Peter Kristolaitis wrote: > >> >> As far as horror stories... yeah. ? My most memorable experience was a guy (with a CISSP designation, working for a company who came highly recommended) who: >> ? ?- Spent a day trying to get his Backtrack CD to "work properly". ?When I looked at it, it was just a color depth issue in X that took about 45 seconds from "why is this broken?" to "hey look, I fixed it!". >> ? ?- Completely missed the honeypot machine I set up for the test. ?I had logs from the machine showing that his scanning had hit the machine and had found several of the vulnerabilities, but the entire machine was absent from the report. >> ? ?- Called us complaining that a certain behavior that "he'd never seen before" was happening when he tried to nmap our network. ?The "certain behavior" was a firewall with some IPS functionality, along with him not knowing how to read nmap output. >> ? ?- Completely messed up the report -- three times. ?His report had the wrong ports & vulnerabilities listed on the wrong IPs, so according to the report, we apparently had FreeBSD boxes running IOS or MS SQL... >> ? ?- Stopped taking our calls when we asked why the honeypot machine was completely missing from the report. >> >> In general, my experience with most "pen testers" is a severe disappointment, and isn't anything that couldn't be done in-house by taking the person in your department who has the most ingrained hacker/geek personality, giving them Nessus/Metasploit/nmap/etc, pizza and a big ass pot of coffee, and saying "Find stuff we don't know about. Go.". ? There is the occasional pen tester who is absolutely phenomenal and does the job properly (i.e. the guys who actually write their own shellcode, etc), but the vast majority of "pen testers" just use automated tools and call it a day. ?Like everything else in IT, security has been "commercialized" to the point where finding really good vendors/people is hard, because everyone and their mom has CEH, CISSP, and whatever other alphabet soup certifications you can imagine. > > I agree with a lot of what you've said, but there are absolutely good security guys (pen tester, vulnerability assessors, etc) that use both open source and commercial automated tools, but still do a fantastic job because they understand the underlying technologies and protocols. > > I used to do a lot of this in the past, had lots of automated tools, and only occasionally wrote some assessment modules or exploit code if necessary. > > But again, a person in that position has to understand technology holistically (network, systems, software, protocols, etc). > > -b -- BaconZombie LOAD "*",8,1 From alter3d at alter3d.ca Tue Jun 5 15:24:14 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 05 Jun 2012 16:24:14 -0400 Subject: Penetration Test Assistance In-Reply-To: <268BCFA8-24DD-4794-8DDF-FA7833C328A2@the-watsons.org> References: <4FCE394D.4040102@alter3d.ca> <268BCFA8-24DD-4794-8DDF-FA7833C328A2@the-watsons.org> Message-ID: <4FCE6AEE.6070308@alter3d.ca> On 12-06-05 03:48 PM, Brett Watson wrote: > On Jun 5, 2012, at 9:52 AM, Peter Kristolaitis wrote: > >> As far as horror stories... yeah. My most memorable experience was a guy (with a CISSP designation, working for a company who came highly recommended) who: >> - Spent a day trying to get his Backtrack CD to "work properly". When I looked at it, it was just a color depth issue in X that took about 45 seconds from "why is this broken?" to "hey look, I fixed it!". >> - Completely missed the honeypot machine I set up for the test. I had logs from the machine showing that his scanning had hit the machine and had found several of the vulnerabilities, but the entire machine was absent from the report. >> - Called us complaining that a certain behavior that "he'd never seen before" was happening when he tried to nmap our network. The "certain behavior" was a firewall with some IPS functionality, along with him not knowing how to read nmap output. >> - Completely messed up the report -- three times. His report had the wrong ports& vulnerabilities listed on the wrong IPs, so according to the report, we apparently had FreeBSD boxes running IOS or MS SQL... >> - Stopped taking our calls when we asked why the honeypot machine was completely missing from the report. >> >> In general, my experience with most "pen testers" is a severe disappointment, and isn't anything that couldn't be done in-house by taking the person in your department who has the most ingrained hacker/geek personality, giving them Nessus/Metasploit/nmap/etc, pizza and a big ass pot of coffee, and saying "Find stuff we don't know about. Go.". There is the occasional pen tester who is absolutely phenomenal and does the job properly (i.e. the guys who actually write their own shellcode, etc), but the vast majority of "pen testers" just use automated tools and call it a day. Like everything else in IT, security has been "commercialized" to the point where finding really good vendors/people is hard, because everyone and their mom has CEH, CISSP, and whatever other alphabet soup certifications you can imagine. > I agree with a lot of what you've said, but there are absolutely good security guys (pen tester, vulnerability assessors, etc) that use both open source and commercial automated tools, but still do a fantastic job because they understand the underlying technologies and protocols. > > I used to do a lot of this in the past, had lots of automated tools, and only occasionally wrote some assessment modules or exploit code if necessary. > > But again, a person in that position has to understand technology holistically (network, systems, software, protocols, etc). > > -b I completely agree. I didn't mean to imply that using automated tools is a bad thing -- simply that running an automated tool to pump out a report with no further investigation isn't really a useful pen test. I've seen vendors whose "comprehensive penetration testing" was basically "We'll run Nessus against your network, write up an executive summary and email you the scan results. Quite the bargain for $20K!" Automated tools are definitely good to provide a first pass over a network, but even then multiple tools should be used, and an experienced eye should review the results for anomalies (whether that's a vulnerability that has a chance for false positives, discrepancies between the results of two or more automated tools, etc). That kind of work, along with more aggressive pen tests and exploit development, need a "guru meditation"-level understanding of the involved technologies, protocols, etc, as you mentioned. Like everything else IT, the specific tools used are more or less immaterial to an excellent practitioner -- a good programmer can hack code in any language, a good network engineer can use any brand of network equipment, etc -- because these types of people truly understand the systems they're dealing with, and use tools to accomplish a specific task which fits into part of the "big picture" they have in their heads. Poor practitioners in a field use tools for the sake of using the tool ("I'm scanning a network with Nessus because that's what the certification course told me to do") without that deep level of understanding, and therefore don't provide any real value to the process. - Pete From brett at the-watsons.org Tue Jun 5 15:31:02 2012 From: brett at the-watsons.org (Brett Watson) Date: Tue, 5 Jun 2012 13:31:02 -0700 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: <57459835-4E26-41F5-B02F-8036CFF36823@the-watsons.org> On Jun 5, 2012, at 11:34 AM, Darden, Patrick S. wrote: > > I'm with Barry--a network diagram showing everything from the pov of the pen team should be part of the end report. Maybe, maybe not. It all depends on the scope of the engagement. I've had customers ask for very specific pen test of a group of servers, or specific applications, wherein they provide all the topology, system, and network info, and just want me to look at one specific area. Then of course others want a "black box" assessment, wherein they don't tell you anything, and expect you to discover whatever you can discover. I'm personally very specific about scoping, and just give the customer exactly what they want but you've got to "interview" each other to figure all of that out. And totally agree with a previous poster, you should always get a redacted or sample report to see what kind of quality you can expect in the finished product. -b From shortdudey123 at gmail.com Tue Jun 5 15:46:26 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 5 Jun 2012 15:46:26 -0500 Subject: ATT DSL IPv6 In-Reply-To: References: Message-ID: After talking with someone else, i am guessing that your Toredo statement is correct. However, i don't know why that would have stopped working as it works fine when i am at school on TWTC circuit. I do not have a Cisco gateway however, i have been looking into switching to one that i have laying around. Thanks, Grant On Tue, Jun 5, 2012 at 9:06 AM, Brian Christopher Raaen < mailing-lists at brianraaen.com> wrote: > Probably, you were using Teredo or some other method to use IPv6. BTW > if you have a Cisco gateway I have a blog post on how to set up a > dynamic tunnel with HE. While native IPv6 would be best, the tunnel > should work for you as I also have Bellsouth/AT&T DSL. > http://www.brianraaen.com/2011/10/21/dynamic-he-tunnel-and-dyndns/ > Brian Raaen > Zcorum > Network Architect > > On Mon, Jun 4, 2012 at 8:35 PM, Grant Ridder > wrote: > > Hi Everyone, > > > > Does anyone know about IPv6 on ATT residential DSL circuits? About 8 or > 9 > > months ago i ran through several IPv6 tests ( > http://test-ipv6.iad.vr.org/) > > and they all passed. With all the talk of IPv6 day over the past week i > > decided to run it again just out of curiosity. However to my surprise, > it > > is returning the result of IPv4 only now. Any ideas why they would have > > rolled back IPv6? > > > > Thanks, > > Grant > From AdamKennedy at omnicity.net Tue Jun 5 16:00:01 2012 From: AdamKennedy at omnicity.net (Adam Kennedy) Date: Tue, 5 Jun 2012 17:00:01 -0400 Subject: ipv6 book recommendations? In-Reply-To: Message-ID: And you get a t-shirt at the end! That was enough motivation for me, anyway :) -- Adam Kennedy Network Engineer Omnicity, Inc. From: Owen DeLong > To: isabel dias > Cc: "nanog at nanog.org" > Subject: Re: ipv6 book recommendations? Shameless plug: Certification wise, the IPv6 Sage certification at Hurricane Electric (http://www.tunnelbroker.net) uses a practical step-by-step approach where you actually have to deploy IPv6 and make it work to progress through the steps. Owen On Jun 5, 2012, at 10:07 AM, isabel dias wrote: http://long.ccaba.upc.es/long/070Related_Activities/020Documents/IPv6_An_Internet_Revolution.pdf worth going through certification................ ________________________________ From: Seth Mos > To: nanog at nanog.org Sent: Tuesday, June 5, 2012 3:45 PM Subject: Re: ipv6 book recommendations? Op 5-6-2012 16:29, David Hubbard schreef: Does anyone have suggestions on good books to really get a thorough understanding of v6, subnetting, security practices, etc. Or a few books. Just turned up dual stack with our peers and a test network but I'd like to be a lot more comfortable with it before looking at our customer network. I liked the O'reilly IPv6 essentials. I've read a few chapters when I needed it. Cheers, Seth From randy at psg.com Tue Jun 5 16:00:49 2012 From: randy at psg.com (Randy Bush) Date: Tue, 05 Jun 2012 14:00:49 -0700 Subject: ROVER routing security - its not enumeration In-Reply-To: References: Message-ID: >>>> routing protection without enumeration. >>> I can see a use-case for something like: >>> ? "Build me a prefix list from the RIR data" >> this requires a full data fetch, not doable in dns. > does it? shane implied (and it doesn't seem UNREASONABLE, modulo some > 'doing lots of spare queries') to query for each filter entry at > filter creation time, no? what is the query set, every prefix /7-/24 for the whole fracking ABC space? > that could be optimized I bet, but it SEEMS doable, cumbersome, but > doable. the 'fail open' answer also seems a bit rough in this case > (but no worse than 'download irr, upload to router, win!' which is > today's model). irr, i do have the 'full' set. but you said RIR (the in-addr roots), not IRR. was it a mis-type? and i am not gonna put my origin data in the irr and the dns. randy From jeroen at unfix.org Tue Jun 5 16:12:10 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 05 Jun 2012 14:12:10 -0700 Subject: New routing systems (Was: IPv6 day and tunnels) In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <4FCD53BD.9050204@necom830.hpcl.titech.ac.jp> <0E60355A-88A1-4A8B-BF5E-248011FF7711@delong.com> <4FCD5CDC.3060209@unfix.org> <4FCE1B4B.8060602@unfix.org> Message-ID: <4FCE762A.1040008@unfix.org> On 2012-06-05 11:44, Owen DeLong wrote: [..] > LISP et. al requires a rather complicated deployment and would be even > more complex to troubleshoot when it fails. > > What I am proposing could, literally, be deployed with the existing system > still running as it does. The difference would be that for packets containing > a dest-as field, we would (initially) have the option of routing to destination > based on that field and ignoring the prefix. I would love to see a more formal specification ala a IETF draft about it and/or a short preso style thing along with a comparison of existing proposals and how this is different/better. > What I am proposing, however, requires us to add fields to the packet > header (at the source) Well, we have IPv6 extension headers and the flow-label is still undefined too ;) Greets, Jeroen From bill at herrin.us Tue Jun 5 16:23:17 2012 From: bill at herrin.us (William Herrin) Date: Tue, 5 Jun 2012 17:23:17 -0400 Subject: ipv6 book recommendations? In-Reply-To: References: Message-ID: On 6/5/12, David Hubbard wrote: > Does anyone have suggestions on good books to really get > a thorough understanding of v6, subnetting, security practices, > etc. Or a few books. Just turned up dual stack with our > peers and a test network but I'd like to be a lot more > comfortable with it before looking at our customer network. Hi David, Instead of going the book route, I'd suggest getting some tunneled addresses from he.net and then working through http://ipv6.he.net/certification/ . They have the basics pretty well covered, it's interactive and it's free. Some additional thoughts: 1. Anybody who tells you that there are security best practices for IPv6 is full of it. It simply hasn't seen enough use in the environment to which we're now deploying it and rudimentary technologies widely used in IPv4 (e.g. NAT/PAT to private address space) haven't yet made their transition. 2. Subnetting in v6 in a nutshell: a. If it's a LAN, /64. Always. Stateless autoconfiguration (SLAAC) only works for /64. b. Delegations on 4-bit boundaries for reverse-DNS convenience. c. If it's a point to point, a reasonable practice seems to be a /64 per network area and around /124 per link. Works OK for ethernet point to points too. d. Default customer assignments should be /56 or /48 depending on who you ask. /48 was the IETF's original plan. Few of your customers appear to use tens of LANS, let alone thousands. Maybe that will change but the motivations driving such a thing seem a bit pie in the sky. /56 let's the customer implement more than one LAN (e.g. wired and wireless) but burns through your address space much more slowly. /60 would do that too but nobody seems to be using it. /64 allows only one LAN, so avoid it. e. "sparse allocation" if you feel like it. The jury is still out on whether this is a good idea. Basically, instead of assigning address blocks linearly, you divide your largest free space in half and stick the new assignment right in the middle. Good news: if the assignment later needs to grow your can probably just change the subnet mask, keeping the number of entries in the routing table the same. Bad news: fragments the heck out of your address space so when you actually need a large address block for something, you don't have it. Trying to keep non-dynamic assignments in local or regional aggregable blocks works about as well as it did in IPv4, which is to say poorly. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Tue Jun 5 16:23:47 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 5 Jun 2012 17:23:47 -0400 Subject: ROVER routing security - its not enumeration In-Reply-To: References: Message-ID: On Tue, Jun 5, 2012 at 5:00 PM, Randy Bush wrote: >>>>> routing protection without enumeration. >>>> I can see a use-case for something like: >>>> ? "Build me a prefix list from the RIR data" >>> this requires a full data fetch, not doable in dns. >> does it? shane implied (and it doesn't seem UNREASONABLE, modulo some >> 'doing lots of spare queries') to query for each filter entry at >> filter creation time, no? > > what is the query set, every prefix /7-/24 for the whole fracking ABC > space? > >> that could be optimized I bet, but it SEEMS doable, cumbersome, but >> doable. ?the 'fail open' answer also seems a bit rough in this case >> (but no worse than 'download irr, upload to router, win!' which is >> today's model). > > irr, i do have the 'full' set. ?but you said RIR (the in-addr roots), > not IRR. ?was it a mis-type? oh hell :( yes, I meant IRR. > and i am not gonna put my origin data in the irr and the dns. yea... so today people already fill in: RIR (swip/rwhois) IRR (routing filter updates) DNS (make sure your mailserver has PTRs!) putting origin-validation data into IRR's happens today, it's not 'secured' in any fashion, and lots of proof has shown that 'people fill it with junk' :( So being able to bounce the IRR data off some verifiable source of truth seems like a plus. How verifiable is the rdns-rover tree though? how do I get my start in that prefix hierarchy anyway? by talking to IANA? to my local RIR? to 'jimbo the dns guy down the street?' (I realize that referencing the draft would probably get me this answer but it's too hard to look that up in webcrawler that right now...) -Chris From randy at psg.com Tue Jun 5 16:31:36 2012 From: randy at psg.com (Randy Bush) Date: Tue, 05 Jun 2012 14:31:36 -0700 Subject: ROVER routing security - its not enumeration In-Reply-To: References: Message-ID: > putting origin-validation data into IRR's happens today, it's not > 'secured' in any fashion, and lots of proof has shown that 'people > fill it with junk' :( So being able to bounce the IRR data off some > verifiable source of truth seems like a plus. so i should use the sow's ear as the authoritative definition of the full set? randy From ttauber at 1-4-5.net Tue Jun 5 16:39:31 2012 From: ttauber at 1-4-5.net (Tony Tauber) Date: Tue, 5 Jun 2012 17:39:31 -0400 Subject: ROVER routing security - its not enumeration In-Reply-To: References: Message-ID: Shane A. gave a Lightning Talk the slides for which will be posted at some time soon. They came in at the last minute which is why they're not up already. Tony On Tue, Jun 5, 2012 at 3:28 PM, Christopher Morrow wrote: > On Tue, Jun 5, 2012 at 2:42 PM, Daniel Massey > wrote: > > > > 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 > > you referenced this a few times: > > > doesn't mention a talk from L3 on 6/4 ... got link? > > -chris > > From mohta at necom830.hpcl.titech.ac.jp Tue Jun 5 16:44:22 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Jun 2012 06:44:22 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> Message-ID: <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: > General statement for IPv6-in-IPv4 tunneling, yes. But > inner fragmentation applies equally for *-in-* tunneling. > >> Even though you assume tunnel MTU 1500B > > What I am after is a tunnel MTU of infinity. 1500 is > the minimum packet size that MUST get through. 1501+ > packets are admitted into the tunnel unconditionally > in hopes that they MIGHT get through. Infinity? You can't carry 65516B in an IPv4 packet. > My document also allows for outer fragmentation on the > inner fragments. But, like the RFC4213-derived IPv6 > transition mechanisms treats outer fragmentation as > an anomalous condition to be avoided if possible - not > a steady state operational approach. See Section 3.2 > of RFC4213. Instead, see the last two lines in second last slide of: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf It is a common condition. Masataka Ohta From Fred.L.Templin at boeing.com Tue Jun 5 17:01:55 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 5 Jun 2012 15:01:55 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Tuesday, June 05, 2012 2:44 PM > To: Templin, Fred L; nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > > General statement for IPv6-in-IPv4 tunneling, yes. But > > inner fragmentation applies equally for *-in-* tunneling. > > > >> Even though you assume tunnel MTU 1500B > > > > What I am after is a tunnel MTU of infinity. 1500 is > > the minimum packet size that MUST get through. 1501+ > > packets are admitted into the tunnel unconditionally > > in hopes that they MIGHT get through. > > Infinity? You can't carry 65516B in an IPv4 packet. I should qualify that by saying: 1) For tunnels over IPv4, let infinity equal (2^16 - 1) minus the length of the encapsulation headers 2) For tunnels over IPv6, let infinity equal (2^32 - 1) minus the length of the encapsulation headers > > My document also allows for outer fragmentation on the > > inner fragments. But, like the RFC4213-derived IPv6 > > transition mechanisms treats outer fragmentation as > > an anomalous condition to be avoided if possible - not > > a steady state operational approach. See Section 3.2 > > of RFC4213. > > Instead, see the last two lines in second last slide of: > > http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf > > It is a common condition. Are you interested in only supporting tinygrams? IMHO, go big or go home! Fred fred.l.templin at boeing.com > Masataka Ohta From owen at delong.com Tue Jun 5 17:00:55 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 15:00:55 -0700 Subject: ipv6 book recommendations? In-Reply-To: References: Message-ID: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> On Jun 5, 2012, at 2:23 PM, William Herrin wrote: > On 6/5/12, David Hubbard wrote: >> Does anyone have suggestions on good books to really get >> a thorough understanding of v6, subnetting, security practices, >> etc. Or a few books. Just turned up dual stack with our >> peers and a test network but I'd like to be a lot more >> comfortable with it before looking at our customer network. > > Hi David, > > Instead of going the book route, I'd suggest getting some tunneled > addresses from he.net and then working through > http://ipv6.he.net/certification/ . > > They have the basics pretty well covered, it's interactive and it's free. > > > Some additional thoughts: > > 1. Anybody who tells you that there are security best practices for > IPv6 is full of it. It simply hasn't seen enough use in the > environment to which we're now deploying it and rudimentary > technologies widely used in IPv4 (e.g. NAT/PAT to private address > space) haven't yet made their transition. Not quite. I will say that the security BCPs are not mature and are evolving, but that does not mean that they do not yet exist. > 2. Subnetting in v6 in a nutshell: > > a. If it's a LAN, /64. Always. Stateless autoconfiguration (SLAAC) > only works for /64. > > b. Delegations on 4-bit boundaries for reverse-DNS convenience. > > c. If it's a point to point, a reasonable practice seems to be a /64 > per network area and around /124 per link. Works OK for ethernet point > to points too. /64 is perfectly reasonable per point to point as well. > d. Default customer assignments should be /56 or /48 depending on who > you ask. /48 was the IETF's original plan. Few of your customers > appear to use tens of LANS, let alone thousands. Maybe that will > change but the motivations driving such a thing seem a bit pie in the > sky. /56 let's the customer implement more than one LAN (e.g. wired > and wireless) but burns through your address space much more slowly. > /60 would do that too but nobody seems to be using it. /64 allows only > one LAN, so avoid it. Planning your IPv6 deployment based on today's network needs is folly. Deploying /48s will help future-proof your network and pave the way for some very interesting innovations in the home networking space. > e. "sparse allocation" if you feel like it. The jury is still out on > whether this is a good idea. Basically, instead of assigning address > blocks linearly, you divide your largest free space in half and stick > the new assignment right in the middle. Good news: if the assignment > later needs to grow your can probably just change the subnet mask, > keeping the number of entries in the routing table the same. Bad news: > fragments the heck out of your address space so when you actually need > a large address block for something, you don't have it. Since you should be doing this mostly at the 4-12 bits to the right of your base allocation and the policy is structured such that you should, in most cases, be able to assign same-sized chunks everywhere at this level, that really shouldn't be an issue. Lower in the hierarchy, it's a judgement call on which optimization fits better on a case-by-case basis. Generally, the higher up the hierarchy, the more likely that allocation by bisection (there are other forms of sparse allocation as well) is ideal. In some cases, sparse allocation by reservation, for example, can reduce fragmentation while still providing substantial room for likely growth. > Trying to keep non-dynamic assignments in local or regional aggregable > blocks works about as well as it did in IPv4, which is to say poorly. If you apply for a large enough IPv6 block, this should be less of an issue. That was hard to do under previous policy regimes, but the current ISP allocation policy should make it pretty easy to optimize for this. Certainly, if you have suggestions for how policy can better support this, I am open to improvements at any time. Owen From cgrundemann at gmail.com Tue Jun 5 17:15:42 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 5 Jun 2012 16:15:42 -0600 Subject: ipv6 book recommendations? In-Reply-To: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> References: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> Message-ID: > On Jun 5, 2012, at 2:23 PM, William Herrin wrote: >> 2. Subnetting in v6 in a nutshell: FWIW - There is a published BCOP on IPv6 subnetting: http://www.ipbcop.org/ratified-bcops/bcop-ipv6-subnetting/ Cheers, ~Chris -- @ChrisGrundemann http://chrisgrundemann.com From bill at herrin.us Tue Jun 5 17:23:00 2012 From: bill at herrin.us (William Herrin) Date: Tue, 5 Jun 2012 18:23:00 -0400 Subject: ipv6 book recommendations? In-Reply-To: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> References: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> Message-ID: On 6/5/12, Owen DeLong wrote: > On Jun 5, 2012, at 2:23 PM, William Herrin wrote: >> c. If it's a point to point, a reasonable practice seems to be a /64 >> per network area and around /124 per link. Works OK for ethernet point >> to points too. > > /64 is perfectly reasonable per point to point as well. Hi Owen, Sure, but with the neighbor discovery cache issues that come up with /64's under attack, why open yourself to trouble where you can't realize any benefit? Regards, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Tue Jun 5 17:29:53 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 15:29:53 -0700 Subject: ipv6 book recommendations? In-Reply-To: References: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> Message-ID: On Jun 5, 2012, at 3:15 PM, Chris Grundemann wrote: >> On Jun 5, 2012, at 2:23 PM, William Herrin wrote: > >>> 2. Subnetting in v6 in a nutshell: > > FWIW - There is a published BCOP on IPv6 subnetting: > http://www.ipbcop.org/ratified-bcops/bcop-ipv6-subnetting/ > Unfortunately, this BCOP recommends /56s for residential which is potentially harmful. I'm also not a fan of the /126 or /127 on point-to-points, but, the theoretical issues of neighbor table exhaustion attacks, etc. certainly should not be ignored entirely. Owen From owen at delong.com Tue Jun 5 17:30:56 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 15:30:56 -0700 Subject: ipv6 book recommendations? In-Reply-To: References: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> Message-ID: <2E992D34-DF53-49D5-9ED1-7D46BEE92581@delong.com> On Jun 5, 2012, at 3:23 PM, William Herrin wrote: > On 6/5/12, Owen DeLong wrote: >> On Jun 5, 2012, at 2:23 PM, William Herrin wrote: >>> c. If it's a point to point, a reasonable practice seems to be a /64 >>> per network area and around /124 per link. Works OK for ethernet point >>> to points too. >> >> /64 is perfectly reasonable per point to point as well. > > Hi Owen, > > Sure, but with the neighbor discovery cache issues that come up with > /64's under attack, why open yourself to trouble where you can't > realize any benefit? > Why permit external traffic aimed at your point to point links at all? No external traffic, no attack surface. Owen From owen at delong.com Tue Jun 5 17:32:36 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 15:32:36 -0700 Subject: ipv6 book recommendations? In-Reply-To: References: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> Message-ID: On Jun 5, 2012, at 3:23 PM, William Herrin wrote: > On 6/5/12, Owen DeLong wrote: >> On Jun 5, 2012, at 2:23 PM, William Herrin wrote: >>> c. If it's a point to point, a reasonable practice seems to be a /64 >>> per network area and around /124 per link. Works OK for ethernet point >>> to points too. >> >> /64 is perfectly reasonable per point to point as well. > > Hi Owen, > > Sure, but with the neighbor discovery cache issues that come up with > /64's under attack, why open yourself to trouble where you can't > realize any benefit? > It makes little sense to me to permit people outside your network to deliver packets to your point to point interfaces. Denying this traffic at your borders/edges eliminates all of the attacks without having to juggle inconsistent prefix sizes or do silly bit-math to figure out which address is at the other end of the link. Owen From booloo at ucsc.edu Tue Jun 5 17:37:12 2012 From: booloo at ucsc.edu (Mark Boolootian) Date: Tue, 5 Jun 2012 15:37:12 -0700 Subject: ipv6 book recommendations? In-Reply-To: References: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> Message-ID: Sure, but with the neighbor discovery cache issues that come up with > /64's under attack, why open yourself to trouble where you can't > realize any benefit? > I happen to be a fan of /126s, but if you chose to use a /64, presumably your infrastructure ACLs would provide protection against such attacks. From cgrundemann at gmail.com Tue Jun 5 17:39:14 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 5 Jun 2012 16:39:14 -0600 Subject: ipv6 book recommendations? In-Reply-To: References: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> Message-ID: On Tue, Jun 5, 2012 at 4:29 PM, Owen DeLong wrote: > > On Jun 5, 2012, at 3:15 PM, Chris Grundemann wrote: > >>> On Jun 5, 2012, at 2:23 PM, William Herrin wrote: >> >>>> 2. Subnetting in v6 in a nutshell: >> >> FWIW - There is a published BCOP on IPv6 subnetting: >> http://www.ipbcop.org/ratified-bcops/bcop-ipv6-subnetting/ >> > > Unfortunately, this BCOP recommends /56s for residential which is > potentially harmful. While it does use /56 as an example (mainly because most of the operators I have spoken to say that is as big as they'll go and many are shooting for less) but it does NOT make that a recommendation, from the BCOP: "This is an example for demonstrative purposes only. Individual operators will need to determine their own prefix size preference for serving customers (internal or external). The SMEs of this BCOP highly recommend a /48 for any site that requires more than one subnet and that a site be defined as an individual customer in residential networks." > I'm also not a fan of the /126 or /127 on point-to-points, but, the theoretical > issues of neighbor table exhaustion attacks, etc. certainly should not > be ignored entirely. Agreed, they must be considered. Cheers, ~Chris > Owen > -- @ChrisGrundemann http://chrisgrundemann.com From mohta at necom830.hpcl.titech.ac.jp Tue Jun 5 17:41:04 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Jun 2012 07:41:04 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> Message-ID: <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: >> Infinity? You can't carry 65516B in an IPv4 packet. > 2) For tunnels over IPv6, let infinity equal (2^32 - 1) You can't carry a 65516B IPv6 packet in an IPv4 packet. >> Instead, see the last two lines in second last slide of: >> >> http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf >> >> It is a common condition. > > Are you interested in only supporting tinygrams? IMHO, > go big or go home! Bigger packets makes it rather circuit switching than packet switching. The way to lose. Faster is the way to go. Masataka Ohta From owen at delong.com Tue Jun 5 17:41:27 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 15:41:27 -0700 Subject: ipv6 book recommendations? In-Reply-To: References: <6E302C4A-925B-44C4-8BEA-31FE4E28E31B@delong.com> Message-ID: <450D2AF8-16BC-4B7B-884C-FA44071686BA@delong.com> Apologies for the double post... Mistakenly hit send instead of cancel on the first one. Owen On Jun 5, 2012, at 3:32 PM, Owen DeLong wrote: > > On Jun 5, 2012, at 3:23 PM, William Herrin wrote: > >> On 6/5/12, Owen DeLong wrote: >>> On Jun 5, 2012, at 2:23 PM, William Herrin wrote: >>>> c. If it's a point to point, a reasonable practice seems to be a /64 >>>> per network area and around /124 per link. Works OK for ethernet point >>>> to points too. >>> >>> /64 is perfectly reasonable per point to point as well. >> >> Hi Owen, >> >> Sure, but with the neighbor discovery cache issues that come up with >> /64's under attack, why open yourself to trouble where you can't >> realize any benefit? >> > > It makes little sense to me to permit people outside your network > to deliver packets to your point to point interfaces. Denying this > traffic at your borders/edges eliminates all of the attacks without > having to juggle inconsistent prefix sizes or do silly bit-math to > figure out which address is at the other end of the link. > > Owen > From owen at delong.com Tue Jun 5 17:40:11 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 15:40:11 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCDF9D0.1020004@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> <4FCDF9D0.1020004@ttec.com> Message-ID: On Jun 5, 2012, at 5:21 AM, Joe Maimon wrote: > > > Owen DeLong wrote: > >> >> But that's a whole lot more packets than working PMTU-D to get there and >> you're also waiting for all those round trips, not just the 4 timeouts. >> >> The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at >> 100ms is 2.2 seconds. That's a long time to go without first data packet >> passed, >> >> Owen > > > Yes, it is quite nice when ICMP helpfully informs you what your MTU is. > > However, we have known for quite some time that is simply not reliable on the IPv4 internet, for a multitude of reasons, with intentional ICMP blocking just one of them. You keep saying this, yet you have offered no other explanations. > I have no reason to expect it to work better in IPv6. That's where we differ. In IPv4, since PMTU-D was a new thing, it had to be optional and we had to work around places where it was broken to avoid flat-out breaking the internet. In IPv6, we have the opportunity to push the issue and use education to resolve the problem correctly. > This is why more reliable methods are a good idea, even if they work slower or add more overhead, because as I see it they are intended to be used concurrently with ICMP. ICMP can be a reliable method if we just stop breaking it. Do you have some reason to believe people won't break the other methods, too? I don't. PMTU-D can't be fire-and-forget because paths aren't static. > Also, as I understand the probing, getting data through happens much faster then arriving at the optimal mtu size might take. At the expense of sending a lot of unnecessary additional datagrams. > Perhaps short flows should just be sticking to the min-mtu anyways. So you want to turn a short-flow (say a retrieving a 20k PNG) from being a 3-packet transaction on a path with jumbo frame support at 9000 octets into a 16+ packet exchange? (note I'm only counting the payload packets in one direction, not setup, teardown, additional acks, etc.). Still seems like a bad idea to me. Owen From Fred.L.Templin at boeing.com Tue Jun 5 17:50:58 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 5 Jun 2012 15:50:58 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <20120604163503.GA28331@panix.com> <4FCD0713.4030309@necom830.hpcl.titech.ac.jp> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Tuesday, June 05, 2012 3:41 PM > To: Templin, Fred L > Cc: nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > >> Infinity? You can't carry 65516B in an IPv4 packet. > > > 2) For tunnels over IPv6, let infinity equal (2^32 - 1) > > You can't carry a 65516B IPv6 packet in an IPv4 packet. No, but you can carry a ((2^32 - 1) - X) IPv6 packet in an IPv6 packet. Just insert a jumbogram extension header. > >> Instead, see the last two lines in second last slide of: > >> > >> http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf > >> > >> It is a common condition. > > > > Are you interested in only supporting tinygrams? IMHO, > > go big or go home! > > Bigger packets makes it rather circuit switching than packet > switching. The way to lose. > > Faster is the way to go. Why only fast when you can have both big *and* fast? See Matt's pages on raising the Internet MTU: http://staff.psc.edu/mathis/MTU/ Time on the wire is what matters, and on a 100Gbps wire you can push 6MB in 480usec. That seems more like packet switching latency rather than circuit switching latency. Fred fred.l.templin at boeing.com > Masataka Ohta From mysidia at gmail.com Tue Jun 5 20:02:58 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 5 Jun 2012 20:02:58 -0500 Subject: IPv6 day and tunnels In-Reply-To: <90A5DA13-6AEA-4EF2-AA7B-9A3559717A90@delong.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> <90A5DA13-6AEA-4EF2-AA7B-9A3559717A90@delong.com> Message-ID: On 6/5/12, Owen DeLong wrote: > This is a horrible misconfiguration of the devices on that link. > If your MTU setting on your interface is larger than the smallest MTU > of any L2 forwarder on the link, then, you have badly misconfigured Not really; The network layer and L2 protocols should both be designed to handle this, it is a design error in the protocol that it doesn't. You say it's "misconfiguration", but if IP handled the situation reasonably, it shouldn't be necessary to configure anything in the first place. Whether the neighbors are LAN or cross-tunnel, the issues are similar. It's only a misconfiguration because of flaws in the protocol. Just like you expect to plug devices in a typical LAN and it's not a configuration error to fail to manually find every switch in the LAN and enter MAC addresses into a forwarding table by hand; likewise, you shouldn't expect to key a MTU into every device by hand. IP should be designed so that devices on the link that _can_ handle the large transmission unit, which provides efficiency gains, should be allowed to fully utilize those capabilities, without breakage of connectivity to devices on the same link that have more limited capabilities and can only receive the Minimum required frame size (smaller MTU), and without separating the subnet or installing dividing Proxy ARP servers to send ICMP TooBig packets. > Adding probing to compensate for this misconfiguration merely > serves to perpetuate such errant configurations. Just like adding MAC address learning to Ethernet switches to compensate for the misconfiguration of failing to manually enter hardware addreses into your switches, serves to perpetuate such errant configurations, where the state of the forwarding tables are unreliably left in a non-deterministic state. >> You've got an issue if there are 100ms between two peers on your LAN. >> You're right, you don't need to probe for possible MTUs below 1280. > LAN, sure. However, consider that there are intercontinental L2 links. Intercontinental multi-access L2 links, perhaps, are a horrible misconfiguration. > Owen -- -JH From dennis at justipit.com Tue Jun 5 14:47:40 2012 From: dennis at justipit.com (dennis) Date: Tue, 5 Jun 2012 15:47:40 -0400 Subject: Penetration Test Assistance In-Reply-To: References: Message-ID: Tim, In the past I've used high level diagrams to illustrate the overall network topology with individual tabs (drill down) per data center or POP. The first step to assessing risk is to identify your assets. I'd suggest performing a discovery of your network. Keep in mind Pen tests are typically inconclusive of availability based threats DOS/DDOS (a very high risk today) and in fact specifically avoid tests which might cause degradation of service. I'd suggest including volumetric network (tcp, udp), application floods (http get, post, etc. /dns query floods, etc.) and slow and low attacks. Best of Luck, Dennis -------------------------------------------------- From: "Baklarz, Ron" Sent: Tuesday, June 05, 2012 12:41 PM To: "Green, Timothy" Cc: Subject: RE: Penetration Test Assistance > Not discounting the need for network diagrams, there are also differing > approaches to pen testing. One alternative is a sort of black-box > approach where the pen testers are given little or no advanced knowledge > of the network. It is up to them to 'discover' what they can through open > source means and commence their attacks from what they glean from their > intelligence gathering. This way they are realistically mimicking the > hacker methodology. > > Ron Baklarz C|CISO, CISSP, CISA, CISM, NSA-IAM/IEM > Chief Information Security Officer > Export Control Compliance Officer > National Passenger Railroad Corporation (AMTRAK) > 10 G Street, NE Office 6E606 > Washington, DC 20002 > BaklarR at Amtrak.com > > -----Original Message----- > From: Green, Timothy [mailto:Timothy.Green at ManTech.com] > Sent: Tuesday, June 05, 2012 10:53 AM > To: nanog at nanog.org > Subject: Penetration Test Assistance > > Howdy all, > > I'm a Security Manager of a large network, we are conducting a Pentest > next month and the testers are demanding a complete network diagram of the > entire network. We don't have a "complete" network diagram that shows > everything and everywhere we are. At most we have a bunch of network > diagrams that show what we have in various areas throughout the country. > I've been asking the network engineers for over a month and they seem to > be too lazy to put it together or they have no idea where everything is. > > I've never been in this situation before. Should I be honest to the > testers and tell them here is what we have, we aren't sure if it's > accurate; find everything else? How would they access those areas that > we haven't identified? How can I give them access to stuff that I didn't > know existed? > > What do you all do with your large networks? One huge network diagram, a > bunch of network diagrams separated by region, or both? Any pentest > horror stories? > > Thanks, > > Tim > > ________________________________ > This e-mail and any attachments are intended only for the use of the > addressee(s) named herein and may contain proprietary information. If you > are not the intended recipient of this e-mail or believe that you received > this email in error, please take immediate action to notify the sender of > the apparent error by reply e-mail; permanently delete the e-mail and any > attachments from your computer; and do not disseminate, distribute, use, > or copy this message and any attachments. > > From mohta at necom830.hpcl.titech.ac.jp Tue Jun 5 20:42:48 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Jun 2012 10:42:48 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> Message-ID: <4FCEB598.8000902@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: >> You can't carry a 65516B IPv6 packet in an IPv4 packet. > > No, but you can carry a ((2^32 - 1) - X) IPv6 packet in > an IPv6 packet. I'm afraid you wrote: >> General statement for IPv6-in-IPv4 tunneling, yes. But and >> What I am after is a tunnel MTU of infinity. in a single mail. >> Bigger packets makes it rather circuit switching than packet >> switching. The way to lose. >> >> Faster is the way to go. > > Why only fast when you can have both big *and* fast? Because bigger packets makes it rather circuit switching than packet switching, which is the way to lose. > See > Matt's pages on raising the Internet MTU: > > http://staff.psc.edu/mathis/MTU/ A page with too narrow perspective. > Time on the wire is what matters, In senses you have never imagined, yes. > and on a 100Gbps wire > you can push 6MB in 480usec. That seems more like packet > switching latency rather than circuit switching latency. 100Gbps is boringly slow. Are you interested in only supporting slowgrams? IMHO, go fast or go home! At 1Tbps optical packet switched network, there is no practical buffer other than fiber delay lines. If MTU is 1500B, a delay for a packet is 12ns long, delay for which requires 2.5m fiber. For practical packet lose probability, delay for tens of packets is necessary, which is not a problem. 9000B may still be acceptable. But, 6MB means too lengthy fiber. That's how time matters. Worse, at a 10Mbps edge of a network with 1Tbps backbone, 6MB packets means 4.8 seconds of blocking of other packets, which is why it is like circuit switching. Or, at a 1Tbps link in a super computer, 48usec is too much blocking. That's another way how time matters. Are you interested in only supporting circuitgrams? IMHO, go packet or go ITU! Masataka Ohta From Courtney_Smith at Cable.Comcast.com Tue Jun 5 20:49:37 2012 From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney) Date: Wed, 6 Jun 2012 01:49:37 +0000 Subject: Trouble viewing slides for Automated Configuration and Validation of a Large Scale Network Message-ID: <8DD18D69FFC6DB46AE9CDB191CD8B9812D99DB66@PACDCEXMB04.cable.comcast.com> I am having trouble view the slides for this morning's presentation by Vijay Gill. It appears conversion from power point to a PDF cropped the slides. Can someone else try? Is there an email for reporting issues with the slides? Thanks. http://www.nanog.org/meetings/nanog55/presentations/Tuesday/Gill_Schmidt.pdf From morrowc.lists at gmail.com Tue Jun 5 22:12:25 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 5 Jun 2012 23:12:25 -0400 Subject: ROVER routing security - its not enumeration In-Reply-To: References: Message-ID: On Tue, Jun 5, 2012 at 5:39 PM, Tony Tauber wrote: > Shane A. gave a Lightning Talk the slides for which will be posted at some > time soon. I figured the talk was shane's. > They came in at the last minute which is why they're not up already. > ok, cool. thanks -chris > Tony > > On Tue, Jun 5, 2012 at 3:28 PM, Christopher Morrow > wrote: >> >> On Tue, Jun 5, 2012 at 2:42 PM, Daniel Massey >> wrote: >> >> >> > 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 >> >> you referenced this a few times: >> ? >> >> doesn't mention a talk from L3 on 6/4 ... got link? >> >> -chris >> > From owen at delong.com Tue Jun 5 23:44:59 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 21:44:59 -0700 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> <90A5DA13-6AEA-4EF2-AA7B-9A3559717A90@delong.com> Message-ID: <66335AB0-A842-4C5B-88E0-B36DE10FEB5E@delong.com> On Jun 5, 2012, at 6:02 PM, Jimmy Hess wrote: > On 6/5/12, Owen DeLong wrote: >> This is a horrible misconfiguration of the devices on that link. >> If your MTU setting on your interface is larger than the smallest MTU >> of any L2 forwarder on the link, then, you have badly misconfigured > > Not really; The network layer and L2 protocols should both be > designed to handle this, it is a design error in the protocol that it > doesn't. You say it's "misconfiguration", but if IP handled the > situation reasonably, it shouldn't be necessary to configure anything > in the first place. Whether the neighbors are LAN or cross-tunnel, > the issues are similar. > Really, no. The L3 MTU on an interface should be configured to the lowest MTU reachable via that link without crossing a router. It's just that simple. Anything else _IS_ a misconfiguration. First, your idea of handling the situation reasonably is a layering violation. Second, you are correct. All L2 bridges for a given media type should support the largest configurable MTU for that media type, so, it is arguably a design flaw in the bridges. However, in an environment where you have broken L2 devices (design flaw), you have to configure appropriately for that. > It's only a misconfiguration because of flaws in the protocol. No, it's a misconfiguration because of the limitations of the hardware due to its design defects. L3 should not need to test the end-to-end L2 capabilities. It should be able to depend on what the OS tells it. > Just like you expect to plug devices in a typical LAN and it's not a > configuration error to fail to manually find every switch in the LAN > and enter MAC addresses into a forwarding table by hand; likewise, > you shouldn't expect to key a MTU into every device by hand. You don't expect to ever care about the MAC addresses of any of the switches in the LAN let alone enter them into any form of forwarding table at all. You do expect to need to know about the MAC addresses of adjacent systems you are trying to reach, and, you use either ND or ARP to map L3 addresses onto their corresponding L2 addresses as needed. I will note that this depends on sending a packet out to an address that reaches all of the candidate hosts (In the case of ND, this is a multicast to all hosts which have the same last 24 bits in their IP suffix. In the case of ARP, this is a broadcast packet) and expects them (at L3) to answer "That's ME!". Of course you can enter them by hand in situations where ARP or ND don't work for whatever reason. You expect ARP or ND to work and a bridge that didn't forward ARP would be just as broken as a bridge which doesn't support the full interface MTU. I would expect to have to enter MAC adjacencies manually if I had a bridge that didn't pass ARP/ND traffic, just as I expect to have to enter the MTU manually if I have a bridge that doesn't support the correct full MTU of the network. > IP should be designed so that devices on the link that _can_ handle > the large transmission unit, which provides efficiency gains, should > be allowed to fully utilize those capabilities, without breakage of > connectivity to devices on the same link that have more limited > capabilities and can only receive the Minimum required frame size > (smaller MTU), and without separating the subnet or installing > dividing Proxy ARP servers to send ICMP TooBig packets. No, it really shouldn't. Doing this is a serious layering violation for one, and, it can't be achieved efficiently number two. It adds lots of overhead and is very error prone. There's no signaling mechanism for L3 to be informed when the L2 topology changes, for example, which might necessitate a recalculation of the MTU. A given link should have a single MTU period. I don't know of ANY L3 protocol which supports anything else. Not IP, not IPX, not DECNET, not AppleTalk, no Banyan Vines, not XNS, none of them support the idea of MTU per adjacency. If you can only have one MTU per link, then, it must be the lowest common denominator of all participants and forwarders on that link. >> Adding probing to compensate for this misconfiguration merely >> serves to perpetuate such errant configurations. > > Just like adding MAC address learning to Ethernet switches to > compensate for the misconfiguration of failing to manually enter > hardware addreses into your switches, serves to perpetuate such errant > configurations, where the state of the forwarding tables > are unreliably left in a non-deterministic state. Apples and oranges. See above. In fact, MAC address learning on the switches is utterly unrelated to the MAC adjacency table maintained by ARP/ND. One is an L2 forwarding tree never learned by anything at L3 (the MAC forwarding table learned on the switches) and the other is a MAC adjacency table for a given link used by the L2 software on the host to populate the L2 packet header based on the L3 information. >>> You've got an issue if there are 100ms between two peers on your LAN. >>> You're right, you don't need to probe for possible MTUs below 1280. >> LAN, sure. However, consider that there are intercontinental L2 links. > > Intercontinental multi-access L2 links, perhaps, are a horrible > misconfiguration. > No, they are not. They may be a horribly bad idea in many cases, but, there are actually legitimate applications for them and they conform to the existing documented standards. Owen From owen at delong.com Tue Jun 5 23:58:26 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jun 2012 21:58:26 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCEB598.8000902@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> Message-ID: >>> Bigger packets makes it rather circuit switching than packet >>> switching. The way to lose. >>> >>> Faster is the way to go. >> >> Why only fast when you can have both big *and* fast? > > Because bigger packets makes it rather circuit switching than > packet switching, which is the way to lose. > Er... No. It's attitudes like this that killed ATM. (argument about whether the ATM cell payload should be 64 or 128 octets lead to a mathematical compromise decision that was completely unworkable and vastly inferior to either choice. Unfortunately, neither the US telcos (128) or the EU telcos (64) would give ground and accept the other standard.) Larger packets for sustained flows of large amounts of data do not make it circuit switched, they make packet switching more efficient by reducing overhead. Especially on higher bandwidth links. Admittedly, if you go to too large an MTU for your bps, you can create HOL blocking issues which have the same loss characteristics as circuit switching. However, let's say that anything >10ms HOL blocking is our definition of bad. At 10Gbps, that's 100,000 bits or 12,500 octets. At 100Gbps, that's 125,000 octets. Given the combination of Moore's law and the deployment lifecycle, designs we do today in this regard can be expected to last ~12 years or more, so they should be prepared for at least 16x. At 1,600 Gbps, that puts our target maximum MTU up around 200M octets. >> See >> Matt's pages on raising the Internet MTU: >> >> http://staff.psc.edu/mathis/MTU/ > > A page with too narrow perspective. > >> Time on the wire is what matters, > > In senses you have never imagined, yes. > ? Time on the wire is what matters. It is the primary distinction between packet and circuit switching. >> and on a 100Gbps wire >> you can push 6MB in 480usec. That seems more like packet >> switching latency rather than circuit switching latency. > > 100Gbps is boringly slow. > His case only gets better when you go faster. Seriously, Mas, try to keep up. > Are you interested in only supporting slowgrams? IMHO, > go fast or go home! > > At 1Tbps optical packet switched network, there is no > practical buffer other than fiber delay lines. Which argues for an even larger MTU. > If MTU is 1500B, a delay for a packet is 12ns long, delay for > which requires 2.5m fiber. For practical packet lose probability, > delay for tens of packets is necessary, which is not a problem. > > 9000B may still be acceptable. > > But, 6MB means too lengthy fiber. 6MB at 1TB/sec is 48 microseconds which is 120 km fiber. Modern single-mode spools 10 times that size can actually be built within reason. > That's how time matters. > > Worse, at a 10Mbps edge of a network with 1Tbps backbone, > 6MB packets means 4.8 seconds of blocking of other packets, > which is why it is like circuit switching. But you wouldn't carry a 6MB MTU out to a 10 Mbps edge. You'd drop the edge MTU to 1500. That's why Path MTU Discovery is useful. > Or, at a 1Tbps link in a super computer, 48usec is too much > blocking. In which case you would want to use a smaller MTU. However, I doubt that anyone is likely to run a tunnel in a situation where 48microseconds is too much latency and we are talking about tunnel MTUs here. > > That's another way how time matters. > > Are you interested in only supporting circuitgrams? IMHO, > go packet or go ITU! Sigh... I now realize that the other end of this conversation is a human with too narrow a view. Owen From joly at punkcast.com Wed Jun 6 01:29:46 2012 From: joly at punkcast.com (Joly MacFie) Date: Wed, 6 Jun 2012 02:29:46 -0400 Subject: WEBCAST: Is Asia Pacific and China doing well on IPv6 Deployment? - just started In-Reply-To: References: Message-ID: > > ** > > [image: isoc-hk] The Internet Society's Hong Kong > Chapter (ISOC HK ), continuing its pioneering series > of IPv6 events, will mark today June 6 2012 Global IPv6 Launch with a > seminar: 'Is Asia Pacific and China doing well on IPv6 Deployment?'. > Featured speakers include Geoff Huston of APNIC who will talk about "The > Post - IPocalypse Internet", and Walter Fung of NTT who will address "IPv6 > on Cloud in Asia Pacific". Since HK is EDT+12 the live webcast has just > begun. > > *What:* Is Asia Pacific and China doing well on IPv6 Deployment? > * Where:* Cyberport Hong Kong > *When:* Weds Jun 6 2012 2pm-5.30pm HKT|0600-0930UTC|0200-0530EDT > *Webcast:* http://www.livestream.com/internetsocietychapters > *Hashtags*: #v6launch | #ipv6| > @isochk > * More info:* http://www.isoc.hk/ > > Comment See all comments > > > *Trouble clicking?* Copy and paste this URL into your browser: > http://isoc-ny.org/p2/?p=3541 > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > > VP (Admin) - ISOC-NY - http://isoc-ny.org > -------------------------------------------------------------- > - > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From seth.mos at dds.nl Wed Jun 6 02:10:37 2012 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 06 Jun 2012 09:10:37 +0200 Subject: ipv6 book recommendations? In-Reply-To: References: Message-ID: <4FCF026D.4040409@dds.nl> Op 5-6-2012 23:23, William Herrin schreef: > On 6/5/12, David Hubbard wrote: > Hi David, > > Instead of going the book route, I'd suggest getting some tunneled > addresses from he.net and then working through > http://ipv6.he.net/certification/ . > > They have the basics pretty well covered, it's interactive and it's free. +1 it's one of the best ways to learn. Do. > > Some additional thoughts: > > 1. Anybody who tells you that there are security best practices for > IPv6 is full of it. It simply hasn't seen enough use in the > environment to which we're now deploying it and rudimentary > technologies widely used in IPv4 (e.g. NAT/PAT to private address > space) haven't yet made their transition. Well, not quite, but firewall rules work just the same as before. Use those. The longer version is that some people used from internet to any rules on their wan which in a IPv4 NAT really translated to allow everything to my external address. Unless you used 1:1 ofcourse, but I digress. In IPv6 such a rule really means anything internal. People that have administered firewalls that route public addresses will know exactly what I mean. > d. Default customer assignments should be /56 or /48 depending on who > you ask. /48 was the IETF's original plan. Few of your customers > appear to use tens of LANS, let alone thousands. Maybe that will > change but the motivations driving such a thing seem a bit pie in the > sky. /56 let's the customer implement more than one LAN (e.g. wired > and wireless) but burns through your address space much more slowly. > /60 would do that too but nobody seems to be using it. /64 allows only > one LAN, so avoid it. You seem to miss a semi important thing here. Daisy chaining of routers in the premises. Some routers (pfSense included) allow for setting up prefix delegation, this means that you can connect routers behind the one you have and still have native v6. Although the automatic setup system I wrote for this works with /56 networks it will only setup PD for /64 networks at this point. I allocate a part of the assigned /56 network for prefix delegation automatically. If the PD is /48 I can delegate /56 networks to the subrouters, which on their turn can delegate /64 networks to another sub router. It's not that the user itself will actually assign all those networks, but routers will do automatically and you need proper route aggregation. It's unlikely that all networks will be directly assinged as /64 networks either, it could also be multiple routers. Even if it was done manually I'd assign a /60 route out of a /56 PD. The notion that it will always be a /64 is... well. Regards, Seth From valdis.kletnieks at vt.edu Wed Jun 6 02:22:05 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 06 Jun 2012 03:22:05 -0400 Subject: IPv6 day and tunnels In-Reply-To: Your message of "Tue, 05 Jun 2012 21:44:59 -0700." <66335AB0-A842-4C5B-88E0-B36DE10FEB5E@delong.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> <90A5DA13-6AEA-4EF2-AA7B-9A3559717A90@delong.com> <66335AB0-A842-4C5B-88E0-B36DE10FEB5E@delong.com> Message-ID: <9738.1338967325@turing-police.cc.vt.edu> On Tue, 05 Jun 2012 21:44:59 -0700, Owen DeLong said: > Second, you are correct. All L2 bridges for a given media type > should support the largest configurable MTU for that media > type, so, it is arguably a design flaw in the bridges. However, > in an environment where you have broken L2 devices (design > flaw), you have to configure appropriately for that. Don't waste your time configuring for that case. Find a shotgun, some ammo, and a bring-your-own-target range... You'll feel better, live longer, and the world will be a better place for it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jordi.palet at consulintel.es Wed Jun 6 02:22:20 2012 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 06 Jun 2012 09:22:20 +0200 Subject: ipv6 book recommendations? In-Reply-To: <4FCF026D.4040409@dds.nl> Message-ID: One more (free) book: http://www.ipv6tf.org/index.php?page=news/newsroom&id=8281 (available in several languages) ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From james.cutler at consultant.com Wed Jun 6 08:12:40 2012 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 6 Jun 2012 09:12:40 -0400 Subject: ipv6 book recommendations? In-Reply-To: References: Message-ID: On Jun 5, 2012, at 5:23 PM, William Herrin wrote: > On 6/5/12, David Hubbard wrote: >> Does anyone have suggestions on good books to really get >> a thorough understanding of v6, subnetting, security practices, >> etc. Or a few books. Just turned up dual stack with our >> peers and a test network but I'd like to be a lot more >> comfortable with it before looking at our customer network. > > Hi David, > > Instead of going the book route, I'd suggest getting some tunneled > addresses from he.net and then working through > http://ipv6.he.net/certification/ . > > They have the basics pretty well covered, it's interactive and it's free. > > > Some additional thoughts: > > 1. Anybody who tells you that there are security best practices for > IPv6 is full of it. It simply hasn't seen enough use in the > environment to which we're now deploying it and rudimentary > technologies widely used in IPv4 (e.g. NAT/PAT to private address > space) haven't yet made their transition. > > > 2. Subnetting in v6 in a nutshell: > > a. If it's a LAN, /64. Always. Stateless autoconfiguration (SLAAC) > only works for /64. > > b. Delegations on 4-bit boundaries for reverse-DNS convenience. > > c. If it's a point to point, a reasonable practice seems to be a /64 > per network area and around /124 per link. Works OK for ethernet point > to points too. > > d. Default customer assignments should be /56 or /48 depending on who > you ask. /48 was the IETF's original plan. Few of your customers > appear to use tens of LANS, let alone thousands. Maybe that will > change but the motivations driving such a thing seem a bit pie in the > sky. /56 let's the customer implement more than one LAN (e.g. wired > and wireless) but burns through your address space much more slowly. > /60 would do that too but nobody seems to be using it. /64 allows only > one LAN, so avoid it. > > e. "sparse allocation" if you feel like it. The jury is still out on > whether this is a good idea. Basically, instead of assigning address > blocks linearly, you divide your largest free space in half and stick > the new assignment right in the middle. Good news: if the assignment > later needs to grow your can probably just change the subnet mask, > keeping the number of entries in the routing table the same. Bad news: > fragments the heck out of your address space so when you actually need > a large address block for something, you don't have it. > > Trying to keep non-dynamic assignments in local or regional aggregable > blocks works about as well as it did in IPv4, which is to say poorly. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > Bill's additional comments about subnetting are a concise and accurate view. They also show and overlooked benefit of IPv6 over IPv4 -- For address planning, it is no longer necessary to count individual end points, rather only the subnets must be counted. This reduces labor in planning, assigning, and tracking addresses. James R. Cutler james.cutler at consultant.com From jmaimon at ttec.com Wed Jun 6 08:28:36 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 06 Jun 2012 09:28:36 -0400 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> Message-ID: <4FCF5B04.4050806@ttec.com> Owen DeLong wrote: > Given the combination of Moore's law and the deployment > lifecycle, designs we do today in this regard can be expected > to last ~12 years or more, so they should be prepared for > at least 16x. At 1,600 Gbps, that puts our target maximum > MTU up around 200M octets. > If ICMP is the only interop method we have, we will still be using 1500 with 1280 the next most popular value. L2 uniformity requirements is a contributing factor to this as well as to the various ways ICMP does not serve well for L3. Consider a NBMA networks, or commonly found today, NHRP tunnela. All endpoints must use the same MTU. Perhaps some devices are capabable of much higher. Perhaps some tunnel egresses are capable of re-assembly. Static configuration of MTU is not ideal. It does not allow for dynamic changes in circumstances, such as tunnels/encapsulation rerouting between different MTU links. Between mpls and ethernet services, encapsulation and re-encapsulation is more and more prevalent, making MTU an issue again and again. Blocking is not the only way ICMP messages may fail to arrive. Configured MTU values can very easily be incorrect and hard to detect - this will get worse as L2 networks are glued together through various providers and segments. Devices in the path may have rate limiting or may simply be unable to route back to the source. Devices should be able to dynamically detect MTU on L3 links, and yes, maybe even for L2 adjancencies as well. L3 protocols should not have to rely solely on ICMP exception handling to work properly. Joe From jmaimon at ttec.com Wed Jun 6 08:31:20 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 06 Jun 2012 09:31:20 -0400 Subject: IPv6 day and tunnels In-Reply-To: <66335AB0-A842-4C5B-88E0-B36DE10FEB5E@delong.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> <90A5DA13-6AEA-4EF2-AA7B-9A3559717A90@delong.com> <66335AB0-A842-4C5B-88E0-B36DE10FEB5E@delong.com> Message-ID: <4FCF5BA8.2050602@ttec.com> Owen DeLong wrote: > > Really, no. The L3 MTU on an interface should be configured to the > lowest MTU reachable via that link without crossing a router. It's > just that simple. Anything else _IS_ a misconfiguration. Perhaps this should be thought of as a limitation, rather then a feature. Joe From ben at bencarleton.com Wed Jun 6 08:34:12 2012 From: ben at bencarleton.com (Ben Carleton) Date: Wed, 6 Jun 2012 09:34:12 -0400 (EDT) Subject: =?utf-8?Q?.GW_registrar=3F?= Message-ID: <1338989652.698228506@apps.rackspace.com> Hello all, Does anyone have a contact at either DENIC or "Funda??o IT & MEDIA Universidade de Bissao" that can advise if registrations are currently being accepted for .GW domain names? The IANA admin contact, admin at register.gw, is at a domain with no valid MX records (or A records, for that matter). The technical contact is listed as DENIC. TIA, -- Ben Carleton From anton at huge.geek.nz Wed Jun 6 08:53:02 2012 From: anton at huge.geek.nz (Anton Smith) Date: Wed, 6 Jun 2012 14:53:02 +0100 Subject: ipv6 book recommendations? In-Reply-To: References: Message-ID: On 6 June 2012 14:12, Cutler James R wrote: > > On Jun 5, 2012, at 5:23 PM, William Herrin wrote: > > > On 6/5/12, David Hubbard wrote: > >> Does anyone have suggestions on good books to really get > >> a thorough understanding of v6, subnetting, security practices, > >> etc. ?Or a few books. ?Just turned up dual stack with our > >> peers and a test network but I'd like to be a lot more > >> comfortable with it before looking at our customer network. > > > > Hi David, > > > > Instead of going the book route, I'd suggest getting some tunneled > > addresses from he.net and then working through > > http://ipv6.he.net/certification/ . > > > > They have the basics pretty well covered, it's interactive and it's free. > > > > > > Some additional thoughts: > > > > 1. Anybody who tells you that there are security best practices for > > IPv6 is full of it. It simply hasn't seen enough use in the > > environment to which we're now deploying it and rudimentary > > technologies widely used in IPv4 (e.g. NAT/PAT to private address > > space) haven't yet made their transition. > > > > > > 2. Subnetting in v6 in a nutshell: > > > > a. If it's a LAN, /64. Always. Stateless autoconfiguration (SLAAC) > > only works for /64. > > > > b. Delegations on 4-bit boundaries for reverse-DNS convenience. > > > > c. If it's a point to point, a reasonable practice seems to be a /64 > > per network area and around /124 per link. Works OK for ethernet point > > to points too. > > > > d. Default customer assignments should be /56 or /48 depending on who > > you ask. /48 was the IETF's original plan. Few of your customers > > appear to use tens of LANS, let alone thousands. Maybe that will > > change but the motivations driving such a thing seem a bit pie in the > > sky. /56 let's the customer implement more than one LAN (e.g. wired > > and wireless) but burns through your address space much more slowly. > > /60 would do that too but nobody seems to be using it. /64 allows only > > one LAN, so avoid it. > > > > e. "sparse allocation" if you feel like it. The jury is still out on > > whether this is a good idea. Basically, instead of assigning address > > blocks linearly, you divide your largest free space in half and stick > > the new assignment right in the middle. Good news: if the assignment > > later needs to grow your can probably just change the subnet mask, > > keeping the number of entries in the routing table the same. Bad news: > > fragments the heck out of your address space so when you actually need > > a large address block for something, you don't have it. > > > > Trying to keep non-dynamic assignments in local or regional aggregable > > blocks works about as well as it did in IPv4, which is to say poorly. > > > > Regards, > > Bill Herrin > > > > > > -- > > William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us > > 3005 Crane Dr. ...................... Web: > > Falls Church, VA 22042-3004 > > > > Bill's additional comments about subnetting are a concise and accurate view. ?They also show and overlooked benefit of IPv6 over IPv4 -- For address planning, it is no longer necessary to count individual end points, rather only the subnets must be counted. ?This reduces labor in planning, assigning, and tracking addresses. > > > James R. Cutler > james.cutler at consultant.com > Hi all, Potentially silly question but, as Bill points out a LAN always occupies a /64. Does this imply that we would have large L2 segments with a large number of hosts on them? What about the age old discussion about keeping broadcast segments small? Or, will it be that a /64 will only typically have a similar number of hosts in it as say, a /23|4 in the IPv4 world? Cheers, Anton From vgill at vijaygill.com Wed Jun 6 08:57:52 2012 From: vgill at vijaygill.com (vijay gill) Date: Wed, 6 Jun 2012 06:57:52 -0700 Subject: Trouble viewing slides for Automated Configuration and Validation of a Large Scale Network In-Reply-To: <8DD18D69FFC6DB46AE9CDB191CD8B9812D99DB66@PACDCEXMB04.cable.comcast.com> References: <8DD18D69FFC6DB46AE9CDB191CD8B9812D99DB66@PACDCEXMB04.cable.comcast.com> Message-ID: A non-cut off version is here: http://sdrv.ms/MeQl1L On Tue, Jun 5, 2012 at 6:49 PM, Smith, Courtney < Courtney_Smith at cable.comcast.com> wrote: > I am having trouble view the slides for this morning's presentation by > Vijay Gill. It appears conversion from power point to a PDF cropped the > slides. Can someone else try? Is there an email for reporting issues with > the slides? Thanks. > > > http://www.nanog.org/meetings/nanog55/presentations/Tuesday/Gill_Schmidt.pdf > > > From frnkblk at iname.com Wed Jun 6 09:05:04 2012 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 6 Jun 2012 09:05:04 -0500 Subject: AAAA's for www.netflix.com Message-ID: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> I started monitoring IPv6 access to www.netflix.com after seeing this posting (http://www.personal.psu.edu/dvm105/blogs/ipv6/2012/06/netflix-is-back.html) and what I found, over the week, was that access was coming and going (www.premieronline.net/~fbulk/netflix.png). But not because of IPv6 connectivity, but because the AAAA's were coming and going. Netflix's DNS TTL is pretty short. I assume Netflix has some global DNS load balancing so my perspective may not be complete. Has anyone else been seeing this? I contacted a Netflix employee (he's well known on this list) and he responded once but I haven't heard back since Saturday. Here's some sample queries from Saturday and today. ========================================================= nagios:/home/fbulk# dig AAAA www.netflix.com ; <<>> DiG 9.7.3 <<>> AAAA www.netflix.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26825 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.netflix.com. IN AAAA ;; AUTHORITY SECTION: netflix.com. 150 IN SOA dns.netflix.com. nicadmin.netflix.com. 2012060104 900 600 1209600 1800 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jun 2 09:29:17 2012 ;; MSG SIZE rcvd: 82 nagios:/home/fbulk# ========================================================= ========================================================= nagios:/home/fbulk# dig AAAA www.netflix.com ; <<>> DiG 9.7.3 <<>> AAAA www.netflix.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33117 ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 8, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.netflix.com. IN AAAA ;; ANSWER SECTION: www.netflix.com. 132 IN CNAME dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN AAAA 2406:da00:ff00::3210:e195 dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN AAAA 2406:da00:ff00::3213:5282 dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN AAAA 2406:da00:ff00::3213:6340 dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN AAAA 2406:da00:ff00::3213:779a dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN AAAA 2406:da00:ff00::1715:75cd dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN AAAA 2406:da00:ff00::1715:eceb dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN AAAA 2406:da00:ff00::1717:e388 dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN AAAA 2406:da00:ff00::1717:eb58 ;; AUTHORITY SECTION: elb.amazonaws.com. 7092 IN NS ns-916.amazonaws.com. elb.amazonaws.com. 7092 IN NS ns-941.amazonaws.com. elb.amazonaws.com. 7092 IN NS ns-927.amazonaws.com. elb.amazonaws.com. 7092 IN NS ns-925.amazonaws.com. elb.amazonaws.com. 7092 IN NS ns-934.amazonaws.com. elb.amazonaws.com. 7092 IN NS ns-935.amazonaws.com. elb.amazonaws.com. 7092 IN NS ns-944.amazonaws.com. elb.amazonaws.com. 7092 IN NS ns-947.amazonaws.com. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jun 2 09:34:35 2012 ;; MSG SIZE rcvd: 504 nagios:/home/fbulk# ========================================================= ========================================================= nagios:/home/fbulk# dig AAAA www.netflix.com ; <<>> DiG 9.7.3 <<>> AAAA www.netflix.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34529 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.netflix.com. IN AAAA ;; AUTHORITY SECTION: netflix.com. 94 IN SOA dns.netflix.com. nicadmin.netflix.com. 2012060107 900 600 1209600 1800 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jun 6 09:00:44 2012 ;; MSG SIZE rcvd: 82 nagios:/home/fbulk# ========================================================= Frank Bulk From saku at ytti.fi Wed Jun 6 09:18:01 2012 From: saku at ytti.fi (Saku Ytti) Date: Wed, 6 Jun 2012 17:18:01 +0300 Subject: Trouble viewing slides for Automated Configuration and Validation of a Large Scale Network In-Reply-To: References: <8DD18D69FFC6DB46AE9CDB191CD8B9812D99DB66@PACDCEXMB04.cable.comcast.com> Message-ID: <20120606141801.GA9095@pob.ytti.fi> On (2012-06-06 06:57 -0700), vijay gill wrote: > A non-cut off version is here: http://sdrv.ms/MeQl1L For me provisioning automatically has always been quite trivial problem, system just has object representation of service with references to other objects and then those objects are used to fill in blanks of config snipsets. Config snipset being rather flat ascii, maintained by people, not system. Thus system really doesn't need platform specific intelligence. What is difficult problem, is configuration conformance, as the configuration you generate does not look the same after it has passed the platforms parser for various extremely good reasons. It looks like Microsoft has implemented parser for each vendor they use, since without parser doing context sensitive repairs isn't going to happen. This is huge chore, requires constant maintenance when new services/products are added and when software are upgraded. If you have enough scale I'm sure the work needed to do parsers is acceptable. However I think for most shops, it's not practical to have per-platform parsers, so most shops probably don't have hard-guarantees of configuration conformance. But if you ignore need for context sensitive repairs you can get hard guarantees for configuration conformance without having platform specific intelligence in system to either direction (out/in). Out is solved as explained above, in you can solve by storing the object based copy of config and then grabbing the config right after it passed platform parser, now you know that this bit of config means this bit of ascii data and you can keep verifying that they match. When they don't match, you know something is off, but machine won't be able to tell what. So system must have 100% coverage, nothing can be changed outside system. But this isn't actually that hard to satisfy, once you introduce 'alien objects' which are just raw-config-snipset punched into the provisioning system. -- ++ytti From Jean-Francois.TremblayING at videotron.com Wed Jun 6 09:35:48 2012 From: Jean-Francois.TremblayING at videotron.com (Jean-Francois.TremblayING at videotron.com) Date: Wed, 6 Jun 2012 10:35:48 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: Message-ID: Anton Smith a ?crit sur 06/06/2012 09:53:02 AM : > Potentially silly question but, as Bill points out a LAN always > occupies a /64. > > Does this imply that we would have large L2 segments with a large > number of hosts on them? What about the age old discussion about > keeping broadcast segments small? The /64 only removes the limitation on the number of *addresses* on the L2 domain. Limitations still apply for the amount of ARP and ND noise. A maximum number of hosts is reached when that noise floor represents a significant portion of the link bandwidth. If ARP/ND proxying is used, the limiting factor may instead be the CPU on the gateway. The ND noise generated is arguably higher than ARP because of DAD, but I don't remember seeing actual numbers on this (anybody?). I've seen links with up to 15k devices where ARP represented a significant part of the link usage, but most weren't (yet) IPv6. /JF From elmi at 4ever.de Wed Jun 6 09:43:43 2012 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 6 Jun 2012 16:43:43 +0200 Subject: .GW registrar? In-Reply-To: <1338989652.698228506@apps.rackspace.com> References: <1338989652.698228506@apps.rackspace.com> Message-ID: <20120606144343.GA7032@h.detebe.org> Re Ben, ben at bencarleton.com (Ben Carleton) wrote: > Does anyone have a contact at either DENIC or "Funda??o IT & MEDIA Universidade de Bissao" that can advise if registrations are currently being accepted for .GW domain names? The IANA admin contact, > admin at register.gw, is at a domain with no valid MX records (or A records, for that matter). The technical contact is listed as DENIC. I'll pick this up and forward your contact info to someone inside DENIC who might know. Yours, Elmar. From chuckchurch at gmail.com Wed Jun 6 09:58:05 2012 From: chuckchurch at gmail.com (Chuck Church) Date: Wed, 6 Jun 2012 10:58:05 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: Message-ID: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> Does anyone know the reason /64 was proposed as the size for all L2 domains? I've looked for this answer before, never found a good one. I thought I read there are some L2 technologies that use a 64 bit hardware address, might have been Bluetooth. Guaranteeing that ALL possible hosts could live together in the same L2 domain seems like overkill, even for this group. /80 would make more sense, it does match up with Ethernet MACs. Not as easy to compute, for humans nor processors that like things in 32 or 64 bit chunks however. Anyone have a definite answer? Thanks, Chuck -----Original Message----- From: Jean-Francois.TremblayING at videotron.com [mailto:Jean-Francois.TremblayING at videotron.com] Sent: Wednesday, June 06, 2012 10:36 AM To: anton at huge.geek.nz Cc: NANOG list Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) Anton Smith a ?crit sur 06/06/2012 09:53:02 AM : > Potentially silly question but, as Bill points out a LAN always > occupies a /64. > > Does this imply that we would have large L2 segments with a large > number of hosts on them? What about the age old discussion about > keeping broadcast segments small? The /64 only removes the limitation on the number of *addresses* on the L2 domain. Limitations still apply for the amount of ARP and ND noise. A maximum number of hosts is reached when that noise floor represents a significant portion of the link bandwidth. If ARP/ND proxying is used, the limiting factor may instead be the CPU on the gateway. The ND noise generated is arguably higher than ARP because of DAD, but I don't remember seeing actual numbers on this (anybody?). I've seen links with up to 15k devices where ARP represented a significant part of the link usage, but most weren't (yet) IPv6. /JF From james.cutler at consultant.com Wed Jun 6 10:00:02 2012 From: james.cutler at consultant.com (Cutler James R) Date: Wed, 6 Jun 2012 11:00:02 -0400 Subject: ipv6 book recommendations? In-Reply-To: References: Message-ID: <704922D8-3D6B-43E4-B6D5-4101D7B3C620@consultant.com> On Jun 6, 2012, at 9:53 AM, Anton Smith wrote: > > Hi all, > > Potentially silly question but, as Bill points out a LAN always occupies a /64. > > Does this imply that we would have large L2 segments with a large > number of hosts on them? What about the age old discussion about > keeping broadcast segments small? > > Or, will it be that a /64 will only typically have a similar number of > hosts in it as say, a /23|4 in the IPv4 world? > > Cheers, > Anton Now you have deduced the beauty of the scheme. The number of end points does not matter to IPv6 address planning. Said another way - my factory subnet may have a gazillion(1) little machines on one subnet while my data center boxes may have several subnets. Just count the subnets. Let the traffic/technology drive the use per subnet whilst you TRILL(2) a pretty tune. Note (1) Gazillion < 2^64 Note (2) Thanks, Radia James R. Cutler james.cutler at consultant.com From Fred.L.Templin at boeing.com Wed Jun 6 11:00:41 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Wed, 6 Jun 2012 09:00:41 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCF5BA8.2050602@ttec.com> References: <4FCC11B2.2090405@ttec.com> <4FCC4A6F.30907@necom830.hpcl.titech.ac.jp> <25CD6ADB-7BC1-4E26-83F9-AEAF17CB4367@unfix.org> <4FCCB9CA.7010008@necom830.hpcl.titech.ac.jp> <530ECE73-1DF6-4387-A27A-869724F291A5@unfix.org> <07C40F62-0BF6-4B77-BD9E-4F7E75922140@puck.nether.net> <4FCD1B13.7080801@unfix.org> <4FCD2803.9070206@ttec.com> <4FCD2CD4.30307@unfix.org> <4FCD364C.5070001@ttec.com> <4FCD49D8.30704@unfix.org> <4FCD5115.7090003@ttec.com> <2AC1B772-1852-4135-A0D1-7DED309A37F2@delong.com> <90A5DA13-6AEA-4EF2-AA7B-9A3559717A90@delong.com> <66335AB0-A842-4C5B-88E0-B36DE10FEB5E@delong.com> <4FCF5BA8.2050602@ttec.com> Message-ID: A few more words on MTU. What we are after is accommodation of MTU diversity - not any one specific size. Practical limit is (2^32 - 1) for IPv6, but we expect smaller sizes for the near term. Operators know how to configure MTUs appropriate for their links. 1280 is too small, and turns the IPv6 Internet into ATM. In order to support MTU diversity, PMTUD must be made to work. This means working to eliminate all network blockage of ICMPv6 PTBs, while at the same time provisioning hosts and tunnels with mechanisms that work even if no PTBs are delivered. For hosts, that requires RFC4821. For tunnels, that requires fragmentation. >From an earlier message: > 9000B may still be acceptable. True, but what we need is not any one fixed Internet "cell size" but rather full support for MTU diversity. Fred fred.l.templin at boeing.com From dwcarder at wisc.edu Wed Jun 6 11:01:56 2012 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 06 Jun 2012 11:01:56 -0500 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> References: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> Message-ID: <20120606160156.GD28584@ricotta.doit.wisc.edu> Thus spake Chuck Church (chuckchurch at gmail.com) on Wed, Jun 06, 2012 at 10:58:05AM -0400: > Does anyone know the reason /64 was proposed as the size for all L2 domains? Some day eui-48 will "run out". So, just assume eui-64 now and map into it. Also, as you point out below, not all L2 is ethernet. > I've looked for this answer before, never found a good one. I thought I > read there are some L2 technologies that use a 64 bit hardware address, > might have been Bluetooth. Guaranteeing that ALL possible hosts could live > together in the same L2 domain seems like overkill, even for this group. > /80 would make more sense, it does match up with Ethernet MACs. Not as easy > to compute, for humans nor processors that like things in 32 or 64 bit > chunks however. Anyone have a definite answer? A good history lesson for this addressing model would be to look at IPX. (And maybe also IRDP for ipv4). When we did our first trial ipv6 deployments here in the early 2000's we were still running IPX, so I guess SLAAC wasn't hard to grasp. Dale From mkarir at merit.edu Wed Jun 6 12:13:45 2012 From: mkarir at merit.edu (Manish Karir) Date: Wed, 6 Jun 2012 13:13:45 -0400 Subject: seeking older .com / .net zone files Message-ID: All, We are working on a project with the University of Michigan related with studying the evolution of .com/.net zones Does anyone have copies of .com / .net zone files around the beginning of 2011? Any help would be greatly appreciated. Thanks. -manish From aristidis.lambrianidis at ams-ix.net Wed Jun 6 12:59:28 2012 From: aristidis.lambrianidis at ams-ix.net (Aris Lambrianidis) Date: Wed, 6 Jun 2012 10:59:28 -0700 Subject: RFC5549 Message-ID: <40EC5F92-BE23-4CE7-A17F-1FA28BCA8CB8@ams-ix.net> Hello all, In light of World IPv6 Launch day, I would like to raise awareness for RFC5549, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop" (http://tools.ietf.org/html/rfc5549). As far as I'm aware of, this RFC has yet to be implemented by any vendors so far but it could help massively in the increasing scenarios where IPv4 addressing is scarce. This includes many IXPs which invariably will sooner or later run into this problem. If you happen to be attending the last day of NANOG, I'd be happy to talk to you in person about this for further details (I'm the dude with "RFC5549" written on the back of his laptop). Aris Lambrianidis, AMS-IX From dougm.tlist at gmail.com Wed Jun 6 13:13:41 2012 From: dougm.tlist at gmail.com (Doug Montgomery) Date: Wed, 06 Jun 2012 14:13:41 -0400 Subject: ROVER routing security - its not enumeration In-Reply-To: References: Message-ID: <4FCF9DD5.8040102@gmail.com> On 6/5/12 3:40 PM, Randy Bush wrote: >>> There are number of operational models that provide the needed >>> routing protection without enumeration. >> I can see a use-case for something like: >> "Build me a prefix list from the RIR data" > this requires a full data fetch, not doable in dns. > > and, at the other end of the spectrum, for any dynamic lookup on > receiving a bgp announcement, the data had best be already in the > router. a full data set on an in-rack cache will go nuts on any > significant bgp load. beyond that, you are in non-op space. > > randy > I think we debate the superficial here, and without sufficient imagination. The enumerations vs query issue is a NOOP as far as I am concerned. With a little imagination, one could envision building a box that takes a feed of prefixes observed, builds an aged cache of prefixes of interest, queries for their SRO records, re queries for those records before their TTLs expire, and maintains a white list of "SRO valid" prefix/origin pairs that it downloads to the router. Lets call that box a SRO validating cache. Where do you get the feed of prefixes of interest? From your own RIBs if you are only interested in white lists proportional to the routes you actually see, e.g., feed the box iBGP. From other sources (monitors, etc) if you would like a white list of every known prefix that anyone has seen. What about a completely new prefix being turned up? ... we could talk through those scenarios in each approach. How does the cache down load the white list to the router ... we already have one approach for that. Add a bit to the protocol to distinguish semantics of SRO from ROA semantics if necessary. Point being, with a little imagination I think one could build components with either approach with similar black box behavior. If there are real differences in these approaches it will be in their inherent trust models, the processes that maintain those trust models, the system's level behavior of the info creation and distribution systems, and the expressiveness of their validation frameworks. dougm From nanog-post at rsuc.gweep.net Wed Jun 6 13:19:26 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 6 Jun 2012 14:19:26 -0400 Subject: seeking older .com / .net zone files In-Reply-To: References: Message-ID: <20120606181926.GA78996@gweep.net> On Wed, Jun 06, 2012 at 01:13:45PM -0400, Manish Karir wrote: > > All, > > We are working on a project with the University of Michigan related > with studying the evolution of .com/.net zones > Does anyone have copies of .com / .net zone files around the > beginning of 2011? > Any help would be greatly appreciated. You might want to get with DNS-OARC: https://www.dns-oarc.net/oarc/data/zfr -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From owen at delong.com Wed Jun 6 14:05:31 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Jun 2012 12:05:31 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> References: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> Message-ID: <4969C721-8B76-4221-9282-84CEFFB72D25@delong.com> It is because of IEEE EUI-64 standard. It was believed at the time of IPv6 development that EUI-48 would run out of numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't quite made that change (though Firewire does appear to use EUI-64 already), it will likely occur prior to the EOL for IPv6. There is a simple algorithm used by IEEE for mapping EUI-48 onto the EUI-64 space. The 0x02 bit of the first octet of an EUI-64 address is an L-Flag, indicating that the address was locally generated (if it is a 1) vs. IEEE/vendor assigned (if it is a 0). The mapping process takes the EUI-48 address XX:YY:ZZ:RR:SS:TT and maps it as follows: let AA = XX xor 0x02. AAYY:ZZff:feRR:SSTT ff:fe above is literal. IPv6 was originally going to be a 32-bit address space, but, the developers and proponent of SLAAC convinced IETF to add 64 more bits to the IPv6 address for this purpose. Since bits are free when designing a new protocol, there really was no reason to impose such limitations. You really don't gain anything by going to /80 at this point. There are more than enough addresses available in IPv6 for any foreseeable future even with /64 subnets. Owen On Jun 6, 2012, at 7:58 AM, Chuck Church wrote: > Does anyone know the reason /64 was proposed as the size for all L2 domains? > I've looked for this answer before, never found a good one. I thought I > read there are some L2 technologies that use a 64 bit hardware address, > might have been Bluetooth. Guaranteeing that ALL possible hosts could live > together in the same L2 domain seems like overkill, even for this group. > /80 would make more sense, it does match up with Ethernet MACs. Not as easy > to compute, for humans nor processors that like things in 32 or 64 bit > chunks however. Anyone have a definite answer? > > Thanks, > > Chuck > > -----Original Message----- > From: Jean-Francois.TremblayING at videotron.com > [mailto:Jean-Francois.TremblayING at videotron.com] > Sent: Wednesday, June 06, 2012 10:36 AM > To: anton at huge.geek.nz > Cc: NANOG list > Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) > > Anton Smith a ?crit sur 06/06/2012 09:53:02 AM : > >> Potentially silly question but, as Bill points out a LAN always >> occupies a /64. >> >> Does this imply that we would have large L2 segments with a large >> number of hosts on them? What about the age old discussion about >> keeping broadcast segments small? > > The /64 only removes the limitation on the number of *addresses* on the L2 > domain. Limitations still apply for the amount of ARP and ND noise. A > maximum number of hosts is reached when that noise floor represents a > significant portion of the link bandwidth. If ARP/ND proxying is used, the > limiting factor may instead be the CPU on the gateway. > > The ND noise generated is arguably higher than ARP because of DAD, but I > don't remember seeing actual numbers on this (anybody?). > I've seen links with up to 15k devices where ARP represented a significant > part of the link usage, but most weren't (yet) IPv6. > > /JF > > > From sclark at netwolves.com Wed Jun 6 15:02:42 2012 From: sclark at netwolves.com (Steve Clark) Date: Wed, 06 Jun 2012 16:02:42 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4969C721-8B76-4221-9282-84CEFFB72D25@delong.com> References: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> <4969C721-8B76-4221-9282-84CEFFB72D25@delong.com> Message-ID: <4FCFB762.2030202@netwolves.com> On 06/06/2012 03:05 PM, Owen DeLong wrote: > It is because of IEEE EUI-64 standard. > > It was believed at the time of IPv6 development that EUI-48 would run out of > numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't > quite made that change (though Firewire does appear to use EUI-64 already), > it will likely occur prior to the EOL for IPv6. > > There is a simple algorithm used by IEEE for mapping EUI-48 onto the EUI-64 > space. > > The 0x02 bit of the first octet of an EUI-64 address is an L-Flag, indicating that > the address was locally generated (if it is a 1) vs. IEEE/vendor assigned (if it is a 0). > > The mapping process takes the EUI-48 address XX:YY:ZZ:RR:SS:TT and maps > it as follows: > > let AA = XX xor 0x02. > > AAYY:ZZff:feRR:SSTT > > ff:fe above is literal. > > IPv6 was originally going to be a 32-bit address space, but, the developers did you mean "originally going to be a 64-bit address space"... > and proponent of SLAAC convinced IETF to add 64 more bits to the IPv6 > address for this purpose. Since bits are free when designing a new protocol, > there really was no reason to impose such limitations. > > You really don't gain anything by going to /80 at this point. There are more > than enough addresses available in IPv6 for any foreseeable future even > with /64 subnets. > > Owen > > > > > On Jun 6, 2012, at 7:58 AM, Chuck Church wrote: > >> Does anyone know the reason /64 was proposed as the size for all L2 domains? >> I've looked for this answer before, never found a good one. I thought I >> read there are some L2 technologies that use a 64 bit hardware address, >> might have been Bluetooth. Guaranteeing that ALL possible hosts could live >> together in the same L2 domain seems like overkill, even for this group. >> /80 would make more sense, it does match up with Ethernet MACs. Not as easy >> to compute, for humans nor processors that like things in 32 or 64 bit >> chunks however. Anyone have a definite answer? >> >> Thanks, >> >> Chuck >> >> -----Original Message----- >> From: Jean-Francois.TremblayING at videotron.com >> [mailto:Jean-Francois.TremblayING at videotron.com] >> Sent: Wednesday, June 06, 2012 10:36 AM >> To: anton at huge.geek.nz >> Cc: NANOG list >> Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) >> >> Anton Smith a ?crit sur 06/06/2012 09:53:02 AM : >> >>> Potentially silly question but, as Bill points out a LAN always >>> occupies a /64. >>> >>> Does this imply that we would have large L2 segments with a large >>> number of hosts on them? What about the age old discussion about >>> keeping broadcast segments small? >> The /64 only removes the limitation on the number of *addresses* on the L2 >> domain. Limitations still apply for the amount of ARP and ND noise. A >> maximum number of hosts is reached when that noise floor represents a >> significant portion of the link bandwidth. If ARP/ND proxying is used, the >> limiting factor may instead be the CPU on the gateway. >> >> The ND noise generated is arguably higher than ARP because of DAD, but I >> don't remember seeing actual numbers on this (anybody?). >> I've seen links with up to 15k devices where ARP represented a significant >> part of the link usage, but most weren't (yet) IPv6. >> >> /JF >> >> >> > > -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From ben at bjencks.net Wed Jun 6 15:24:17 2012 From: ben at bjencks.net (Ben Jencks) Date: Wed, 6 Jun 2012 16:24:17 -0400 Subject: AAAA's for www.netflix.com In-Reply-To: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> Message-ID: <5F907BC1-9344-4187-BA12-CEAF7E1C3E73@bjencks.net> On Jun 6, 2012, at 10:05 AM, Frank Bulk wrote: > I started monitoring IPv6 access to www.netflix.com after seeing this > posting > (http://www.personal.psu.edu/dvm105/blogs/ipv6/2012/06/netflix-is-back.html) > and what I found, over the week, was that access was coming and going > (www.premieronline.net/~fbulk/netflix.png). But not because of IPv6 > connectivity, but because the AAAA's were coming and going. Netflix's DNS > TTL is pretty short. > > I assume Netflix has some global DNS load balancing so my perspective may > not be complete. Has anyone else been seeing this? > > I contacted a Netflix employee (he's well known on this list) and he > responded once but I haven't heard back since Saturday. UltraDNS is doing something strange with its CNAME responses. www.netflix.com is a CNAME to a name with both A and AAAA, but the authoritative server for netflix.com only returns that CNAME for A queries, not AAAA. So, if you do an A query first, your resolver will cache the CNAME and use it for the subsequent AAAA query (returning an AAAA), but if you do an AAAA query first, it will cache the no-records response and return no AAAA record. $ dig ns netflix.com ;; QUESTION SECTION: ;netflix.com. IN NS ;; ANSWER SECTION: netflix.com. 162 IN NS pdns5.ultradns.info. netflix.com. 162 IN NS pdns6.ultradns.co.uk. netflix.com. 162 IN NS pdns4.ultradns.org. netflix.com. 162 IN NS pdns2.ultradns.net. netflix.com. 162 IN NS pdns1.ultradns.net. netflix.com. 162 IN NS pdns3.ultradns.org. $ dig @pdns1.ultradns.net. www.netflix.com ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61357 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.netflix.com. IN A ;; ANSWER SECTION: www.netflix.com. 300 IN CNAME dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. $ dig @pdns1.ultradns.net. aaaa www.netflix.com ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34855 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.netflix.com. IN AAAA ;; AUTHORITY SECTION: netflix.com. 1800 IN SOA dns.netflix.com. nicadmin.netflix.com. 2012060120 900 600 1209600 1800 -Ben From owen at delong.com Wed Jun 6 15:21:09 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Jun 2012 13:21:09 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1339012964956-013-00428989.sclark.netwolves.com@sclark66.netwolves.com> References: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> <4969C721-8B76-4221-9282-84CEFFB72D25@delong.com> <1339012964956-013-00428989.sclark.netwolves.com@sclark66.netwolves.com> Message-ID: <15C23604-66F9-43E8-B612-399BD38E2E85@delong.com> On Jun 6, 2012, at 1:02 PM, Steve Clark wrote: > On 06/06/2012 03:05 PM, Owen DeLong wrote: >> >> It is because of IEEE EUI-64 standard. >> >> It was believed at the time of IPv6 development that EUI-48 would run out of >> numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't >> quite made that change (though Firewire does appear to use EUI-64 already), >> it will likely occur prior to the EOL for IPv6. >> >> There is a simple algorithm used by IEEE for mapping EUI-48 onto the EUI-64 >> space. >> >> The 0x02 bit of the first octet of an EUI-64 address is an L-Flag, indicating that >> the address was locally generated (if it is a 1) vs. IEEE/vendor assigned (if it is a 0). >> >> The mapping process takes the EUI-48 address XX:YY:ZZ:RR:SS:TT and maps >> it as follows: >> >> let AA = XX xor 0x02. >> >> AAYY:ZZff:feRR:SSTT >> >> ff:fe above is literal. >> >> IPv6 was originally going to be a 32-bit address space, but, the developers > did you mean "originally going to be a 64-bit address space"... Uh, yeah... Sorry... Brain fart. Originally a 64-bit address space. Owen From dougb at dougbarton.us Wed Jun 6 15:58:13 2012 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 06 Jun 2012 13:58:13 -0700 Subject: .GW registrar? In-Reply-To: <1338989652.698228506@apps.rackspace.com> References: <1338989652.698228506@apps.rackspace.com> Message-ID: <4FCFC465.6080604@dougbarton.us> On 06/06/2012 06:34, Ben Carleton wrote: > > > Hello all, > > Does anyone have a contact at either DENIC or "Funda??o IT & MEDIA Universidade de Bissao" that can advise if registrations are currently being accepted for .GW domain names? The IANA admin contact, > admin at register.gw, is at a domain with no valid MX records (or A records, for that matter). The technical contact is listed as DENIC. You should let ICANN know that you're having problems reaching the admin contact. The best starting point is probably iana at iana.org. hth, Doug -- If you're never wrong, you're not trying hard enough From ben at bencarleton.com Wed Jun 6 16:14:54 2012 From: ben at bencarleton.com (Ben Carleton) Date: Wed, 06 Jun 2012 17:14:54 -0400 Subject: .GW registrar? In-Reply-To: <1338989652.698228506@apps.rackspace.com> References: <1338989652.698228506@apps.rackspace.com> Message-ID: <4FCFC84E.3070502@bencarleton.com> On 6/6/2012 9:34 AM, Ben Carleton wrote: > > Hello all, > > Does anyone have a contact at either DENIC or "Funda??o IT & MEDIA Universidade de Bissao" that can advise if registrations are currently being accepted for .GW domain names? The IANA admin contact, > admin at register.gw, is at a domain with no valid MX records (or A records, for that matter). The technical contact is listed as DENIC. > > TIA, > -- Ben Carleton Thank you to everyone who contacted me off-list, my questions have been answered. For everyone's future reference, .GW is not currently accepting registrations. -- Ben Carleton From mohta at necom830.hpcl.titech.ac.jp Wed Jun 6 16:15:53 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 07 Jun 2012 06:15:53 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4969C721-8B76-4221-9282-84CEFFB72D25@delong.com> References: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> <4969C721-8B76-4221-9282-84CEFFB72D25@delong.com> Message-ID: <4FCFC889.2060408@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: > It is because of IEEE EUI-64 standard. Right, so far. > It was believed at the time of IPv6 development that EUI-48 would run out of > numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't > quite made that change (though Firewire does appear to use EUI-64 already), > it will likely occur prior to the EOL for IPv6. Wrong. It is because I pointed out that IEEE1394 already use EUI-64. > Since bits are free when designing a new protocol, > there really was no reason to impose such limitations. Bits are not free. Remembering a 64 bit value human, a 128 bit value divine, which makes IPv6 network operation hard. Masataka Ohta From kauer at biplane.com.au Wed Jun 6 16:17:37 2012 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 07 Jun 2012 07:17:37 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: Message-ID: <1339017457.2754.8.camel@karl> On Wed, 2012-06-06 at 10:35 -0400, Jean-Francois.TremblayING at videotron.com wrote: > The ND noise generated is arguably higher than ARP because of DAD, > but I don't remember seeing actual numbers on this (anybody?). > I've seen links with up to 15k devices where ARP represented > a significant part of the link usage, but most weren't (yet) IPv6. That doesn't sound right to me. a) DAD only happens when an IPv6 node is starting up. ARP happens whenever a node needs to talk to another node that it hasn't seen in while. b) DAD only goes to solicited node multicast addresses, i.e., only to those nodes that share the same last 24 bits as the target address. ARP goes to every node on the link (broadcast). c) Similarly, ND (the direct equivalent of ARP) goes only to solicited node multicast addresses, ARP goes to every node on the link. So I'm not sure how DAD traffic would exceed ARP traffic. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From valdis.kletnieks at vt.edu Wed Jun 6 16:44:45 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 06 Jun 2012 17:44:45 -0400 Subject: ipv6 book recommendations? In-Reply-To: Your message of "Wed, 06 Jun 2012 14:53:02 +0100." References: Message-ID: <19751.1339019085@turing-police.cc.vt.edu> On Wed, 06 Jun 2012 14:53:02 +0100, Anton Smith said: > Potentially silly question but, as Bill points out a LAN always occupies a /64. > > Does this imply that we would have large L2 segments with a large > number of hosts on them? What about the age old discussion about > keeping broadcast segments small? > > Or, will it be that a /64 will only typically have a similar number of > hosts in it as say, a /23|4 in the IPv4 world? We simply allocated a v6 /64 for each v4 /21, /22, /23, /2whatever in our network. Works fine. No more "what the fsck is the subnet in THIS building?" issues. Amazing how often we find hosts that are in one building but misconfig'ed because the sysadmin put in the netmask for the building his office is in, not the building the server is in. When there's 125+ buildings on the campus, this matters. ;) As somebody else mentioned, the limiting factor is "How much ND/ARP traffic are you willing to tolerate in one broadcast domain?". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Wed Jun 6 19:56:33 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 07 Jun 2012 09:56:33 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> Message-ID: <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: >> Because bigger packets makes it rather circuit switching than >> packet switching, which is the way to lose. > Er... No. It's attitudes like this that killed ATM. ATM committed suicide because its slow target speed (64Kbps voice) and inappropriate QoS theory required small cell of 32B. > (argument about whether the ATM cell payload should > be 64 or 128 octets It was between 32B and 64B. > lead to a mathematical compromise It is no mathematical. Instead, 48B is an algebraic mean of 32B and 64B. > Larger packets for sustained flows of large amounts of data > do not make it circuit switched, As I already gave blocking examples with problematic blocking times, it's your problem of lack of understanding on why circuit switching is bad. > Admittedly, if you go to too large an MTU for your bps, you > can create HOL blocking issues which have the same loss > characteristics as circuit switching. However, let's say that > anything>10ms HOL blocking is our definition of bad. At > 10Gbps, that's 100,000 bits or 12,500 octets. At 100Gbps, > that's 125,000 octets. People, like you, who think 10ms blocking is fine care voice communications only and are people for circuit switching. We, people working on the Internet, which began as a computer network, know 48usec can be significantly lengthy for many computations today. When experimental Ethernet was 3Mbps, 1500B meant 4ms blocking, which was tolerable because computers were slow to compute and most computation was done inside a single computer. But, Moore's law changed everything. Go your home of ITU. Masataka Ohta From marka at isc.org Wed Jun 6 20:19:48 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 07 Jun 2012 11:19:48 +1000 Subject: AAAA's for www.netflix.com In-Reply-To: Your message of "Wed, 06 Jun 2012 16:24:17 -0400." <5F907BC1-9344-4187-BA12-CEAF7E1C3E73@bjencks.net> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <5F907BC1-9344-4187-BA12-CEAF7E1C3E73@bjencks.net> Message-ID: <20120607011948.2A2532154FD0@drugs.dv.isc.org> In message <5F907BC1-9344-4187-BA12-CEAF7E1C3E73 at bjencks.net>, Ben Jencks write s: > On Jun 6, 2012, at 10:05 AM, Frank Bulk wrote: > > > I started monitoring IPv6 access to www.netflix.com after seeing this > > posting > > = > (http://www.personal.psu.edu/dvm105/blogs/ipv6/2012/06/netflix-is-back.htm= > l) > > and what I found, over the week, was that access was coming and going > > (www.premieronline.net/~fbulk/netflix.png). But not because of IPv6 > > connectivity, but because the AAAA's were coming and going. Netflix's = > DNS > > TTL is pretty short. =20 > >=20 > > I assume Netflix has some global DNS load balancing so my perspective = > may > > not be complete. Has anyone else been seeing this? > >=20 > > I contacted a Netflix employee (he's well known on this list) and he > > responded once but I haven't heard back since Saturday. =20 > > UltraDNS is doing something strange with its CNAME responses. = > www.netflix.com is a CNAME to a name with both A and AAAA, but the = > authoritative server for netflix.com only returns that CNAME for A = > queries, not AAAA. It's not strange. IT IS BROKEN. There is zero, nada, none, no excuse for not returning a CNAME to the AAAA in this situation. > So, if you do an A query first, your resolver will = > cache the CNAME and use it for the subsequent AAAA query (returning an = > AAAA), but if you do an AAAA query first, it will cache the no-records = > response and return no AAAA record. > > $ dig ns netflix.com > ;; QUESTION SECTION: > ;netflix.com. IN NS > ;; ANSWER SECTION: > netflix.com. 162 IN NS pdns5.ultradns.info. > netflix.com. 162 IN NS pdns6.ultradns.co.uk. > netflix.com. 162 IN NS pdns4.ultradns.org. > netflix.com. 162 IN NS pdns2.ultradns.net. > netflix.com. 162 IN NS pdns1.ultradns.net. > netflix.com. 162 IN NS pdns3.ultradns.org. > > $ dig @pdns1.ultradns.net. www.netflix.com > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61357 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;www.netflix.com. IN A > ;; ANSWER SECTION: > www.netflix.com. 300 IN CNAME = > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. > > $ dig @pdns1.ultradns.net. aaaa www.netflix.com > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34855 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;www.netflix.com. IN AAAA > ;; AUTHORITY SECTION: > netflix.com. 1800 IN SOA dns.netflix.com. = > nicadmin.netflix.com. 2012060120 900 600 1209600 1800 > > -Ben= > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From shrdlu at deaddrop.org Wed Jun 6 20:33:36 2012 From: shrdlu at deaddrop.org (Lynda) Date: Wed, 06 Jun 2012 18:33:36 -0700 Subject: LinkedIn password database compromised Message-ID: <4FD004F0.4060606@deaddrop.org> Sorry to be the bearer of such bad tidings. Please note that I'm doing a quick copy/paste from a notification I received. I've edited it a bit. Please note that LinkedIn has weighed in with a carefully worded blog post: http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/ Further details: 1. The leak took place on June 4 2. LinkedIn was using unsalted SHA-1 for their password store. 3. FYI, there are two lists. The second one appears to be from eHarmony. Unsalted MD5 used there. 4. The posted passwords are believed to be ones the cracker wanted help with, i.e., they have significantly more already cracked. Apparently phishing emails are already active in the wild based on the crack: http://bits.blogs.nytimes.com/2012/06/06/that-was-fast-criminals-exploit-linkedin-breach-for-phishing-attacks/ In other words, if you have a LinkedIn account, expect that the password has been stolen. Go change your password now. If you used that password elsewhere, you know the routine. In addition, as has been pointed out elsewhere, there's no sign LI has fixed the problem. Expect that the password you change it to will also be compromised. :-( -- A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures. From marshall.eubanks at gmail.com Wed Jun 6 21:19:13 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Wed, 6 Jun 2012 22:19:13 -0400 Subject: LinkedIn password database compromised In-Reply-To: <4FD004F0.4060606@deaddrop.org> References: <4FD004F0.4060606@deaddrop.org> Message-ID: On Wed, Jun 6, 2012 at 9:33 PM, Lynda wrote: > Sorry to be the bearer of such bad tidings. Please note that I'm doing a > quick copy/paste from a notification I received. I've edited it a bit. > > Please note that LinkedIn has weighed in with a carefully worded blog post: > > http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/ > > Further details: > 1. The leak took place on June 4 > 2. LinkedIn was using unsalted SHA-1 for their password store. Raising the issue of why Linkedin hasn't adopted the latest security wrinkles from 1978. ( http://cm.bell-labs.com/cm/cs/who/dmr/passwd.ps ) > 3. FYI, there are two lists. The second one appears to be from eHarmony. > Unsalted MD5 used there. Ditto. Normally I would complain about the use of MD5, but what's the point. Regards Marshall > 4. The posted passwords are believed to be ones the cracker wanted help > with, i.e., they have significantly more already cracked. > > Apparently phishing emails are already active in the wild based on the > crack: > > http://bits.blogs.nytimes.com/2012/06/06/that-was-fast-criminals-exploit-linkedin-breach-for-phishing-attacks/ > > In other words, if you have a LinkedIn account, expect that the password has > been stolen. Go change your password now. If you used that password > elsewhere, you know the routine. In addition, as has been pointed out > elsewhere, there's no sign LI has fixed the problem. Expect that the > password you change it to will also be compromised. > > :-( > > -- > A picture is worth 10K words -- but only those to describe > the picture. ?Hardly any sets of 10K words can be adequately > described with pictures. > > From aaron at heyaaron.com Wed Jun 6 21:43:42 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 6 Jun 2012 19:43:42 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: On Wed, Jun 6, 2012 at 7:19 PM, Marshall Eubanks wrote: > On Wed, Jun 6, 2012 at 9:33 PM, Lynda wrote: >> In other words, if you have a LinkedIn account, expect that the password has >> been stolen. Go change your password now. If you used that password >> elsewhere, you know the routine. In addition, as has been pointed out >> elsewhere, there's no sign LI has fixed the problem. Expect that the >> password you change it to will also be compromised. Why haven't we taken this out of the hands of website operators yet? Why can't I use my ssh-agent to sign in to a website just like I do for about hundred servers, workstations, and my PCs at home? One local password used everywhere that can't be compromised through website stupidity... -A From lathama at gmail.com Wed Jun 6 21:49:30 2012 From: lathama at gmail.com (Andrew Latham) Date: Wed, 6 Jun 2012 22:49:30 -0400 Subject: Configuration Systems Message-ID: Lurker speaking... beware... I have been talking with some folks from various industries about configuration systems ala Bcfg2, Puppet, Chef, and others. Many of them care far too much about the current nodes configuration status as some admin had logged in and changed something. I am authoring a system called Enablement that uses what ever technology needed (ssh, telnet over admin vlan, rsh, etc...) to push a planned system/config to the device. Monitoring and auditing are all the same at the moment as we need historical data on when a service or port started and stopped offering its planned or unplanned service. For a meeting Thursday I am looking forward to the future of configuring systems. My idea is push + netblock scanning of services. With stacks for clouds we can startup and shut down nodes easy. Would a bend over backwards config reader for all the "Configuration Management Systems" be the best medium ground from the service provider point of view? Enablement.... Send another man to fight on the front line. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From lathama at gmail.com Wed Jun 6 21:58:48 2012 From: lathama at gmail.com (Andrew Latham) Date: Wed, 6 Jun 2012 22:58:48 -0400 Subject: Configuration Systems In-Reply-To: References: Message-ID: Jonathan That is the exact question I have asked myself many times. All of the major players in Configuration management have a "client" program that must run and at times requires some libraries that are newer than the platforms a company may need to support or that clients may wish supported. Another issue is the secure communication over a proprietary or SSH connection and not allowing secured VLANs or other services like RSH and Telnet over a point to point connection. Also you will find that the demand for cloud systems and the complex languages used in the "Configuration Management Systems" do not easily translate to the existing and developing cloud infrastructure. and stuff... On Wed, Jun 6, 2012 at 10:52 PM, Jonathan Herbert wrote: > Hi Andrew, > > Out of curiosity, why are you reinventing the wheel here? > > Don't take this the wrong way- I'm just curious why you're building > something new. What does Enablement do that the other technologies you've > mentioned doesn't? > > Jonathan > > > On Wed, Jun 6, 2012 at 10:49 PM, Andrew Latham wrote: >> >> Lurker speaking... beware... >> >> I have been talking with some folks from various industries about >> configuration systems ala Bcfg2, Puppet, Chef, and others. ?Many of >> them care far too much about the current nodes configuration status as >> some admin had logged in and changed something. ?I am authoring a >> system called Enablement that uses what ever technology needed (ssh, >> telnet over admin vlan, rsh, etc...) to push a planned system/config >> to the device. ?Monitoring and auditing are all the same at the moment >> as we need historical data on when a service or port started and >> stopped offering its planned or unplanned service. ?For a meeting >> Thursday I am looking forward to the future of configuring systems. >> My idea is push + netblock scanning of services. ?With stacks for >> clouds we can startup and shut down nodes easy. ?Would a bend over >> backwards config reader for all the "Configuration Management Systems" >> be the best medium ground from the service provider point of view? >> >> Enablement.... ?Send another man to fight on the front line. >> >> -- >> ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ >> > -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From mysidia at gmail.com Wed Jun 6 22:34:39 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 6 Jun 2012 22:34:39 -0500 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: On 6/6/12, Aaron C. de Bruyn wrote: [snip] > One local password used everywhere that can't be compromised through > website stupidity... One local password is an excellent idea of course. "Remote servers directly handling user created credentials" should be appended to the list of the worst ideas in computer security. Which digital id architecture should web sites implement, and what's going to make them all agree on one SSO system and move from the current state to one of the possible solutions though? :) A TLS + Client-Side X.509 Certificate for every user. BrowserID OpenID Active Directory Federation Services OASIS SAML / STS + WS-Trust Shibboleth SSO CoSign SSO Facebook Connect Novell Access Manager Windows Live ID [insert a thousand of the other slightly more obscure Multi-website Single-Login systems] .... -- -JH From aaron at heyaaron.com Thu Jun 7 01:14:58 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 6 Jun 2012 23:14:58 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: On Wed, Jun 6, 2012 at 8:34 PM, Jimmy Hess wrote: > Which digital id architecture should web sites implement, and what's > going to make them ?all agree on one SSO system ? and move from the > current state to one of the possible solutions though? ?:) > > ? ? ? ?A TLS + Client-Side X.509 Certificate ?for every user. Heck no to X.509. We'd run into the same issue we have right now--a select group of companies charging users to prove their identity. > [insert a thousand of the other ?slightly more obscure Multi-website > Single-Login systems] SSH does a good job of avoiding the pitfalls that most of those other products have. Active Directory has costs associated with it. OpenID requires setting up your own server or using a third party. Facebook and Google have their own auth systems, but quite a few people are worried about how much they track you. And the only time I use a Windows Live account is when I set one up for a client who needs access to their volume licensing site. Imaging signing up for a site by putting in your email and pasting your public key. No third party verifying and certifying who you are like with SSL certs and charging you for the privilege (plain 'ol username/password logins don't give you any verification either--linkedin has no clue who I really am) just a key exchange from the user and server proving that you've both seen each other before. -A From shortdudey123 at gmail.com Thu Jun 7 01:54:23 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 7 Jun 2012 01:54:23 -0500 Subject: IPv6 on AWS Message-ID: Hi, Is there anyone here from Amazon that knows when Amazon Web Services will support native IPv6? Thanks, Grant From snow at teardrop.org Thu Jun 7 08:22:40 2012 From: snow at teardrop.org (James Snow) Date: Thu, 7 Jun 2012 06:22:40 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: <20120607132240.GO32960@teardrop.org> On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote: > > Imaging signing up for a site by putting in your email and pasting > your public key. Yes! Yes! Yes! I've been making this exact argument for about a year. It even retains the same "email a link" reset mechanism when someone needs to reset their key. A common counter-argument is, "But ordinary Internet users won't understand SSH keys." They don't need to! The idea is easily explained via a lock-and-key metaphor that people already understand. The UI for walking users through key creation is easily imagined. -Snow From alter3d at alter3d.ca Thu Jun 7 08:36:18 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Thu, 07 Jun 2012 09:36:18 -0400 Subject: LinkedIn password database compromised In-Reply-To: <20120607132240.GO32960@teardrop.org> References: <4FD004F0.4060606@deaddrop.org> <20120607132240.GO32960@teardrop.org> Message-ID: <4FD0AE52.20602@alter3d.ca> On 6/7/2012 9:22 AM, James Snow wrote: > On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote: >> Imaging signing up for a site by putting in your email and pasting >> your public key. > Yes! Yes! Yes! > > I've been making this exact argument for about a year. It even retains > the same "email a link" reset mechanism when someone needs to reset > their key. > > A common counter-argument is, "But ordinary Internet users won't > understand SSH keys." They don't need to! The idea is easily explained > via a lock-and-key metaphor that people already understand. The UI for > walking users through key creation is easily imagined. > > > -Snow Oh yeah, I can just imagine that "lock and key" conversation now... "Imagine if the website has a lock on it, and you tell them what key you want to use by giving them a copy." "But if they have a copy of my key, couldn't they use it to open all of the other locks I've set up to use it?" "(explain public key crypto)" "(drool, distraction by the latest Facebook feature)" The other problem with this approach is that, as bad as trusting remote sites to do security properly is, I'm not sure that putting a "one key to rule them all" on users' machines is that much better, given the average user's penchant for installing malware on their machine because "FunnyMonkeyScreensaver.exe" sounded like such a good idea at the time... I suspect we'd see a huge wave of malware whose sole purpose is to steal public keys (and you KNOW users won't password-protect their private keys!). Plus, now you have the problem of users not being able to login to their favourite websites when they're using a friend's computer, internet cafe, etc, unless they've remembered to bring a copy of their private key with them. I think public key auth for websites is a great idea for geeks who understand the benefits, limitations and security concerns, but I have serious doubts that it would hold up when subjected to the "idiot test". - Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4418 bytes Desc: S/MIME Cryptographic Signature URL: From dave at temk.in Thu Jun 7 08:52:29 2012 From: dave at temk.in (Dave Temkin) Date: Thu, 07 Jun 2012 07:52:29 -0600 Subject: AAAA's for www.netflix.com In-Reply-To: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> Message-ID: <4FD0B21D.4060707@temk.in> Just to close the loop on this - UltraDNS has an issue with CNAMEs and their Directional DNS service. We (Netflix) have applied a workaround and it appears stable. -Dave On 6/6/12 8:05 AM, Frank Bulk wrote: > I started monitoring IPv6 access to www.netflix.com after seeing this > posting > (http://www.personal.psu.edu/dvm105/blogs/ipv6/2012/06/netflix-is-back.html) > and what I found, over the week, was that access was coming and going > (www.premieronline.net/~fbulk/netflix.png). But not because of IPv6 > connectivity, but because the AAAA's were coming and going. Netflix's DNS > TTL is pretty short. > > I assume Netflix has some global DNS load balancing so my perspective may > not be complete. Has anyone else been seeing this? > > I contacted a Netflix employee (he's well known on this list) and he > responded once but I haven't heard back since Saturday. > > Here's some sample queries from Saturday and today. > ========================================================= > nagios:/home/fbulk# dig AAAA www.netflix.com > > ;<<>> DiG 9.7.3<<>> AAAA www.netflix.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26825 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.netflix.com. IN AAAA > > ;; AUTHORITY SECTION: > netflix.com. 150 IN SOA dns.netflix.com. > nicadmin.netflix.com. 2012060104 900 600 1209600 1800 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Jun 2 09:29:17 2012 > ;; MSG SIZE rcvd: 82 > > nagios:/home/fbulk# > ========================================================= > > ========================================================= > nagios:/home/fbulk# dig AAAA www.netflix.com > > ;<<>> DiG 9.7.3<<>> AAAA www.netflix.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33117 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 8, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.netflix.com. IN AAAA > > ;; ANSWER SECTION: > www.netflix.com. 132 IN CNAME > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN > AAAA 2406:da00:ff00::3210:e195 > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN > AAAA 2406:da00:ff00::3213:5282 > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN > AAAA 2406:da00:ff00::3213:6340 > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN > AAAA 2406:da00:ff00::3213:779a > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN > AAAA 2406:da00:ff00::1715:75cd > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN > AAAA 2406:da00:ff00::1715:eceb > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN > AAAA 2406:da00:ff00::1717:e388 > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. 12 IN > AAAA 2406:da00:ff00::1717:eb58 > > ;; AUTHORITY SECTION: > elb.amazonaws.com. 7092 IN NS ns-916.amazonaws.com. > elb.amazonaws.com. 7092 IN NS ns-941.amazonaws.com. > elb.amazonaws.com. 7092 IN NS ns-927.amazonaws.com. > elb.amazonaws.com. 7092 IN NS ns-925.amazonaws.com. > elb.amazonaws.com. 7092 IN NS ns-934.amazonaws.com. > elb.amazonaws.com. 7092 IN NS ns-935.amazonaws.com. > elb.amazonaws.com. 7092 IN NS ns-944.amazonaws.com. > elb.amazonaws.com. 7092 IN NS ns-947.amazonaws.com. > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Jun 2 09:34:35 2012 > ;; MSG SIZE rcvd: 504 > > nagios:/home/fbulk# > ========================================================= > > ========================================================= > nagios:/home/fbulk# dig AAAA www.netflix.com > > ;<<>> DiG 9.7.3<<>> AAAA www.netflix.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34529 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.netflix.com. IN AAAA > > ;; AUTHORITY SECTION: > netflix.com. 94 IN SOA dns.netflix.com. > nicadmin.netflix.com. 2012060107 900 600 1209600 1800 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Wed Jun 6 09:00:44 2012 > ;; MSG SIZE rcvd: 82 > > nagios:/home/fbulk# > ========================================================= > > Frank Bulk > > From bicknell at ufp.org Thu Jun 7 08:58:01 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 7 Jun 2012 06:58:01 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: <20120607135801.GA24269@ussenterprise.ufp.org> In a message written on Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote: > Heck no to X.509. We'd run into the same issue we have right now--a > select group of companies charging users to prove their identity. Why? A user providing the public half of a self-signed certificate is exactly the same as the user providing the public half of a self-generated SSH key. The fact that you can have a trust chain may be useful in some cases. For instance, I'm not at all opposed to the idea of the government having a way to issue me a signed certificate that I then use to access government services, like submitting my tax return online, renewing my drivers license, or maybe even e-voting. The X.509 certificates have an added bonus that they can be used to secure the transport layer, something that your ssh-key-for-login proposal can't do. This is all a UI problem. If Windows/OSX or Safari/Firefox/Chrome prompted users to create or import a "user certificate" when first run, and provided a one-click way to provide it to a form when signing up there would be a lot more incentive to use that method. Today pretty much the only place you see certificates for users is Enterprises with Microsoft's certificate tools because of the UI problem. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jcmurphy at jeffmurphy.org Thu Jun 7 09:06:25 2012 From: jcmurphy at jeffmurphy.org (jeff murphy) Date: Thu, 7 Jun 2012 10:06:25 -0400 Subject: LinkedIn password database compromised In-Reply-To: <20120607135801.GA24269@ussenterprise.ufp.org> References: <4FD004F0.4060606@deaddrop.org> <20120607135801.GA24269@ussenterprise.ufp.org> Message-ID: On Jun 7, 2012, at 9:58 AM, Leo Bicknell wrote: > In a message written on Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote: >> Heck no to X.509. We'd run into the same issue we have right now--a >> select group of companies charging users to prove their identity. > ... > For instance, I'm not at all opposed to the idea of the > government having a way to issue me a signed certificate that I > then use to access government services, like submitting my tax > return online, renewing my drivers license, or maybe even e-voting. All in favor of paying $119/year to vote, please raise your hands. http://www.verisign.com/dod-interoperability/ From jcdill.lists at gmail.com Thu Jun 7 09:58:18 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 07 Jun 2012 07:58:18 -0700 Subject: LinkedIn password database compromised In-Reply-To: <4FD0AE52.20602@alter3d.ca> References: <4FD004F0.4060606@deaddrop.org> <20120607132240.GO32960@teardrop.org> <4FD0AE52.20602@alter3d.ca> Message-ID: <4FD0C18A.7060605@gmail.com> On 07/06/12 6:36 AM, Peter Kristolaitis wrote: > Plus, now you have the problem of users not being able to login to > their favourite websites when they're using a friend's computer, > internet cafe, etc, unless they've remembered to bring a copy of their > private key with them. I've run into this problem with setting up accounts on aps on my smartphone. A secure password that is relatively easy to type on a regular keyboard becomes a PITA to type on a smartphone. There are a number of sites I simply don't use on my phone because the hassle of setting up each site's ap is greater than the benefit I get from accessing it via the phone. jc From aaron at heyaaron.com Thu Jun 7 10:29:16 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 7 Jun 2012 08:29:16 -0700 Subject: LinkedIn password database compromised In-Reply-To: <4FD0AE52.20602@alter3d.ca> References: <4FD004F0.4060606@deaddrop.org> <20120607132240.GO32960@teardrop.org> <4FD0AE52.20602@alter3d.ca> Message-ID: On Thu, Jun 7, 2012 at 6:36 AM, Peter Kristolaitis wrote: > On 6/7/2012 9:22 AM, James Snow wrote: >> On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote: >>> > "Imagine if the website has a lock on it, and you tell them what key you > want to use by giving them a copy." > "But if they have a copy of my key, couldn't they use it to open all of the > other locks I've set up to use it?" > "(explain public key crypto)" > "(drool, distraction by the latest Facebook feature)" You'd run into the same issue explaining how MD5, SHA1, salting, etc... works to 'protect' their password. Users don't care. If putty were to pop up its password box when my mother signed in to her computer and then I said something like "Don't worry, you won't need to enter passwords while you surf the 'net now." and maybe showed her the chrome extension icon thingy to click when she wants to paste her 'password' (public key) into a new site, she'd be fine with it. > The other problem with this approach is that, as bad as trusting remote > sites to do security properly is, I'm not sure that putting a "one key to > rule them all" on users' machines is that much better, given the average > user's penchant for installing malware on their machine because > "FunnyMonkeyScreensaver.exe" sounded like such a good idea at the time... And how does our current system of usernames and passwords avoid malware that logs keystrokes? > I suspect we'd see a huge wave of malware whose sole purpose is to steal > public keys (and you KNOW users won't password-protect their private keys!). > ? Plus, now you have the problem of users not being able to login to their > favourite websites when they're using a friend's computer, internet cafe, > etc, unless they've remembered to bring a copy of their private key with > them. Yep--that's the one big problem I can see with this 'solution' that I don't have an answer for yet. It would be difficult to get users to carry around a USB key or a smartcard, or whatever to get them signed in while away from their home computer. -A From mhuff at ox.com Thu Jun 7 10:39:51 2012 From: mhuff at ox.com (Matthew Huff) Date: Thu, 7 Jun 2012 11:39:51 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <20120607135801.GA24269@ussenterprise.ufp.org> Message-ID: <483E6B0272B0284BA86D7596C40D29F901928BC8AB5D@PUR-EXCH07.ox.com> True, Back in 1998-1999 timeline, there was an ongoing project to have the US Postal service issue X.509 certificates at a nominal fee. The fact that even the most rural areas have access to a post office made a lot of sense. After the 2000 election, the project was cancelled because "private business" can handle it better. ---- Matthew Huff? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: jeff murphy [mailto:jcmurphy at jeffmurphy.org] > Sent: Thursday, June 07, 2012 10:06 AM > To: Nanog > Subject: Re: LinkedIn password database compromised > > > On Jun 7, 2012, at 9:58 AM, Leo Bicknell wrote: > > > In a message written on Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron > C. de Bruyn wrote: > >> Heck no to X.509. We'd run into the same issue we have right now--a > >> select group of companies charging users to prove their identity. > > > ... > > For instance, I'm not at all opposed to the idea of the government > > having a way to issue me a signed certificate that I then use to > > access government services, like submitting my tax return online, > > renewing my drivers license, or maybe even e-voting. > > > > All in favor of paying $119/year to vote, please raise your hands. > > http://www.verisign.com/dod-interoperability/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5339 bytes Desc: not available URL: From solene at franceix.net Thu Jun 7 10:45:55 2012 From: solene at franceix.net (=?ISO-8859-1?Q?Sol=E8ne_Souquet?=) Date: Thu, 7 Jun 2012 17:45:55 +0200 Subject: IX in France In-Reply-To: <4F61ECDF.6050901@ceriz.fr> References: <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local> <4F61ECDF.6050901@ceriz.fr> Message-ID: Hi everyone, Allow me to send you the link to France-IX's white paper on the peering situation in France: http://bit.ly/y7KQ90. If you have questions, you can drop us an e-mail to info at franceix.net. Best regards, 2012/3/15 J?r?me Nicolle > Le 21/02/12 17:46, Ido Szargel a ?crit : > > It seems that there are 2 "major" players - FranceIX and Equinix FR, can > > anyone share their opinions about those? > > Equinix-IX is cheaper (free Gig-e port) and has more member (including a > few big eyeball players with restrictive or selective policies). > > France-IX has a robust structure and team, seems more stable according > to my logs. > > Both allow private VLANs and commercial services over the public fabric. > > Panap and Free-IX are dead, PARIX isn't although their site is down on > purpose for the pas two years or so. It's a commercial service from > Orange / France Telecom (wich is selling AS3215 transit and peering there). > > > > -- > J?r?me Nicolle > 06 19 31 27 14 > > -- Sol?ne SOUQUET Marketing Manager [image: youtube] [image: facebook][image: twitter] [image: linked in] From jared at puck.nether.net Thu Jun 7 10:58:48 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 7 Jun 2012 11:58:48 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: On Jun 7, 2012, at 2:14 AM, Aaron C. de Bruyn wrote: > Imaging signing up for a site by putting in your email and pasting > your public key. > I'm imagining my mother trying this, or trying to help her change it after the hard drive dies and the media in the safe deposit box doesn't read anymore. From Fred.L.Templin at boeing.com Thu Jun 7 11:05:28 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Thu, 7 Jun 2012 09:05:28 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <4FCD1596.7040800@necom830.hpcl.titech.ac.jp> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> Message-ID: Here is Matt's full table and descriptive text: "Note that there is no specific reason to require any particular MTU at any particular rate. As a general principle, we prefer declining packet times (and declining worst case jitter) as you go to higher rates. Actual Vision Alternate 1 Alternate 2 Rate MTU Time MTU Time MTU Time MTU Time 10 Mb/s 1.5kB 1200uS 100 Mb/s 1.5kB 120uS 12kB 960uS 9kB 720uS 4.3kB 433uS 1 Gb/s 1.5kB 12uS 96kB 768uS 64kB 512uS 9kB 72uS 10 Gb/s 1.5kB 1.2uS 750kB 600uS 150kB 120uS 64kB 51.2uS 100 Gb/s 6MB 480uS 1.5MB 120uS 64kB 5.12uS 1 Tb/s 50MB 400uS 15MB 120uS 64kB 0.512uS The above numbers are very speculative about what MTUs might make sense in the market. We keep updating them as we learn more about how MTU affects the balance between switching costs and end-system costs vs. end-to-end performance." If you wish, you can also consider Alternate 3 for 9kB: 72us at 1Gbps, 7.2us at 10Gbps, .72us at 100Gbps, .072us at 1Tbps. Fred fred.l.templin at boeing.com From aaron at heyaaron.com Thu Jun 7 11:09:44 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 7 Jun 2012 09:09:44 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: On Thu, Jun 7, 2012 at 8:58 AM, Jared Mauch wrote: > I'm imagining my mother trying this, or trying to help her change it after the hard drive dies and the media in the safe deposit box doesn't read anymore. I would think it's fairly simple. What if she forgot her existing password? Most sites have a 'reset password' link they e-mail you. A browser extension 'helper' would simply generate a new key and let you reset your password. Maybe the helper could be dumbed down enough to automatically handle the password reset screen and automatically POST the new key to the reset page. I'm sure it could be done transparently enough that our mothers wouldn't need to think twice about it. Heck--the 'helper' could probably even back up your SSH key off-site sorta like LastPass does. And if your private key is actually password protected, it's slightly less useless if the off-site backup company were compromised. The only downfall is how do you get access to your e-mail account? (Google already calls my cell and/or home phone if I request access without using my password.) I agree there are stumbling blocks, and it wouldn't be perfect--but it seems like it would be much better than the alternative we have now. People using the same password on multiple sites, passwords written down, dumb website operators not salting their hashes, etc... Also, thanks for the great secondary DNS service. ;) -A From marshall.eubanks at gmail.com Thu Jun 7 11:12:02 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Thu, 7 Jun 2012 12:12:02 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: On Thu, Jun 7, 2012 at 11:58 AM, Jared Mauch wrote: > > On Jun 7, 2012, at 2:14 AM, Aaron C. de Bruyn wrote: > >> Imaging signing up for a site by putting in your email and pasting >> your public key. >> > > I'm imagining my mother trying this, or trying to help her change it after the hard drive dies and the media in the safe deposit box doesn't read anymore. Or having to deal with family tech support, along the lines of "You said you pasted it exactly." "But I did. I've spent hours trying to watch that movie. I don't know why it isn't working." "But you {added a period at the end / didn't include the line wrap / added a space at the beginning / etc}" "Oh. Does that matter" For more joy, imagine debugging such issues over the phone. At least I can say that my Mother (God rest her soul) would never have indulged in such foolery. She would have just called the company to send a technician in to send the email for her. Regards Marshall From cdmbruch at nmhg.com Thu Jun 7 11:29:27 2012 From: cdmbruch at nmhg.com (Bruch, Mark) Date: Thu, 7 Jun 2012 11:29:27 -0500 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: <5E50AC3B0F1FA9408A82DC0DEB965E4AF02E6E@APMMAIL02.global.nmhg.corp> I rarely reply to threads. However the point of interest that is missed is "Not supported anymore because Microsoft says so". So Microsoft starts putting out systems at one per year and not supporting old ones because they "Have you over a barrel"? Tell your daughter she can't get married? You haven't bought your new operating system this year, and "backward compatible" is a thing of the past? Then it is $119.00 per year on top of that (maybe)? Let's say Microsoft promised business to the PC building companies and decides that an operating system per year is only supported on new equipment? The cost to vote could be thousands per year. Only the rich can afford to vote? The point is that you have to be careful about where you go with technology and who controls it. I am sure there are people who would love to see voting as a "can you afford it" right. -----Original Message----- From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] Sent: Thursday, June 07, 2012 11:10 AM To: Jared Mauch Cc: Nanog Subject: Re: LinkedIn password database compromised On Thu, Jun 7, 2012 at 8:58 AM, Jared Mauch wrote: > I'm imagining my mother trying this, or trying to help her change it after the hard drive dies and the media in the safe deposit box doesn't read anymore. I would think it's fairly simple. What if she forgot her existing password? Most sites have a 'reset password' link they e-mail you. A browser extension 'helper' would simply generate a new key and let you reset your password. Maybe the helper could be dumbed down enough to automatically handle the password reset screen and automatically POST the new key to the reset page. I'm sure it could be done transparently enough that our mothers wouldn't need to think twice about it. Heck--the 'helper' could probably even back up your SSH key off-site sorta like LastPass does. And if your private key is actually password protected, it's slightly less useless if the off-site backup company were compromised. The only downfall is how do you get access to your e-mail account? (Google already calls my cell and/or home phone if I request access without using my password.) I agree there are stumbling blocks, and it wouldn't be perfect--but it seems like it would be much better than the alternative we have now. People using the same password on multiple sites, passwords written down, dumb website operators not salting their hashes, etc... Also, thanks for the great secondary DNS service. ;) -A From shrdlu at deaddrop.org Thu Jun 7 11:53:00 2012 From: shrdlu at deaddrop.org (Lynda) Date: Thu, 07 Jun 2012 09:53:00 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: <4FD0DC6C.9060502@deaddrop.org> On 6/7/2012 8:58 AM, Jared Mauch wrote: > > On Jun 7, 2012, at 2:14 AM, Aaron C. de Bruyn wrote: > >> Imaging signing up for a site by putting in your email and pasting >> your public key. > I'm imagining my mother trying this, or trying to help her change it > after the hard drive dies and the media in the safe deposit box > doesn't read anymore. There are other issues than not being familiar with technology, and they specifically affect those of us who have grown older, and lost certain dexterity that used to be innate. There are passwords and pass phrases I used to have committed to muscle memory. I never even had to think about them. I've had to spend literally hours trying to type in a PGP pass phrase that used to be something I could type without thinking. There is no one size fits all solution to this. I'm still very annoyed with a company that has only now moved to a password solution that should have been in place in 2005. I still don't want single sign on. Not anywhere. I've been around for a very long time, and I'm fine with technical complexity for me, but do not expect the standard 16 year old text messaging addict to be able to handle some of the solutions I've seen suggested, much less most people my age. Things are so complex now that people on nanog-l forget the average level of expertise among their peer groups is simply not replicated in the outside world. Jokes about needing a teenager to reprogram your VCR are a thing of the past. I used to be in the business of forecasting the future (among other things), and any security solution that is more difficult than knowing not to use the same password for your bank that you do for Facebook is doomed to fail. {P.S. Ditto on thanks for backup DNS.} -- A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures. From dr at cluenet.de Thu Jun 7 11:58:18 2012 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 7 Jun 2012 18:58:18 +0200 Subject: AAAA's for www.netflix.com In-Reply-To: <4FD0B21D.4060707@temk.in> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> Message-ID: <20120607165818.GA30416@srv03.cluenet.de> On Thu, Jun 07, 2012 at 07:52:29AM -0600, Dave Temkin wrote: > Just to close the loop on this - UltraDNS has an issue with CNAMEs and > their Directional DNS service. We (Netflix) have applied a workaround and > it appears stable. Hm, looking at http://v6launch.ripe.net/, whatever you changed didn't improve visibility of the AAAA, but decreased it. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From randy at psg.com Thu Jun 7 12:03:17 2012 From: randy at psg.com (Randy Bush) Date: Thu, 07 Jun 2012 10:03:17 -0700 Subject: LinkedIn password database compromised In-Reply-To: <4FD0DC6C.9060502@deaddrop.org> References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> Message-ID: hi etaoin, > I still don't want single sign on. Not anywhere. i believe that 'single sign on' is a bad deal and dangerous for all, not just we geeks. essentially it means that the 'identiry provider' owns your identity. i love that they call themselves 'identity providers' when it is MY fracking identity and they are reselling it. the 'single sign on' i encourage for the end using human beings i support is 1password and its ilk. it provides the user with one sign-on yet strongly encourages separation of identities and strong passwords for sites. add to that, something such as ghostery for your browser, and you have a small chance of actually preserving your identity and minimizing cross- site tracking. randy From morrowc.lists at gmail.com Thu Jun 7 12:09:48 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 7 Jun 2012 13:09:48 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> Message-ID: On Thu, Jun 7, 2012 at 1:03 PM, Randy Bush wrote: > hi etaoin, > >> I still don't want single sign on. ?Not anywhere. > > i believe that 'single sign on' is a bad deal and dangerous for all, not > just we geeks. ?essentially it means that the 'identiry provider' owns > your identity. ?i love that they call themselves 'identity providers' > when it is MY fracking identity and they are reselling it. so... now that this can is open, has anyone looked at: they seem to have some interesting options for better authentication. > the 'single sign on' i encourage for the end using human beings i > support is 1password and its ilk. ?it provides the user with one sign-on > yet strongly encourages separation of identities and strong passwords > for sites. the oneid people would say: "it is still a shared secret" -chris From randy at psg.com Thu Jun 7 12:14:21 2012 From: randy at psg.com (Randy Bush) Date: Thu, 07 Jun 2012 10:14:21 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> Message-ID: > so... now that this can is open, has anyone looked at: > yep. yet another bucket of identity slime wanting to resell my identity. randy From oscar.vives at gmail.com Thu Jun 7 12:30:11 2012 From: oscar.vives at gmail.com (Tei) Date: Thu, 7 Jun 2012 10:30:11 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> Message-ID: The problem: - Modern internet users must have lots of different login/passwords around the internet. Most of then in easy-to-break poorly-patched poorly-managed servers, like linkedin. The solution: - Reduce the number of authentication. Allow anonymous posting in more sites. Imagine this. I post something on the blog "yadaydayda". I give my email and nothing else. The blog software sends me a email to confirm the post. I click on it, and the post is published. The real problem is that nowdays everybody and his dog want a password, and a password is expensive for the user. The internet need more anonymous ways to publish content. -- -- ?in del ?ensaje. From morrowc.lists at gmail.com Thu Jun 7 12:31:00 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 7 Jun 2012 13:31:00 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> Message-ID: On Thu, Jun 7, 2012 at 1:14 PM, Randy Bush wrote: >> so... now that this can is open, has anyone looked at: >> ? > > yep. ?yet another bucket of identity slime wanting to resell my > identity. maybe? they don't seem to want to be the 'identity provider' directly though, or rather they point out that your corporation could be your identity provider (or anyone else you might trust) they simply sell the enabling software/tech. From marshall.eubanks at gmail.com Thu Jun 7 12:33:59 2012 From: marshall.eubanks at gmail.com (Marshall Eubanks) Date: Thu, 7 Jun 2012 13:33:59 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> Message-ID: On Thu, Jun 7, 2012 at 1:30 PM, Tei wrote: > The problem: > - Modern internet users must have lots of different login/passwords around > the internet. ?Most of then in easy-to-break poorly-patched poorly-managed > servers, ?like linkedin. > > The solution: > - ?Reduce the number of authentication. ?Allow anonymous posting in more > sites. > > Imagine this. ? I post something on the blog ?"yadaydayda". I give my email > and nothing else. ? The blog software sends me a email to confirm the post. > I click on it, and the post is published. > > The real problem is that nowdays everybody and his dog want a password, and > a password is expensive for the user. ?The internet need more anonymous > ways to publish content. Maybe so, but anonymous entries on linkedin seems like a zen koan, beyond the powers of my simple mind. Regards Marshall > > > -- > -- > ?in del ?ensaje. From hrlinneweh at sbcglobal.net Thu Jun 7 12:41:49 2012 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Thu, 7 Jun 2012 10:41:49 -0700 (PDT) Subject: AT&T Bucks IPv6 Trend Message-ID: <1339090909.5314.YahooMailNeo@web180307.mail.gq1.yahoo.com> Since AT&T has not said much about ipv6, here is their position on it and how they intend to deploy http://www.lightreading.com/blog.asp?blog_sectionid=847&doc_id=221739&f_src=lrdailynewsletter -Henry From randy at psg.com Thu Jun 7 12:43:09 2012 From: randy at psg.com (Randy Bush) Date: Thu, 07 Jun 2012 10:43:09 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> Message-ID: >>> so... now that this can is open, has anyone looked at: >>> ? >> >> yep. ?yet another bucket of identity slime wanting to resell my >> identity. > > maybe? they don't seem to want to be the 'identity provider' directly > though, or rather they point out that your corporation could be your > identity provider (or anyone else you might trust) they simply sell > the enabling software/tech. so they provide tools to indentity resellers. the folk their software enables are still *reselling* MY identity. my point is that it is MY identity. there are tools, such as 1password, which enable me to control MY identity and yet have the effect of single sign-on. and i believe it is important that mom and pop retain control of their identities. randy From valdis.kletnieks at vt.edu Thu Jun 7 13:24:34 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 07 Jun 2012 14:24:34 -0400 Subject: LinkedIn password database compromised In-Reply-To: Your message of "Thu, 07 Jun 2012 13:33:59 -0400." References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> Message-ID: <10506.1339093474@turing-police.cc.vt.edu> On Thu, 07 Jun 2012 13:33:59 -0400, Marshall Eubanks said: > Maybe so, but anonymous entries on linkedin seems like a zen koan, > beyond the powers of my simple mind. There's a distinction between anonymous and pseudonymous. I'm certainly not the former, but to all but maybe a dozen or two NANOG'ers, I'm pretty much the latter - somebody who always posts from the same identity, but they've never actually personally verified the identity. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From owen at delong.com Thu Jun 7 13:51:51 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 11:51:51 -0700 Subject: Configuration Systems In-Reply-To: References: Message-ID: On Jun 6, 2012, at 7:58 PM, Andrew Latham wrote: > Jonathan > > That is the exact question I have asked myself many times. All of the > major players in Configuration management have a "client" program that > must run and at times requires some libraries that are newer than the > platforms a company may need to support or that clients may wish > supported. Another issue is the secure communication over a > proprietary or SSH connection and not allowing secured VLANs or other > services like RSH and Telnet over a point to point connection. > I would argue that not allowing telnet/rsh in favor of requiring SSH is a good thing. As to the client program, so long as the system makes the client available via open source and/or publishes the required client API, you should be able to work around any library issues or system age issues by developing your own client component. > Also you will find that the demand for cloud systems and the complex > languages used in the "Configuration Management Systems" do not easily > translate to the existing and developing cloud infrastructure. This is a hard problem to solve. Not the least of the difficulties is the fact that if you ask 50 engineers to define "Cloud", you will get at least 100 definitions many of which are incompatible to the point of mutually exclusive. Owen > > and stuff... > > > On Wed, Jun 6, 2012 at 10:52 PM, Jonathan Herbert wrote: >> Hi Andrew, >> >> Out of curiosity, why are you reinventing the wheel here? >> >> Don't take this the wrong way- I'm just curious why you're building >> something new. What does Enablement do that the other technologies you've >> mentioned doesn't? >> >> Jonathan >> >> >> On Wed, Jun 6, 2012 at 10:49 PM, Andrew Latham wrote: >>> >>> Lurker speaking... beware... >>> >>> I have been talking with some folks from various industries about >>> configuration systems ala Bcfg2, Puppet, Chef, and others. Many of >>> them care far too much about the current nodes configuration status as >>> some admin had logged in and changed something. I am authoring a >>> system called Enablement that uses what ever technology needed (ssh, >>> telnet over admin vlan, rsh, etc...) to push a planned system/config >>> to the device. Monitoring and auditing are all the same at the moment >>> as we need historical data on when a service or port started and >>> stopped offering its planned or unplanned service. For a meeting >>> Thursday I am looking forward to the future of configuring systems. >>> My idea is push + netblock scanning of services. With stacks for >>> clouds we can startup and shut down nodes easy. Would a bend over >>> backwards config reader for all the "Configuration Management Systems" >>> be the best medium ground from the service provider point of view? >>> >>> Enablement.... Send another man to fight on the front line. >>> >>> -- >>> ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ >>> >> > > > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From owen at delong.com Thu Jun 7 14:24:00 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 12:24:00 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: <56F14D89-FCD8-4ECB-9FC0-6E2A8A9A666F@delong.com> On Jun 6, 2012, at 11:14 PM, Aaron C. de Bruyn wrote: > On Wed, Jun 6, 2012 at 8:34 PM, Jimmy Hess wrote: >> Which digital id architecture should web sites implement, and what's >> going to make them all agree on one SSO system and move from the >> current state to one of the possible solutions though? :) >> >> A TLS + Client-Side X.509 Certificate for every user. > > Heck no to X.509. We'd run into the same issue we have right now--a > select group of companies charging users to prove their identity. > Not if enough of us get behind CACERT. Non-profit organization providing fee certificates based on web of trust model. http://www.cacert.org For any of you in the bay area and/or who encounter me in my various travels, I am an CACERT top-level notary. Personally, I like the SSH model and simply giving the web-site your public key at sign-up, but, there are issues with that as well... If your private key is compromised, how do you notify all of the web-sites that it needs to be revoked? Owen From owen at delong.com Thu Jun 7 14:31:57 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 12:31:57 -0700 Subject: LinkedIn password database compromised In-Reply-To: <4FD0AE52.20602@alter3d.ca> References: <4FD004F0.4060606@deaddrop.org> <20120607132240.GO32960@teardrop.org> <4FD0AE52.20602@alter3d.ca> Message-ID: <7D175958-294E-467C-9F21-2431E46B88F8@delong.com> On Jun 7, 2012, at 6:36 AM, Peter Kristolaitis wrote: > On 6/7/2012 9:22 AM, James Snow wrote: >> On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote: >>> Imaging signing up for a site by putting in your email and pasting >>> your public key. >> Yes! Yes! Yes! >> >> I've been making this exact argument for about a year. It even retains >> the same "email a link" reset mechanism when someone needs to reset >> their key. >> >> A common counter-argument is, "But ordinary Internet users won't >> understand SSH keys." They don't need to! The idea is easily explained >> via a lock-and-key metaphor that people already understand. The UI for >> walking users through key creation is easily imagined. >> >> >> -Snow > > Oh yeah, I can just imagine that "lock and key" conversation now... > > "Imagine if the website has a lock on it, and you tell them what key you want to use by giving them a copy." > "But if they have a copy of my key, couldn't they use it to open all of the other locks I've set up to use it?" > "(explain public key crypto)" > "(drool, distraction by the latest Facebook feature)" > Wrong approach... "Imagine if the website has a lock created by each user. The user creates the lock by giving the web site their "lock template". Once you give them the "lock template", only your key will open that lock." (Lock template = public key, key = private key) "No, the lock template won't open the other copies of the lock template. Only the key will open the lock template, but, the key will open all the lock templates. It's just like having all the locks on your house "keyed alike". I can't take the lock off the front door and use it to open the back door, neither can the lock template given to one website be used to unlock your account at another website." > The other problem with this approach is that, as bad as trusting remote sites to do security properly is, I'm not sure that putting a "one key to rule them all" on users' machines is that much better, given the average user's penchant for installing malware on their machine because "FunnyMonkeyScreensaver.exe" sounded like such a good idea at the time... I suspect we'd see a huge wave of malware whose sole purpose is to steal public keys (and you KNOW users won't password-protect their private keys!). Plus, now you have the problem of users not being able to login to their favourite websites when they're using a friend's computer, internet cafe, etc, unless they've remembered to bring a copy of their private key with them. Yeah, there is that problem as well. Personally, I'd like to see someone produce what amounts to a mini-HSM such as a USB-dongle that will contain but never emit the private key, and perform one of the following functions, given the right one-time password (which could be produced either by display on the dongle, or, by a mobile app): 1. Emit public key. 2. Encrypt challenge response or other data using private key. 3. Create new keypair. This would provide the benefits of 2-factor authentication along with the ease of the proposed SSH-key mechanism. The key wouldn't be accessible to malware and in order to exploit the key, the malware would have to convince the user to enter their one-time password and/or would be required to beat the legitimate application to the request (in which case, the legitimate application's request would fail making the failure obvious to the user). > I think public key auth for websites is a great idea for geeks who understand the benefits, limitations and security concerns, but I have serious doubts that it would hold up when subjected to the "idiot test". I think that there is a lot of UI work to be done in this area, but, that it can actually be made safe and effective for lay-persons. After all, if Blizzard can get a bunch of their players using 2-factor tokens for authentication, this can't really be that much harder. Owen From aaron at heyaaron.com Thu Jun 7 14:37:50 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 7 Jun 2012 12:37:50 -0700 Subject: LinkedIn password database compromised In-Reply-To: <56F14D89-FCD8-4ECB-9FC0-6E2A8A9A666F@delong.com> References: <4FD004F0.4060606@deaddrop.org> <56F14D89-FCD8-4ECB-9FC0-6E2A8A9A666F@delong.com> Message-ID: On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong wrote: >> Heck no to X.509. ?We'd run into the same issue we have right now--a >> select group of companies charging users to prove their identity. > > Not if enough of us get behind CACERT. Yet again, another org (free or not) that is holding my identity hostage. Would you give cacert your SSH key and use them to log in to your Linux servers? I'd bet most *nix admins would shout "hell no!" So why would you make them the gateway for your online identity? -A From owen at delong.com Thu Jun 7 14:57:48 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 12:57:48 -0700 Subject: LinkedIn password database compromised In-Reply-To: <5E50AC3B0F1FA9408A82DC0DEB965E4AF02E6E@APMMAIL02.global.nmhg.corp> References: <4FD004F0.4060606@deaddrop.org> <5E50AC3B0F1FA9408A82DC0DEB965E4AF02E6E@APMMAIL02.global.nmhg.corp> Message-ID: <867C550A-B4F3-4D4D-9DB8-FA2CF05B3591@delong.com> On Jun 7, 2012, at 9:29 AM, Bruch, Mark wrote: > I rarely reply to threads. However the point of interest that is missed is "Not supported anymore because Microsoft says so". So Microsoft starts putting out systems at one per year and not supporting old ones because they "Have you over a barrel"? > > Tell your daughter she can't get married? You haven't bought your new operating system this year, and "backward compatible" is a thing of the past? > > Then it is $119.00 per year on top of that (maybe)? > > Let's say Microsoft promised business to the PC building companies and decides that an operating system per year is only supported on new equipment? The cost to vote could be thousands per year. Only the rich can afford to vote? > > The point is that you have to be careful about where you go with technology and who controls it. I am sure there are people who would love to see voting as a "can you afford it" right. Nah... They've obviated the need with superPACs and other mechanisms for purchasing the politicians we vote for much more cost effectively than purchasing the elections themselves. Owen > > -----Original Message----- > From: Aaron C. de Bruyn [mailto:aaron at heyaaron.com] > Sent: Thursday, June 07, 2012 11:10 AM > To: Jared Mauch > Cc: Nanog > Subject: Re: LinkedIn password database compromised > > On Thu, Jun 7, 2012 at 8:58 AM, Jared Mauch wrote: >> I'm imagining my mother trying this, or trying to help her change it after the hard drive dies and the media in the safe deposit box doesn't read anymore. > > I would think it's fairly simple. > What if she forgot her existing password? Most sites have a 'reset password' link they e-mail you. > A browser extension 'helper' would simply generate a new key and let you reset your password. Maybe the helper could be dumbed down enough to automatically handle the password reset screen and automatically POST the new key to the reset page. > > I'm sure it could be done transparently enough that our mothers wouldn't need to think twice about it. > > Heck--the 'helper' could probably even back up your SSH key off-site sorta like LastPass does. And if your private key is actually password protected, it's slightly less useless if the off-site backup company were compromised. > > The only downfall is how do you get access to your e-mail account? > (Google already calls my cell and/or home phone if I request access without using my password.) > > I agree there are stumbling blocks, and it wouldn't be perfect--but it seems like it would be much better than the alternative we have now. > People using the same password on multiple sites, passwords written down, dumb website operators not salting their hashes, etc... > > Also, thanks for the great secondary DNS service. ;) > > -A > From bhmccie at gmail.com Thu Jun 7 15:04:57 2012 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 07 Jun 2012 15:04:57 -0500 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <56F14D89-FCD8-4ECB-9FC0-6E2A8A9A666F@delong.com> Message-ID: <4FD10969.8070500@gmail.com> I gotta agree with Aaron here. What would be my motivation to "trust" an open and public infrastructure? With my business or personal keys? -Hammer- "I was a normal American nerd" -Jack Herer On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote: > On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong wrote: >>> Heck no to X.509. We'd run into the same issue we have right now--a >>> select group of companies charging users to prove their identity. >> Not if enough of us get behind CACERT. > Yet again, another org (free or not) that is holding my identity hostage. > Would you give cacert your SSH key and use them to log in to your > Linux servers? I'd bet most *nix admins would shout "hell no!" > > So why would you make them the gateway for your online identity? > > -A > > From owen at delong.com Thu Jun 7 15:00:38 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 13:00:38 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> Message-ID: <6546EADC-BFD9-4214-B96C-BC0D763D73FC@delong.com> On Jun 7, 2012, at 10:03 AM, Randy Bush wrote: > hi etaoin, > >> I still don't want single sign on. Not anywhere. > > i believe that 'single sign on' is a bad deal and dangerous for all, not > just we geeks. essentially it means that the 'identiry provider' owns > your identity. i love that they call themselves 'identity providers' > when it is MY fracking identity and they are reselling it. > If single sign-on is done right, then YOU are the identity provider and YOU own your identity. It does, however, potentially enable cross-site tracking. Owen From owen at delong.com Thu Jun 7 15:06:04 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 13:06:04 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <56F14D89-FCD8-4ECB-9FC0-6E2A8A9A666F@delong.com> Message-ID: On Jun 7, 2012, at 12:37 PM, Aaron C. de Bruyn wrote: > On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong wrote: >>> Heck no to X.509. We'd run into the same issue we have right now--a >>> select group of companies charging users to prove their identity. >> >> Not if enough of us get behind CACERT. > > Yet again, another org (free or not) that is holding my identity hostage. > Would you give cacert your SSH key and use them to log in to your > Linux servers? I'd bet most *nix admins would shout "hell no!" > > So why would you make them the gateway for your online identity? > > -A HuH? They don't hold my identity hostage. They sign my identity. That's it. I create the certificate and the private key. They never receive the private key. They merely provide a mechanism by which trusted parties can verify and then attest that I am, indeed, who I claim to be. Would I consider using my X.509 certificate as an authentication method for my linux servers? Not at this time for the simple reason that the combinations of expiry and the UI complexities in doing so make it significantly less convenient than my SSH keys. However, if it were made to be equally convenient with SSH keys, then, I don't see a problem with it. Owen From owen at delong.com Thu Jun 7 15:18:18 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 13:18:18 -0700 Subject: LinkedIn password database compromised In-Reply-To: <4FD10969.8070500@gmail.com> References: <4FD004F0.4060606@deaddrop.org> <56F14D89-FCD8-4ECB-9FC0-6E2A8A9A666F@delong.com> <4FD10969.8070500@gmail.com> Message-ID: <844C316A-4535-4D18-A112-59AE47398636@delong.com> A proper CA does not have your business or personal keys, they merely sign them and attest to the fact that they actually represent you. You are free to seek and obtain such validation from any and as many parties as you see fit. At no point should any CA be given your private key data. They merely use their private key to encrypt a hash of your public key and other data to indicate that your private key is bound to your other data. You trust DMV/Passport Agency/etc. to validate your identity in the form of your government issued ID credentials, right? That doesn't give DMV/Passport Agency/etc. control over your face, but, it does allow them to indicate to others that your face is tied to your name, date of birth, etc. Owen On Jun 7, 2012, at 1:04 PM, -Hammer- wrote: > I gotta agree with Aaron here. What would be my motivation to "trust" an open and public infrastructure? With my business or personal keys? > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote: >> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong wrote: >>>> Heck no to X.509. We'd run into the same issue we have right now--a >>>> select group of companies charging users to prove their identity. >>> Not if enough of us get behind CACERT. >> Yet again, another org (free or not) that is holding my identity hostage. >> Would you give cacert your SSH key and use them to log in to your >> Linux servers? I'd bet most *nix admins would shout "hell no!" >> >> So why would you make them the gateway for your online identity? >> >> -A >> >> From jfbeam at gmail.com Thu Jun 7 15:27:52 2012 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 07 Jun 2012 16:27:52 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> References: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> Message-ID: On Wed, 06 Jun 2012 10:58:05 -0400, Chuck Church wrote: > Does anyone know the reason /64 was proposed as the size for all L2 > domains? There is one, and only one, reason for the ::/64 split: SLAAC. IPv6 is a classless addressing system. You can make your LAN ::/117 if you want to; SLAAC will not work there. The reason the requirement is (currently) 64 is to accomodate EUI-64 hardware addresses -- firewire, bluetooth, fibre channel, etc. Originally, SLAAC was designed for ethernet and its 48bit hardware address. (required LAN mask was ::/80.) The purpose wasn't to put the whole internet into one LAN. It was to make address selection "brainless", esp. for embeded systems with limited memory/cpu/etc... they can form an address by simply appending their MAC to the prefix, and be 99.99999% sure it won't be in use. (i.e. no DAD required.) However, that was optimizing a problem that never existed -- existing tiny systems of the day were never destined to have an IPv6 stack, "modern" IPv6 hardware can select an address and perform DAD efficiently in well under 1K. (which is noise vs. the size of the rest of the IPv6 stack.) SLAAC has been a flawed idea from the first letter... if for no other reason than it makes people think "64bit network + 64bit host" -- and that is absolutely wrong. (one cannot make such assumptions about networks they do not control. it's even worse when people design hardware thinking that.) --Ricky From bhmccie at gmail.com Thu Jun 7 15:31:38 2012 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 07 Jun 2012 15:31:38 -0500 Subject: LinkedIn password database compromised In-Reply-To: <844C316A-4535-4D18-A112-59AE47398636@delong.com> References: <4FD004F0.4060606@deaddrop.org> <56F14D89-FCD8-4ECB-9FC0-6E2A8A9A666F@delong.com> <4FD10969.8070500@gmail.com> <844C316A-4535-4D18-A112-59AE47398636@delong.com> Message-ID: <4FD10FAA.5060306@gmail.com> Thank you for educating without insulting. Always professional Owen. It's appreciated. -Hammer- "I was a normal American nerd" -Jack Herer On 6/7/2012 3:18 PM, Owen DeLong wrote: > A proper CA does not have your business or personal keys, they merely > sign them and attest to the fact that they actually represent you. You are > free to seek and obtain such validation from any and as many parties as > you see fit. > > At no point should any CA be given your private key data. They merely > use their private key to encrypt a hash of your public key and other data > to indicate that your private key is bound to your other data. > > You trust DMV/Passport Agency/etc. to validate your identity in the form > of your government issued ID credentials, right? > > That doesn't give DMV/Passport Agency/etc. control over your face, but, > it does allow them to indicate to others that your face is tied to your > name, date of birth, etc. > > Owen > > On Jun 7, 2012, at 1:04 PM, -Hammer- wrote: > >> I gotta agree with Aaron here. What would be my motivation to "trust" an open and public infrastructure? With my business or personal keys? >> >> -Hammer- >> >> "I was a normal American nerd" >> -Jack Herer >> >> >> >> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote: >>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong wrote: >>>>> Heck no to X.509. We'd run into the same issue we have right now--a >>>>> select group of companies charging users to prove their identity. >>>> Not if enough of us get behind CACERT. >>> Yet again, another org (free or not) that is holding my identity hostage. >>> Would you give cacert your SSH key and use them to log in to your >>> Linux servers? I'd bet most *nix admins would shout "hell no!" >>> >>> So why would you make them the gateway for your online identity? >>> >>> -A >>> >>> > From jfbeam at gmail.com Thu Jun 7 15:42:52 2012 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 07 Jun 2012 16:42:52 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1339017457.2754.8.camel@karl> References: <1339017457.2754.8.camel@karl> Message-ID: On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer wrote: > a) DAD only happens when an IPv6 node is starting up. ARP happens > whenever a node needs to talk to another node that it hasn't seen in > while. DAD is a special case of ND. It happens every time the system selects an address. (i.e. startup with non-SLAAC address, and when privacy extensions generates an address.) > b) DAD only goes to solicited node multicast addresses, i.e., only to > those nodes that share the same last 24 bits as the target address. ARP > goes to every node on the link (broadcast). This assumes a network of devices that do multicast filtering, correctly. This is not a good assumption even in large enterprises. Common residential gear usually doesn't understand multicast at all. (unless you're a uverse tv customer using ethernet and paid close attention to your hardware.) > c) Similarly, ND (the direct equivalent of ARP) goes only to solicited > node multicast addresses, ARP goes to every node on the link. Effectively the same as broadcast in the IPv6 world. If everyone is running IPv6, then everyone will see the packet. (things not running ipv6 can filter it out, but odds are it'll be put on the cable.) > So I'm not sure how DAD traffic would exceed ARP traffic. I wouldn't expect it to. Looking at the output of my 3745, it fires 3 ND's at startup and is then silent. (TWC has no IPv6 on my node, but v4 ARP broadcasts amount to ~16K/s) --Ricky From davehart at gmail.com Thu Jun 7 16:07:31 2012 From: davehart at gmail.com (Dave Hart) Date: Thu, 7 Jun 2012 21:07:31 +0000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <1339017457.2754.8.camel@karl> Message-ID: On Thu, Jun 7, 2012 at 8:42 PM, Ricky Beam wrote: > On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer wrote: >> >> c) Similarly, ND (the direct equivalent of ARP) goes only to solicited >> node multicast addresses, ARP goes to every node on the link. > > Effectively the same as broadcast in the IPv6 world. ?If everyone is running > IPv6, then everyone will see the packet. (things not running ipv6 can filter > it out, but odds are it'll be put on the cable.) Bzzt. With ARP, every IPv4 node on the link indicates each ARP packet to the OS. With ND, only those nodes sharing the same last 24 bits of the IPv6 address indicate the packet up the stack. The rest of the IPv6 nodes filter the multicast in the NIC. Cheers, Dave Hart From matthew at matthew.at Thu Jun 7 16:26:45 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 7 Jun 2012 14:26:45 -0700 Subject: LinkedIn password database compromised In-Reply-To: <844C316A-4535-4D18-A112-59AE47398636@delong.com> References: <4FD004F0.4060606@deaddrop.org> <56F14D89-FCD8-4ECB-9FC0-6E2A8A9A666F@delong.com> <4FD10969.8070500@gmail.com> <844C316A-4535-4D18-A112-59AE47398636@delong.com> Message-ID: It also allows them to sign anyone they want as someone pretending to be you, but with a different key pair. Just like the DMV could, if it wanted to (or was ordered to) issue a drivers license with my name and DL number but an FBI agent's photo and thumbprint associated. You'd want your logins to be at sites that only trusted CAs that you trusted to not do this... for HTTPS we're already way over that line I'm afraid. Matthew Kaufman (Sent from my iPhone) On Jun 7, 2012, at 1:18 PM, Owen DeLong wrote: > A proper CA does not have your business or personal keys, they merely > sign them and attest to the fact that they actually represent you. You are > free to seek and obtain such validation from any and as many parties as > you see fit. > > At no point should any CA be given your private key data. They merely > use their private key to encrypt a hash of your public key and other data > to indicate that your private key is bound to your other data. > > You trust DMV/Passport Agency/etc. to validate your identity in the form > of your government issued ID credentials, right? > > That doesn't give DMV/Passport Agency/etc. control over your face, but, > it does allow them to indicate to others that your face is tied to your > name, date of birth, etc. > > Owen > > On Jun 7, 2012, at 1:04 PM, -Hammer- wrote: > >> I gotta agree with Aaron here. What would be my motivation to "trust" an open and public infrastructure? With my business or personal keys? >> >> -Hammer- >> >> "I was a normal American nerd" >> -Jack Herer >> >> >> >> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote: >>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong wrote: >>>>> Heck no to X.509. We'd run into the same issue we have right now--a >>>>> select group of companies charging users to prove their identity. >>>> Not if enough of us get behind CACERT. >>> Yet again, another org (free or not) that is holding my identity hostage. >>> Would you give cacert your SSH key and use them to log in to your >>> Linux servers? I'd bet most *nix admins would shout "hell no!" >>> >>> So why would you make them the gateway for your online identity? >>> >>> -A >>> >>> > > From m.hallgren at free.fr Thu Jun 7 16:35:59 2012 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 07 Jun 2012 23:35:59 +0200 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> Message-ID: <1339104959.27885.10.camel@home> Hi Randy, Le jeudi 07 juin 2012 ? 10:03 -0700, Randy Bush a ?crit : > hi etaoin, > > > I still don't want single sign on. Not anywhere. > > i believe that 'single sign on' is a bad deal and dangerous for all, not > just we geeks. essentially it means that the 'identiry provider' owns > your identity. i love that they call themselves 'identity providers' > when it is MY fracking identity and they are reselling it. I agree. > > the 'single sign on' i encourage for the end using human beings i > support is 1password and its ilk. it provides the user with one sign-on > yet strongly encourages separation of identities and strong passwords > for sites. > Local repository of passwords, aggregation in a way. Right? Encrypted? Open source? > add to that, something such as ghostery for your browser, and you have a > small chance of actually preserving your identity and minimizing cross- > site tracking. > > randy mh > From owen at delong.com Thu Jun 7 16:45:22 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 14:45:22 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> Message-ID: <0A8C5C72-D154-4EAE-82C7-83F34EAAFFD0@delong.com> On Jun 7, 2012, at 1:27 PM, Ricky Beam wrote: > On Wed, 06 Jun 2012 10:58:05 -0400, Chuck Church wrote: >> Does anyone know the reason /64 was proposed as the size for all L2 domains? > > There is one, and only one, reason for the ::/64 split: SLAAC. IPv6 is a classless addressing system. You can make your LAN ::/117 if you want to; SLAAC will not work there. > Nope... There's also ND and the solicited node address. > The reason the requirement is (currently) 64 is to accomodate EUI-64 hardware addresses -- firewire, bluetooth, fibre channel, etc. Originally, SLAAC was designed for ethernet and its 48bit hardware address. (required LAN mask was ::/80.) The purpose wasn't to put the whole internet into one LAN. It was to make address selection "brainless", esp. for embeded systems with limited memory/cpu/etc... they can form an address by simply appending their MAC to the prefix, and be 99.99999% sure it won't be in use. (i.e. no DAD required.) However, that was optimizing a problem that never existed -- existing tiny systems of the day were never destined to have an IPv6 stack, "modern" IPv6 hardware can select an address and perform DAD efficiently in well under 1K. (which is noise vs. the size of the rest of the IPv6 stack.) Modern embedded IPv6 systems in short order will have IPv6 implemented in the chip ala the Wizard W5100 chip that is very popular for IPv4 in embedded systems and micro-controllers today. > SLAAC has been a flawed idea from the first letter... if for no other reason than it makes people think "64bit network + 64bit host" -- and that is absolutely wrong. (one cannot make such assumptions about networks they do not control. it's even worse when people design hardware thinking that.) While one cannot assume 64+64 on networks you don't control and CIDR is the rule for IPv6, having a common 64+64 subnet size widely deployed has a number of advantages. I am interested to hear what people are using in lieu of ND and ARP on NBMA and/or BMA multipoint IPv6 networks with netmasks longer than /64. Owen From valdis.kletnieks at vt.edu Thu Jun 7 16:49:54 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 07 Jun 2012 17:49:54 -0400 Subject: Configuration Systems In-Reply-To: Your message of "Thu, 07 Jun 2012 11:51:51 -0700." References: Message-ID: <20785.1339105794@turing-police.cc.vt.edu> On Thu, 07 Jun 2012 11:51:51 -0700, Owen DeLong said: > This is a hard problem to solve. Not the least of the difficulties is the fact that > if you ask 50 engineers to define "Cloud", you will get at least 100 definitions > many of which are incompatible to the point of mutually exclusive. "cloud" == "you rented in a colo, but have no clue where". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From davidianwalker at gmail.com Thu Jun 7 16:56:09 2012 From: davidianwalker at gmail.com (David Walker) Date: Fri, 8 Jun 2012 07:26:09 +0930 Subject: LinkedIn password database compromised In-Reply-To: <4FD004F0.4060606@deaddrop.org> References: <4FD004F0.4060606@deaddrop.org> Message-ID: On 07/06/2012, Lynda wrote: > Sorry to be the bearer of such bad tidings. I'm a very amateur cryptologist so some of this is new to me: "Any organization using SHA-1 without salting user passwords is running a great risk -- much higher than they should," said Per Thorsheim, chief information security advisor at Norwegian IT services company EVRY. "We've seen this time and time again. This is not good practice. Salt should be a minimum." http://money.cnn.com/2012/06/06/technology/linkedin-password-hack/ This, however, is all too commonplace: "We take the security of our members very seriously." http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/ This is the only security item they have and it's mission critical right? The issues are well understood and highly publicized. The procedures are simple. Taking a casual interest in security pretty much precludes mistakes here. I'm not fooled at all. http://press.linkedin.com/node/1192 The current system can work if applied correctly but time and again we're seeing failure from service providers to follow the dots. As I mentioned I'm no expert but I don't think widening the circle of trust is the correct answer regardless of the technology. There's no technology shortfall here. Self signed certificates does sound great and for most purposes, certainly in this case, fulfills all the requirements. There's no need to verify anything about me is correct other than to tie my authentication to my account. If I fail to meet the TOS then the plug is easily pulled and any further activity can be dealt with as it currently is by other means. I think there's enough risk in bringing in a CA and so little advantage that it's wrong. As far as moving the cryptographic responsibility from the service provider to us - I'm all for it. They've been telling us for some time now they'd rather not do that stuff. I'd much rather have control and introduce something a little sleeker. As far as users go, if they have to learn it to get on FaceSpace then they'll learn it - that's a given. There's no reason for it not to be optional anyway. To all the people who've figured this out, my hat's off. I'm very suspicious of any mention of a browser being involved in this process though. Shifiting some software responsibility to the client probably brings new/different danger anyway but probably the last piece of goop that should be involved is a browser. That's anecdotal aversion but I'll stand by it. > Please note that LinkedIn has weighed in with a carefully worded blog post: > > http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/ > > Further details: > 1. The leak took place on June 4 > 2. LinkedIn was using unsalted SHA-1 for their password store. > 3. FYI, there are two lists. The second one appears to be from eHarmony. > Unsalted MD5 used there. > 4. The posted passwords are believed to be ones the cracker wanted help > with, i.e., they have significantly more already cracked. > > Apparently phishing emails are already active in the wild based on the > crack: > > http://bits.blogs.nytimes.com/2012/06/06/that-was-fast-criminals-exploit-linkedin-breach-for-phishing-attacks/ > > In other words, if you have a LinkedIn account, expect that the password > has been stolen. Go change your password now. If you used that password > elsewhere, you know the routine. In addition, as has been pointed out > elsewhere, there's no sign LI has fixed the problem. Expect that the > password you change it to will also be compromised. > > :-( > > -- > A picture is worth 10K words -- but only those to describe > the picture. Hardly any sets of 10K words can be adequately > described with pictures. > > > From owen at delong.com Thu Jun 7 17:00:03 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 15:00:03 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <56F14D89-FCD8-4ECB-9FC0-6E2A8A9A666F@delong.com> <4FD10969.8070500@gmail.com> <844C316A-4535-4D18-A112-59AE47398636@delong.com> Message-ID: <149C7986-34AF-416B-980E-1F3C63665307@delong.com> No argument about that at all. Owen On Jun 7, 2012, at 2:26 PM, Matthew Kaufman wrote: > It also allows them to sign anyone they want as someone pretending to be you, but with a different key pair. > > Just like the DMV could, if it wanted to (or was ordered to) issue a drivers license with my name and DL number but an FBI agent's photo and thumbprint associated. > > You'd want your logins to be at sites that only trusted CAs that you trusted to not do this... for HTTPS we're already way over that line I'm afraid. > > Matthew Kaufman > > (Sent from my iPhone) > > On Jun 7, 2012, at 1:18 PM, Owen DeLong wrote: > >> A proper CA does not have your business or personal keys, they merely >> sign them and attest to the fact that they actually represent you. You are >> free to seek and obtain such validation from any and as many parties as >> you see fit. >> >> At no point should any CA be given your private key data. They merely >> use their private key to encrypt a hash of your public key and other data >> to indicate that your private key is bound to your other data. >> >> You trust DMV/Passport Agency/etc. to validate your identity in the form >> of your government issued ID credentials, right? >> >> That doesn't give DMV/Passport Agency/etc. control over your face, but, >> it does allow them to indicate to others that your face is tied to your >> name, date of birth, etc. >> >> Owen >> >> On Jun 7, 2012, at 1:04 PM, -Hammer- wrote: >> >>> I gotta agree with Aaron here. What would be my motivation to "trust" an open and public infrastructure? With my business or personal keys? >>> >>> -Hammer- >>> >>> "I was a normal American nerd" >>> -Jack Herer >>> >>> >>> >>> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote: >>>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong wrote: >>>>>> Heck no to X.509. We'd run into the same issue we have right now--a >>>>>> select group of companies charging users to prove their identity. >>>>> Not if enough of us get behind CACERT. >>>> Yet again, another org (free or not) that is holding my identity hostage. >>>> Would you give cacert your SSH key and use them to log in to your >>>> Linux servers? I'd bet most *nix admins would shout "hell no!" >>>> >>>> So why would you make them the gateway for your online identity? >>>> >>>> -A >>>> >>>> >> >> From marka at isc.org Thu Jun 7 17:04:12 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 08 Jun 2012 08:04:12 +1000 Subject: AAAA's for www.netflix.com In-Reply-To: Your message of "Thu, 07 Jun 2012 18:58:18 +0200." <20120607165818.GA30416@srv03.cluenet.de> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> <20120607165818.GA30416@srv03.cluenet.de> Message-ID: <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> In message <20120607165818.GA30416 at srv03.cluenet.de>, Daniel Roesen writes: > On Thu, Jun 07, 2012 at 07:52:29AM -0600, Dave Temkin wrote: > > Just to close the loop on this - UltraDNS has an issue with CNAMEs and > > their Directional DNS service. We (Netflix) have applied a workaround and > > it appears stable. > > Hm, looking at http://v6launch.ripe.net/, whatever you changed didn't > improve visibility of the AAAA, but decreased it. TTL's of zero don't help. The A query has a TTL of 3600 in the response the AAAA query has a zero TTL. This is rocket science. This isn't hard to do correctly. How to handle CNAMEs has been specified 1/4 of a century. > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Thu Jun 7 17:01:04 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 15:01:04 -0700 Subject: Configuration Systems In-Reply-To: <20785.1339105794@turing-police.cc.vt.edu> References: <20785.1339105794@turing-police.cc.vt.edu> Message-ID: <6CF34DB5-7159-4DA0-8556-9770B208DD71@delong.com> On Jun 7, 2012, at 2:49 PM, valdis.kletnieks at vt.edu wrote: > On Thu, 07 Jun 2012 11:51:51 -0700, Owen DeLong said: > >> This is a hard problem to solve. Not the least of the difficulties is the fact that >> if you ask 50 engineers to define "Cloud", you will get at least 100 definitions >> many of which are incompatible to the point of mutually exclusive. > > "cloud" == "you rented in a colo, but have no clue where". Congratulations of being one of the first in the room to offer a candidate definition. So... What's your second definition? If you don't have a second definition, you're just asking someone else to provide 3 or more. Owen From kauer at biplane.com.au Thu Jun 7 17:09:46 2012 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 08 Jun 2012 08:09:46 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <1339017457.2754.8.camel@karl> Message-ID: <1339106986.2754.37.camel@karl> On Thu, 2012-06-07 at 16:42 -0400, Ricky Beam wrote: > On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer wrote: > > a) DAD only happens when an IPv6 node is starting up. ARP happens > > whenever a node needs to talk to another node that it hasn't seen in > > while. > > DAD is a special case of ND. It happens every time the system selects > an address. (i.e. startup with non-SLAAC address, and when privacy > extensions generates an address.) Er - OK. I should have said "happens when an address is assigned to an interface". It is still, however, way less traffic than ARP, which was my point. Possible exception - a network where everyone is using privacy addresses. > > b) DAD only goes to solicited node multicast addresses > > This assumes a network of devices that do multicast filtering, > correctly. Yes, it does. It assumes a properly provisioned and configured IPv6 network. While that may not be common now, it will become more common. And it is a self-correcting problem - people who don't want lots of noise will implement their networks correctly, those who don't care will do as they wish. No change there :-) BTW, I'm assuming here that by "multicast filtering" you mean "switching that properly snoops on MLD and sends multicast packets only to the correct listeners". > > c) Similarly, ND (the direct equivalent of ARP) goes only to > solicited node multicast addresses, ARP goes to every node on the > link. > > Effectively the same as broadcast in the IPv6 world. If everyone is > running IPv6, then everyone will see the packet. (things not running > ipv6 can filter it out, but odds are it'll be put on the cable.) On this point I think you are wrong. Except for router advertisements, most NDP packets are sent to a solicited node multicast address, and so do NOT go to all nodes. It is "the same as broadcast" only in a network with switches that do not do MLD snooping. > > So I'm not sure how DAD traffic would exceed ARP traffic. > > I wouldn't expect it to. Nor would I - which was the point of my response to an original poster who said it might. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From davidianwalker at gmail.com Thu Jun 7 17:10:19 2012 From: davidianwalker at gmail.com (David Walker) Date: Fri, 8 Jun 2012 07:40:19 +0930 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <56F14D89-FCD8-4ECB-9FC0-6E2A8A9A666F@delong.com> <4FD10969.8070500@gmail.com> <844C316A-4535-4D18-A112-59AE47398636@delong.com> Message-ID: On 08/06/2012, Matthew Kaufman wrote: > It also allows them to sign anyone they want as someone pretending to be > you, but with a different key pair. You're exacly correct but in this case I don't think CAs are necessary and probably detrimental so it's moot. Currently I don't care at all if somebody joins YouTube with my name or whatever and has a password I know nothing about. Well I do care a little. The point is that there's nothing sensitive about a username/password combination for these type of accounts. We don't care. I'm sure I've communicated on the internet with President Obama and Johnny Cash. If there's ever any doubt and something nefarious is going on there are other methods. I don't think anyone's suggesting that this is appropriate for anything sensitive. In short nothing changes at all other than swapping certificates for passwords. If my bank wants to start doing it then they'll have to keep doing what they're doing now and use other channels to verify me at establishment, i.e. I'll have to walk into a branch and verify myself and give them a USB stick with my certificate or whatever ... > > Just like the DMV could, if it wanted to (or was ordered to) issue a drivers > license with my name and DL number but an FBI agent's photo and thumbprint > associated. > > You'd want your logins to be at sites that only trusted CAs that you trusted > to not do this... for HTTPS we're already way over that line I'm afraid. > > Matthew Kaufman > > (Sent from my iPhone) > > On Jun 7, 2012, at 1:18 PM, Owen DeLong wrote: > >> A proper CA does not have your business or personal keys, they merely >> sign them and attest to the fact that they actually represent you. You >> are >> free to seek and obtain such validation from any and as many parties as >> you see fit. >> >> At no point should any CA be given your private key data. They merely >> use their private key to encrypt a hash of your public key and other data >> to indicate that your private key is bound to your other data. >> >> You trust DMV/Passport Agency/etc. to validate your identity in the form >> of your government issued ID credentials, right? >> >> That doesn't give DMV/Passport Agency/etc. control over your face, but, >> it does allow them to indicate to others that your face is tied to your >> name, date of birth, etc. >> >> Owen >> >> On Jun 7, 2012, at 1:04 PM, -Hammer- wrote: >> >>> I gotta agree with Aaron here. What would be my motivation to "trust" an >>> open and public infrastructure? With my business or personal keys? >>> >>> -Hammer- >>> >>> "I was a normal American nerd" >>> -Jack Herer >>> >>> >>> >>> On 6/7/2012 2:37 PM, Aaron C. de Bruyn wrote: >>>> On Thu, Jun 7, 2012 at 12:24 PM, Owen DeLong wrote: >>>>>> Heck no to X.509. We'd run into the same issue we have right now--a >>>>>> select group of companies charging users to prove their identity. >>>>> Not if enough of us get behind CACERT. >>>> Yet again, another org (free or not) that is holding my identity >>>> hostage. >>>> Would you give cacert your SSH key and use them to log in to your >>>> Linux servers? I'd bet most *nix admins would shout "hell no!" >>>> >>>> So why would you make them the gateway for your online identity? >>>> >>>> -A >>>> >>>> >> >> > > From paul at paulgraydon.co.uk Thu Jun 7 17:12:09 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 07 Jun 2012 12:12:09 -1000 Subject: Configuration Systems In-Reply-To: <20785.1339105794@turing-police.cc.vt.edu> References: <20785.1339105794@turing-police.cc.vt.edu> Message-ID: <4FD12739.8080604@paulgraydon.co.uk> On 06/07/2012 11:49 AM, valdis.kletnieks at vt.edu wrote: > On Thu, 07 Jun 2012 11:51:51 -0700, Owen DeLong said: > >> This is a hard problem to solve. Not the least of the difficulties is the fact that >> if you ask 50 engineers to define "Cloud", you will get at least 100 definitions >> many of which are incompatible to the point of mutually exclusive. > "cloud" == "you rented in a colo, but have no clue where". Only if you're talking IaaS, and that's only a very vague and not necessarily accurate description of that too. When you start describing what cloud is you've also got to go into the realms of private clouds (using, for example, openstack), on your own infrastructure in your own datacenter. That's before you even start delving into PaaS, SaaS "clouds" etc. "Cloud" is a marketing term, not an engineering one. Paul From kauer at biplane.com.au Thu Jun 7 17:14:59 2012 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 08 Jun 2012 08:14:59 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <1339017457.2754.8.camel@karl> Message-ID: <1339107299.2754.42.camel@karl> On Thu, 2012-06-07 at 21:07 +0000, Dave Hart wrote: > Bzzt. With ARP, every IPv4 node on the link indicates each ARP packet > to the OS. With ND, only those nodes sharing the same last 24 bits of > the IPv6 address indicate the packet up the stack. The rest of the > IPv6 nodes filter the multicast in the NIC. Still not quite correct :-) The "filtering" is done by a MLD-aware switch, which will send multicast packets only to nodes that are listening to the appropriate multicast group. The filtering you describe is pretty much what ARP does - ALL nodes receive the packet, all but one ignore it. It depends on the platform whether the CPU that does the ignoring is just in the NIC or is in the node itself. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From davehart at gmail.com Thu Jun 7 17:27:53 2012 From: davehart at gmail.com (Dave Hart) Date: Thu, 7 Jun 2012 22:27:53 +0000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1339107299.2754.42.camel@karl> References: <1339017457.2754.8.camel@karl> <1339107299.2754.42.camel@karl> Message-ID: On Thu, Jun 7, 2012 at 10:14 PM, Karl Auer wrote: > On Thu, 2012-06-07 at 21:07 +0000, Dave Hart wrote: >> Bzzt. ?With ARP, every IPv4 node on the link indicates each ARP packet >> to the OS. ?With ND, only those nodes sharing the same last 24 bits of >> the IPv6 address indicate the packet up the stack. ?The rest of the >> IPv6 nodes filter the multicast in the NIC. > > Still not quite correct :-) > > The "filtering" is done by a MLD-aware switch, which will send multicast > packets only to nodes that are listening to the appropriate multicast > group. The filtering you describe is pretty much what ARP does - ALL > nodes receive the packet, all but one ignore it. It depends on the > platform whether the CPU that does the ignoring is just in the NIC or is > in the node itself. Karl, you seem to fail to understand how ethernet NICs are implemented in the real world. Ignoring the optional (but common) promiscuous mode support and various offloading, IPv4 ARP is sent as ethernet broadcast and the NIC hardware and driver is in no position to filter -- it must be done by the IP stack. In contrast, ND is sent as ethernet multicast which are filtered by receivers in hardware. Whether or not the switches are smart enough to filter is an implementation decision that has no bearing on the requirement to filter in the NIC hardware. Cheers, Dave Hart From casey at deccio.net Thu Jun 7 17:46:55 2012 From: casey at deccio.net (Casey Deccio) Date: Thu, 7 Jun 2012 15:46:55 -0700 Subject: sporadic IPv6 connectivity to forums.comcast.com Message-ID: I'm seeing sporadic IPv6 connectivity issues to forums.comcast.com: casey at rome$ curl -I6 forums.comcast.com HTTP/1.1 200 OK Date: Thu, 07 Jun 2012 21:48:37 GMT [snip...] casey at rome$ curl -I6 forums.comcast.com curl: (7) couldn't connect to host casey at rome:~$ traceroute6 forums.comcast.com traceroute to forums.comcast.com (2620:6a:8000:4::11) from 2001:470:21:31::adf5:492a, port 33434, from port 42309, 30 hops max, 60 byte packets 1 2001:470:21:31::1 (2001:470:21:31::1) 1.713 ms 1.922 ms 2.039 ms 2 2001:470:1f:b::1 (2001:470:1f:b::1) 10.575 ms 3.343 ms 3.147 ms 3 10gigabitethernet1-1.core1.sjc1.he.net (2001:470:1:7c::1) 6.855 ms 4.225 ms 4.252 ms 4 10gigabitethernet2-1.core1.sjc2.he.net (2001:470:0:55::2) 4.271 ms 14.442 ms 4.469 ms 5 sjo-eqx-s1-link.telia.net (2001:2000:3080:1b7::1) 5.385 ms 4.669 ms 4.434 ms 6 internap-ic-140172-sjo-bb1.c.telia.net (2001:2000:3080:17f::2) 4.702 ms 4.803 ms 4.848 ms 7 border1-bbnet2.sje.pnap.net (2600:c02:0:102::1:1) 5.175 ms 25.023 ms 4.808 ms 8 lithiumtechinc-2.border1.sje.pnap.net (2600:c02:1001:3::2) 9.445 ms 8.120 ms 7.804 ms 9 2620:6a:8000:4::11 (2620:6a:8000:4::11) 5.491 ms 5.712 ms 5.873 ms casey at rome:~$ traceroute6 forums.comcast.com traceroute to forums.comcast.com (2620:6a:8000:4::11) from 2001:470:21:31::adf5:492a, port 33434, from port 42311, 30 hops max, 60 byte packets 1 2001:470:21:31::1 (2001:470:21:31::1) 1.574 ms 1.514 ms 1.856 ms 2 2001:470:1f:b::1 (2001:470:1f:b::1) 2.882 ms 3.089 ms 14.462 ms 3 10gigabitethernet1-1.core1.sjc1.he.net (2001:470:1:7c::1) 4.573 ms 4.466 ms 6.683 ms 4 10gigabitethernet2-1.core1.sjc2.he.net (2001:470:0:55::2) 4.525 ms 10.401 ms 4.748 ms 5 sjo-eqx-s1-link.telia.net (2001:2000:3080:1b7::1) 4.794 ms 4.931 ms 4.406 ms 6 internap-ic-140172-sjo-bb1.c.telia.net (2001:2000:3080:17f::2) 4.837 ms 4.922 ms 4.527 ms 7 border1-bbnet1.sje.pnap.net (2600:c02:0:101::1:1) 5.884 ms 4.626 ms 5.037 ms 8 border3-bbnet2.sje.pnap.net (2600:c02:0:102::1:3) 3157.850 ms !H 3270.481 ms !H 3226.411 ms !H Is this perhaps a routing issue? Casey From randy at psg.com Thu Jun 7 17:49:18 2012 From: randy at psg.com (Randy Bush) Date: Thu, 07 Jun 2012 15:49:18 -0700 Subject: LinkedIn password database compromised In-Reply-To: <1339104959.27885.10.camel@home> References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> <1339104959.27885.10.camel@home> Message-ID: >> the 'single sign on' i encourage for the end using human beings i >> support is 1password and its ilk. it provides the user with one >> sign-on yet strongly encourages separation of identities and strong >> passwords for sites. > > Local repository of passwords, aggregation in a way. Right? Encrypted? > Open source? local repository good, i.e. the user owns and controls. others can not associate the user's different identities. (again, run the ghostery browser add-on) encrypted good, a bit protected from loss of laptop, a 'maid attack', etc. open source sure would be good randy From valdis.kletnieks at vt.edu Thu Jun 7 17:59:04 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 07 Jun 2012 18:59:04 -0400 Subject: Configuration Systems In-Reply-To: Your message of "Thu, 07 Jun 2012 12:12:09 -1000." <4FD12739.8080604@paulgraydon.co.uk> References: <20785.1339105794@turing-police.cc.vt.edu> <4FD12739.8080604@paulgraydon.co.uk> Message-ID: <24017.1339109944@turing-police.cc.vt.edu> On Thu, 07 Jun 2012 12:12:09 -1000, Paul Graydon said: > what cloud is you've also got to go into the realms of private clouds > (using, for example, openstack), on your own infrastructure in your own > datacenter. Same definition. The user I've provisioned still has no idea where I provisioned him. > That's before you even start delving into PaaS, SaaS "clouds" etc. Still the same definition. You have no idea where you're provisioned from. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From marka at isc.org Thu Jun 7 18:00:45 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 08 Jun 2012 09:00:45 +1000 Subject: LinkedIn password database compromised In-Reply-To: Your message of "Thu, 07 Jun 2012 09:36:18 -0400." <4FD0AE52.20602@alter3d.ca> References: <4FD004F0.4060606@deaddrop.org> <20120607132240.GO32960@teardrop.org> <4FD0AE52.20602@alter3d.ca> Message-ID: <20120607230045.98D40215BA84@drugs.dv.isc.org> In message <4FD0AE52.20602 at alter3d.ca>, Peter Kristolaitis writes: > On 6/7/2012 9:22 AM, James Snow wrote: > > On Wed, Jun 06, 2012 at 11:14:58PM -0700, Aaron C. de Bruyn wrote: > >> Imaging signing up for a site by putting in your email and pasting > >> your public key. > > Yes! Yes! Yes! > > > > I've been making this exact argument for about a year. It even retains > > the same "email a link" reset mechanism when someone needs to reset > > their key. > > > > A common counter-argument is, "But ordinary Internet users won't > > understand SSH keys." They don't need to! The idea is easily explained > > via a lock-and-key metaphor that people already understand. The UI for > > walking users through key creation is easily imagined. > > > > > > -Snow > > Oh yeah, I can just imagine that "lock and key" conversation now... > > "Imagine if the website has a lock on it, and you tell them what key you = > > want to use by giving them a copy." > "But if they have a copy of my key, couldn't they use it to open all of=20 > the other locks I've set up to use it?" > "(explain public key crypto)" > "(drool, distraction by the latest Facebook feature)" No. The correct metaphor is I have a key and a bunch of locks keyed to that lock. I give them a lock to install which only the key I have can open. > The other problem with this approach is that, as bad as trusting remote=20 > sites to do security properly is, I'm not sure that putting a "one key=20 > to rule them all" on users' machines is that much better, given the=20 > average user's penchant for installing malware on their machine because=20 > "FunnyMonkeyScreensaver.exe" sounded like such a good idea at the=20 > time... I suspect we'd see a huge wave of malware whose sole purpose=20 > is to steal public keys (and you KNOW users won't password-protect their = > private keys!). Actually it is a big win. You now have to compromise millions of machines to get millions of keys rather than a couple of machines to get millions of passwords. > Plus, now you have the problem of users not being able = > to login to their favourite websites when they're using a friend's=20 > computer, internet cafe, etc, unless they've remembered to bring a copy=20 > of their private key with them. That is a real issue. > I think public key auth for websites is a great idea for geeks who=20 > understand the benefits, limitations and security concerns, but I have=20 > serious doubts that it would hold up when subjected to the "idiot test". > > - Pete -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joly at punkcast.com Thu Jun 7 18:14:32 2012 From: joly at punkcast.com (Joly MacFie) Date: Thu, 7 Jun 2012 19:14:32 -0400 Subject: AAAA's for www.netflix.com In-Reply-To: <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> <20120607165818.GA30416@srv03.cluenet.de> <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> Message-ID: well, something appears to be working.. http://www.betterbroadbandblog.com/2012/06/world-ipv6-daywe-have-liftoff/ Netflix moved up to second in the IPv6 list ? as noted above, Netflix has been rolling out IPv6 coverage over the last few weeks. Interestingly, it appears as if Netflix may have created its own IPv6-specific domain which is responsible for almost a third of all IPv6 traffic. If this is the case it might not be in full compliance with the spirit of World IPv6 Day, as the aim should have been for Netflix to operate one single domain with both AAAA records for IPv6 and A records for IPv4. On Thu, Jun 7, 2012 at 6:04 PM, Mark Andrews wrote: > > In message <20120607165818.GA30416 at srv03.cluenet.de>, Daniel Roesen > writes: > > On Thu, Jun 07, 2012 at 07:52:29AM -0600, Dave Temkin wrote: > > > Just to close the loop on this - UltraDNS has an issue with CNAMEs and > > > their Directional DNS service. We (Netflix) have applied a workaround > and > > > it appears stable. > > > > Hm, looking at http://v6launch.ripe.net/, whatever you changed didn't > > improve visibility of the AAAA, but decreased it. > > TTL's of zero don't help. The A query has a TTL of 3600 in the > response the AAAA query has a zero TTL. This is rocket science. > This isn't hard to do correctly. How to handle CNAMEs has been > specified 1/4 of a century. > > > Best regards, > > Daniel > > > > -- > > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From randy at psg.com Thu Jun 7 18:24:11 2012 From: randy at psg.com (Randy Bush) Date: Thu, 07 Jun 2012 16:24:11 -0700 Subject: LinkedIn password database compromised In-Reply-To: <20120607230045.98D40215BA84@drugs.dv.isc.org> References: <4FD004F0.4060606@deaddrop.org> <20120607132240.GO32960@teardrop.org> <4FD0AE52.20602@alter3d.ca> Message-ID: > Plus, now you have the problem of users not being able to login to > their favourite websites when they're using a friend's computer, > internet cafe, etc, unless they've remembered to bring a copy of their > private key with them. this is a feature, not a bug. you should be explaining to them why they should never type passwords on another's keyboard, log on to anything from an internet cafe, ... randy From paul at paulgraydon.co.uk Thu Jun 7 18:30:53 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 07 Jun 2012 13:30:53 -1000 Subject: Configuration Systems In-Reply-To: <24017.1339109944@turing-police.cc.vt.edu> References: <20785.1339105794@turing-police.cc.vt.edu> <4FD12739.8080604@paulgraydon.co.uk> <24017.1339109944@turing-police.cc.vt.edu> Message-ID: <4FD139AD.2010505@paulgraydon.co.uk> On 06/07/2012 12:59 PM, valdis.kletnieks at vt.edu wrote: > On Thu, 07 Jun 2012 12:12:09 -1000, Paul Graydon said: >> what cloud is you've also got to go into the realms of private clouds >> (using, for example, openstack), on your own infrastructure in your own >> datacenter. > Same definition. The user I've provisioned still has no idea where I provisioned him. > >> That's before you even start delving into PaaS, SaaS "clouds" etc. > Still the same definition. You have no idea where you're provisioned from. Your original definition: "cloud" == "you rented a colo, but have no clue where". I know exactly where my colo is. I know exactly where my physical servers are. If I run a private cloud on those servers and provision stuff there, I'll still know exactly where my colo is and I'll still know where my "cloud" infrastructure is deployed (http://en.wikipedia.org/wiki/Cloud_computing#Private_cloud) Even that wiki page doesn't quite go far enough in defining cloud, at least compared to stuff people sell as "cloud" (as I said, cloud is a marketing term, not an engineering one. Its accuracy is negligible) Paul From dave at temk.in Thu Jun 7 18:43:41 2012 From: dave at temk.in (David Temkin) Date: Thu, 7 Jun 2012 16:43:41 -0700 Subject: AAAA's for www.netflix.com In-Reply-To: References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> <20120607165818.GA30416@srv03.cluenet.de> <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> Message-ID: Joly, What do you mean? www.netflix.com is dual stacked, which represents availability of our website (and PC/Mac streaming clients) to100% of our users who have IPv6. -Dave On Thursday, June 7, 2012, Joly MacFie wrote: > well, something appears to be working.. > > http://www.betterbroadbandblog.com/2012/06/world-ipv6-daywe-have-liftoff/ > > Netflix moved up to second in the IPv6 list ? as noted above, Netflix has > been rolling out IPv6 coverage over the last few weeks. Interestingly, it > appears as if Netflix may have created its own IPv6-specific domain which > is responsible for almost a third of all IPv6 traffic. If this is the case > it might not be in full compliance with the spirit of World IPv6 Day, as > the aim should have been for Netflix to operate one single domain with both > AAAA records for IPv6 and A records for IPv4. > > On Thu, Jun 7, 2012 at 6:04 PM, Mark Andrews > > wrote: > > > > > In message <20120607165818.GA30416 at srv03.cluenet.de >, > Daniel Roesen > > writes: > > > On Thu, Jun 07, 2012 at 07:52:29AM -0600, Dave Temkin wrote: > > > > Just to close the loop on this - UltraDNS has an issue with CNAMEs > and > > > > their Directional DNS service. We (Netflix) have applied a > workaround > > and > > > > it appears stable. > > > > > > Hm, looking at http://v6launch.ripe.net/, whatever you changed didn't > > > improve visibility of the AAAA, but decreased it. > > > > TTL's of zero don't help. The A query has a TTL of 3600 in the > > response the AAAA query has a zero TTL. This is rocket science. > > This isn't hard to do correctly. How to handle CNAMEs has been > > specified 1/4 of a century. > > > > > Best regards, > > > Daniel > > > > > > -- > > > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- > PGP: 0xA85C8AA0 > > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > > > > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org > -------------------------------------------------------------- > - > From John_Brzozowski at Cable.Comcast.com Thu Jun 7 19:11:55 2012 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Fri, 8 Jun 2012 00:11:55 +0000 Subject: sporadic IPv6 connectivity to forums.comcast.com In-Reply-To: References: Message-ID: We are investigating. -------- Original Message -------- From: Casey Deccio Sent: Thu, 07/06/2012 18:47 To: nanog at nanog.org CC: Subject: sporadic IPv6 connectivity to forums.comcast.com I'm seeing sporadic IPv6 connectivity issues to forums.comcast.com: casey at rome$ curl -I6 forums.comcast.com HTTP/1.1 200 OK Date: Thu, 07 Jun 2012 21:48:37 GMT [snip...] casey at rome$ curl -I6 forums.comcast.com curl: (7) couldn't connect to host casey at rome:~$ traceroute6 forums.comcast.com traceroute to forums.comcast.com (2620:6a:8000:4::11) from 2001:470:21:31::adf5:492a, port 33434, from port 42309, 30 hops max, 60 byte packets 1 2001:470:21:31::1 (2001:470:21:31::1) 1.713 ms 1.922 ms 2.039 ms 2 2001:470:1f:b::1 (2001:470:1f:b::1) 10.575 ms 3.343 ms 3.147 ms 3 10gigabitethernet1-1.core1.sjc1.he.net (2001:470:1:7c::1) 6.855 ms 4.225 ms 4.252 ms 4 10gigabitethernet2-1.core1.sjc2.he.net (2001:470:0:55::2) 4.271 ms 14.442 ms 4.469 ms 5 sjo-eqx-s1-link.telia.net (2001:2000:3080:1b7::1) 5.385 ms 4.669 ms 4.434 ms 6 internap-ic-140172-sjo-bb1.c.telia.net (2001:2000:3080:17f::2) 4.702 ms 4.803 ms 4.848 ms 7 border1-bbnet2.sje.pnap.net (2600:c02:0:102::1:1) 5.175 ms 25.023 ms 4.808 ms 8 lithiumtechinc-2.border1.sje.pnap.net (2600:c02:1001:3::2) 9.445 ms 8.120 ms 7.804 ms 9 2620:6a:8000:4::11 (2620:6a:8000:4::11) 5.491 ms 5.712 ms 5.873 ms casey at rome:~$ traceroute6 forums.comcast.com traceroute to forums.comcast.com (2620:6a:8000:4::11) from 2001:470:21:31::adf5:492a, port 33434, from port 42311, 30 hops max, 60 byte packets 1 2001:470:21:31::1 (2001:470:21:31::1) 1.574 ms 1.514 ms 1.856 ms 2 2001:470:1f:b::1 (2001:470:1f:b::1) 2.882 ms 3.089 ms 14.462 ms 3 10gigabitethernet1-1.core1.sjc1.he.net (2001:470:1:7c::1) 4.573 ms 4.466 ms 6.683 ms 4 10gigabitethernet2-1.core1.sjc2.he.net (2001:470:0:55::2) 4.525 ms 10.401 ms 4.748 ms 5 sjo-eqx-s1-link.telia.net (2001:2000:3080:1b7::1) 4.794 ms 4.931 ms 4.406 ms 6 internap-ic-140172-sjo-bb1.c.telia.net (2001:2000:3080:17f::2) 4.837 ms 4.922 ms 4.527 ms 7 border1-bbnet1.sje.pnap.net (2600:c02:0:101::1:1) 5.884 ms 4.626 ms 5.037 ms 8 border3-bbnet2.sje.pnap.net (2600:c02:0:102::1:3) 3157.850 ms !H 3270.481 ms !H 3226.411 ms !H Is this perhaps a routing issue? Casey From sean at seanharlow.info Thu Jun 7 19:25:51 2012 From: sean at seanharlow.info (Sean Harlow) Date: Thu, 7 Jun 2012 20:25:51 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <20120607132240.GO32960@teardrop.org> <4FD0AE52.20602@alter3d.ca> Message-ID: On Jun 7, 2012, at 19:24, Randy Bush wrote: > this is a feature, not a bug. you should be explaining to them why they > should never type passwords on another's keyboard, log on to anything > from an internet cafe, ... And this is where you lose the user. It doesn't matter that you're entirely right about the security risks of doing so, but real-world security is all about finding a balance with usability. Situations where the data really does need to be secure are great for mandating public key authentication, as you point out it raises a significant technical barrier to the unskilled user preventing them from even attempting to access it from anywhere they shouldn't. That said, I doubt anyone but the most insane of security geeks are using it for their personal email. If the value to the person of being able to access their data from $random_computer exceeds the perceived risk, they'll do it if they can. --- Sean Harlow sean at seanharlow.info From randy at psg.com Thu Jun 7 19:30:06 2012 From: randy at psg.com (Randy Bush) Date: Thu, 07 Jun 2012 17:30:06 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <20120607132240.GO32960@teardrop.org> <4FD0AE52.20602@alter3d.ca> Message-ID: >> this is a feature, not a bug. you should be explaining to them why >> they should never type passwords on another's keyboard, log on to >> anything from an internet cafe, ... > And this is where you lose the user. actually, not. it's like safe sex, an anology they understand. you may be tempted over the line, but you know you may regret it for the rest of your shortened life. of course, having net on tablets and ip phones helps. randy From kauer at biplane.com.au Thu Jun 7 19:48:12 2012 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 08 Jun 2012 10:48:12 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <1339017457.2754.8.camel@karl> <1339107299.2754.42.camel@karl> Message-ID: <1339116492.2754.162.camel@karl> On Thu, 2012-06-07 at 22:27 +0000, Dave Hart wrote: > Karl, you seem to fail to understand how ethernet NICs are implemented > in the real world. Ignoring the optional (but common) promiscuous > mode support and various offloading, IPv4 ARP is sent as ethernet > broadcast and the NIC hardware and driver is in no position to filter > -- it must be done by the IP stack. In contrast, ND is sent as > ethernet multicast which are filtered by receivers in hardware. > Whether or not the switches are smart enough to filter is an > implementation decision that has no bearing on the requirement to > filter in the NIC hardware. I'm the first to admit that I often don't know stuff. One good reason to be on the NANOG mailing list! But in this case... Yes - whether with ARP or ND, any node has to filter out the packets that do not apply to it (whether it's done by the NIC or the host CPU is another question, not relevant here). But in a properly switched IPv6 network, many/most ND packets do not arrive at most nodes' network interfaces at all, so those nodes have no filtering work to do. Yes, the nodes that DO get a packet - those listening on the relevant multicast group, often a solicited node multicast group - DO need to filter out the NDs that don't apply to them, but the point is that a vastly reduced number of nodes are thus inconvenienced compared. The original post posited that ND could cause as much traffic as ARP. My point is that it probably doesn't, because the ND packets will only be seen on the specific switch ports belonging to those nodes that are listening to the relevant multicast groups, and only those nodes will actually receive the ND packets. In contrast to ARP, which is broadcast, always, to all nodes, and thus goes out every switch port in the broadcast domain. This is pretty much the *point* of using multicast instead of broadcast. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From marka at isc.org Thu Jun 7 20:08:06 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 08 Jun 2012 11:08:06 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: Your message of "Fri, 08 Jun 2012 10:48:12 +1000." <1339116492.2754.162.camel@karl> References: <1339017457.2754.8.camel@karl> <1339107299.2754.42.camel@karl> <1339116492.2754.162.camel@karl> Message-ID: <20120608010806.4D3CF215D358@drugs.dv.isc.org> In message <1339116492.2754.162.camel at karl>, Karl Auer writes: > > --=-ebOzahzuucm9tstf70zM > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Thu, 2012-06-07 at 22:27 +0000, Dave Hart wrote: > > Karl, you seem to fail to understand how ethernet NICs are implemented > > in the real world. Ignoring the optional (but common) promiscuous > > mode support and various offloading, IPv4 ARP is sent as ethernet > > broadcast and the NIC hardware and driver is in no position to filter > > -- it must be done by the IP stack. In contrast, ND is sent as > > ethernet multicast which are filtered by receivers in hardware. > > Whether or not the switches are smart enough to filter is an > > implementation decision that has no bearing on the requirement to > > filter in the NIC hardware. > > I'm the first to admit that I often don't know stuff. One good reason to > be on the NANOG mailing list! But in this case... > > Yes - whether with ARP or ND, any node has to filter out the packets > that do not apply to it (whether it's done by the NIC or the host CPU is > another question, not relevant here). > > But in a properly switched IPv6 network, many/most ND packets do not > arrive at most nodes' network interfaces at all, so those nodes have no > filtering work to do. Yes, the nodes that DO get a packet - those > listening on the relevant multicast group, often a solicited node > multicast group - DO need to filter out the NDs that don't apply to > them, but the point is that a vastly reduced number of nodes are thus > inconvenienced compared. > > The original post posited that ND could cause as much traffic as ARP. My > point is that it probably doesn't, because the ND packets will only be > seen on the specific switch ports belonging to those nodes that are > listening to the relevant multicast groups, and only those nodes will > actually receive the ND packets. In contrast to ARP, which is broadcast, > always, to all nodes, and thus goes out every switch port in the > broadcast domain. > > This is pretty much the *point* of using multicast instead of broadcast. The point of multicast is be able to reject traffic sooner rather than later. Running IPv6 with a nic that doesn't support several multicast addresses is a real pain which I know from experience. It can however be done. > Regards, K. > > --=20 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dr at cluenet.de Thu Jun 7 20:19:10 2012 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 8 Jun 2012 03:19:10 +0200 Subject: AAAA's for www.netflix.com In-Reply-To: References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> <20120607165818.GA30416@srv03.cluenet.de> <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> Message-ID: <20120608011910.GA16069@srv03.cluenet.de> On Thu, Jun 07, 2012 at 04:43:41PM -0700, David Temkin wrote: > What do you mean? www.netflix.com is dual stacked, which represents > availability of our website (and PC/Mac streaming clients) to100% of our > users who have IPv6. The zero TTL on the CNAME an AAAA RRs makes www.netflix.com zero-stacked at least for some resolvers: $ dig @pdns3.ultradns.org www.netflix.com. A +norec +short wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. $ dig @pdns3.ultradns.org www.netflix.com. AAAA +norec +short dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. $ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec $ Resolving www.netflix.com using ANY RRtype fails with an empty answer section in the DNS response. This DNS trickery seems to be from the "taking a shower, trying not to get wet" department. And has adverse effects in corner cases. While playing around, I had periods of time where I couldn't resolve the FQDN at all, possibly due some caching of the empty response. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Thu Jun 7 20:24:34 2012 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 8 Jun 2012 03:24:34 +0200 Subject: AAAA's for www.netflix.com In-Reply-To: <20120608011910.GA16069@srv03.cluenet.de> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> <20120607165818.GA30416@srv03.cluenet.de> <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> <20120608011910.GA16069@srv03.cluenet.de> Message-ID: <20120608012434.GB16069@srv03.cluenet.de> On Fri, Jun 08, 2012 at 03:19:10AM +0200, Daniel Roesen wrote: > The zero TTL on the CNAME an AAAA RRs makes www.netflix.com > zero-stacked at least for some resolvers: Correction... I don't really know wether the zero TTL on the CNAME provokes problems, but not returning any RR on ANY RRtype queries seems to do. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From kauer at biplane.com.au Thu Jun 7 21:01:04 2012 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 08 Jun 2012 12:01:04 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <20120608010806.4D3CF215D358@drugs.dv.isc.org> References: <1339017457.2754.8.camel@karl> <1339107299.2754.42.camel@karl> <1339116492.2754.162.camel@karl> <20120608010806.4D3CF215D358@drugs.dv.isc.org> Message-ID: <1339120864.2754.168.camel@karl> On Fri, 2012-06-08 at 11:08 +1000, Mark Andrews wrote: > > This is pretty much the *point* of using multicast instead of > broadcast. > > The point of multicast is be able to reject traffic sooner rather > than later. Well - yes - and my description was of how, when properly configured and on the right hardware, unwanted multicast IPv6 packets do not even reach the NIC. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From marka at isc.org Thu Jun 7 21:11:20 2012 From: marka at isc.org (Mark Andrews) Date: Fri, 08 Jun 2012 12:11:20 +1000 Subject: AAAA's for www.netflix.com In-Reply-To: Your message of "Fri, 08 Jun 2012 03:19:10 +0200." <20120608011910.GA16069@srv03.cluenet.de> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> <20120607165818.GA30416@srv03.cluenet.de> <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> <20120608011910.GA16069@srv03.cluenet.de> Message-ID: <20120608021120.31A0C215D5AB@drugs.dv.isc.org> In message <20120608011910.GA16069 at srv03.cluenet.de>, Daniel Roesen writes: > On Thu, Jun 07, 2012 at 04:43:41PM -0700, David Temkin wrote: > > What do you mean? www.netflix.com is dual stacked, which represents > > availability of our website (and PC/Mac streaming clients) to100% of our > > users who have IPv6. > > The zero TTL on the CNAME an AAAA RRs makes www.netflix.com > zero-stacked at least for some resolvers: > > $ dig @pdns3.ultradns.org www.netflix.com. A +norec +short > wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. > $ dig @pdns3.ultradns.org www.netflix.com. AAAA +norec +short > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. > $ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec > $ > > Resolving www.netflix.com using ANY RRtype fails with an empty answer > section in the DNS response. Which is just plain BROKEN. > This DNS trickery seems to be from the "taking a shower, trying not > to get wet" department. And has adverse effects in corner cases. While > playing around, I had periods of time where I couldn't resolve the FQDN > at all, possibly due some caching of the empty response. It's not DNS trickery. It's not reading the RFC or doing any testing for common cases. Not every query has type A. Way too many load balancers get the answers to anything other than A queries wrong. If your load balancer get answers to queries other than A wrong demand your money back. This sort of !@$E in authoritative servers makes it hard for recursive servers to do the right thing. pandora.tv servers are the poster child for getting it wrong currently. * They don't set "aa" as per RFC 103[45]. (If you set it in the query they clear it.) * They don't clear "ad" as per RFC 103[45]. * They have extra data after the DNS response. * They send back malformed responses to EDNS queries. bsdi# dig9 ns pandora.tv @N1.pandora.tv +noedns +norec ; <<>> DiG 9.9.1-P1 <<>> ns pandora.tv @N1.pandora.tv +noedns +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36153 ;; flags: qr ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: Messages has 27 extra bytes at end ;; QUESTION SECTION: ;pandora.tv. IN NS ;; ANSWER SECTION: pandora.tv. 300 IN NS N1.pandora.tv. pandora.tv. 300 IN NS N2.pandora.tv. pandora.tv. 300 IN NS N15.pandora.tv. pandora.tv. 300 IN NS N16.pandora.tv. pandora.tv. 300 IN NS N17.pandora.tv. ;; Query time: 385 msec ;; SERVER: 61.111.8.236#53(61.111.8.236) ;; WHEN: Fri Jun 8 11:56:22 2012 ;; MSG SIZE rcvd: 143 bsdi# dig9 ns pandora.tv @N1.pandora.tv +edns=0 +norec ;; Got bad packet: FORMERR 143 bytes cd c9 80 a0 00 01 00 05 00 00 00 01 07 70 61 6e .............pan 64 6f 72 61 02 74 76 00 00 02 00 01 c0 0c 00 02 dora.tv......... 00 01 00 00 01 2c 00 05 02 4e 31 c0 0c c0 0c 00 .....,...N1..... 02 00 01 00 00 01 2c 00 05 02 4e 32 c0 0c c0 0c ......,...N2.... 00 02 00 01 00 00 01 2c 00 06 03 4e 31 35 c0 0c .......,...N15.. c0 0c 00 02 00 01 00 00 01 2c 00 06 03 4e 31 36 .........,...N16 c0 0c c0 0c 00 02 00 01 00 00 01 2c 00 06 03 4e ...........,...N 31 37 c0 0c 00 00 00 00 00 00 00 00 00 00 00 00 17.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............... bsdi# Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dr at cluenet.de Thu Jun 7 21:23:33 2012 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 8 Jun 2012 04:23:33 +0200 Subject: AAAA's for www.netflix.com In-Reply-To: <20120608021120.31A0C215D5AB@drugs.dv.isc.org> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> <20120607165818.GA30416@srv03.cluenet.de> <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> <20120608011910.GA16069@srv03.cluenet.de> <20120608021120.31A0C215D5AB@drugs.dv.isc.org> Message-ID: <20120608022333.GA12126@srv03.cluenet.de> On Fri, Jun 08, 2012 at 12:11:20PM +1000, Mark Andrews wrote: > > $ dig @pdns3.ultradns.org www.netflix.com. A +norec +short > > wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. > > $ dig @pdns3.ultradns.org www.netflix.com. AAAA +norec +short > > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. > > $ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec > > $ > > > > Resolving www.netflix.com using ANY RRtype fails with an empty answer > > section in the DNS response. > > Which is just plain BROKEN. Yup. > > This DNS trickery seems to be from the "taking a shower, trying not > > to get wet" department. And has adverse effects in corner cases. While > > playing around, I had periods of time where I couldn't resolve the FQDN > > at all, possibly due some caching of the empty response. > > It's not DNS trickery. The "trickery" is returning different CNAMEs for QTYPE=A and QTYPE=AAAA. I'm not sure what's the goal of that is, but it's 4am here so I have an excuse of not seeing the light. :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From davehart at gmail.com Thu Jun 7 22:08:33 2012 From: davehart at gmail.com (Dave Hart) Date: Fri, 8 Jun 2012 03:08:33 +0000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1339116492.2754.162.camel@karl> References: <1339017457.2754.8.camel@karl> <1339107299.2754.42.camel@karl> <1339116492.2754.162.camel@karl> Message-ID: On Fri, Jun 8, 2012 at 12:48 AM, Karl Auer wrote: > Yes - whether with ARP or ND, any node has to filter out the packets > that do not apply to it (whether it's done by the NIC or the host CPU is > another question, not relevant here). It is relevant to the question of the scalability of large L2 networks. With IPv4, ARP presents not only a network capacity issue, but also a host capacity issue as every node expends software resources processing every broadcast ARP. With ND, only a tiny fraction of hosts expend any software capacity processing a given multicast packet, thanks to ethernet NIC's hardware filtering of received multicasts -- with or without multicast-snooping switches. > The original post posited that ND could cause as much traffic as ARP. My > point is that it probably doesn't, because the ND packets will only be > seen on the specific switch ports belonging to those nodes that are > listening to the relevant multicast groups, and only those nodes will > actually receive the ND packets. In contrast to ARP, which is broadcast, > always, to all nodes, and thus goes out every switch port in the > broadcast domain. > > This is pretty much the *point* of using multicast instead of broadcast. I agree. From ops.lists at gmail.com Thu Jun 7 22:53:44 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 8 Jun 2012 09:23:44 +0530 Subject: Configuration Systems In-Reply-To: <4FD139AD.2010505@paulgraydon.co.uk> References: <20785.1339105794@turing-police.cc.vt.edu> <4FD12739.8080604@paulgraydon.co.uk> <24017.1339109944@turing-police.cc.vt.edu> <4FD139AD.2010505@paulgraydon.co.uk> Message-ID: It is like that supreme court judge who defined porn as "i know it when I see it" On Fri, Jun 8, 2012 at 5:00 AM, Paul Graydon wrote: > Your original definition: "cloud" == "you rented a colo, but have no clue > where". ?I know exactly where my colo is. ?I know exactly where my physical > servers are. ?If I run a private cloud on those servers and provision stuff > there, I'll still know exactly where my colo is and I'll still know where my > "cloud" infrastructure is deployed > (http://en.wikipedia.org/wiki/Cloud_computing#Private_cloud) ?Even that wiki > page doesn't quite go far enough in defining cloud, at least compared to > stuff people sell as "cloud" (as I said, cloud is a marketing term, not an > engineering one. ?Its accuracy is negligible) -- Suresh Ramasubramanian (ops.lists at gmail.com) From kauer at biplane.com.au Thu Jun 7 23:31:09 2012 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 08 Jun 2012 14:31:09 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <1339017457.2754.8.camel@karl> <1339107299.2754.42.camel@karl> <1339116492.2754.162.camel@karl> Message-ID: <1339129869.2754.316.camel@karl> On Fri, 2012-06-08 at 03:08 +0000, Dave Hart wrote: > networks. With IPv4, ARP presents not only a network capacity issue, > but also a host capacity issue as every node expends software > resources processing every broadcast ARP. With ND, only a tiny > fraction of hosts expend any software capacity processing a given > multicast packet, thanks to ethernet NIC's hardware filtering of > received multicasts -- with or without multicast-snooping switches. So we are actually sort of agreeing. That's a relief :-) However, preventing packets getting to the NICs *at all* is a pretty big win, because even if a clever NIC can prevent a host CPU being interrupted, the packet was still wasting bandwidth on the path to the NIC. I would go so far as to say that MLD snooping makes the NIC side of things almost irrelevant. Almost :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From dave at temk.in Thu Jun 7 23:31:22 2012 From: dave at temk.in (David Temkin) Date: Fri, 08 Jun 2012 00:31:22 -0400 Subject: AAAA's for www.netflix.com In-Reply-To: <20120608022333.GA12126@srv03.cluenet.de> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> <20120607165818.GA30416@srv03.cluenet.de> <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> <20120608011910.GA16069@srv03.cluenet.de> <20120608021120.31A0C215D5AB@drugs.dv.isc.org> <20120608022333.GA12126@srv03.cluenet.de> Message-ID: <4FD1801A.8050902@temk.in> On 6/7/12 10:23 PM, Daniel Roesen wrote: > On Fri, Jun 08, 2012 at 12:11:20PM +1000, Mark Andrews wrote: >>> $ dig @pdns3.ultradns.org www.netflix.com. A +norec +short >>> wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. >>> $ dig @pdns3.ultradns.org www.netflix.com. AAAA +norec +short >>> dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. >>> $ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec >>> $ >>> >>> Resolving www.netflix.com using ANY RRtype fails with an empty answer >>> section in the DNS response. >> Which is just plain BROKEN. > Yup. > >>> This DNS trickery seems to be from the "taking a shower, trying not >>> to get wet" department. And has adverse effects in corner cases. While >>> playing around, I had periods of time where I couldn't resolve the FQDN >>> at all, possibly due some caching of the empty response. >> It's not DNS trickery. > The "trickery" is returning different CNAMEs for QTYPE=A and QTYPE=AAAA. > I'm not sure what's the goal of that is, but it's 4am here so I have an > excuse of not seeing the light. :) > > Best regards, > Daniel > We've confirmed that UltraDNS had "additional" issues caused by the push that they fixed for the previously reported problem. We are actively engaged with them to come to a resolution. -Dave From joly at punkcast.com Fri Jun 8 00:19:56 2012 From: joly at punkcast.com (Joly MacFie) Date: Fri, 8 Jun 2012 01:19:56 -0400 Subject: AAAA's for www.netflix.com In-Reply-To: <4FD1801A.8050902@temk.in> References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> <20120607165818.GA30416@srv03.cluenet.de> <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> <20120608011910.GA16069@srv03.cluenet.de> <20120608021120.31A0C215D5AB@drugs.dv.isc.org> <20120608022333.GA12126@srv03.cluenet.de> <4FD1801A.8050902@temk.in> Message-ID: > > Netflix may have created its own IPv6-specific domain which is responsible > for almost a third of all IPv6 traffic. If this is the case it might not be > in full compliance with the spirit of World IPv6 Day, as the aim should > have been for Netflix to operate one single domain with both AAAA records > for IPv6 and A records for IPv4. What about that? j On Fri, Jun 8, 2012 at 12:31 AM, David Temkin wrote: > On 6/7/12 10:23 PM, Daniel Roesen wrote: >> >> On Fri, Jun 08, 2012 at 12:11:20PM +1000, Mark Andrews wrote: >>>> >>>> $ dig @pdns3.ultradns.org www.netflix.com. A +norec +short >>>> wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. >>>> $ dig @pdns3.ultradns.org www.netflix.com. AAAA +norec +short >>>> dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com. >>>> $ dig @pdns3.ultradns.org www.netflix.com. ANY +short +norec >>>> $ >>>> >>>> Resolving www.netflix.com using ANY RRtype fails with an empty answer >>>> section in the DNS response. >>> >>> Which is just plain BROKEN. >> >> Yup. >> >>>> This DNS trickery seems to be from the "taking a shower, trying not >>>> to get wet" department. And has adverse effects in corner cases. While >>>> playing around, I had periods of time where I couldn't resolve the FQDN >>>> at all, possibly due some caching of the empty response. >>> >>> It's not DNS trickery. >> >> The "trickery" is returning different CNAMEs for QTYPE=A and QTYPE=AAAA. >> I'm not sure what's the goal of that is, but it's 4am here so I have an >> excuse of not seeing the light. :) >> >> Best regards, >> Daniel >> > We've confirmed that UltraDNS had "additional" issues caused by the push > that they fixed for the previously reported problem. We are actively > engaged with them to come to a resolution. > > -Dave > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From owen at delong.com Fri Jun 8 00:24:00 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2012 22:24:00 -0700 Subject: Configuration Systems In-Reply-To: References: <20785.1339105794@turing-police.cc.vt.edu> <4FD12739.8080604@paulgraydon.co.uk> <24017.1339109944@turing-police.cc.vt.edu> <4FD139AD.2010505@paulgraydon.co.uk> Message-ID: By my count, we now have 3 engineers that have chimed in and somewhere between 5 and 6 definitions. Q.E. D. Owen On Jun 7, 2012, at 8:53 PM, Suresh Ramasubramanian wrote: > It is like that supreme court judge who defined porn as "i know it > when I see it" > > On Fri, Jun 8, 2012 at 5:00 AM, Paul Graydon wrote: >> Your original definition: "cloud" == "you rented a colo, but have no clue >> where". I know exactly where my colo is. I know exactly where my physical >> servers are. If I run a private cloud on those servers and provision stuff >> there, I'll still know exactly where my colo is and I'll still know where my >> "cloud" infrastructure is deployed >> (http://en.wikipedia.org/wiki/Cloud_computing#Private_cloud) Even that wiki >> page doesn't quite go far enough in defining cloud, at least compared to >> stuff people sell as "cloud" (as I said, cloud is a marketing term, not an >> engineering one. Its accuracy is negligible) > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) From valdis.kletnieks at vt.edu Fri Jun 8 00:37:06 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 08 Jun 2012 01:37:06 -0400 Subject: Configuration Systems In-Reply-To: Your message of "Thu, 07 Jun 2012 13:30:53 -1000." <4FD139AD.2010505@paulgraydon.co.uk> References: <20785.1339105794@turing-police.cc.vt.edu> <4FD12739.8080604@paulgraydon.co.uk> <24017.1339109944@turing-police.cc.vt.edu> <4FD139AD.2010505@paulgraydon.co.uk> Message-ID: <16588.1339133826@turing-police.cc.vt.edu> On Thu, 07 Jun 2012 13:30:53 -1000, Paul Graydon said: > Your original definition: "cloud" == "you rented a colo, but have no > clue where". I know exactly where my colo is. I know exactly where my > physical servers are. If I run a private cloud on those servers and > provision stuff there, I'll still know exactly where my colo is and I'll > still know where my "cloud" infrastructure is deployed I posit the thesis that if you know where it is, it's not really a cloud, it's just a server farm with a severe attack of buzzwords. The whole point of "cloud" is that you've made "where" Somebody Else's Problem - and if you know where it is because you're still managing it yourself, it isn't an SEP. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From joelja at bogus.com Fri Jun 8 02:06:45 2012 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 08 Jun 2012 00:06:45 -0700 Subject: Configuration Systems In-Reply-To: References: <20785.1339105794@turing-police.cc.vt.edu> <4FD12739.8080604@paulgraydon.co.uk> <24017.1339109944@turing-police.cc.vt.edu> <4FD139AD.2010505@paulgraydon.co.uk> Message-ID: <4FD1A485.2000202@bogus.com> On 6/7/12 20:53 , Suresh Ramasubramanian wrote: > It is like that supreme court judge who defined porn as "i know it > when I see it" http://en.wikipedia.org/wiki/Jacobellis_v._Ohio a case which is notable in this context for having four differing majority opinions. > On Fri, Jun 8, 2012 at 5:00 AM, Paul Graydon wrote: >> Your original definition: "cloud" == "you rented a colo, but have no clue >> where". I know exactly where my colo is. I know exactly where my physical >> servers are. If I run a private cloud on those servers and provision stuff >> there, I'll still know exactly where my colo is and I'll still know where my >> "cloud" infrastructure is deployed >> (http://en.wikipedia.org/wiki/Cloud_computing#Private_cloud) Even that wiki >> page doesn't quite go far enough in defining cloud, at least compared to >> stuff people sell as "cloud" (as I said, cloud is a marketing term, not an >> engineering one. Its accuracy is negligible) > > > From rsk at gsp.org Fri Jun 8 06:21:17 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 8 Jun 2012 07:21:17 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <4FD0DC6C.9060502@deaddrop.org> <1339104959.27885.10.camel@home> Message-ID: <20120608112117.GA24920@gsp.org> On Thu, Jun 07, 2012 at 03:49:18PM -0700, Randy Bush wrote: > open source sure would be good I think it's mandatory. It's the only way we can have even modest trust that it does what it claims to do. And...as the last week's events have shown us...vendor-signed software sometimes isn't. ---rsk From mysidia at gmail.com Fri Jun 8 07:09:53 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 8 Jun 2012 07:09:53 -0500 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: On 6/7/12, Aaron C. de Bruyn wrote: >> A TLS + Client-Side X.509 Certificate for every user. > Heck no to X.509. We'd run into the same issue we have right now--a > select group of companies charging users to prove their identity. The PKI infrastructure and authority validation components are not required. Even if they were -- anyone can setup a PKI infrastructure, the problem is trust. Self-signed certificates are just fine for this application. The authentication credential stored on the server for the user, can simply be the public key of the user's certificate, and the certificate hash. There's no need for the TLS server to verify the client cert is issued by a recognized authority; although it would be nice for there to be Free X.509 certificate authorities to issue a signed TLS cert for E-MAIL address authentication. This would allow websites to accept user signup without a need to spam the user with additional "Click this link here to prove that this is actually your real e-mail address". It should ideally be integrated with the web browser. The user should be prompted to create their certificate by their web browser, and given the option to self-sign an "Anonymous" certificate; use a Free certificate authority, that will list and validate their e-mail address. Or an alternate CA that will validate their e-mail address and optionally additional fields, such as a real name. Only fields listed on a certificate need to be verified. If a site doesn't trust the authority to issue the cert, the connection proceeds, the site just asks the user to prove "Yes, that really is their e-mail address" > SSH does a good job of avoiding the pitfalls that most of those other > products have. SSH is vulnerable to MITM on the first connection to a new host, you are prompted to save a host key, but noone really verifies this. After you've saved a host key, if the host has to change keys for legitimate reasons, such as previous host key compromised, the SSH client refuses to connect, and the user has to manually remove entries from their known_hosts file. Username, password is more user-friendly than the SSH behavior, unfortunately. Which means username/password would still be used in preference. > Active Directory has costs associated with it. Yes > OpenID requires setting up your own server or using a third party. Most options that exists require setting up your own server or using a third party. > Imaging signing up for a site by putting in your email and pasting > your public key. No... that's not convenient or user-friendly enough. "Public what?" There must be a browser integration where the public key is automatically submitted (with the user's permission). There are too many users who don't know how to use "copy and paste". There are too many users not willing to dig into their browser's settings to lookup their public key. -- -JH From Jean-Francois.TremblayING at videotron.com Fri Jun 8 07:37:00 2012 From: Jean-Francois.TremblayING at videotron.com (Jean-Francois.TremblayING at videotron.com) Date: Fri, 8 Jun 2012 08:37:00 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1339106986.2754.37.camel@karl> Message-ID: Karl Auer a ?crit sur 07/06/2012 06:09:46 PM : > On this point I think you are wrong. Except for router advertisements, > most NDP packets are sent to a solicited node multicast address, and so > do NOT go to all nodes. It is "the same as broadcast" only in a network > with switches that do not do MLD snooping. > > > So I'm not sure how DAD traffic would exceed ARP traffic. > > I wouldn't expect it to. > Nor would I - which was the point of my response to an original poster > who said it might. Karl, Actually, your analysis seems fair for a normal broadcast network. It's true that DAD is fairly rare. RS and RAs are also part of ND though, but they shouldn't be a large part of the trafic. My comment was probably skewed by my perspective as an MSO. Docsis networks are not really broadcast in nature and the gateway (CMTS) sees all the ND trafic (ND-proxying), including DAD and RS, which can become a fair amount of trafic in some specific situations. /JF From pauldotwall at gmail.com Fri Jun 8 09:33:45 2012 From: pauldotwall at gmail.com (Paul WALL) Date: Fri, 8 Jun 2012 10:33:45 -0400 Subject: A's for www.xfinitytv.com Message-ID: I'm not learning any AAAA records for Streampix (www.xfinitytv.com), only A's. The domains this site redirects to are available over a v6 transport, but not the actual streaming. Anyone know what's going on? Thanks, Paul Wall From kmedcalf at dessus.com Fri Jun 8 09:44:07 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 08 Jun 2012 08:44:07 -0600 Subject: Configuration Systems In-Reply-To: Message-ID: <0ee9f39dc582b64393b122a653d9fc0d@mail.dessus.com> On Thursday, 07 June, 2012 12:52, Owen DeLong observed: > This is a hard problem to solve. Not the least of the difficulties is > the fact that if you ask 50 engineers to define "Cloud", you will get > at least 100 definitions many of which are incompatible to the point > of mutually exclusive. That is *the* definition of "Cloud". The term "Cloud" is a proxy for the expression "under the exclusive control of a third-party over which we have no influence nor control in order to gain plausibile denibility and CYA ptotection if something bad happens". Eg: Store you data "in the cloud". Run a server "in the cloud". Put your e-mail "in the cloud". Run your application "in the cloud". See, 100% accurate! --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From jay at miscreant.org Fri Jun 8 08:49:30 2012 From: jay at miscreant.org (Jay Mitchell) Date: Fri, 8 Jun 2012 23:49:30 +1000 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: <4A9C0355-98BC-475F-878F-49D3B1C40E43@miscreant.org> On 08/06/2012, at 2:09 AM, "Aaron C. de Bruyn" wrote: > > I would think it's fairly simple. > What if she forgot her existing password? Most sites have a 'reset > password' link they e-mail you. I especially like the ones that email back your password in clear text... Sadly this still happens all too often. From rob at invaluement.com Fri Jun 8 10:14:54 2012 From: rob at invaluement.com (Rob McEwen) Date: Fri, 08 Jun 2012 11:14:54 -0400 Subject: Configuration Systems In-Reply-To: <0ee9f39dc582b64393b122a653d9fc0d@mail.dessus.com> References: <0ee9f39dc582b64393b122a653d9fc0d@mail.dessus.com> Message-ID: <4FD216EE.6060906@invaluement.com> On 6/8/2012 10:44 AM, Keith Medcalf wrote: > That is *the* definition of "Cloud". The term "Cloud" is a proxy for the expression "under the exclusive control of a third-party over which we have no influence nor control in order to gain plausibile denibility and CYA ptotection if something bad happens". Here is my take on this... I think that hosting/datacenter admins sat around one day and lamented about the fact that so many of their clients were buying dedicated hosting servers and utilizing a very tiny percent of the CPU & storage. Often, the customer had been burned by "shared hosting" years earlier because of another shared hosting customer on the same server crashing the entire server, thus making everyone on that box suffer. So dedicated hosting became critical for many businesses who outsourced their hosting. But, again, many of those boxes sat year round utilizing something like <5% of CPU, and <5% of the available disk space (after OS installation). Then "virtual servers" matured, where you could create entire logically partitioned boxes running on the same server. These were sold as "virtual dedicated" servers, which was a step up from "shared hosting", and a step down from getting a dedicated server. But many didn't like this because they it was inherent that they were stuck on the same box with other customers. Those with deep pockets didn't take the bait. It had a niche, but didn't make for a good "sales pitch". Next, they found a way to leverage virtual servers by making it so that the virtual server didn't have to reside on one box... but could dynamically use various resources from a server farm, as needed. (for a simplified explanation). Thus, the "cloud" was then born. Now... all those unused CPU cycles and disk space are not wasted any more... they are dynamically put to use. RESULT>>>the aggregate sum of all that re-allocatable drive space and CPU cycles is ENORMOUS. It makes for a massively more efficient leveraging of hardware and software. The ratio of hardware costs to costumer revenue is massively better for a hoster/datacenter compared to selling traditional dedicated servers. That is not necessarily bad because some of the cost savings is passed back to the consumer in the form of lower prices. So this is not evil. Plus, there is an ability to "scale up" that exists with the cloud (where affordable!). But the funny part about this is that (a) the extent that cost savings are passed back to the client AND (b) the improved "scale up" technology.. those are the ONLY 2 benefits of cloud computing. Everything else is to benefit the hoster/datacenter. That so many CEOs/CTOs/directors/etc have bought into the hype, and see some kind of magical benefits seemingly beyond this... is just amazing. Personally, I prefer paying a little extra for my own dedicated and/or co-located servers... where I'm in total control of ALL aspects of hardware/software. -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From aaron at heyaaron.com Fri Jun 8 10:16:10 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 8 Jun 2012 08:16:10 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: On Fri, Jun 8, 2012 at 5:09 AM, Jimmy Hess wrote: > The PKI infrastructure and ?authority validation components are not > required. Even if they were -- anyone ?can setup a PKI infrastructure, > ?the problem is trust. We don't need all the 'PKI' crap to do this. We already have SSL/TLS for this purpose. Let's face it. 99% of the sites I use don't actually verify and/or trust who I am. But those sites DO trust that they have my e-mail address (click here to activate) and that I'm using the password I had when I first signed up. So forget all PKI infrastructure. Just establish that I'm the person who originally signed up for the account. Something as simple as an ssh-style key exchange would be perfect. No other information needs to be exchanged. Anonymous users could still be anonymous (sites like slashdot allow 'anonymous' posting--or you could create an account with a certain keypair and then throw that keypair away) and non-anonymous users have a better method of signing in. > This would allow websites to accept user signup without a need to spam > the user with additional ?"Click this link here to prove that this is > actually your real e-mail address". In the grand scheme of things, I don't think this is a huge hassle. > Or an alternate CA that will validate their e-mail address and > optionally additional fields, such as a real name. ? ? Only fields > listed on a certificate need to be verified. ...and now you need checking to figure out which CAs are anonymous or not, combined with the original problem--a single point of failure. One (or a handful) of providers that control access to your identity. Would you switch to a version of SSH that requires signed certificates--even if those certificates were free through cacert.org? > SSH is vulnerable to MITM on the first connection to a new host, you > are prompted to save a host key, ?but noone really verifies this. That's what the existing PKI infrastructure is for--verifying the site you are connecting to is 'legit'. (The brokenness of that system is an entirely different topic.) Another thing to keep in mind is that SSH can verify key fingerprints automatically too--you can publish them in DNS. Not infallible, but it should be very difficult once DNS is secured. And for sites that don't publish that info (like my podunk home machine) you can prompt the first time to validate the fingerprint. So what. How many geeks bypass the cert warnings in their browser almost out of habit? (Obviously not when going to your bank--but for smaller sites.) > After ?you've saved a host key, ?if the host has to change keys for > legitimate reasons, such as previous host key compromised, ? the SSH > client refuses to connect, ?and the user has to manually remove > entries from their known_hosts file. That could be solved by updating the DNS records or prompting the user to update the key. But seriously--what's going to happen if someone does an MitM on me connecting to my bank and doing SSH auth? The bank connection uses TLS. They'd have to forge that. Then I get the home page and I click the 'sshauth' icon in my browser....and it submits what? My username and does some key negotiation? What's the MitM guy going to do? What's he going to steal? He doesn't have my private key--nor the server's. > Username, password ?is more user-friendly than the SSH behavior, unfortunately. > Which means username/password would still be used in preference. So have the browser 'sshauth' plugin ask for a username and your 'ssh passphrase' but call it a 'password'. Most users wouldn't know or care about the difference. >> OpenID requires setting up your own server or using a third party. > Most options that exists require setting up your own server or using a > third party. The whole point of my original rant was to remove the ability of website operators to screw up and release your password which you may have used in multiple places. We have a simple system like that called SSH (simple as opposed to SSL/TLS certs) that centralizes everything on the user-side rather than the hundreds or thousands of servers the user uses. -A From dave at temk.in Fri Jun 8 10:26:04 2012 From: dave at temk.in (David Temkin) Date: Fri, 08 Jun 2012 11:26:04 -0400 Subject: AAAA's for www.netflix.com In-Reply-To: References: <00a501cd43ed$5ee99950$1cbccbf0$@iname.com> <4FD0B21D.4060707@temk.in> <20120607165818.GA30416@srv03.cluenet.de> <20120607220412.E0FC0215B3B6@drugs.dv.isc.org> <20120608011910.GA16069@srv03.cluenet.de> <20120608021120.31A0C215D5AB@drugs.dv.isc.org> <20120608022333.GA12126@srv03.cluenet.de> <4FD1801A.8050902@temk.in> Message-ID: <4FD2198C.8040102@temk.in> On 6/8/12 1:19 AM, Joly MacFie wrote: > > Netflix may have created its own IPv6-specific domain which is > responsible for almost a third of all IPv6 traffic. If this is the > case it might not be in full compliance with the spirit of World > IPv6 Day, as the aim should have been for Netflix to operate one > single domain with both AAAA records for IPv6 and A records for IPv4. > > > What about that? I've asked Sandvine to explain exactly what this means. We haven't created anything IPv6 specific, aside from starting to serve 100% of our IPv6 traffic from the Netflix CDN instead of our CDN partners, which is irrelevant to this actual exercise. > > j > > On Fri, Jun 8, 2012 at 12:31 AM, David Temkin > wrote: > > On 6/7/12 10:23 PM, Daniel Roesen wrote: > >> > >> On Fri, Jun 08, 2012 at 12:11:20PM +1000, Mark Andrews wrote: > >>>> > >>>> $ dig @pdns3.ultradns.org > www.netflix.com . A +norec +short > >>>> wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com > . > >>>> $ dig @pdns3.ultradns.org > www.netflix.com . AAAA +norec +short > >>>> > dualstack.wwwservice--frontend-313423742.us-east-1.elb.amazonaws.com > . > >>>> $ dig @pdns3.ultradns.org > www.netflix.com . ANY +short +norec > >>>> $ > >>>> > >>>> Resolving www.netflix.com using ANY > RRtype fails with an empty answer > >>>> section in the DNS response. > >>> > >>> Which is just plain BROKEN. > >> > >> Yup. > >> > >>>> This DNS trickery seems to be from the "taking a shower, trying not > >>>> to get wet" department. And has adverse effects in corner cases. > While > >>>> playing around, I had periods of time where I couldn't resolve > the FQDN > >>>> at all, possibly due some caching of the empty response. > >>> > >>> It's not DNS trickery. > >> > >> The "trickery" is returning different CNAMEs for QTYPE=A and > QTYPE=AAAA. > >> I'm not sure what's the goal of that is, but it's 4am here so I have an > >> excuse of not seeing the light. :) > >> > >> Best regards, > >> Daniel > >> > > We've confirmed that UltraDNS had "additional" issues caused by the push > > that they fixed for the previously reported problem. We are actively > > engaged with them to come to a resolution. > > > > -Dave > > > > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org > -------------------------------------------------------------- > - From Vinny_Abello at Dell.com Fri Jun 8 10:39:11 2012 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Fri, 8 Jun 2012 15:39:11 +0000 Subject: Peeringdb down? Message-ID: I already sent an email to support at peeringdb.com about this, but I'm uncertain they are receiving email properly, so I'll mention it here as well. I hadn't seen mention of it already anywhere. I'm seeing MySQL errors when attempting to query peeringdb.com this morning. I'm assuming the admins or friends of admins lurk here. :) IE: Database error: Invalid SQL: ..... MySQL Error: 1030 (Got error 28 from storage engine) Session halted. -Vinny From djahandarie at gmail.com Fri Jun 8 11:03:00 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Fri, 8 Jun 2012 12:03:00 -0400 Subject: Peeringdb down? In-Reply-To: References: Message-ID: On Fri, Jun 8, 2012 at 11:39 AM, wrote: > I already sent an email to support at peeringdb.com about this, but I'm uncertain they are receiving email properly, so I'll mention it here as well. I hadn't seen mention of it already anywhere. > > I'm seeing MySQL errors when attempting to query peeringdb.com this morning. I'm assuming the admins or friends of admins lurk here. :) > > IE: > > Database error: Invalid SQL: ..... > MySQL Error: 1030 (Got error 28 from storage engine) > Session halted. > > -Vinny The box that peeringDB is on is old and cranky. People are working on moving it to a better box. However, when the web interface goes down, usually you can still get information with the whois and finger interfaces: d82h214:~ Darius$ whois -h whois.peeringdb.com AS4436 General Network Information --------------------------- Network Name : nLayer Communications Name Aliases : Primary ASN : 4436 Website : http://www.nlayer.net/ IRR AS-SET : AS-NLAYER Network Type : NSP Approx BGP Prefixes : 10000 Traffic Levels : 1 Tbps+ Traffic Ratios : Mostly Outbound Geographic Scope : Global Supported Protocols : Coming Soon Looking Glass URL : http://lg.nlayer.net/ Route Server URL : telnet://route-server.nlayer.net Public Notes : Record Created Date : 2004-07-28 00:00:00 Last Updated Date : 2012-05-31 01:25:53 [...] d82h214:~ Darius$ whois -h whois.peeringdb.com AS4436 General Network Information --------------------------- Network Name : nLayer Communications Name Aliases : Primary ASN : 4436 Website : http://www.nlayer.net/ IRR AS-SET : AS-NLAYER Network Type : NSP Approx BGP Prefixes : 10000 Traffic Levels : 1 Tbps+ Traffic Ratios : Mostly Outbound Geographic Scope : Global Supported Protocols : Coming Soon Looking Glass URL : http://lg.nlayer.net/ Route Server URL : telnet://route-server.nlayer.net Public Notes : Record Created Date : 2004-07-28 00:00:00 Last Updated Date : 2012-05-31 01:25:53 [...] All the best. -- Darius Jahandarie From djahandarie at gmail.com Fri Jun 8 11:04:27 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Fri, 8 Jun 2012 12:04:27 -0400 Subject: Peeringdb down? In-Reply-To: References: Message-ID: On Fri, Jun 8, 2012 at 12:03 PM, Darius Jahandarie wrote: > However, when the web interface goes down, usually you can still get > information with the whois and finger interfaces: And of course, this is what I meant by the finger interface: d82h214:~ Darius$ finger as4436 at peeringdb.com Still early. -- Darius Jahandarie From peterehiwe at gmail.com Fri Jun 8 11:55:23 2012 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Fri, 8 Jun 2012 17:55:23 +0100 Subject: AUT-NUM ROUTE OBJECT Message-ID: 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 From nick at foobar.org Fri Jun 8 11:59:00 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 08 Jun 2012 17:59:00 +0100 Subject: AUT-NUM ROUTE OBJECT In-Reply-To: References: Message-ID: <4FD22F54.8070102@foobar.org> On 08/06/2012 17:55, Peter Ehiwe wrote: > Authorisation for parent [as-block] > using mnt-lower: > not authenticated by: RIPE-NCC-RPSL-MNT http://apps.db.ripe.net/whois/lookup/ripe/mntner/RIPE-NCC-RPSL-MNT.html Nick From cscora at apnic.net Fri Jun 8 14:03:20 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Jun 2012 05:03:20 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201206081903.q58J3KBp017770@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Jun, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 413039 Prefixes after maximum aggregation: 175026 Deaggregation factor: 2.36 Unique aggregates announced to Internet: 201617 Total ASes present in the Internet Routing Table: 41269 Prefixes per ASN: 10.01 Origin-only ASes present in the Internet Routing Table: 33286 Origin ASes announcing only one prefix: 15684 Transit ASes present in the Internet Routing Table: 5524 Transit-only ASes present in the Internet Routing Table: 140 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 28 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 395 Unregistered ASNs in the Routing Table: 138 Number of 32-bit ASNs allocated by the RIRs: 2815 Number of 32-bit ASNs visible in the Routing Table: 2459 Prefixes from 32-bit ASNs in the Routing Table: 6257 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 158 Number of addresses announced to Internet: 2561425708 Equivalent to 152 /8s, 172 /16s and 65 /24s Percentage of available address space announced: 69.1 Percentage of allocated address space announced: 69.2 Percentage of available address space allocated: 99.9 Percentage of address space in use by end-sites: 92.8 Total number of prefixes smaller than registry allocations: 171497 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 100699 Total APNIC prefixes after maximum aggregation: 32592 APNIC Deaggregation factor: 3.09 Prefixes being announced from the APNIC address blocks: 97153 Unique aggregates announced from the APNIC address blocks: 40289 APNIC Region origin ASes present in the Internet Routing Table: 4708 APNIC Prefixes per ASN: 20.64 APNIC Region origin ASes announcing only one prefix: 1257 APNIC Region transit ASes present in the Internet Routing Table: 739 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 224 Number of APNIC addresses announced to Internet: 648549440 Equivalent to 38 /8s, 168 /16s and 20 /24s Percentage of available APNIC address space announced: 82.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 151599 Total ARIN prefixes after maximum aggregation: 77134 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 121982 Unique aggregates announced from the ARIN address blocks: 51397 ARIN Region origin ASes present in the Internet Routing Table: 15161 ARIN Prefixes per ASN: 8.05 ARIN Region origin ASes announcing only one prefix: 5758 ARIN Region transit ASes present in the Internet Routing Table: 1601 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 816518336 Equivalent to 48 /8s, 171 /16s and 20 /24s Percentage of available ARIN address space announced: 65.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 102916 Total RIPE prefixes after maximum aggregation: 54777 RIPE Deaggregation factor: 1.88 Prefixes being announced from the RIPE address blocks: 94838 Unique aggregates announced from the RIPE address blocks: 59810 RIPE Region origin ASes present in the Internet Routing Table: 16620 RIPE Prefixes per ASN: 5.71 RIPE Region origin ASes announcing only one prefix: 8068 RIPE Region transit ASes present in the Internet Routing Table: 2663 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1626 Number of RIPE addresses announced to Internet: 515524868 Equivalent to 30 /8s, 186 /16s and 73 /24s Percentage of available RIPE address space announced: 83.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 41994 Total LACNIC prefixes after maximum aggregation: 8290 LACNIC Deaggregation factor: 5.07 Prefixes being announced from the LACNIC address blocks: 42193 Unique aggregates announced from the LACNIC address blocks: 20602 LACNIC Region origin ASes present in the Internet Routing Table: 1601 LACNIC Prefixes per ASN: 26.35 LACNIC Region origin ASes announcing only one prefix: 436 LACNIC Region transit ASes present in the Internet Routing Table: 306 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 587 Number of LACNIC addresses announced to Internet: 101954184 Equivalent to 6 /8s, 19 /16s and 178 /24s Percentage of available LACNIC address space announced: 67.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9388 Total AfriNIC prefixes after maximum aggregation: 2169 AfriNIC Deaggregation factor: 4.33 Prefixes being announced from the AfriNIC address blocks: 7442 Unique aggregates announced from the AfriNIC address blocks: 2195 AfriNIC Region origin ASes present in the Internet Routing Table: 544 AfriNIC Prefixes per ASN: 13.68 AfriNIC Region origin ASes announcing only one prefix: 165 AfriNIC Region transit ASes present in the Internet Routing Table: 120 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 31836160 Equivalent to 1 /8s, 229 /16s and 200 /24s Percentage of available AfriNIC address space announced: 47.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2637 11113 1122 Korea Telecom (KIX) 17974 1928 530 81 PT TELEKOMUNIKASI INDONESIA 7545 1682 301 86 TPG Internet Pty Ltd 4755 1590 385 155 TATA Communications formerly 9829 1297 1085 28 BSNL National Internet Backbo 9583 1175 87 502 Sify Limited 7552 1173 1062 11 Vietel Corporation 4808 1103 2049 314 CNCGROUP IP network: China169 24560 1029 385 163 Bharti Airtel Ltd., Telemedia 9498 965 291 64 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3409 3791 192 bellsouth.net, inc. 7029 3250 986 159 Windstream Communications Inc 18566 2091 382 181 Covad Communications 1785 1917 681 131 PaeTec Communications, Inc. 20115 1646 1570 616 Charter Communications 22773 1644 2911 121 Cox Communications, Inc. 4323 1574 1043 385 Time Warner Telecom 30036 1426 265 754 Mediacom Communications Corp 7018 1224 10013 823 AT&T WorldNet Services 11492 1189 216 356 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1740 544 16 Corbina telecom 2118 1226 97 14 EUnet/RELCOM Autonomous Syste 12479 718 699 84 Uni2 Autonomous System 34984 705 188 171 BILISIM TELEKOM 31148 684 37 9 FreeNet ISP 20940 667 219 523 Akamai Technologies European 6830 657 2217 426 UPC Distribution Services 8551 580 364 61 Bezeq International 3320 489 8442 402 Deutsche Telekom AG 3292 474 2108 408 TDC Tele Danmark Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1932 342 205 TVCABLE BOGOTA 28573 1923 1184 48 NET Servicos de Comunicao S.A 6503 1532 418 65 AVANTEL, S.A. 8151 1496 3084 336 UniNet S.A. de C.V. 7303 1437 901 193 Telecom Argentina Stet-France 26615 903 760 32 Tim Brasil S.A. 27947 700 73 94 Telconet S.A 11172 644 91 73 Servicios Alestra S.A de C.V 3816 584 247 89 Empresa Nacional de Telecomun 22047 583 326 15 VTR PUNTO NET S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1391 958 13 TEDATA 24863 846 274 35 LINKdotNET AS number 6713 497 649 18 Itissalat Al-MAGHRIB 24835 321 80 8 RAYA Telecom - Egypt 3741 262 905 223 The Internet Solution 33776 210 12 21 Starcomms Nigeria Limited 12258 197 28 62 Vodacom Internet Company 16637 170 664 87 MTN Network Solutions 29571 157 15 16 Ci Telecom Autonomous system 36923 157 20 4 Swift Networks Limited Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3409 3791 192 bellsouth.net, inc. 7029 3250 986 159 Windstream Communications Inc 4766 2637 11113 1122 Korea Telecom (KIX) 18566 2091 382 181 Covad Communications 10620 1932 342 205 TVCABLE BOGOTA 17974 1928 530 81 PT TELEKOMUNIKASI INDONESIA 28573 1923 1184 48 NET Servicos de Comunicao S.A 1785 1917 681 131 PaeTec Communications, Inc. 8402 1740 544 16 Corbina telecom 7545 1682 301 86 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3250 3091 Windstream Communications Inc 18566 2091 1910 Covad Communications 28573 1923 1875 NET Servicos de Comunicao S.A 17974 1928 1847 PT TELEKOMUNIKASI INDONESIA 1785 1917 1786 PaeTec Communications, Inc. 10620 1932 1727 TVCABLE BOGOTA 8402 1740 1724 Corbina telecom 7545 1682 1596 TPG Internet Pty Ltd 22773 1644 1523 Cox Communications, Inc. 4766 2637 1515 Korea Telecom (KIX) Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser 32873 UNALLOCATED 12.46.102.0/24 10912 InterNAP Network Ser 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 41.188.64.0/18 29544 Mauritanian Telecommunication Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:13 /10:28 /11:82 /12:236 /13:461 /14:832 /15:1505 /16:12298 /17:6303 /18:10641 /19:20776 /20:29530 /21:31054 /22:40785 /23:38492 /24:216195 /25:1236 /26:1449 /27:827 /28:172 /29:66 /30:17 /31:0 /32:22 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2910 3250 Windstream Communications Inc 6389 2129 3409 bellsouth.net, inc. 18566 2040 2091 Covad Communications 8402 1718 1740 Corbina telecom 30036 1366 1426 Mediacom Communications Corp 6503 1222 1532 AVANTEL, S.A. 8452 1190 1391 TEDATA 11492 1152 1189 Cable One 22773 1089 1644 Cox Communications, Inc. 7011 1073 1188 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:555 2:746 3:1 4:13 5:51 6:3 8:425 12:2012 13:1 14:619 15:12 16:3 17:5 20:23 23:180 24:1778 27:1306 31:977 32:56 33:2 34:2 36:9 37:684 38:812 40:127 41:3269 42:135 44:3 46:1423 47:2 49:401 50:555 52:13 54:12 55:8 56:1 57:33 58:960 59:497 60:259 61:1212 62:981 63:2008 64:4233 65:2249 66:4451 67:2028 68:1158 69:3174 70:950 71:508 72:1824 74:2591 75:471 76:327 77:956 78:973 79:478 80:1225 81:939 82:663 83:543 84:491 85:1192 86:432 87:918 88:334 89:1726 90:293 91:4919 92:557 93:1391 94:1566 95:1213 96:367 97:315 98:900 99:38 100:8 101:261 103:1133 106:95 107:186 108:330 109:1359 110:775 111:923 112:417 113:616 114:629 115:846 116:956 117:721 118:923 119:1232 120:358 121:695 122:1668 123:1102 124:1388 125:1261 128:559 129:202 130:247 131:632 132:288 133:22 134:242 135:61 136:215 137:239 138:358 139:185 140:494 141:252 142:417 143:375 144:532 145:72 146:508 147:293 148:776 149:312 150:164 151:179 152:469 153:174 154:14 155:446 156:222 157:381 158:186 159:578 160:345 161:265 162:347 163:190 164:638 165:404 166:592 167:471 168:863 169:127 170:878 171:136 172:4 173:1766 174:604 175:433 176:540 177:821 178:1381 180:1234 181:91 182:1050 183:228 184:528 185:1 186:2318 187:1122 188:1340 189:1827 190:5601 192:5992 193:5516 194:4532 195:3390 196:1224 197:151 198:3664 199:4763 200:5896 201:1951 202:8618 203:8565 204:4347 205:2509 206:2772 207:2801 208:4007 209:3608 210:2761 211:1545 212:2034 213:1931 214:874 215:98 216:5102 217:1548 218:553 219:313 220:1235 221:569 222:317 223:321 End of report From jmaimon at ttec.com Fri Jun 8 14:09:04 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 08 Jun 2012 15:09:04 -0400 Subject: Open DNS Resolver reflection attack Mitigation Message-ID: <4FD24DD0.5000408@ttec.com> 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 From rdobbins at arbor.net Fri Jun 8 14:15:41 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 8 Jun 2012 19:15:41 +0000 Subject: Open DNS Resolver reflection attack Mitigation In-Reply-To: <4FD24DD0.5000408@ttec.com> References: <4FD24DD0.5000408@ttec.com> Message-ID: <394CB6F9-15C2-485C-B09F-F6A517796683@arbor.net> On Jun 9, 2012, at 2:09 AM, Joe Maimon wrote: > Google and Level3 manage to run open resolvers, why cant I? Because they have probably have opsec resources you don't. If you can't defend it/keep it from being abused, don't do it. ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From bortzmeyer at nic.fr Fri Jun 8 14:26:05 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 8 Jun 2012 21:26:05 +0200 Subject: Open DNS Resolver reflection attack Mitigation In-Reply-To: <4FD24DD0.5000408@ttec.com> References: <4FD24DD0.5000408@ttec.com> Message-ID: <20120608192605.GA19427@sources.org> On Fri, Jun 08, 2012 at 03:09:04PM -0400, Joe Maimon wrote a message of 7 lines which said: > Is there any publicly available rate limiting for BIND? Not as far as I know. I'm not sure it would be a good idea. BIND is feature-rich enough. > How about host-based IDS that can be used to trigger rtbh or iptables? What I do (I manage a small and experimental open resolver) is to use iptables this way (porting it to IPv6 is left as an exercice): iptables -A INPUT -p udp --dport 53 -m hashlimit \ --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \ --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP So, every prefix (length 28) can send 20 r/s with allowed bursts of 100. This requires a Netfilter >= 1.4 (recent options of module hashlimit). Most iptables recipes that you find on the Web are not well suited to DNS. They use connection tracking, for instance, while, with the DNS, every request/response is a "connection". I have a more complete article on this setup but in french only . > Google and Level3 manage to run open resolvers, why cant I? You have less money :-) From jmaimon at ttec.com Fri Jun 8 14:31:52 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 08 Jun 2012 15:31:52 -0400 Subject: Open DNS Resolver reflection attack Mitigation In-Reply-To: <394CB6F9-15C2-485C-B09F-F6A517796683@arbor.net> References: <4FD24DD0.5000408@ttec.com> <394CB6F9-15C2-485C-B09F-F6A517796683@arbor.net> Message-ID: <4FD25328.9050808@ttec.com> Dobbins, Roland wrote: > > On Jun 9, 2012, at 2:09 AM, Joe Maimon wrote: > >> Google and Level3 manage to run open resolvers, why cant I? > > Because they have probably have opsec resources you don't. If you can't defend it/keep it from being abused, don't do it. > > ;> I think I will explore my options first. Until then, its whack a mole. Joe From mike at mtcc.com Fri Jun 8 14:48:38 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 08 Jun 2012 12:48:38 -0700 Subject: Dear Linkedin, Message-ID: <4FD25716.3000801@mtcc.com> 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 From jmaimon at ttec.com Fri Jun 8 14:48:48 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 08 Jun 2012 15:48:48 -0400 Subject: Open DNS Resolver reflection attack Mitigation In-Reply-To: <20120608192605.GA19427@sources.org> References: <4FD24DD0.5000408@ttec.com> <20120608192605.GA19427@sources.org> Message-ID: <4FD25720.9010209@ttec.com> Stephane Bortzmeyer wrote: > On Fri, Jun 08, 2012 at 03:09:04PM -0400, > Joe Maimon wrote > a message of 7 lines which said: > >> Is there any publicly available rate limiting for BIND? > > Not as far as I know. I'm not sure it would be a good idea. BIND is > feature-rich enough. I really hope you have a minority viewpoint on this one. I would really like to see it. > >> How about host-based IDS that can be used to trigger rtbh or iptables? > > What I do (I manage a small and experimental open resolver) is to use > iptables this way (porting it to IPv6 is left as an exercice): > > iptables -A INPUT -p udp --dport 53 -m hashlimit \ > --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \ > --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP > > So, every prefix (length 28) can send 20 r/s with allowed bursts of > 100. This requires a Netfilter>= 1.4 (recent options of module > hashlimit). Missing the amplification factor goodness google says they have, but I'll take it. https://developers.google.com/speed/public-dns/docs/security > > Most iptables recipes that you find on the Web are not well suited to > DNS. They use connection tracking, for instance, while, with the DNS, > every request/response is a "connection". > > I have a more complete article on this setup but in french only > . This sounds promising. I will give it a spin. Thank you! > >> Google and Level3 manage to run open resolvers, why cant I? > > You have less money :-) > > With help like yours, I hope to compensate for that. Joe From lyndon at orthanc.ca Fri Jun 8 14:54:44 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Fri, 8 Jun 2012 12:54:44 -0700 Subject: Dear Linkedin, In-Reply-To: <4FD25716.3000801@mtcc.com> References: <4FD25716.3000801@mtcc.com> Message-ID: 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. https://agilebits.com/onepassword (1Password) is one solution to managing web site passwords. --lyndon From paul at paulgraydon.co.uk Fri Jun 8 14:56:03 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 08 Jun 2012 09:56:03 -1000 Subject: Dear Linkedin, In-Reply-To: <4FD25716.3000801@mtcc.com> References: <4FD25716.3000801@mtcc.com> Message-ID: <4FD258D3.8080907@paulgraydon.co.uk> On 06/08/2012 09:48 AM, Michael Thomas wrote: > 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. Use a password safe. Simple. Most of them even include secure password generators. That way you only have one password to remember stored in a location you have control over (and is encrypted), and you get to adopt secure practices with websites. The only real inconvenience might be having to log into each of whatever sites it is you're concerned about and changing the password on them. Paul From alec.muffett at gmail.com Fri Jun 8 14:58:21 2012 From: alec.muffett at gmail.com (Alec Muffett) Date: Fri, 8 Jun 2012 20:58:21 +0100 Subject: Dear Linkedin, In-Reply-To: <4FD25716.3000801@mtcc.com> References: <4FD25716.3000801@mtcc.com> Message-ID: > 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. > 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. Yes; of course more than a couple of dozen random passwords or passphrases will be hard to remember, so look into something like 1Password, PasswordSafe or LastPass to help you with that - amongst others. It goes without saying that your password database should be protected by something really quite long but memorable to you. > * 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. Yes. My 1Password configuration for my work system is for 16 character random passwords, sprinkled with punctuation and mixed case. My home one is less thoroughly set up but is being migrated to the same. They are this way because I have both read and understood the performance statistics for some software called "Hashcat" which I have seen burn through every single 1 thru 8 character lowercase alphanumeric password in 32 minutes, on a single Alienware gamer laptop. Imagine what it can do on AWS. > 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. Stop using your brain, use a computer. > What's most pathetic about this is that somebody actually believes that we all really > deserve this finger wagging. Yes, some people evidently do. -a From jmaimon at ttec.com Fri Jun 8 14:58:56 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 08 Jun 2012 15:58:56 -0400 Subject: Dear Linkedin, In-Reply-To: <4FD25716.3000801@mtcc.com> References: <4FD25716.3000801@mtcc.com> Message-ID: <4FD25980.6090506@ttec.com> Michael Thomas wrote: > 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 > Different passwords have different security clearances. Some stuff, especially all those "security questions" just has to be stored somewhere retrievable. Joe From owen at delong.com Fri Jun 8 14:56:23 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Jun 2012 12:56:23 -0700 Subject: Open DNS Resolver reflection attack Mitigation In-Reply-To: <20120608192605.GA19427@sources.org> References: <4FD24DD0.5000408@ttec.com> <20120608192605.GA19427@sources.org> Message-ID: <9EAC3D5B-BAFA-437F-94E9-673E67806F3A@delong.com> On Jun 8, 2012, at 12:26 PM, Stephane Bortzmeyer wrote: > On Fri, Jun 08, 2012 at 03:09:04PM -0400, > Joe Maimon wrote > a message of 7 lines which said: > >> Is there any publicly available rate limiting for BIND? > > Not as far as I know. I'm not sure it would be a good idea. BIND is > feature-rich enough. > >> How about host-based IDS that can be used to trigger rtbh or iptables? > > What I do (I manage a small and experimental open resolver) is to use > iptables this way (porting it to IPv6 is left as an exercice): > > iptables -A INPUT -p udp --dport 53 -m hashlimit \ > --hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \ > --hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP > IPv6 should be a simple matter of putting the same line in your ip6tables file. Owen From surfer at mauigateway.com Fri Jun 8 15:02:49 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 8 Jun 2012 13:02:49 -0700 Subject: Dear Linkedin, Message-ID: <20120608130249.BFE61B1B@m0005311.ppops.net> --- lyndon at orthanc.ca wrote: From: Lyndon Nerenberg 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 From jna at retina.net Fri Jun 8 15:03:03 2012 From: jna at retina.net (John Adams) Date: Fri, 8 Jun 2012 13:03:03 -0700 Subject: Dear Linkedin, In-Reply-To: <4FD25716.3000801@mtcc.com> References: <4FD25716.3000801@mtcc.com> Message-ID: On Fri, Jun 8, 2012 at 12:48 PM, Michael Thomas wrote: > 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. > > 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. > No actually, it's not impossible. I use 1password, you might use LastPass. They both work on Android, iPhone, Linux, Mac, Windows. I have over 900 passwords in that system, and I don't know any of them. They're all 8-14 characters. All random. I know my master password, and no one on the Internet has a copy of that. On some systems, I have a Yubikey with a 45 character master password. Change your habits. Fix the password anti-pattern. -j From jna at retina.net Fri Jun 8 15:03:54 2012 From: jna at retina.net (John Adams) Date: Fri, 8 Jun 2012 13:03:54 -0700 Subject: Dear Linkedin, In-Reply-To: <20120608130249.BFE61B1B@m0005311.ppops.net> References: <20120608130249.BFE61B1B@m0005311.ppops.net> Message-ID: On Fri, Jun 8, 2012 at 1:02 PM, Scott Weeks wrote: > :: 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. > > So use LastPass, then. -j From simon.perreault at viagenie.ca Fri Jun 8 15:07:56 2012 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Fri, 08 Jun 2012 16:07:56 -0400 Subject: Dear Linkedin, In-Reply-To: <4FD25716.3000801@mtcc.com> References: <4FD25716.3000801@mtcc.com> Message-ID: <4FD25B9C.5050906@viagenie.ca> On 2012-06-08 15:48, Michael Thomas wrote: > * Make sure you update your password on LinkedIn (and any site that you > visit on the Web) at least once every few months. > * Do not use the same password for multiple sites or accounts. > * Create a strong password for your account, one that includes letters, > numbers, and other characters. And how about "Do not store your passwords using unsalted sha1?" Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From lyndon at orthanc.ca Fri Jun 8 15:08:09 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Fri, 8 Jun 2012 13:08:09 -0700 Subject: Dear Linkedin, In-Reply-To: <20120608130249.BFE61B1B@m0005311.ppops.net> References: <20120608130249.BFE61B1B@m0005311.ppops.net> Message-ID: <89D345EF-333C-4975-9205-B1F5E7E7750B@orthanc.ca> On 2012-06-08, at 1:02 PM, Scott Weeks wrote: > Only if you have an OS you have to pay for: apple or ms. I don't pay for them. $WORK pays for them. If you're complaint is about 1Password not running on your particular operating systems, then pick a solution that *does* run on your OS. There are several open source alternatives you can use. From surfer at mauigateway.com Fri Jun 8 15:08:34 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 8 Jun 2012 13:08:34 -0700 Subject: Dear Linkedin, Message-ID: <20120608130834.BFE61BC0@m0005311.ppops.net> --- jna at retina.net wrote: From: John Adams I use 1password, you might use LastPass. They both work on Android, iPhone, Linux, Mac, Windows. ---------------------------------------- No, according to their site 1password does not work on *nix, however lastpass says it does all *nix flavors. scott From paul at paulgraydon.co.uk Fri Jun 8 15:09:52 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 08 Jun 2012 10:09:52 -1000 Subject: Dear Linkedin, In-Reply-To: <20120608130249.BFE61B1B@m0005311.ppops.net> References: <20120608130249.BFE61B1B@m0005311.ppops.net> Message-ID: <4FD25C10.8060606@paulgraydon.co.uk> On 06/08/2012 10:02 AM, Scott Weeks wrote: > > --- lyndon at orthanc.ca wrote: > From: Lyndon Nerenberg > 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 > Use lastpass, or maybe Password Gorilla (uses an encrypted local file but you could stick that on a dropbox space or SpiderOak space). From bortzmeyer at nic.fr Fri Jun 8 15:11:27 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 8 Jun 2012 22:11:27 +0200 Subject: Open DNS Resolver reflection attack Mitigation In-Reply-To: <9EAC3D5B-BAFA-437F-94E9-673E67806F3A@delong.com> References: <4FD24DD0.5000408@ttec.com> <20120608192605.GA19427@sources.org> <9EAC3D5B-BAFA-437F-94E9-673E67806F3A@delong.com> Message-ID: <20120608201127.GA24608@sources.org> On Fri, Jun 08, 2012 at 12:56:23PM -0700, Owen DeLong wrote a message of 28 lines which said: > IPv6 should be a simple matter of putting the same line in your > ip6tables file. My experience with attack mitigation is that tools do not always work as advertised and sometimes do bad things (such as crashing the machine). So, I agree, it "should be a simple matter" but I prefer to test first. [For instance, my IPv4 rule required a maximum of 2^28 buckets in memory while an IPv6 rule with --hashlimit-srcmask 64 would require a maximum of 2^64 buckets... What will be the effect on the system memory?] From nanog at lacutt.com Fri Jun 8 15:20:22 2012 From: nanog at lacutt.com (Derrick H.) Date: Fri, 8 Jun 2012 15:20:22 -0500 Subject: Dear Linkedin, In-Reply-To: <20120608130834.BFE61BC0@m0005311.ppops.net> References: <20120608130834.BFE61BC0@m0005311.ppops.net> Message-ID: <20120608202022.GA5319@nm.lacutt.com> I'm surprised no one mentioned a locally stored (and backed up of course) gpg encrypted file for securing all of your passwords. Very simple solution for the technically inclined. Derrick On Fri, Jun 08, 2012 at 01:08:34PM -0700, Scott Weeks wrote: > > > --- jna at retina.net wrote: > From: John Adams > > I use 1password, you might use LastPass. They both work on > Android, iPhone, Linux, Mac, Windows. > ---------------------------------------- > > > No, according to their site 1password does not work on > *nix, however lastpass says it does all *nix flavors. > > scott > From jra at baylink.com Fri Jun 8 15:22:09 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 8 Jun 2012 16:22:09 -0400 (EDT) Subject: Dear Linkedin, In-Reply-To: <4FD25716.3000801@mtcc.com> Message-ID: <23473829.8446.1339186929532.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Thomas" > 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. Whether those rules are *practical* is orthogonal to whether they're necessary. Ob: https://xkcd.com/792/ https://xkcd.com/936/ Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From mike at mtcc.com Fri Jun 8 15:22:30 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 08 Jun 2012 13:22:30 -0700 Subject: Dear Linkedin, In-Reply-To: <4FD258D3.8080907@paulgraydon.co.uk> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> Message-ID: <4FD25F06.6040801@mtcc.com> On 06/08/2012 12:56 PM, Paul Graydon wrote: > Use a password safe. Simple. Most of them even include secure password generators. That way you only have one password to remember stored in a location you have control over (and is encrypted), and you get to adopt secure practices with websites. > > The only real inconvenience might be having to log into each of whatever sites it is you're concerned about and changing the password on them. Does your password safe know how to change the password on each website every several months? Mike From paul at paulgraydon.co.uk Fri Jun 8 15:24:38 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 08 Jun 2012 10:24:38 -1000 Subject: Dear Linkedin, In-Reply-To: <4FD25F06.6040801@mtcc.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> Message-ID: <4FD25F86.6070908@paulgraydon.co.uk> On 06/08/2012 10:22 AM, Michael Thomas wrote: > On 06/08/2012 12:56 PM, Paul Graydon wrote: >> Use a password safe. Simple. Most of them even include secure >> password generators. That way you only have one password to remember >> stored in a location you have control over (and is encrypted), and >> you get to adopt secure practices with websites. >> >> The only real inconvenience might be having to log into each of >> whatever sites it is you're concerned about and changing the password >> on them. > > Does your password safe know how to change the password on each > website every several months? > > Mike Oh come on.. now you're just being ridiculous, even bordering on childish. LinkedIn are offering solid advice, routed in safe practices. If you don't want to do it that's your problem. Stop bitching just because security is hard. From mike at mtcc.com Fri Jun 8 15:27:09 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 08 Jun 2012 13:27:09 -0700 Subject: Dear Linkedin, In-Reply-To: <4FD25F86.6070908@paulgraydon.co.uk> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> Message-ID: <4FD2601D.6050705@mtcc.com> On 06/08/2012 01:24 PM, Paul Graydon wrote: > On 06/08/2012 10:22 AM, Michael Thomas wrote: >> On 06/08/2012 12:56 PM, Paul Graydon wrote: >>> Use a password safe. Simple. Most of them even include secure password generators. That way you only have one password to remember stored in a location you have control over (and is encrypted), and you get to adopt secure practices with websites. >>> >>> The only real inconvenience might be having to log into each of whatever sites it is you're concerned about and changing the password on them. >> >> Does your password safe know how to change the password on each >> website every several months? >> >> Mike > Oh come on.. now you're just being ridiculous, even bordering on childish. > LinkedIn are offering solid advice, routed in safe practices. If you don't want to do it that's your problem. Stop bitching just because security is hard. Uh, I'm not the one saying you should change your passwords every month, Linkedin is. If you think it's childish, take it up with them. Mike From christopher.morrow at gmail.com Fri Jun 8 15:27:29 2012 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 8 Jun 2012 16:27:29 -0400 Subject: My view of the arin db boarked? Message-ID: err, last 3 times I asked this I was shown the error of my ways, but here goes... 209.250.228.241 - seems to not have any records in ARIN's WHOIS database, everythign seems to roll up to the /8 record :( I see this routed as a /23: (from routeviews) BGP routing table entry for 209.250.228.0/23, version 2072545487 Paths: (33 available, best #19, table Default-IP-Routing-Table) Not advertised to any peer 3277 3267 174 27431 14037 194.85.102.33 from 194.85.102.33 (194.85.4.4) Origin IGP, localpref 100, valid, external Community: 3277:3267 3277:65321 3277:65323 3277:65330 If I look at the ASN in particular: AS14037 no records exist for that in ARIN's WHOIS database either ;( If I look at all the networks announced by AS14037: 14037 | 204.8.216.0/21 | 14037 | 209.250.224.0/19 | 14037 | 209.250.228.0/23 | 14037 | 209.250.242.0/24 | 14037 | 209.250.247.0/24 | 14037 | 64.18.128.0/19 | 14037 | 64.18.159.0/24 | none of them have any records in the ARIN WHOIS database :( The upstream for this network is AS 27431 - JTL Networks who seems to get transit/peer with 3356/174. It's nice to see folk who use IRR databases to filter their customers still permit this sort of thing to go on though: AS3356 I'm looking at you... I think first: "Where are the records for this set of ip number resources?" and second: "Why are we still seeing this on the network with no way to contact the operators of the resources?" -chris From alec.muffett at gmail.com Fri Jun 8 15:29:40 2012 From: alec.muffett at gmail.com (Alec Muffett) Date: Fri, 8 Jun 2012 21:29:40 +0100 Subject: Dear Linkedin, In-Reply-To: <4FD25F06.6040801@mtcc.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> Message-ID: <7747D456-FB70-4374-BF49-140BAD8080E0@gmail.com> > Does your password safe know how to change the password on each > website every several months? Not far off, actually; my 1Password has an auto-login-page feature which you can often wire to be the same as the password-change URL. So, nyah. -a From mike at mtcc.com Fri Jun 8 15:30:42 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 08 Jun 2012 13:30:42 -0700 Subject: Dear Linkedin, In-Reply-To: <4FD25F86.6070908@paulgraydon.co.uk> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> Message-ID: <4FD260F2.7000407@mtcc.com> On 06/08/2012 01:24 PM, Paul Graydon wrote: > Oh come on.. now you're just being ridiculous, even bordering on childish. > LinkedIn are offering solid advice, routed in safe practices. If you don't want to do it that's your problem. Stop bitching just because security is hard. PS: when security is hard, people simply don't do it. Blaming the victim of poor engineering that leads people to not be able to perform best practices is not the answer. Mike From lyndon at orthanc.ca Fri Jun 8 15:35:22 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Fri, 8 Jun 2012 13:35:22 -0700 Subject: Dear Linkedin, In-Reply-To: <4FD25F06.6040801@mtcc.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> Message-ID: <142D8C95-5FA3-4404-B043-A7BDD52C100E@orthanc.ca> On 2012-06-08, at 1:22 PM, Michael Thomas wrote: > Does your password safe know how to change the password on each > website every several months? Yes. From alec.muffett at gmail.com Fri Jun 8 15:41:03 2012 From: alec.muffett at gmail.com (Alec Muffett) Date: Fri, 8 Jun 2012 21:41:03 +0100 Subject: Dear Linkedin, In-Reply-To: <4FD260F2.7000407@mtcc.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> Message-ID: > PS: when security is hard, people simply don't do it. Blaming the victim > of poor engineering that leads people to not be able to perform best > practices is not the answer. Passwords suck, but they are the best that we have at the moment in terms of being cheap and free from infrastructure - see http://goo.gl/3lggk We've been in a bubble for the past few years, where Moore's law hardware had not quite caught up with the speed of SHA and MD5 password hashing throughput for effective brute force guessing; that bubble is well and truly burst. Welcome back to 1995 where the advice is to change your passwords frequently, because it has a half-life of usefulness imposed upon it from (a) day to day external exposure and (b) the march of technology - and keep your hashing algorithms up to date, too. See http://goo.gl/iL9EP for suggestions. Have a nice weekend, -a From mike at mtcc.com Fri Jun 8 15:41:28 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 08 Jun 2012 13:41:28 -0700 Subject: Dear Linkedin, In-Reply-To: <142D8C95-5FA3-4404-B043-A7BDD52C100E@orthanc.ca> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <142D8C95-5FA3-4404-B043-A7BDD52C100E@orthanc.ca> Message-ID: <4FD26378.9070900@mtcc.com> On 06/08/2012 01:35 PM, Lyndon Nerenberg wrote: > On 2012-06-08, at 1:22 PM, Michael Thomas wrote: > >> Does your password safe know how to change the password on each >> website every several months? > Yes. I run a website. If it can change it on mine, I'd like to understand how it manages to do that. Mike From asullivan at dyn.com Fri Jun 8 15:48:38 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 8 Jun 2012 16:48:38 -0400 Subject: Password safes &c. (was: Dear Linkedin,) In-Reply-To: <4FD260F2.7000407@mtcc.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> Message-ID: <20120608204838.GG10216@dyn.com> On Fri, Jun 08, 2012 at 01:30:42PM -0700, Michael Thomas wrote: > PS: when security is hard, people simply don't do it. I think this is exactly right. The idea that we are going to train everyone on earth to keep eleventy billion distinct passwords in their heads -- or in a "password safe" that is either (1) under someone else's control because it's a web service or (2) inaccessible half the time because it's on their laptop and they're using their phone now and OMG -- is preposterous. (This without mentioning that they also have to remember the username that goes with it, which is _also_ variable.) We have an engineering challenge here, and the PKI we have so far doesn't work. No, I have no magic answers. I'm not that smart. Michael Thomas is still right about this. Best, A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From mike at mtcc.com Fri Jun 8 15:55:46 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 08 Jun 2012 13:55:46 -0700 Subject: Dear Linkedin, In-Reply-To: References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> Message-ID: <4FD266D2.6060600@mtcc.com> On 06/08/2012 01:41 PM, Alec Muffett wrote: >> PS: when security is hard, people simply don't do it. Blaming the victim >> of poor engineering that leads people to not be able to perform best >> practices is not the answer. > Passwords suck, but they are the best that we have at the moment in terms of being cheap and free from infrastructure - see http://goo.gl/3lggk > > We've been in a bubble for the past few years, where Moore's law hardware had not quite caught up with the speed of SHA and MD5 password hashing throughput for effective brute force guessing; that bubble is well and truly burst. > > Welcome back to 1995 where the advice is to change your passwords frequently, because it has a half-life of usefulness imposed upon it from (a) day to day external exposure and (b) the march of technology - and keep your hashing algorithms up to date, too. See http://goo.gl/iL9EP for suggestions. > A lot has changed from 1995, and still we're using technology that is essentially unchanged from the 1960's. For my part, on my app/website (Phresheez), the app actually auto-generates passwords for the user so that they don't have to type one in. I do this mainly because people hate typing on phones, but it has the nice property that if you have a password exposure event, you do not have the cascading failure mode that Linkedin has now unleashed. With apps and browsers that can remember passwords why are we still insisting that users generate and remember their own bad passwords? That's one reason that I find the finger wagging tone of that Linkedin post extremely problematic -- they have obviously never even considered thinking beyond the current bad practice. Mike From tyler.haske at gmail.com Fri Jun 8 16:00:14 2012 From: tyler.haske at gmail.com (Tyler Haske) Date: Fri, 8 Jun 2012 17:00:14 -0400 Subject: Password safes &c. (was: Dear Linkedin,) In-Reply-To: <20120608204838.GG10216@dyn.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> <20120608204838.GG10216@dyn.com> Message-ID: KeePass, KeyPassDroid and Dropbox. I'm sure it will just get simpler as time goes on. My mom uses a key database just fine. On Jun 8, 2012 4:49 PM, "Andrew Sullivan" wrote: > > On Fri, Jun 08, 2012 at 01:30:42PM -0700, Michael Thomas wrote: > > PS: when security is hard, people simply don't do it. > > I think this is exactly right. > > The idea that we are going to train everyone on earth to keep eleventy > billion distinct passwords in their heads -- or in a "password safe" > that is either (1) under someone else's control because it's a web > service or (2) inaccessible half the time because it's on their laptop > and they're using their phone now and OMG -- is preposterous. (This > without mentioning that they also have to remember the username that > goes with it, which is _also_ variable.) From lyndon at orthanc.ca Fri Jun 8 16:01:43 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Fri, 8 Jun 2012 14:01:43 -0700 Subject: Password Safes In-Reply-To: <4FD26378.9070900@mtcc.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <142D8C95-5FA3-4404-B043-A7BDD52C100E@orthanc.ca> <4FD26378.9070900@mtcc.com> Message-ID: On 2012-06-08, at 1:41 PM, Michael Thomas wrote: > I run a website. If it can change it on mine, I'd like to understand > how it manages to do that. I log in to your website, change my password, and the software picks up that I've changed the password and updates the safe accordingly. The software doesn't initiate the password change, it just notices it and updates its database accordingly. Sorry, I should have explained that more clearly. If you have a Mac or a Windows box, download the 1Password 30 day trail and take it for a run. It really is a useful bit of software. No, it doesn't work on my *BSD, Solaris, or Plan 9 machines. But it does sync across all my Mac, Windows, and Android gear, and the Android client lets me pull up passwords on my phone when I'm on one of the systems that doesn't have a native 1Password client, or when I am on the road. --lyndon From christopher.morrow at gmail.com Fri Jun 8 16:02:39 2012 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Fri, 8 Jun 2012 17:02:39 -0400 Subject: My view of the arin db boarked? In-Reply-To: References: Message-ID: it seems fair to note that: also doesn't mention this 209.250 range, nor the others from this mystery ASN. (back to 12/2008 at least) -chris On Fri, Jun 8, 2012 at 4:27 PM, Christopher Morrow wrote: > err, last 3 times I asked this I was shown the error of my ways, but > here goes... > > 209.250.228.241 - seems to not have any records in ARIN's WHOIS > database, everythign seems to roll up to the /8 record :( > > I see this routed as a /23: (from routeviews) > ?BGP routing table entry for 209.250.228.0/23, version 2072545487 > Paths: (33 available, best #19, table Default-IP-Routing-Table) > ?Not advertised to any peer > ?3277 3267 174 27431 14037 > ? ?194.85.102.33 from 194.85.102.33 (194.85.4.4) > ? ? ?Origin IGP, localpref 100, valid, external > ? ? ?Community: 3277:3267 3277:65321 3277:65323 3277:65330 > > If I look at the ASN in particular: AS14037 > no records exist for that in ARIN's WHOIS database either ;( If I look > at all the networks announced by AS14037: > 14037 ? | 204.8.216.0/21 ? ? ?| > 14037 ? | 209.250.224.0/19 ? ?| > 14037 ? | 209.250.228.0/23 ? ?| > 14037 ? | 209.250.242.0/24 ? ?| > 14037 ? | 209.250.247.0/24 ? ?| > 14037 ? | 64.18.128.0/19 ? ? ?| > 14037 ? | 64.18.159.0/24 ? ? ?| > > > none of them have any records in the ARIN WHOIS database :( The > upstream for this network is ?AS 27431 - JTL Networks > who seems to get transit/peer with 3356/174. > > It's nice to see folk who use IRR databases to filter their customers > still permit this sort of thing to go on though: AS3356 I'm looking at > you... > > I think first: "Where are the records for this set of ip number resources?" > and second: "Why are we still seeing this on the network with no way > to contact the operators of the resources?" > > -chris From mike at mtcc.com Fri Jun 8 16:06:25 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 08 Jun 2012 14:06:25 -0700 Subject: Password Safes In-Reply-To: References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <142D8C95-5FA3-4404-B043-A7BDD52C100E@orthanc.ca> <4FD26378.9070900@mtcc.com> Message-ID: <4FD26951.6020401@mtcc.com> On 06/08/2012 02:01 PM, Lyndon Nerenberg wrote: > On 2012-06-08, at 1:41 PM, Michael Thomas wrote: > >> I run a website. If it can change it on mine, I'd like to understand >> how it manages to do that. > I log in to your website, change my password, and the software picks up that I've changed the password and updates the safe accordingly. The software doesn't initiate the password change, it just notices it and updates its database accordingly. Sorry, I should have explained that more clearly. > > If you have a Mac or a Windows box, download the 1Password 30 day trail and take it for a run. It really is a useful bit of software. No, it doesn't work on my *BSD, Solaris, or Plan 9 machines. But it does sync across all my Mac, Windows, and Android gear, and the Android client lets me pull up passwords on my phone when I'm on one of the systems that doesn't have a native 1Password client, or when I am on the road. > Ah, ok. Still Linkedin's contention that I should log in to every account that I've created and change the password is still silly -- nobody's going to do that. That said, if there were a standardized way to get these password vault software -- or whatever else wanted to manage them -- to do key refresh, I'd be happy to implement it for my site. To my knowledge, such a protocol does not exist. Mike From asullivan at dyn.com Fri Jun 8 16:07:40 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 8 Jun 2012 17:07:40 -0400 Subject: Password safes &c. (was: Dear Linkedin,) In-Reply-To: References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> <20120608204838.GG10216@dyn.com> Message-ID: <20120608210739.GH10216@dyn.com> On Fri, Jun 08, 2012 at 05:00:14PM -0400, Tyler Haske wrote: > KeePass, KeyPassDroid and Dropbox. Yes, of course, I'll just upload all my passwords to a place totally under the control of someone (well, actually, _two_ other ones) else, and then pray that there never turns out to be a nasty attack against the programs and algorithms I used. (I'm more concerned about the programs. Obviously, if SHA-2 or whatever breaks, we gots bigger problems than all my personal passwords.) I'm not trying to be dismissive. Those are excellent stopgap measures. They're not a solution. Best, A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From paul at paulgraydon.co.uk Fri Jun 8 16:10:49 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 08 Jun 2012 11:10:49 -1000 Subject: Password safes &c. In-Reply-To: References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> <20120608204838.GG10216@dyn.com> Message-ID: <4FD26A59.4030502@paulgraydon.co.uk> In my case I rely on Password Safe (http://passwordsafe.sourceforge.net/), Password Gorilla (https://github.com/zdia/gorilla/wiki/) and Dropbox. PasswordSafe has android and windows clients. The windows client will work under wine on linux if you really want, but it's a bit of a pain. Password Gorilla is a TCL app that is cross-platform that reads PasswordSafe files. There are a number of iPhone clients for passwordsafe mentioned on the Password Gorilla page linked above. Dropbox keeps the safe sync'd between locations (including phone). In each of them adding, fetching or changing a password is simple and involves only a few clicks. I've got somewhere approaching 200+ passwords in mine. On 06/08/2012 11:00 AM, Tyler Haske wrote: > KeePass, KeyPassDroid and Dropbox. > > I'm sure it will just get simpler as time goes on. > > My mom uses a key database just fine. > On Jun 8, 2012 4:49 PM, "Andrew Sullivan" wrote: >> On Fri, Jun 08, 2012 at 01:30:42PM -0700, Michael Thomas wrote: >>> PS: when security is hard, people simply don't do it. >> I think this is exactly right. >> >> The idea that we are going to train everyone on earth to keep eleventy >> billion distinct passwords in their heads -- or in a "password safe" >> that is either (1) under someone else's control because it's a web >> service or (2) inaccessible half the time because it's on their laptop >> and they're using their phone now and OMG -- is preposterous. (This >> without mentioning that they also have to remember the username that >> goes with it, which is _also_ variable.) From lyndon at orthanc.ca Fri Jun 8 16:15:22 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Fri, 8 Jun 2012 14:15:22 -0700 Subject: Password safes &c. (was: Dear Linkedin,) In-Reply-To: <20120608210739.GH10216@dyn.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> <20120608204838.GG10216@dyn.com> <20120608210739.GH10216@dyn.com> Message-ID: On 2012-06-08, at 2:07 PM, Andrew Sullivan wrote: > I'm not trying to be dismissive. Those are excellent stopgap > measures. They're not a solution. There is no "solution." Security is about risk management, nothing more. The only way to ensure your personal passwords are never compromised is to kill yourself after destroying all physical copies of those passwords. While ultimately secure, you won't be able to do your daily online banking. --lyndon From paul at paulgraydon.co.uk Fri Jun 8 16:15:46 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 08 Jun 2012 11:15:46 -1000 Subject: Password safes &c. In-Reply-To: <20120608210739.GH10216@dyn.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> <20120608204838.GG10216@dyn.com> <20120608210739.GH10216@dyn.com> Message-ID: <4FD26B82.2050709@paulgraydon.co.uk> On 06/08/2012 11:07 AM, Andrew Sullivan wrote: > On Fri, Jun 08, 2012 at 05:00:14PM -0400, Tyler Haske wrote: >> KeePass, KeyPassDroid and Dropbox. > Yes, of course, I'll just upload all my passwords to a place totally > under the control of someone (well, actually, _two_ other ones) else, > and then pray that there never turns out to be a nasty attack against > the programs and algorithms I used. (I'm more concerned about the > programs. Obviously, if SHA-2 or whatever breaks, we gots bigger > problems than all my personal passwords.) > > I'm not trying to be dismissive. Those are excellent stopgap > measures. They're not a solution. > > Best, > > A If you don't trust DropBox, try SpiderOak for an added layer of encryption. From alec.muffett at gmail.com Fri Jun 8 16:28:19 2012 From: alec.muffett at gmail.com (Alec Muffett) Date: Fri, 8 Jun 2012 22:28:19 +0100 Subject: Dear Linkedin, In-Reply-To: <4FD266D2.6060600@mtcc.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> <4FD266D2.6060600@mtcc.com> Message-ID: <94F2EA79-95A0-4992-A23F-2B95A7F2B921@gmail.com> On 8 Jun 2012, at 21:55, Michael Thomas wrote: > With apps and browsers that > can remember passwords why are we still insisting that users generate > and remember their own bad passwords? That's one reason that I > find the finger wagging tone of that Linkedin post extremely problematic -- > they have obviously never even considered thinking beyond the current > bad practice. That's a fair point, well made; in practice I try to educate people on how to choose a good password by showing them bad ones and giving them a list of "Don'ts"; giving them a tool would be easier but then you have a race to the bottom for platform neutral tools which are well-written, don't repeat plaintexts and don't serve off a central authority like a website. In some ways when faced with a challenge like that I would prefer people learned how to pick their own. One pentester-friend of mine can now determine which in department employees of his customer reside because each department circulated its own rules on "how to choose a secure password" and the templates/technique are distinct from one department to the next. He brute-forces a password (possible because the passwords are 8 characters-ish and reasonably short, thereby making templates irrelevant) and then reprograms his cracking software to mess with the per-department template to crack the rest of the users in a shorter time. Having people make up their own passwords reduces scope for that sort of behaviour - you crack some of the clueless folk but the overall quantity of breaks may be reduced. Also: someone earlier mentioned "the password anti-pattern" - just to clear up a misapprehension, password security is not itself the aforementioned "anti-pattern"* but instead the actual "password anti-pattern" is (for example) surrendering your Blog password to a third party like Flickr so that it can post photos to your blog on your behalf. This sort of problem is solved by OAuth which community (unsurprisingly) is from whence the password-anti-pattern term was popularised; Google's "application-specific password" scheme addresses another aspect of the same issue. More concisely the "password anti-pattern" is "giving your password away or using it untowardly". -a From jmaimon at ttec.com Fri Jun 8 16:32:51 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 08 Jun 2012 17:32:51 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: <4FD26F83.9070302@ttec.com> David Walker wrote: > Self signed certificates does sound great and for most purposes, > certainly in this case, fulfills all the requirements. There's no need > to verify anything about me is correct other than to tie my > authentication to my account. If I fail to meet the TOS then the plug > is easily pulled and any further activity can be dealt with as it > currently is by other means. I think there's enough risk in bringing > in a CA and so little advantage that it's wrong. > If LinkedIn or facebook or any large social site were to implement x509, they would be silly not to cast themselves as the trusted root. a) its better than self signed b) now they are an x509 identify provider From johnl at iecc.com Fri Jun 8 16:59:20 2012 From: johnl at iecc.com (John Levine) Date: 8 Jun 2012 21:59:20 -0000 Subject: Dear Linkedin, In-Reply-To: Message-ID: <20120608215920.33274.qmail@joyce.lan> >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. Given that most compromised passwords these days are stolen by malware or phishing, I'm not understanding the threat, unless you're planning to change passwords more frequently than the interval between malware stealing your password and the bad guys using it. I agree that keeping a big file of unsalted hashes is a dumb idea, but there isn't much that users can do about services so inept as to do that. R's, John From cidr-report at potaroo.net Fri Jun 8 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Jun 2012 22:00:00 GMT Subject: BGP Update Report Message-ID: <201206082200.q58M00b7039966@wattle.apnic.net> BGP Update Report Interval: 31-May-12 -to- 07-Jun-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8452 143220 7.0% 131.8 -- TE-AS TE-AS 2 - AS8402 52088 2.5% 37.5 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 49055 2.4% 60.6 -- BSNL-NIB National Internet Backbone 4 - AS19318 36813 1.8% 1673.3 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 5 - AS35994 34504 1.7% 985.8 -- AKAMAI-AS - Akamai Technologies, Inc. 6 - AS12479 27374 1.3% 346.5 -- UNI2-AS France Telecom Espana SA 7 - AS3549 20534 1.0% 211.7 -- GBLX Global Crossing Ltd. 8 - AS17813 19135 0.9% 147.2 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 9 - AS13118 17847 0.9% 482.4 -- ASN-YARTELECOM OJSC Rostelecom 10 - AS786 17391 0.8% 87.4 -- JANET The JNT Association 11 - AS8926 17239 0.8% 12.1 -- MOLDTELECOM-AS Moldtelecom SE 12 - AS35041 17150 0.8% 65.2 -- NET-CRYSTONE-STHLM Crystone Autonomous Network Stockholm 13 - AS5800 14979 0.7% 57.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - AS36856 13702 0.7% 6851.0 -- MOZILLA-CORP - Mozilla Corporation 15 - AS29512 13516 0.7% 2703.2 -- TVK-WROC-AS TVK Tel-Ka Wroclaw 16 - AS7552 12127 0.6% 9.4 -- VIETEL-AS-AP Vietel Corporation 17 - AS47602 10882 0.5% 217.6 -- PROFISOL-AS SC PROFISOL TELECOM SRL 18 - AS28573 10235 0.5% 8.8 -- NET Servicos de Comunicao S.A. 19 - AS11664 10193 0.5% 38.8 -- Techtel LMDS Comunicaciones Interactivas S.A. 20 - AS28306 9861 0.5% 1095.7 -- TC Net Inform?tica e Telecomunica??es LTDA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS36856 13702 0.7% 6851.0 -- MOZILLA-CORP - Mozilla Corporation 2 - AS26249 3092 0.1% 3092.0 -- MAI-CRO - MAI 3 - AS29512 13516 0.7% 2703.2 -- TVK-WROC-AS TVK Tel-Ka Wroclaw 4 - AS17621 2347 0.1% 2347.0 -- CNCGROUP-SH China Unicom Shanghai network 5 - AS19318 36813 1.8% 1673.3 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 6 - AS19647 7011 0.3% 1402.2 -- HPOD20001 - Hewlett-Packard Operation Division 7 - AS1997 3352 0.2% 1117.3 -- IBMDES-AS - IBM Dallas Engineering & Scientific 8 - AS28306 9861 0.5% 1095.7 -- TC Net Inform?tica e Telecomunica??es LTDA 9 - AS35994 34504 1.7% 985.8 -- AKAMAI-AS - Akamai Technologies, Inc. 10 - AS55665 966 0.1% 966.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 11 - AS29126 860 0.0% 860.0 -- DATIQ-AS Datiq B.V. 12 - AS26896 1703 0.1% 567.7 -- D102-ITC - Data 102, LLC 13 - AS10455 7672 0.4% 548.0 -- LUCENT-CIO - Lucent Technologies Inc. 14 - AS30944 499 0.0% 499.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD" 15 - AS48068 483 0.0% 483.0 -- VISONIC Visonic Ltd 16 - AS13118 17847 0.9% 482.4 -- ASN-YARTELECOM OJSC Rostelecom 17 - AS36948 873 0.0% 436.5 -- KENIC 18 - AS3 417 0.0% 1756.0 -- BGTEL-AS BGTEL's AS Number 19 - AS57201 406 0.0% 406.0 -- EDF-AS Estonian Defence Forces 20 - AS20211 406 0.0% 406.0 -- HWI-ASN00 - Henry Wurst, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 17667 0.8% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 63.245.221.0/24 13697 0.6% AS36856 -- MOZILLA-CORP - Mozilla Corporation 3 - 69.31.106.0/23 12726 0.6% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 4 - 23.65.27.0/24 10853 0.5% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 5 - 23.2.6.0/23 10853 0.5% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 6 - 41.43.147.0/24 9282 0.4% AS8452 -- TE-AS TE-AS 7 - 62.36.252.0/22 7967 0.4% AS12479 -- UNI2-AS France Telecom Espana SA 8 - 62.36.249.0/24 6540 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 9 - 62.36.241.0/24 6195 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 62.36.210.0/24 6071 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 11 - 59.177.48.0/20 5994 0.3% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 12 - 194.63.9.0/24 5098 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 149.77.236.0/22 4200 0.2% AS4195 -- DE-SHAW-AS DE SHAW 14 - 195.140.236.0/22 3966 0.2% AS29512 -- TVK-WROC-AS TVK Tel-Ka Wroclaw 15 - 94.231.224.0/20 3661 0.2% AS29512 -- TVK-WROC-AS TVK Tel-Ka Wroclaw 16 - 193.19.212.0/22 3661 0.2% AS29512 -- TVK-WROC-AS TVK Tel-Ka Wroclaw 17 - 200.115.64.0/21 3358 0.1% AS19318 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 18 - 69.10.32.0/19 3357 0.1% AS19318 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 19 - 202.53.73.0/24 3354 0.1% AS19318 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 20 - 129.42.191.0/24 3346 0.1% AS1997 -- IBMDES-AS - IBM Dallas Engineering & Scientific Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 8 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Jun 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201206082200.q58M00QD039961@wattle.apnic.net> This report has been generated at Fri Jun 8 21:12:37 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 01-06-12 415005 242289 02-06-12 415008 242419 03-06-12 415143 242530 04-06-12 414957 242433 05-06-12 415378 242704 06-06-12 415605 242487 07-06-12 415516 242302 08-06-12 415656 242304 AS Summary 41397 Number of ASes in routing system 17290 Number of ASes announcing only one prefix 3409 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113033952 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 08Jun12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 415813 242299 173514 41.7% All ASes AS6389 3409 195 3214 94.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS22773 1644 135 1509 91.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7029 3291 1783 1508 45.8% WINDSTREAM - Windstream Communications Inc AS4766 2645 1184 1461 55.2% KIXS-AS-KR Korea Telecom AS18566 2091 706 1385 66.2% COVAD - Covad Communications Co. AS28573 1923 555 1368 71.1% NET Servicos de Comunicao S.A. AS2118 1226 14 1212 98.9% RELCOM-AS OOO "NPO Relcom" AS4323 1575 387 1188 75.4% TWTC - tw telecom holdings, inc. AS10620 1932 764 1168 60.5% Telmex Colombia S.A. AS1785 1918 809 1109 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1590 538 1052 66.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7303 1437 450 987 68.7% Telecom Argentina S.A. AS7552 1173 214 959 81.8% VIETEL-AS-AP Vietel Corporation AS26615 902 32 870 96.5% Tim Celular S.A. AS8151 1500 686 814 54.3% Uninet S.A. de C.V. AS18101 949 159 790 83.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS17974 1928 1160 768 39.8% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4808 1103 346 757 68.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9394 846 160 686 81.1% CRNET CHINA RAILWAY Internet(CRNET) AS13977 808 125 683 84.5% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS3356 1104 467 637 57.7% LEVEL3 Level 3 Communications AS17676 691 74 617 89.3% GIGAINFRA Softbank BB Corp. AS30036 1426 819 607 42.6% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS19262 997 398 599 60.1% VZGNI-TRANSIT - Verizon Online LLC AS22561 1012 417 595 58.8% DIGITAL-TELEPORT - Digital Teleport Inc. AS8452 1375 784 591 43.0% TE-AS TE-AS AS4780 842 271 571 67.8% SEEDNET Digital United Inc. AS24560 1029 459 570 55.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3549 997 440 557 55.9% GBLX Global Crossing Ltd. AS22047 583 31 552 94.7% VTR BANDA ANCHA S.A. Total 43946 14562 29384 66.9% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.188.64.0/18 AS29544 MAURITEL-AS Mauritanian Telecommunication Company 41.188.96.0/21 AS8346 SONATEL-AS Autonomous System 41.188.104.0/21 AS8346 SONATEL-AS Autonomous System 41.188.112.0/21 AS8346 SONATEL-AS Autonomous System 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.18.128.0/19 AS14037 64.18.128.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 64.18.143.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 64.18.159.0/24 AS14037 64.66.32.0/20 AS18864 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.172.64.0/19 AS6408 PRADO - Prado Internet Access INc. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 EOS - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 98.159.96.0/20 AS46975 100.100.0.0/16 AS9198 KAZTELECOM-AS JSC Kazakhtelecom 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.136.17.0/24 AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.12.224.0/20 AS26285 172.14.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.15.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 190.114.160.0/23 AS22927 Telefonica de Argentina 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/21 AS14754 Telgua 200.106.128.0/20 AS3257 TINET-BACKBONE Tinet SpA 200.115.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.122.134.0/24 AS38615 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.8.216.0/21 AS14037 204.8.216.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 204.8.218.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 204.8.220.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 204.8.222.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.250.224.0/19 AS14037 209.250.227.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.228.0/23 AS14037 209.250.230.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.232.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.235.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.237.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.238.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.241.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.242.0/24 AS14037 209.250.245.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.247.0/24 AS14037 209.250.248.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.250.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.251.0/24 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 209.250.254.0/24 AS39323 209.250.255.0/24 AS46496 213.150.202.0/24 AS8513 SKYVISION SkyVision Global Networks Ltd 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From joesox at gmail.com Fri Jun 8 17:01:59 2012 From: joesox at gmail.com (JoeSox) Date: Fri, 8 Jun 2012 15:01:59 -0700 Subject: Password safes &c. (was: Dear Linkedin,) In-Reply-To: References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> <20120608204838.GG10216@dyn.com> Message-ID: On Fri, Jun 8, 2012 at 2:00 PM, Tyler Haske wrote: > KeePass, KeyPassDroid and Dropbox. > > I'm sure it will just get simpler as time goes on. I second this! I deploy KeePass via MS GPO. No formal training on the application for the end-users but we do one-on-one with end users when we can. I have converted a bunch of users to Keepass. I personally use the KeyPassDroid and Dropbox which is good for end users even if they forget their windows sign-in or need a SSID login. We have some roboform users that think its great, which I don't doubt but I say to them I paid $0 for keepass how much did you pay? -- Joe From owen at delong.com Fri Jun 8 17:03:31 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Jun 2012 15:03:31 -0700 Subject: Open DNS Resolver reflection attack Mitigation In-Reply-To: <20120608201127.GA24608@sources.org> References: <4FD24DD0.5000408@ttec.com> <20120608192605.GA19427@sources.org> <9EAC3D5B-BAFA-437F-94E9-673E67806F3A@delong.com> <20120608201127.GA24608@sources.org> Message-ID: On Jun 8, 2012, at 1:11 PM, Stephane Bortzmeyer wrote: > On Fri, Jun 08, 2012 at 12:56:23PM -0700, > Owen DeLong wrote > a message of 28 lines which said: > >> IPv6 should be a simple matter of putting the same line in your >> ip6tables file. > > My experience with attack mitigation is that tools do not always work > as advertised and sometimes do bad things (such as crashing the > machine). So, I agree, it "should be a simple matter" but I prefer to > test first. > I'm using a much simpler: -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -m limit --limit 30/minute --limit-burst 90 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -m limit --limit 30/minute --limit-burst 90 -j ACCEPT (v4 and v6 identical rules) and it seems to be working so far. YMMV. > [For instance, my IPv4 rule required a maximum of 2^28 buckets in > memory while an IPv6 rule with --hashlimit-srcmask 64 would require a > maximum of 2^64 buckets... What will be the effect on the system > memory?] > True, but, if you leave 28 in place, it will only require 2^28 buckets for IPv6 as well. You might want to bump up the allowed qps since there can be quite a few more hosts per /28, but, otherwise should still be reasonably feasible. Owen From djahandarie at gmail.com Fri Jun 8 17:11:10 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Fri, 8 Jun 2012 18:11:10 -0400 Subject: The Cidr Report In-Reply-To: <201206082200.q58M00QD039961@wattle.apnic.net> References: <201206082200.q58M00QD039961@wattle.apnic.net> Message-ID: On Fri, Jun 8, 2012 at 6:00 PM, wrote: > AS6389 ? ? ?3409 ? ? ?195 ? ? 3214 ? ?94.3% ? BELLSOUTH-NET-BLK - > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? BellSouth.net Inc. It wouldn't be The Internet if BellSouth didn't top the idiot list every single time for the past 3 years. -- Darius Jahandarie From owen at delong.com Fri Jun 8 17:17:25 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Jun 2012 15:17:25 -0700 Subject: Dear Linkedin, In-Reply-To: References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> Message-ID: <6274D4F1-B72D-417E-A3AF-95B9644173E9@delong.com> On Jun 8, 2012, at 1:41 PM, Alec Muffett wrote: >> PS: when security is hard, people simply don't do it. Blaming the victim >> of poor engineering that leads people to not be able to perform best >> practices is not the answer. > > Passwords suck, but they are the best that we have at the moment in terms of being cheap and free from infrastructure - see http://goo.gl/3lggk > > We've been in a bubble for the past few years, where Moore's law hardware had not quite caught up with the speed of SHA and MD5 password hashing throughput for effective brute force guessing; that bubble is well and truly burst. > > Welcome back to 1995 where the advice is to change your passwords frequently, because it has a half-life of usefulness imposed upon it from (a) day to day external exposure and (b) the march of technology - and keep your hashing algorithms up to date, too. See http://goo.gl/iL9EP for suggestions. > > Have a nice weekend, > > -a > Would it really be that hard to release a coordinated One-Time Password system that consumers could readily use across multiple sites? Owen From rsk at gsp.org Fri Jun 8 17:27:52 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 8 Jun 2012 18:27:52 -0400 Subject: Dear Linkedin, [and proposed mitigation approach] In-Reply-To: <4FD25716.3000801@mtcc.com> References: <4FD25716.3000801@mtcc.com> Message-ID: <20120608222752.GA16312@gsp.org> On Fri, Jun 08, 2012 at 12:48:38PM -0700, Michael Thomas wrote: > 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. Um, no. If the site in question has security issues sufficiently egregious that someone can obtain the hashed password table (particularly if it's one that's unsalted...and I'm looking at you, LinkedIn) then we can presume that any reasonably competent attackers can and will acquire it more than once. (That is, they won't post it publicly and ask for help...because they don't need any help. I strongly suspect that this is history, not a prediction.) Changed hashes between successive retrievals indicate account access which in turn indicate live accounts which in turn indicate accounts of higher value which in turn should mean that password cracking resources (such as botnets and clouds) are best focused on those. (Of course if the site is blithely allowing brute-force attacks ad infinitum, then this gets even worse.) And the process of "changing passwords" is fraught with its own issues, particularly when done via portable devices...like, say, smartphones with keystroke loggers installed. CarrierIQ, anyone? And what about (other) malware resident on user systems? Is it better (a) for a user to never log into example.com, thus never presenting their username/password pair for harvesting by malware or (b) to be compelled to log into example.com every few months...thus given resident malware a fresh shot at capturing this information? (Information which, by the way, is probably in use at other sites.) Then there are the human factors: encouraging someone to frequently update their password is contrary to encouraging them to select, memorize and use a strong password. Yet the latter is exactly what we want users to do. One way to mitigate -- but not solve -- this problem is for sites to stop retaining so much data: you can't surrender a secret you don't have. Sites need to use a system of account expiration to purge their rolls of disused accounts which no longer serve any purpose -- except to crackers who may find that X's password from some site that X last visited in 2007 may be quite useful elsewhere in 2012. This is a relatively simple process to implement, and it's something that some mailing lists have done for years. "Your subscription is expiring unless you do the following dance" doesn't work perfectly, but it's at least comprehensible to the overwhelming majority of end users because it fits conceptual models that they've seen elsewhere. Of course this would mean that example.com would have to stop bragging about its 4 million users and admit that 3.7 million of them haven't been there more than once, thus its actual real live user base is 300K and won't the advertisers be VERY interested in that number? So the question becomes: does example.com really, truly, want to try to mitigate the risk to its users by aging out old and disused account data, or does it want to try to keep its stock price propped up and make its 3Q numbers based on a user count that's largely fictional? Yes, well, I'm being cynical but I'm also serious: there are undoubtedly kazillions of completely disused accounts splattered across a hundred thousand web sites. Every single one of those that's deleted incrementally reduces aggregate risk, and if they're not actually being used, then there's no *technical* reason why they should remain. As I said above, this isn't a solution: it's just mitigation. But it appears from this thread and many, many others over the years that we're some way off from a solution, so can't we at least agree to do what we can to shrink the size of the problem while we're arguXXXXdebating how to solve it? ---rsk From hmurray at megapathdsl.net Fri Jun 8 17:33:29 2012 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 08 Jun 2012 15:33:29 -0700 Subject: Dear Linkedin, Message-ID: <20120608223329.4683E80003B@ip-64-139-1-69.sjc.megapath.net> >> 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. From morrowc.lists at gmail.com Fri Jun 8 17:34:00 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 8 Jun 2012 18:34:00 -0400 Subject: The Cidr Report In-Reply-To: References: <201206082200.q58M00QD039961@wattle.apnic.net> Message-ID: On Fri, Jun 8, 2012 at 6:11 PM, Darius Jahandarie wrote: > On Fri, Jun 8, 2012 at 6:00 PM, ? wrote: >> AS6389 ? ? ?3409 ? ? ?195 ? ? 3214 ? ?94.3% ? BELLSOUTH-NET-BLK - >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? BellSouth.net Inc. > > It wouldn't be The Internet if BellSouth didn't top the idiot list > every single time for the past 3 years. is it the 'idiot list' or 'list of people who use OER' ? From alec.muffett at gmail.com Fri Jun 8 17:55:39 2012 From: alec.muffett at gmail.com (Alec Muffett) Date: Fri, 8 Jun 2012 23:55:39 +0100 Subject: Dear Linkedin, In-Reply-To: <20120608215920.33274.qmail@joyce.lan> References: <20120608215920.33274.qmail@joyce.lan> Message-ID: <0CA90864-EC88-4C69-915F-48C12629A7E8@gmail.com> On 8 Jun 2012, at 22:59, John Levine wrote: > Given that most compromised passwords these days are stolen by malware > or phishing, I'm not understanding the threat, unless you're planning > to change passwords more frequently than the interval between malware > stealing your password and the bad guys using it. > > I agree that keeping a big file of unsalted hashes is a dumb idea, but > there isn't much that users can do about services so inept as to do Hi John, I can't easily reconcile the statement that "most passwords ? are stolen by malware/phishing" with the subsequent para referring to the likes of LinkedIn (6.5 million apparently without usernames) or Playstation Network (77 million with PII) or RockYou (32 million IDs) ? but then I lack stats for the former, perhaps you can tell me how many tens-of-millions of people got phished last year? Creditcards scraped by malware may touch that number, but might be themselves outpaced by wholesale CC database theft. Sometimes password changing is done for reducing the window of opportunity, other times it is for education, yet more times it's for both, or to get everyone to refresh their password so the new Bcrypt or SHA512crypt hash algorithm can be enabled and the crummy old short Unix passwords (aaU..z/8FAYEc) can be expunged. With the right tools your identity can be quite (shall we say?) agile and involve a lot of hard work for bad guys to hit. That's the goal. Turning the matter on its head: How tragic would it be for someone still to be using the same password that they were using in the Playstation hack, 14 months after the event? Is 14 months a excusable length of time for someone not to have changed their password after a break? I would say not - but then would 6 months be any more excusable? Or 3 months? How long is it excusable to not get around to changing a known-to-be-hacked password? And what if you don't know you've been hacked? In this game of diminishing time windows and not being sure about whether User-A's password was taken but User-B's was not, perhaps the best strategy is to assume that all passwords are likely broken after a period of time and to change all of them - but that idea does not appeal to everyone; I can see why, but perhaps my goals are different. -a From djahandarie at gmail.com Fri Jun 8 17:55:45 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Fri, 8 Jun 2012 18:55:45 -0400 Subject: The Cidr Report In-Reply-To: References: <201206082200.q58M00QD039961@wattle.apnic.net> Message-ID: On Fri, Jun 8, 2012 at 6:34 PM, Christopher Morrow wrote: > On Fri, Jun 8, 2012 at 6:11 PM, Darius Jahandarie wrote: >> On Fri, Jun 8, 2012 at 6:00 PM, ? wrote: >>> AS6389 ? ? ?3409 ? ? ?195 ? ? 3214 ? ?94.3% ? BELLSOUTH-NET-BLK - >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? BellSouth.net Inc. >> >> It wouldn't be The Internet if BellSouth didn't top the idiot list >> every single time for the past 3 years. > > is it the 'idiot list' or 'list of people who use OER' ? You can do traffic engineering without polluting the global routing table (by tagging the more specifics with no advertise), so vendor-supported or not, I still call it the idiot list. -- Darius Jahandarie From djahandarie at gmail.com Fri Jun 8 17:57:21 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Fri, 8 Jun 2012 18:57:21 -0400 Subject: The Cidr Report In-Reply-To: References: <201206082200.q58M00QD039961@wattle.apnic.net> Message-ID: On Fri, Jun 8, 2012 at 6:55 PM, Darius Jahandarie wrote: > On Fri, Jun 8, 2012 at 6:34 PM, Christopher Morrow > wrote: >> On Fri, Jun 8, 2012 at 6:11 PM, Darius Jahandarie wrote: >>> On Fri, Jun 8, 2012 at 6:00 PM, ? wrote: >>>> AS6389 ? ? ?3409 ? ? ?195 ? ? 3214 ? ?94.3% ? BELLSOUTH-NET-BLK - >>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? BellSouth.net Inc. >>> >>> It wouldn't be The Internet if BellSouth didn't top the idiot list >>> every single time for the past 3 years. >> >> is it the 'idiot list' or 'list of people who use OER' ? > > You can do traffic engineering without polluting the global routing > table (by tagging the more specifics with no advertise), so > vendor-supported or not, I still call it the idiot list. But maybe the "probably an idiot list" would be more accurate in the end. -- Darius Jahandarie From alec.muffett at gmail.com Fri Jun 8 18:05:09 2012 From: alec.muffett at gmail.com (Alec Muffett) Date: Sat, 9 Jun 2012 00:05:09 +0100 Subject: Dear Linkedin, In-Reply-To: <20120608223329.4683E80003B@ip-64-139-1-69.sjc.megapath.net> References: <20120608223329.4683E80003B@ip-64-139-1-69.sjc.megapath.net> Message-ID: <3D17BF53-34C1-4CD3-9BD4-4343B5A44E95@gmail.com> > Does anybody have a good URL explaining that idea? It's been kicking around > for many years. I've never seen a convincing writeup. I've tried to do that in another mail - it's in the realms of philosophy more than strategy; like if you're a really security-aware person and take great care you can probably stretch the useful life of a password out to _years_ - but how typical are *you* in that instance? > Does your bank request/require that you change the PIN on your ATM card every > few months? ATM cards are not passwords, they are a coarse form of two-factor authentication - You have the card, you have the PIN. You have to possess both in order to transact - at least in in theory. Compare that with the secrecy surrounding the CVV - the "last three digits on the number on the back of the card" which you are "not meant to tell anyone" and which _will_ be different if your card is lost/stolen and reissued. Now _that_ is a password. > 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. You know, that's not bad. I am pro-paper for long passwords. I am even-more pro "password safes". > 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. It's harder as we get old. Use technology to aid with the heavy lifting. :-) -a From lsc at prgmr.com Fri Jun 8 18:22:15 2012 From: lsc at prgmr.com (Luke S. Crawford) Date: Fri, 8 Jun 2012 19:22:15 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> Message-ID: <20120608232215.GB20888@luke.xen.prgmr.com> On Wed, Jun 06, 2012 at 07:43:42PM -0700, Aaron C. de Bruyn wrote: > Why haven't we taken this out of the hands of website operators yet? > Why can't I use my ssh-agent to sign in to a website just like I do > for about hundred servers, workstations, and my PCs at home? > > One local password used everywhere that can't be compromised through > website stupidity... This is the way to go. The problem here is that x.509 is the only similar thing for browsers, and x509 requires a ca, which makes the whole process a whole lot more complext than the 'just give me the public half of the key you want to use to authenticate to this service' I mean, unless everyone trusts the same (few) CAs, which has a different set of problems. I haven't found any way that is as simple and as portable as using ssh that works in a web browser. I'm considering re-writing my billing application to be libcurses based or something, and letting users access that through ssh, too. (It would be silly, but it might work for me; it goes along with my schtick.) This would be somewhat suboptimal for things like bandwidth graphs, but eh. but yeah, if someone wants to pass the hat to get an apache module and a firefox addon written to do public key authentication over http using ssh keys, I'd put a couple hundred bucks in the hat. From ml-nanog090304q at elcsplace.com Fri Jun 8 19:59:46 2012 From: ml-nanog090304q at elcsplace.com (Ted Cooper) Date: Sat, 09 Jun 2012 10:59:46 +1000 Subject: Dear Linkedin, In-Reply-To: <4FD25716.3000801@mtcc.com> References: <4FD25716.3000801@mtcc.com> Message-ID: <4FD2A002.2060808@elcsplace.com> On 09/06/12 05:48, Michael Thomas wrote: > 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. They have some things correct in this and some are complete hogwash. Changing your password does not provide any additional security. It is meant to give protection against your credentials having being discovered, but if they have been compromised in that way, they'll have the one you change it to in next to no time too. If the hashes have been compromised, then yes, it's time to change the password. Having a different password for every website is very important though, as demonstrated many times when these lists of passwords and associated usernames turn up. Anyone who uses the same password on multiple sites will find that they have their accounts on multiple services accessed instead of just the original. What is needed are unique, highly difficult to guess passwords for each of them and that's where something like a password safe comes in. KeePassX is a cross platform and can be configured so that it needs a key file and password. I keep several of them with varying levels of importance. My banking details safe is only opened on a very secure computer. What LinkedIn need to do is improve their security so that they don't leak hashed passwords. Giving mostly correct advice like this shouldn't need to be prompted by a large security event. From valdis.kletnieks at vt.edu Fri Jun 8 20:04:10 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 08 Jun 2012 21:04:10 -0400 Subject: Dear Linkedin, In-Reply-To: Your message of "Fri, 08 Jun 2012 16:07:56 -0400." <4FD25B9C.5050906@viagenie.ca> References: <4FD25716.3000801@mtcc.com> <4FD25B9C.5050906@viagenie.ca> Message-ID: <2890.1339203850@turing-police.cc.vt.edu> On Fri, 08 Jun 2012 16:07:56 -0400, Simon Perreault said: > And how about "Do not store your passwords using unsalted sha1?" Heck. I'd let them use pepper or mustard or teriyaki sauce if they wanted. Figuring out which one was used adds to the entropy. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mike at mtcc.com Fri Jun 8 20:29:18 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 08 Jun 2012 18:29:18 -0700 Subject: Dear Linkedin, In-Reply-To: <4FD2A002.2060808@elcsplace.com> References: <4FD25716.3000801@mtcc.com> <4FD2A002.2060808@elcsplace.com> Message-ID: <4FD2A6EE.4010008@mtcc.com> On 06/08/2012 05:59 PM, Ted Cooper wrote: > > They have some things correct in this and some are complete hogwash. > > Changing your password does not provide any additional security. It is > meant to give protection against your credentials having being > discovered, but if they have been compromised in that way, they'll have > the one you change it to in next to no time too. If the hashes have been > compromised, then yes, it's time to change the password. > > Having a different password for every website is very important though, > as demonstrated many times when these lists of passwords and associated > usernames turn up. Anyone who uses the same password on multiple sites > will find that they have their accounts on multiple services accessed > instead of just the original. I agree that it's important, but everything about the current state of affairs makes that impossible except for geeks that care about password vaults, apparently. The great unwashed masses, however, do not do this and there is no reason to expect that they will do it any time soon. My own experience with auto-generating hard passwords and dealing with password recovery is that it seems to work really well, and that it puts the onus on the *website* instead of the user. Every browser has a password rememberer these days that happily fills in your username and password. Every app that needs access can do the same thing. It doesn't get you key rotation [*], but with passwords which are essentially random and unique per site it's less necessary because you don't have the cross-site contamination vulnerability. Mike [*] key rotation is largely orthogonal, but I suppose that it's feasible to cook up a scheme that even got you that. From valdis.kletnieks at vt.edu Fri Jun 8 20:30:00 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 08 Jun 2012 21:30:00 -0400 Subject: Dear Linkedin, In-Reply-To: Your message of "Fri, 08 Jun 2012 15:33:29 -0700." <20120608223329.4683E80003B@ip-64-139-1-69.sjc.megapath.net> References: <20120608223329.4683E80003B@ip-64-139-1-69.sjc.megapath.net> Message-ID: <3717.1339205400@turing-police.cc.vt.edu> On Fri, 08 Jun 2012 15:33:29 -0700, Hal Murray said: > > 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. Gene Spafford did a nice analysis of the *contrary* a while ago, that changing and expiring passwords is essentially useless against the current threat model (he was writing about mandatory changes, but all the arguments hold up just fine for "should be changed" as well): http://www.cerias.purdue.edu/site/blog/post/password-change-myths/ http://www.cerias.purdue.edu/site/blog/post/passwords-and-myth/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From hmurray at megapathdsl.net Fri Jun 8 20:58:02 2012 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 08 Jun 2012 18:58:02 -0700 Subject: Dear Linkedin, [and proposed mitigation approach Message-ID: <20120609015802.C4F4880003B@ip-64-139-1-69.sjc.megapath.net> > 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. From nanog-post at rsuc.gweep.net Fri Jun 8 21:12:27 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 8 Jun 2012 22:12:27 -0400 Subject: Dear Linkedin, In-Reply-To: <6274D4F1-B72D-417E-A3AF-95B9644173E9@delong.com> References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <4FD25F86.6070908@paulgraydon.co.uk> <4FD260F2.7000407@mtcc.com> <6274D4F1-B72D-417E-A3AF-95B9644173E9@delong.com> Message-ID: <20120609021227.GA80990@gweep.net> On Fri, Jun 08, 2012 at 03:17:25PM -0700, Owen DeLong wrote: > > On Jun 8, 2012, at 1:41 PM, Alec Muffett wrote: > > >> PS: when security is hard, people simply don't do it. Blaming the victim > >> of poor engineering that leads people to not be able to perform best > >> practices is not the answer. > > > > Passwords suck, but they are the best that we have at the moment in terms of being cheap and free from infrastructure - see http://goo.gl/3lggk > > > > We've been in a bubble for the past few years, where Moore's law hardware had not quite caught up with the speed of SHA and MD5 password hashing throughput for effective brute force guessing; that bubble is well and truly burst. > > > > Welcome back to 1995 where the advice is to change your passwords frequently, because it has a half-life of usefulness imposed upon it from (a) day to day external exposure and (b) the march of technology - and keep your hashing algorithms up to date, too. See http://goo.gl/iL9EP for suggestions. > > > > Have a nice weekend, > > > > -a > > > > Would it really be that hard to release a coordinated One-Time > Password system that consumers could readily use across multiple > sites? Doesn't seem *that* hard; my current employer has done quite a bit of heavy lifiting for you: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en http://code.google.com/p/google-authenticator/ [yes iOS and blackberry as well] Also, if you just want very lightweight implementation for paper codes, try http://code.google.com/p/otpauth/ -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From ops.lists at gmail.com Fri Jun 8 21:19:02 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 9 Jun 2012 07:49:02 +0530 Subject: My view of the arin db boarked? In-Reply-To: References: Message-ID: The only mention I can find of AS14037 in nanog, funnily enough, is my own post about it .. http://www.gossamer-threads.com/lists/nanog/users/110097 On Sat, Jun 9, 2012 at 1:57 AM, Christopher Morrow wrote: > If I look at the ASN in particular: AS14037 > no records exist for that in ARIN's WHOIS database either ;( If I look > at all the networks announced by AS14037: > 14037 ? | 204.8.216.0/21 ? ? ?| > 14037 ? | 209.250.224.0/19 ? ?| > 14037 ? | 209.250.228.0/23 ? ?| > 14037 ? | 209.250.242.0/24 ? ?| > 14037 ? | 209.250.247.0/24 ? ?| > 14037 ? | 64.18.128.0/19 ? ? ?| > 14037 ? | 64.18.159.0/24 ? ? ?| > > > none of them have any records in the ARIN WHOIS database :( The > upstream for this network is ?AS 27431 - JTL Networks > who seems to get transit/peer with 3356/174. -- Suresh Ramasubramanian (ops.lists at gmail.com) From hmurray at megapathdsl.net Fri Jun 8 23:42:59 2012 From: hmurray at megapathdsl.net (Hal Murray) Date: Fri, 08 Jun 2012 21:42:59 -0700 Subject: Dear Linkedin, Message-ID: <20120609044259.9BF6880003B@ip-64-139-1-69.sjc.megapath.net> >> Does your bank request/require that you change the PIN >> on your ATM card every few months? > ATM cards are not passwords, they are a coarse form of two-factor > authentication - You have the card, you have the PIN. > You have to possess both in order to transact - at least in in theory. > Compare that with the secrecy surrounding the CVV - the "last three digits > on the number on the back of the card" which you are "not meant to tell > anyone" and which _will_ be different if your card is lost/stolen and > reissued. If I'm not supposed to not "tell anyone", why is it even printed where I can read it? ---- [Context is only having so-many brain cycles to memorize passwords.] > It's harder as we get old. Use technology to aid with the heavy lifting. :-) Right. But the meta problem is figuring out which technology to trust. Phishing is the tip of the iceberg on social engineering. So far, the bad guys are winning. -- These are my opinions. I hate spam. From eyeronic.design at gmail.com Sat Jun 9 00:17:31 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 8 Jun 2012 22:17:31 -0700 Subject: Dear Linkedin, In-Reply-To: <20120609044259.9BF6880003B@ip-64-139-1-69.sjc.megapath.net> References: <20120609044259.9BF6880003B@ip-64-139-1-69.sjc.megapath.net> Message-ID: Are the bad guys winning though? Are they really? On Jun 8, 2012 9:43 PM, "Hal Murray" wrote: > > >> Does your bank request/require that you change the PIN > >> on your ATM card every few months? > > > ATM cards are not passwords, they are a coarse form of two-factor > > authentication - You have the card, you have the PIN. > > > You have to possess both in order to transact - at least in in theory. > > > Compare that with the secrecy surrounding the CVV - the "last three > digits > > on the number on the back of the card" which you are "not meant to tell > > anyone" and which _will_ be different if your card is lost/stolen and > > reissued. > > If I'm not supposed to not "tell anyone", why is it even printed where I > can > read it? > > ---- > > [Context is only having so-many brain cycles to memorize passwords.] > > > It's harder as we get old. Use technology to aid with the heavy > lifting. :-) > > Right. But the meta problem is figuring out which technology to trust. > > Phishing is the tip of the iceberg on social engineering. So far, the bad > guys are winning. > > > > > > -- > These are my opinions. I hate spam. > > > > > From christopher.morrow at gmail.com Sat Jun 9 00:48:04 2012 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sat, 9 Jun 2012 01:48:04 -0400 Subject: My view of the arin db boarked? In-Reply-To: References: Message-ID: On Fri, Jun 8, 2012 at 10:19 PM, Suresh Ramasubramanian wrote: > The only mention I can find of AS14037 in nanog, funnily enough, is my > own post about it .. > > http://www.gossamer-threads.com/lists/nanog/users/110097 it looks like cogent stopped propogating the prefixes in question... helo 3356, are you out there? > On Sat, Jun 9, 2012 at 1:57 AM, Christopher Morrow > wrote: >> If I look at the ASN in particular: AS14037 >> no records exist for that in ARIN's WHOIS database either ;( If I look >> at all the networks announced by AS14037: >> 14037 ? | 204.8.216.0/21 ? ? ?| >> 14037 ? | 209.250.224.0/19 ? ?| >> 14037 ? | 209.250.228.0/23 ? ?| >> 14037 ? | 209.250.242.0/24 ? ?| >> 14037 ? | 209.250.247.0/24 ? ?| >> 14037 ? | 64.18.128.0/19 ? ? ?| >> 14037 ? | 64.18.159.0/24 ? ? ?| >> >> >> none of them have any records in the ARIN WHOIS database :( The >> upstream for this network is ?AS 27431 - JTL Networks >> who seems to get transit/peer with 3356/174. > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) From hmurray at megapathdsl.net Sat Jun 9 02:06:11 2012 From: hmurray at megapathdsl.net (Hal Murray) Date: Sat, 09 Jun 2012 00:06:11 -0700 Subject: CVV numbers Message-ID: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> 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. From link at pobox.com Sat Jun 9 06:29:18 2012 From: link at pobox.com (Terje Bless) Date: Sat, 9 Jun 2012 13:29:18 +0200 Subject: Dear Linkedin, In-Reply-To: <4FD25716.3000801@mtcc.com> References: <4FD25716.3000801@mtcc.com> Message-ID: On Fri, Jun 8, 2012 at 9:48 PM, Michael Thomas wrote: > Linkedin has a blog post that ends with this sage advice: The sagest of which is to ask you to change your password on LinkedIn itself, *before* actually plugging the hole that led to the passwords leaking in the first place. Almost as sagely, they're only invalidating the passwords positively identified as having leaked, rather than assume all have, despite several security researchers concluding that the passwords that were posted publically were only a subset of those that were stolen. -link From peterehiwe at gmail.com Sat Jun 9 06:45:46 2012 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Sat, 9 Jun 2012 12:45:46 +0100 Subject: AUT-NUM ROUTE OBJECT In-Reply-To: <4FD22F54.8070102@foobar.org> References: <4FD22F54.8070102@foobar.org> Message-ID: This has been sorted out now. On Fri, Jun 8, 2012 at 5:59 PM, Nick Hilliard wrote: > On 08/06/2012 17:55, Peter Ehiwe wrote: > > Authorisation for parent [as-block] > > using mnt-lower: > > not authenticated by: RIPE-NCC-RPSL-MNT > > http://apps.db.ripe.net/whois/lookup/ripe/mntner/RIPE-NCC-RPSL-MNT.html > > Nick > > -- Warm Regards Peter(CCIE 23782). From shrdlu at deaddrop.org Sat Jun 9 09:14:42 2012 From: shrdlu at deaddrop.org (Lynda) Date: Sat, 09 Jun 2012 07:14:42 -0700 Subject: CVV numbers In-Reply-To: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> Message-ID: <4FD35A52.3030608@deaddrop.org> On 6/9/2012 12:06 AM, Hal Murray wrote: > > 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.) The CVV number is simply to prove that the card is in your possession. The percentage of the sale that goes to Amex/Visa/Mastercard/Discover (etc) is determined by whether the merchant can supply various items, and the CVV is one of them. Running the card physically (where the merchant touches your card, and presumably verifies that you are you) gets taxed the lowest. The CVV is just meant to replace that verification. Sort of. I disapprove *strongly* of any online merchant that does not request this simple item, but it's not magic. > 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 > Should I really take them seriously? No. No you should not. Here's the canonical Wikipedia entry, for those still playing along. http://en.wikipedia.org/wiki/Luhn_algorithm There's a few more grown-up words there. The best part is that it's a public algorithm. What's not to like? -- A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures. From jmaslak at antelope.net Sat Jun 9 09:14:38 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Sat, 9 Jun 2012 08:14:38 -0600 Subject: CVV numbers In-Reply-To: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> Message-ID: <35332AB4-0FB4-4CF1-A73C-6CB4A737B472@antelope.net> On Jun 9, 2012, at 1:06 AM, Hal Murray wrote: > Should I really take them seriously? Your call. That said, the purpose of CVV is to stop *one* type of fraud - it's to stop a skimmer from being able to do mail-order/internet-order with your card number. The CVV is not on the magnetic strip, so a skimmer installed at the ATM or gas pump won't be able to capture it. There's a similar value on the magnetic strip that keeps the internet site you gave your card number and CVV to from being able to print cards and use them at the gas pump. Certainly they don't stop all fraud. They stop one type of fraud. From owen at delong.com Sat Jun 9 09:56:52 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 9 Jun 2012 07:56:52 -0700 Subject: CVV numbers In-Reply-To: <4FD35A52.3030608@deaddrop.org> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> Message-ID: <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> On Jun 9, 2012, at 7:14 AM, Lynda wrote: > On 6/9/2012 12:06 AM, Hal Murray wrote: >> >> 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.) > > The CVV number is simply to prove that the card is in your possession. The percentage of the sale that goes to Amex/Visa/Mastercard/Discover (etc) is determined by whether the merchant can supply various items, and the CVV is one of them. Running the card physically (where the merchant touches your card, and presumably verifies that you are you) gets taxed the lowest. The CVV is just meant to replace that verification. Sort of. I disapprove *strongly* of any online merchant that does not request this simple item, but it's not magic. > How does having the CVV number prove the card is in my possession? I have memorized the CVV in addition to the 16 digits of the cards I commonly use and routinely enter them into online ordering without retrieving the card. What prevents a fraudster from writing the CVV down along with the other card data? Sure, the CVV (in the case of CVV2) may not be included in the computer-readable mag-stripe or in swipe transactions, but I really don't see how CVV does anything to prove physical possession of the card at the time of the transaction (or at any time, in fact). >> 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 > >> Should I really take them seriously? > > No. No you should not. Here's the canonical Wikipedia entry, for those still playing along. > > http://en.wikipedia.org/wiki/Luhn_algorithm Luhn seems to apply to the check digit (last of the (usually) 16 digits) on the face of the credit card and not to the CVV value. Owen From nanog-post at rsuc.gweep.net Sat Jun 9 10:13:51 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sat, 9 Jun 2012 11:13:51 -0400 Subject: My view of the arin db boarked? In-Reply-To: References: Message-ID: <20120609151349.GA93705@gweep.net> On Fri, Jun 08, 2012 at 04:27:29PM -0400, Christopher Morrow wrote: > err, last 3 times I asked this I was shown the error of my ways, but > here goes... > > 209.250.228.241 - seems to not have any records in ARIN's WHOIS > database, everythign seems to roll up to the /8 record :( > > I see this routed as a /23: (from routeviews) > BGP routing table entry for 209.250.228.0/23, version 2072545487 > Paths: (33 available, best #19, table Default-IP-Routing-Table) > Not advertised to any peer > 3277 3267 174 27431 14037 > 194.85.102.33 from 194.85.102.33 (194.85.4.4) > Origin IGP, localpref 100, valid, external > Community: 3277:3267 3277:65321 3277:65323 3277:65330 > > If I look at the ASN in particular: AS14037 > no records exist for that in ARIN's WHOIS database either ;( If I look > at all the networks announced by AS14037: > 14037 | 204.8.216.0/21 | > 14037 | 209.250.224.0/19 | > 14037 | 209.250.228.0/23 | > 14037 | 209.250.242.0/24 | > 14037 | 209.250.247.0/24 | If you query filtergen.level3.com, they are expecting to see it from this ASN: Prefix list for policy as14037 = LEVEL3::AS14037 204.8.216.0/21 209.250.224.0/20 > 14037 | 64.18.128.0/19 | > 14037 | 64.18.159.0/24 | ...but not those, which are registered in ALTDB (as the /19)along with the squatted 204.8.216.0/21 and 209.250.224.0/20 route: 64.18.128.0/19 descr: RackVibe LLC origin: AS14037 admin-c: GC373-ARIN tech-c: GC373-ARIN notify: arin at 6gtech.com mnt-by: MNT-6GTECH changed: arin at 6gtech.com 20081007 source: ALTDB > none of them have any records in the ARIN WHOIS database :( The > upstream for this network is AS 27431 - JTL Networks > who seems to get transit/peer with 3356/174. Amusingly, AS27431 is still the RR contacts cording to the IRR. Score another one in the 'inaccurate IRR' column. > It's nice to see folk who use IRR databases to filter their customers > still permit this sort of thing to go on though: AS3356 I'm looking at > you... Here's a clue of future prefixes to watch for 3356 allowing from this particular nest: % whois -h filtergen.level3.com -- "-searchpath=ARIN;RIPE;RADB;ALTDB;LEVEL3 as27431" Prefix list for policy as27431 = ARIN::AS27431 LEVEL3::AS27431 ALTDB::AS27431 RADB::AS27431 RIPE::AS27431 66.132.44.0/24 66.132.45.0/24 66.132.47.0/24 69.36.0.0/20 209.41.200.0/24 209.41.202.0/24 209.115.40.0/24 209.115.41.0/24 209.115.42.0/24 209.115.43.0/24 209.115.108.0/24 216.28.47.0/24 216.28.134.0/24 216.29.53.0/24 216.29.115.0/24 216.29.116.0/24 216.29.117.0/24 216.29.121.0/24 216.29.122.0/24 216.29.152.0/24 216.29.194.0/24 216.29.247.0/24 % > I think first: "Where are the records for this set of ip number resources?" > and second: "Why are we still seeing this on the network with no way > to contact the operators of the resources?" You can try and contact the entities that are called 'RackVibe' accordin and '6G Tech' according to the various IRR registry entries for 14037 and 46496. Sketchy things which geolocate to Seacaucus? Whoda thunk. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From elw at stderr.org Sat Jun 9 11:53:05 2012 From: elw at stderr.org (elijah wright) Date: Sat, 9 Jun 2012 11:53:05 -0500 Subject: Dear Linkedin, In-Reply-To: <20120608130249.BFE61B1B@m0005311.ppops.net> References: <20120608130249.BFE61B1B@m0005311.ppops.net> Message-ID: > :: 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. The 1password password store has a perfectly usable local-only HTML app that lives in its data folder. http://help.agile.ws/1Password3/1passwordanywhere.html It works perfectly well from Linux and other OSes. I keep hoping for a free full-fledged Linux desktop port a la the android one ;-) [Or for seahorse integration, or whatever - I'm as big an open source advocate as nearly anyone, but having 1P on windows, osx, my droid, my ipad, and usable from my linux and solaris desktops... well, it's just too good not to give them a little money and a lot of respect for a good application.] best, --e From nanog-post at rsuc.gweep.net Sat Jun 9 12:21:46 2012 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sat, 9 Jun 2012 13:21:46 -0400 Subject: ITU funsies Message-ID: <20120609172146.GA34314@gweep.net> 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=nanog55 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 From joseph.snyder at gmail.com Sat Jun 9 12:52:45 2012 From: joseph.snyder at gmail.com (joseph.snyder at gmail.com) Date: Sat, 09 Jun 2012 13:52:45 -0400 Subject: Dear Linkedin, In-Reply-To: References: <20120608130249.BFE61B1B@m0005311.ppops.net> Message-ID: <4d6c939a-9751-48fe-8246-87421e1a1377@email.android.com> My biggest problem still is the multiple computer issue. I am on at least 3-5 physical computers and 1-20 virtual machines, and 2 cellphones a day. I honestly do not want to store a database of passwords encrypted or not on an open service. As I have never had a virus or malware on any of my computers in the last 20 something years I trust my local machine/network more. The problem is it creates a distribution problem that is painful and tedious to deal with. So I stick with 10-15 long reasonably secure passwords that get used for stuff that just doesn't matter because there is an assumed no security (facebook, linkedin, whatever, and honestly who cares if this stupid stuff is hacked, its really just to avoid the hassle it would cause) and 1 unique password per critical sites (bank, benefits, financials). I store them on a local 3x3 levels of encrypted virtual drives with (2) 32-48 remembered passwords to access them just in case I forget any. Then I lock the 2 passwords up in a safe in a sealed envelope just in case something happens to me. If you are cautious on what and where you use them you honestly only need to change the criticals once a year or if there is a security event, heck outside of the bank account, I almost never login to any of the other accounts except to change the password. And for all other internet stuff, who cares, the assumption is it will be hacked, don't put stuff on the open internet that you don't want the entire world to know. From acv at miniguru.ca Sat Jun 9 13:18:15 2012 From: acv at miniguru.ca (Alexandre Carmel-Veilleux) Date: Sat, 9 Jun 2012 14:18:15 -0400 Subject: CVV numbers In-Reply-To: <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> Message-ID: <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> On 2012-06-09, at 10:56, Owen DeLong wrote: > > How does having the CVV number prove the card is in my possession? It doesn't, it merely proves you must have handled the card physically at some point since storing that value in a database is forbidden. Verified by Visa and the MasterCard equivalent actually "prove" that you are the rightful card holder. Unlike CVV numbers, they actually exempt the merchant from chargebacks (or did circa 2003). Alex From stephen at sprunk.org Sat Jun 9 13:35:31 2012 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 09 Jun 2012 13:35:31 -0500 Subject: CVV numbers In-Reply-To: <35332AB4-0FB4-4CF1-A73C-6CB4A737B472@antelope.net> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <35332AB4-0FB4-4CF1-A73C-6CB4A737B472@antelope.net> Message-ID: <4FD39773.2020101@sprunk.org> On 09-Jun-12 09:14, Joel Maslak wrote: > On Jun 9, 2012, at 1:06 AM, Hal Murray wrote: >> Should I really take them seriously? > Your call. > > That said, the purpose of CVV is to stop *one* type of fraud - it's to stop a skimmer from being able to do mail-order/internet-order with your card number. The CVV is not on the magnetic strip, so a skimmer installed at the ATM or gas pump won't be able to capture it. This is CVV2; it is printed (but not embossed) on the card but not on the magstripe. This is requested by online merchants to "prove" that the card is in the customer's possession, since it won't show up on carbons, receipts, etc. and in theory will never be stored by any merchant (unlike the account number, expiration date, etc.). . > There's a similar value on the magnetic strip that keeps the internet site you gave your card number and CVV to from being able to print cards and use them at the gas pump. This is CVV1; it is on the magstripe but not printed on the card; this is how brick-and-mortar merchants can "prove" that your card was in the merchant's possession ("card present"), i.e. swiped rather than entered by hand. > Certainly they don't stop all fraud. They stop one type of fraud. The two codes are targeted at very different types of fraud. What they have in common is that submitting either a CVV1 or CVV2 number enables merchants to get a better discount rate on their transactions. Given the low margins in many industries, this can make the difference between making a profit and losing money on a sale, which is why many merchants refuse transactions without CVV1 or CVV2. Merchants in industries with higher margins often don't care; they'll submit CVV1 or CVV2 when convenient, but they won't let not having them block the sale. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2312 bytes Desc: S/MIME Cryptographic Signature URL: From bzs at world.std.com Sat Jun 9 13:49:09 2012 From: bzs at world.std.com (Barry Shein) Date: Sat, 9 Jun 2012 14:49:09 -0400 Subject: Dear Linkedin, In-Reply-To: <20120609044259.9BF6880003B@ip-64-139-1-69.sjc.megapath.net> References: <20120609044259.9BF6880003B@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20435.39589.202092.547749@world.std.com> A friend would print in block letters in the sig area of his credit cards "ASK FOR PHOTO ID". He said that almost always cashiers et al would give a cursory glance like they were checking his signature and say thank you and hand him back his card. Maybe someone mentioned this but merchant card contracts generally (always?) require that you NOT store CVVs when the transaction is over. It's just some double-check remotely that you physically have the card, or did once in the past, etc. and doesn't imprint. Credit card security is about percentages not absolutes, about the cost-benefit analysis. Many years ago I interviewed at a company which was building a big honking multi-processor. They had $150M in pre-orders from BIG CREDIT CARD COMPANY dependent on the machine being able to run a bunch of anti-fraud algorithms they knew were good (run against historical data) but couldn't run in real-time, no iron was fast enough at the time. BIG CREDIT CARD COMPANY estimated, as I remember, that if they could run those algorithms it would catch about $50,000/hour in fraud, so the $150M was a good investment from their point of view. I didn't take the job and they never finished the system. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From web at typo.org Sat Jun 9 14:12:38 2012 From: web at typo.org (Wayne E Bouchard) Date: Sat, 9 Jun 2012 12:12:38 -0700 Subject: CVV numbers In-Reply-To: <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> Message-ID: <20120609191238.GA76757@wakko.typo.org> On Sat, Jun 09, 2012 at 02:18:15PM -0400, Alexandre Carmel-Veilleux wrote: > On 2012-06-09, at 10:56, Owen DeLong wrote: > > > > How does having the CVV number prove the card is in my possession? > > It doesn't, it merely proves you must have handled the card physically at some point since storing that value in a database is forbidden. > > Verified by Visa and the MasterCard equivalent actually "prove" that you are the rightful card holder. Unlike CVV numbers, they actually exempt the merchant from chargebacks (or did circa 2003). > > Alex Before the days of online transactions, how many people even knew a portion of their CC let alone the verification tag? The main weakness of CVV2 these days is "form history" in browsers. (auto complete). Now, if someone can get ont your PC, they not only get the credit card number (which there are myriad different ways to get) but the CVV as well so that mechanism is, now, all but useless. Add to that the fact online merchants don't even have to appear in the same country, let alone region, and the "location of purchase relative to the home residence of the user" doesn't mean much either so can't act as an effective secondary if the information were to be captured. Just like all other forms of security and fraud protection that we in the online community try to enable, eventually something comes along that makes the job a lot harder. Having these mechanisms is better than not having them but there will never be a perfect system. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From bzs at world.std.com Sat Jun 9 14:30:55 2012 From: bzs at world.std.com (Barry Shein) Date: Sat, 9 Jun 2012 15:30:55 -0400 Subject: CVV numbers In-Reply-To: <20120609191238.GA76757@wakko.typo.org> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> <20120609191238.GA76757@wakko.typo.org> Message-ID: <20435.42095.305421.726255@world.std.com> On June 9, 2012 at 12:12 web at typo.org (Wayne E Bouchard) wrote: > > The main weakness of CVV2 these days is "form history" in browsers. > (auto complete). Now, if someone can get ont your PC, they not only > get the credit card number (which there are myriad different ways to > get) but the CVV as well so that mechanism is, now, all but useless. Oh c'mon, all but useless? Look at all the ifs/ands/buts. They need access to your form history which actually is useless if the merchant's form just uses a password-type field, etc. Yeah, a lot of these techniques are useless if your computer etc is completely pwned. But they help if you're not. Credit card fraud prevention is all about percentages, not absolutes. Even just requiring a valid credit card number and expiration date and nothing else probably prevents, I dunno, 98%+ of all potential fraud, probably 99%+. The rest is about squeezing down that last percentage point or two and generally discouraging crooks from trying. One of the PITA frauds credit card companies deal with is someone in the household, like your teenage kid, taking your card physically out of your wallet and using it w/o your permissin and then you call in when you see the bill that you never ordered $100 from iTunes or bought any cool sneakers at the mall. That's probably more common than a lot of the other frauds you imagine. A lot of these techniques at least prove that *someone* had your card physically if they suspect this was not fraud but, rather, "unauthorized use". People will also try to deny charges they simply regret, like a night at a bar with strippers particularly that one in the blue hot pants, who the h*** KNEW she got $300 for a lap dance and $50/glass for the Kristal, doesn't seem fair not fair at all...it's some backpressure. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From jra at baylink.com Sat Jun 9 14:43:20 2012 From: jra at baylink.com (Jay Ashworth) Date: Sat, 9 Jun 2012 15:43:20 -0400 (EDT) Subject: Password safes &c. (was: Dear Linkedin,) In-Reply-To: Message-ID: <19374833.8594.1339271000259.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Lyndon Nerenberg" > The only way to ensure your personal passwords are never compromised > is to kill yourself after destroying all physical copies of those > passwords. While ultimately secure, you won't be able to do your daily > online banking. No, but on the positive side, the issue will be less pressing to you. User-side authentication security is a multi-dimensional problem, and it is probably not theoretically possible to optimize any given instance for all of the possible vectors simultaneously. Different individuals need to make their own threat estimate, and decide what approach they want to take to it. Of course, 95% of the affected audience wouldn't know what the phrase "threat estimate" meant, even if you threatened them. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jna at retina.net Sat Jun 9 15:08:16 2012 From: jna at retina.net (John Adams) Date: Sat, 9 Jun 2012 13:08:16 -0700 Subject: CVV numbers In-Reply-To: <20435.42095.305421.726255@world.std.com> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> <20120609191238.GA76757@wakko.typo.org> <20435.42095.305421.726255@world.std.com> Message-ID: There is a reason part of most scanners that verify the PCI standard look for autocomplete=off on credit card number and cvv2 fields. This is specifically it. -j On Sat, Jun 9, 2012 at 12:30 PM, Barry Shein wrote: > > On June 9, 2012 at 12:12 web at typo.org (Wayne E Bouchard) wrote: > > > > The main weakness of CVV2 these days is "form history" in browsers. > > (auto complete). Now, if someone can get ont your PC, they not only > > get the credit card number (which there are myriad different ways to > > get) but the CVV as well so that mechanism is, now, all but useless. > > Oh c'mon, all but useless? Look at all the ifs/ands/buts. They need > access to your form history which actually is useless if the > merchant's form just uses a password-type field, etc. > > Yeah, a lot of these techniques are useless if your computer etc is > completely pwned. But they help if you're not. > > Credit card fraud prevention is all about percentages, not absolutes. > > Even just requiring a valid credit card number and expiration date and > nothing else probably prevents, I dunno, 98%+ of all potential fraud, > probably 99%+. > > The rest is about squeezing down that last percentage point or two and > generally discouraging crooks from trying. > > One of the PITA frauds credit card companies deal with is someone in > the household, like your teenage kid, taking your card physically out > of your wallet and using it w/o your permissin and then you call in > when you see the bill that you never ordered $100 from iTunes or > bought any cool sneakers at the mall. > > That's probably more common than a lot of the other frauds you imagine. > > A lot of these techniques at least prove that *someone* had your card > physically if they suspect this was not fraud but, rather, > "unauthorized use". > > People will also try to deny charges they simply regret, like a night > at a bar with strippers particularly that one in the blue hot pants, > who the h*** KNEW she got $300 for a lap dance and $50/glass for the > Kristal, doesn't seem fair not fair at all...it's some backpressure. > > > -- > -Barry Shein > > The World | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, > Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* > > From jra at baylink.com Sat Jun 9 15:28:01 2012 From: jra at baylink.com (Jay Ashworth) Date: Sat, 9 Jun 2012 16:28:01 -0400 (EDT) Subject: Choosing Passwords In-Reply-To: <20120608223329.4683E80003B@ip-64-139-1-69.sjc.megapath.net> Message-ID: <19399279.8600.1339273681468.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Hal Murray" > 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. Well, my personal approach to this -- one which I'm well aware is disparaged by Security Professionals -- is tiered passwords. I have one password for 'throwaway' accounts -- drive-forum postings and the like, another password for slightly more important accounts -- forums in which I participate regularly and the like, a third password for actual machine accounts, VPNs and similar things like equipment control panels, and finally a tier for accounts that people can actually change my life or spend my money; things like eBay, PayPal, etc -- on this tier, each password is actually distinct. Finally, there's a top-emergency fallback password, which I use for password safes, which is -- as nearly as I can determine, unresearchable, even if I told you its description. All of these passwords are rule/pattern constructed, using either The XKCD Rule, or one of a couple of my own construction, and each individual password is infixed after what it applies to, so as to make the actual final passwords *never be the same string of characters*, the infix going in a nondeterministic place in the string. This puts enough bits of entropy into the passwords to make them relatively strong -- sites with strength checkers on password set tend to like them a lot -- while keeping them all unique so they can't be cross referenced... and making them complex enough that they cannot be dictionary cracked either. I am, of course, a special case; I've been a system administrator for 30 years; this is my business -- I am willing to put the necessary energy into it as part of my work. I realize that lots of people (where, by lots, I mean several billion) aren't -- either because they don't understand why its important, or because they don't care, or because "it's someone else's fault when $3800 gets taken out of my bank account cause I'm a careless slob". TL;DR: Everyone, admin, user, or civilian, has to make their own decisions about how much work they want to put into security -- and *we* have to find ways to explain the choices so that Joe Q. Sixpack can understand *why it's important to him to think about it*. That's a sales pitch; engineers are *singularly* unsuited to it, in general. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jra at baylink.com Sat Jun 9 15:36:11 2012 From: jra at baylink.com (Jay Ashworth) Date: Sat, 9 Jun 2012 16:36:11 -0400 (EDT) Subject: CVV numbers In-Reply-To: <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> Message-ID: <11561027.8602.1339274171831.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > How does having the CVV number prove the card is in my possession? > > I have memorized the CVV in addition to the 16 digits of the cards I > commonly use and routinely enter them into online ordering without > retrieving the card. > > What prevents a fraudster from writing the CVV down along with the > other card data? Nothing, but lots of fraud scenarios don't involve a bad actor taking physical posession of your card: magstripe skimmers and charge-slip carbons being only 2 off-hand examples. Clearly, the percentage of fraud it blocks is more than the amount it costs. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jra at baylink.com Sat Jun 9 15:43:20 2012 From: jra at baylink.com (Jay Ashworth) Date: Sat, 9 Jun 2012 16:43:20 -0400 (EDT) Subject: Dear Linkedin, In-Reply-To: <20435.39589.202092.547749@world.std.com> Message-ID: <17987295.8604.1339274600271.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Barry Shein" > A friend would print in block letters in the sig area of his credit > cards "ASK FOR PHOTO ID". He said that almost always cashiers et al > would give a cursory glance like they were checking his signature and > say thank you and hand him back his card. This seems like an altogether excellent time to haul out *this* old chestnut: http://www.zug.com/pranks/credit/ FWIW, My cards have always said SEE ID, and I get about a 40% or so hit rate on that. It's been odd recently, cause I sometimes forget, and the privacy reflex kicks in and makes me want to say "Why??" :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From jmamodio at gmail.com Sat Jun 9 15:48:10 2012 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 9 Jun 2012 15:48:10 -0500 Subject: ITU funsies In-Reply-To: <20120609172146.GA34314@gweep.net> References: <20120609172146.GA34314@gweep.net> Message-ID: Somebody sent a copy of the TD64 working doc to Milton Mueller of IGP/ICANN-NCSG not yet on wcitleaks. Be aware, the new treaty will get rid of SPAM !! http://www.internetgovernance.org/2012/06/06/td-64-for-breakfast/ -J On Sat, Jun 9, 2012 at 12:21 PM, Joe Provo wrote: > > 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=nanog55 > 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 > From lyle at lcrcomputer.net Sat Jun 9 15:48:16 2012 From: lyle at lcrcomputer.net (Lyle Giese) Date: Sat, 09 Jun 2012 15:48:16 -0500 Subject: Dear Linkedin, In-Reply-To: <17987295.8604.1339274600271.JavaMail.root@benjamin.baylink.com> References: <17987295.8604.1339274600271.JavaMail.root@benjamin.baylink.com> Message-ID: <4FD3B690.5050800@lcrcomputer.net> On 06/09/12 15:43, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Barry Shein" >> A friend would print in block letters in the sig area of his credit >> cards "ASK FOR PHOTO ID". He said that almost always cashiers et al >> would give a cursory glance like they were checking his signature and >> say thank you and hand him back his card. > This seems like an altogether excellent time to haul out *this* old > chestnut: > > http://www.zug.com/pranks/credit/ > > FWIW, My cards have always said SEE ID, and I get about a 40% or so hit > rate on that. It's been odd recently, cause I sometimes forget, and the > privacy reflex kicks in and makes me want to say "Why??" :-) > > Cheers, > -- jra My personal favorite is to ask if I spelled my name correctly? Lyle Giese LCR Computer Services, Inc. From scott at doc.net.au Sat Jun 9 16:24:48 2012 From: scott at doc.net.au (Scott Howard) Date: Sat, 9 Jun 2012 14:24:48 -0700 Subject: Dear Linkedin, In-Reply-To: <4d6c939a-9751-48fe-8246-87421e1a1377@email.android.com> References: <20120608130249.BFE61B1B@m0005311.ppops.net> <4d6c939a-9751-48fe-8246-87421e1a1377@email.android.com> Message-ID: On Sat, Jun 9, 2012 at 10:52 AM, wrote: > My biggest problem still is the multiple computer issue. I am on at least > 3-5 physical computers and 1-20 virtual machines, and 2 cellphones a day. > I honestly do not want to store a database of passwords encrypted or not > on an open service. > Security is all about trade-offs. In this case it's the trade-off between storing an excrypted password database on a 3rd party server, v's re-using passwords and having (potentially) weaker passwords as a result of not doing so. Personally I use KeePass, with the database stored on a cloud-synced directory. To decrypt the KeePass database requires both a Passwords AND a Key file, which is NOT synced to the cloud. IMHO this gives the best of both worlds - easy syncing between multiple computers and the ability to use unique, very strong passwords with all websites. But also very strong security in the case that the KeePass database is somehow compromised from the cloud service, as both the password and keyfile would be required to decrypt. Scott From mysidia at gmail.com Sat Jun 9 16:25:04 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 9 Jun 2012 16:25:04 -0500 Subject: CVV numbers In-Reply-To: <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> Message-ID: On 6/9/12, Alexandre Carmel-Veilleux wrote: > On 2012-06-09, at 10:56, Owen DeLong wrote: >> How does having the CVV number prove the card is in my possession? > It doesn't, it merely proves you must have handled the card physically at > some point since storing that value in a database is forbidden. [snip] Someone must have something in a database that can easily derive the CVV2 number; otherwise there would be no way for it to be verified that the correct number has been presented, there's really no hashing scheme for 3-digit numbers that cannot be trivially brute-forced, once any salting procedure is known by an attacker. I bet there is at least one small retailer out there who takes phone orders and gathers CVV2, and at least one POS software developer out there who is unaware of, has ignored, or has intentionally/unintentionally disobeyed the rule about never storing CVV2 values in a database, and does at least one of these things: transmits it without storing but fails to encrypt it (e.g. number sent to a backend with unencrypted XMLRPC transaction), records it in a database, e-mails the data internally, puts it in a spreadsheet, and stores it as data at rest (encrypted it or not), and fails to scrub it, eg deleted but not overwritten file on a computer, file on a share, e-mail saved in a folder, writes it down, or otherwise misappropriates the CVV2 value together with the CC# and Expdate. In other words CVV2 is a "weak" physical "proof" mechanism that only works if all parties involved obey the rules perfectly without error, even parties such as merchants who are not necessarily trustworthy, but even if trustworthy may also have kept record of CVV2 CC Expdate by accident, poor process, or failure of staff to follow established procedures for the handling of the data. -- -JH From scott at doc.net.au Sat Jun 9 16:31:44 2012 From: scott at doc.net.au (Scott Howard) Date: Sat, 9 Jun 2012 14:31:44 -0700 Subject: CVV numbers In-Reply-To: <35332AB4-0FB4-4CF1-A73C-6CB4A737B472@antelope.net> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <35332AB4-0FB4-4CF1-A73C-6CB4A737B472@antelope.net> Message-ID: On Sat, Jun 9, 2012 at 7:14 AM, Joel Maslak wrote: > That said, the purpose of CVV is to stop *one* type of fraud - it's to > stop a skimmer from being able to do mail-order/internet-order with your > card number. The CVV is not on the magnetic strip, so a skimmer installed > at the ATM or gas pump won't be able to capture it. > No, it's to stop more than one type of fraud - however your point is correct in that it's not designed to stop *all* fraud, it's just one of many layers of prevention. In addition to the one you've mentioned, the CVV2 also stop the card being fraudulently being used in any situation where the card number has been leaked, such as a database of card numbers being hacked, a receipt with the full number on it (rare if at all existent these days), etc. The rules on CVV2 numbers basically say that the number can never be recorded by the merchant after the transaction has been processed, which pretty much means that they can't store it at all in any form. If a database is hacked, the CVV2 number will not be there. Scott From scott at doc.net.au Sat Jun 9 16:34:03 2012 From: scott at doc.net.au (Scott Howard) Date: Sat, 9 Jun 2012 14:34:03 -0700 Subject: CVV numbers In-Reply-To: <20120609191238.GA76757@wakko.typo.org> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> <20120609191238.GA76757@wakko.typo.org> Message-ID: On Sat, Jun 9, 2012 at 12:12 PM, Wayne E Bouchard wrote: > The main weakness of CVV2 these days is "form history" in browsers. > (auto complete). Any website requesting a CVV2 in a form field without the form history/autocomplete being disabled is in breach of PCI compliance, and risks losing their ability to accept credit cards. That's not to say there aren't some that do it, but to call this the "main weakness" of CVV2 is simply wrong. Scott From scott at doc.net.au Sat Jun 9 16:42:11 2012 From: scott at doc.net.au (Scott Howard) Date: Sat, 9 Jun 2012 14:42:11 -0700 Subject: CVV numbers In-Reply-To: References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> Message-ID: On Sat, Jun 9, 2012 at 2:25 PM, Jimmy Hess wrote: > Someone must have something in a database that can easily derive the > CVV2 number; > There is no way to "derive" the CVV2 number. It is little more than a random number assigned to the card. > otherwise there would be no way for it to be verified that the correct > number has > It is verified by comparing it to the known CVV2 number stored by the credit card company/bank that issued the card. > I bet there is at least one small retailer out there who takes phone > orders and gathers CVV2, and at least one POS software developer out > there who is unaware of, has ignored, or has > intentionally/unintentionally disobeyed the rule about never storing > CVV2 values in a database, Gathering CVV2 number over the phone is completely valid. It's even valid to write them down, as long as they are destroyed as soon as the transaction has been completed. Of course there are people that disobey/ignore/don't know the rules - no level of security will ever be perfect in this regards - it's all about making the security better and reducing the rate of fraud/chargebacks. > In other words CVV2 is a "weak" physical "proof" mechanism that only > works if all parties involved obey the rules perfectly without error, > Correct. It's a "weak" physical "proof" mechanism that has succeed in having a very significant reduction in fraudulent transactions/chargebacks across pretty much the entire industry. Remind me again what your point was? Scott From aledm at qix.co.uk Sat Jun 9 17:12:56 2012 From: aledm at qix.co.uk (Aled Morris) Date: Sat, 9 Jun 2012 23:12:56 +0100 Subject: CVV numbers In-Reply-To: References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> Message-ID: On 9 June 2012 22:42, Scott Howard wrote: > There is no way to "derive" the CVV2 number. It is little more than a > random number assigned to the card. > [...] > It is verified by comparing it to the known CVV2 number stored by the > credit card company/bank that issued the card. > > I don't think this is correct - I believe the Wikipedia entry is accurate: ---snip--- CVC1, CVV1, CVC2 and CVV2 values are generated when the card is issued. The values are calculated by encrypting the bank card number (also known as the primary account number or PAN), expiration date and service code with encryption keys (often called Card Verification Key or CVK) known only to the issuing bank, and decimalising the result ---snip--- http://en.wikipedia.org/wiki/Cvv2 I suspect the issuing banks can share their CVKs with the card scheme operators (Visa, MC, Amex) if they want them to validate transactions on their behalf. Aled From mpalmer at hezmatt.org Sat Jun 9 17:48:40 2012 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sun, 10 Jun 2012 08:48:40 +1000 Subject: CVV numbers In-Reply-To: References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> <20120609191238.GA76757@wakko.typo.org> Message-ID: <20120609224840.GT2229@hezmatt.org> On Sat, Jun 09, 2012 at 02:34:03PM -0700, Scott Howard wrote: > On Sat, Jun 9, 2012 at 12:12 PM, Wayne E Bouchard wrote: > > The main weakness of CVV2 these days is "form history" in browsers. > > (auto complete). > > Any website requesting a CVV2 in a form field without the form > history/autocomplete being disabled is in breach of PCI compliance, and > risks losing their ability to accept credit cards. And convenience trumps pseudo-security yet again; Chrom(ium) asks me if I want to save my CC details when I put them in (to which I tell it not just "no", but "are you *nuts*?"); presumably this is on forms which include autocomplete=off, since it happens often enough. So I would assume that this PCI compliance tickbox is being ignored by browsers. Whee! - Matt -- Ruby's the only language I've ever used that feels like it was designed by a programmer, and not by a hardware engineer (Java, C, C++), an academic theorist (Lisp, Haskell, OCaml), or an editor of PC World (Python). -- William Morgan From mysidia at gmail.com Sat Jun 9 18:09:24 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 9 Jun 2012 18:09:24 -0500 Subject: Dear Linkedin, In-Reply-To: References: <20120608130249.BFE61B1B@m0005311.ppops.net> <4d6c939a-9751-48fe-8246-87421e1a1377@email.android.com> Message-ID: On 6/9/12, Scott Howard wrote: [snip] > Security is all about trade-offs. In this case it's the trade-off between > storing an excrypted password database on a 3rd party server, v's re-using > passwords and having (potentially) weaker passwords as a result of not [snip] Yes. Using an encrypted online password vault is a trade-off. Risks that are unaffected: o A randomly generated password might be more guessable than a human-created password, if generated by an insecure PRNG, for example, if the possible generation outcomes for given input parameters can be predicted through analysis. o A password can easily be stolen by malware on a computer the password is typed on that logs keystrokes and mouse clicks (even a vault's master password). o A password can easily be stolen if transmitted to a remote site unencrypted, by a computer on the local or remote LAN with malware infection (even a switched LAN). o If either endpoint's SSL certificate (or a CA) is compromised, a MITM attack can be used to learn the contents of encrypted communications. o A password can be stolen by malware if stored temporarily at rest or temporarily in RAM in an unencrypted format. o A password can be stolen if stored at rest in unencrypted format. o A password can be stolen, even if encrypted, if the symmetric encryption key can also be stolen. New risks increased in magnitude: o If malware running on a computer is aware of the password vault application, it may be able to maliciously modify the executable code of the password vault application in memory, resulting in data compromise. o Your password data is vulnerable to local compromise if your master pw is guessed or stolen. (Use a vault with multi-factor authentication to mitigate). o If password vault data is stolen, the thief has a convenient list of accounts. Risk can be reduced by using multiple vaults of different types for different security levels/use frequency. o If the password vault software fails, DB is corrupted, or the online password vault service goes offline, you can lose access to your accounts, because you don't remember the passwords. o The pass vault is an additional piece of software; if the software developers' systems are compromised, it might be possible for malicious code to be inserted in the password vault application. o If the password vault software has a bug, the encryption doesn't work properly, or fails to maintain good security hygene, all your passwords may be vulnerable. For example, if you keep a GPG encrypted list of passwords, and you create a "temporary plain text file" when re-encrypting to create a new encrypted list, passwords are vulnerable to theft during this process, and afterwards via latent disk analysis techniques. Examples of Risks mitigated by online encrypted password vault VS shared or similar passwords that are memorized: o Reduced risk of loss of access to account, resulting from forgetting which password was selected for a particular account, or adverse password changes enforced by "password setting" or "mandatory password change" policies. o No need to use short/guessable passwords (less than 16 characters); high-entropy passwords can be chosen which can only be attacked by brute force, and which will take massive amounts of money or time to successfully attack. o If the login password to one site is compromised, guessed, or accidentally disclosed by any means; many of your accounts are at increased risk. Risks eliminated pw vault VS passwords written down on a slip of paper: o No risk of losing the paper, resulting in account compromise and loss of access o No risk of a piece of paper being stolen. o No need to use short passwords (less than 32 characters) that can easily be written down -- -JH From joelja at bogus.com Sun Jun 10 02:03:43 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 10 Jun 2012 00:03:43 -0700 Subject: Dear Linkedin, In-Reply-To: <3D17BF53-34C1-4CD3-9BD4-4343B5A44E95@gmail.com> References: <20120608223329.4683E80003B@ip-64-139-1-69.sjc.megapath.net> <3D17BF53-34C1-4CD3-9BD4-4343B5A44E95@gmail.com> Message-ID: <4FD446CF.30008@bogus.com> On 6/8/12 16:05 , Alec Muffett wrote: >> Does anybody have a good URL explaining that idea? It's been >> kicking around for many years. I've never seen a convincing >> writeup. > > I've tried to do that in another mail - it's in the realms of > philosophy more than strategy; like if you're a really security-aware > person and take great care you can probably stretch the useful life > of a password out to _years_ - but how typical are *you* in that > instance? I have a slide in a presentation I give about oncea year that goes something like: How good does a password/phrase have to be in order to protect against brute-force or dictionary attacks against the password itself? ? Entropy in language. ? A typical english sentence has 1.2 bits of entropy per character, you need 107 characters to get a statistically random md5 hash. ? Using totally random english characters you need 28 characters. ? Using a random distribution of all 95 printable ascii characters you need 20 characters. ? Observation, good passwords are hard to come by. >> Does your bank request/require that you change the PIN on your ATM >> card every few months? > > ATM cards are not passwords, they are a coarse form of two-factor > authentication - You have the card, you have the PIN. > > You have to possess both in order to transact - at least in in > theory. > > Compare that with the secrecy surrounding the CVV - the "last three > digits on the number on the back of the card" which you are "not > meant to tell anyone" and which _will_ be different if your card is > lost/stolen and reissued. > > Now _that_ is a password. > >> 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. > > You know, that's not bad. I am pro-paper for long passwords. I am > even-more pro "password safes". > >> 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. > > It's harder as we get old. Use technology to aid with the heavy > lifting. :-) > > -a > > > > From johns at sstar.com Sun Jun 10 02:25:22 2012 From: johns at sstar.com (John Souvestre) Date: Sun, 10 Jun 2012 02:25:22 -0500 Subject: Dear Linkedin, In-Reply-To: <4FD446CF.30008@bogus.com> References: <20120608223329.4683E80003B@ip-64-139-1-69.sjc.megapath.net> <3D17BF53-34C1-4CD3-9BD4-4343B5A44E95@gmail.com> <4FD446CF.30008@bogus.com> Message-ID: <028701cd46da$34debd80$9e9c3880$@sstar.com> On 6/10/12, Joel jaeggli wrote: > How good does a password/phrase have to be in order to protect > against brute-force or dictionary attacks against the password itself? > ? Entropy in language. > A typical english sentence has 1.2 bits of entropy per character, > you need 107 characters to get a statistically random md5 hash. > Using totally random english characters you need 28 characters. > Using a random distribution of all 95 printable ascii characters you > need 20 characters. > ? Observation, good passwords are hard to come by. I don't disagree, except regarding dictionary attacks. If the attack isn't random then math based on random events doesn't apply. In the case of a purely dictionary attack if you choose a non-dictionary word and you are 100.000% safe. :) John John Souvestre - New Orleans LA - (504) 454-0899 From owen at delong.com Sun Jun 10 03:02:23 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 10 Jun 2012 01:02:23 -0700 Subject: CVV numbers In-Reply-To: <11561027.8602.1339274171831.JavaMail.root@benjamin.baylink.com> References: <11561027.8602.1339274171831.JavaMail.root@benjamin.baylink.com> Message-ID: On Jun 9, 2012, at 1:36 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> How does having the CVV number prove the card is in my possession? >> >> I have memorized the CVV in addition to the 16 digits of the cards I >> commonly use and routinely enter them into online ordering without >> retrieving the card. >> >> What prevents a fraudster from writing the CVV down along with the >> other card data? > > Nothing, but lots of fraud scenarios don't involve a bad actor taking > physical posession of your card: magstripe skimmers and charge-slip > carbons being only 2 off-hand examples. Clearly, the percentage of fraud > it blocks is more than the amount it costs. The skimmers can use CVV1 and bypass the CVV2 protection in most cases (though that requires them to gen up a fake or fraudulent card and do card present transactions which does add risk for them). I haven't seen a charge slip carbon in so long that I find it hard to believe these would remain a significant factor today. It costs almost nothing, so a few fraudulent transactions blocked is probably enough. That doesn't change the fact that I believe there have to be more effective methods that wouldn't cost much more. Owen From jgreco at ns.sol.net Sun Jun 10 05:58:56 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Jun 2012 05:58:56 -0500 (CDT) Subject: Dear Linkedin, In-Reply-To: <17987295.8604.1339274600271.JavaMail.root@benjamin.baylink.com> Message-ID: <201206101058.q5AAwujs033602@aurora.sol.net> > ----- Original Message ----- > > From: "Barry Shein" > > > A friend would print in block letters in the sig area of his credit > > cards "ASK FOR PHOTO ID". He said that almost always cashiers et al > > would give a cursory glance like they were checking his signature and > > say thank you and hand him back his card. > > This seems like an altogether excellent time to haul out *this* old > chestnut: > > http://www.zug.com/pranks/credit/ > > FWIW, My cards have always said SEE ID, and I get about a 40% or so hit > rate on that. It's been odd recently, cause I sometimes forget, and the > privacy reflex kicks in and makes me want to say "Why??" :-) If your card is not signed, your card is invalid and should not be accepted by any merchant. http://www.mastercard.com/us/merchant/pdf/MerchantAcceptanceGuide_Manual.pdf Page 8-2; "Unsigned Credit Cards". VISA has similar requirements. Writing "SEE ID" in the signature panel primarily makes your card invalid *unless* your signature is also present. One of the design goals of the V/MC system is that a cardholder is not supposed to need anything other than their card and the ability to sign. The comparison of the signature provided to the card signature is supposed to be one of the primary ways to validate a cardholder, but of course these days, most vendors are lazy and don't. In fact, one of my favorite abusive merchant practices, trying to require ID, is expressly prohibited: http://www.mastercard.com/us/merchant/pdf/BM-Entire_Manual_public.pdf Page 5-14, sec. 5.8.4, "Additional Cardholder Identification". They're allowed to ask, you're allowed to refuse, and absent a good reason, they're not allowed to refuse your transaction. Now, if your signature doesn't match or something else is particularly fishy, yes, then they should require it, but they cannot require it by default for all transactions they process. That and a "minimum charge" are among the two most common merchant violations I see. For MasterCard violations, report them! http://www.mastercard.us/support/merchant-violations.html ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From vixie at isc.org Sun Jun 10 09:42:57 2012 From: vixie at isc.org (Paul Vixie) Date: Sun, 10 Jun 2012 14:42:57 +0000 Subject: Our first inbound email via IPv6 In-Reply-To: (Jason Livingood's message of "Tue, 5 Jun 2012 14:10:39 +0000") References: Message-ID: "Livingood, Jason" writes: > In preparation for the World IPv6 Launch, inbound (SMTP) email to the > comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. > Roughly one minute later, at 9:35:30 UTC we received our first > inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail > was spam, and was caught by our Cloudmark messaging anti-abuse platform > (the sender attempted a range of standard spam tactics in subsequent > connections). ... rim shot: i suggest that the e-mail industry consider a two-level approach to rejecting ipv6 spam based on source address. for more information see: http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electronic_mail/ paul From randy at psg.com Sun Jun 10 10:05:24 2012 From: randy at psg.com (Randy Bush) Date: Sun, 10 Jun 2012 08:05:24 -0700 Subject: Our first inbound email via IPv6 In-Reply-To: References: Message-ID: the key question to me is when will my normal dns rbwls support ipv6? in exim-speak !dnslists = list.dnswl.org dnslists = dialups.mail-abuse.org \ : rbl-plus.mail-abuse.org \ : dnsbl.sorbs.net \ : zen.spamhaus.org and this time let's skip the usual round of telling me the worth of each element of my selection. randy From swmike at swm.pp.se Sun Jun 10 10:05:34 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 10 Jun 2012 17:05:34 +0200 (CEST) Subject: Dear Linkedin, In-Reply-To: <201206101058.q5AAwujs033602@aurora.sol.net> References: <201206101058.q5AAwujs033602@aurora.sol.net> Message-ID: On Sun, 10 Jun 2012, Joe Greco wrote: > One of the design goals of the V/MC system is that a cardholder is not > supposed to need anything other than their card and the ability to sign. This seems to be different across the world. Here in Sweden, they don't really look at your signature on the card, they look at the name on the card, name on the ID and the signature of the ID (which is pretty much required if you don't have PIN). > The comparison of the signature provided to the card signature is > supposed to be one of the primary ways to validate a cardholder, but of > course these days, most vendors are lazy and don't. I've seen people verify the signature in France and in some asian countries. I don't travel much these days, so I don't know the situation in other countries. > then they should require it, but they cannot require it by default for > all transactions they process. > > That and a "minimum charge" are among the two most common merchant > violations I see. > > For MasterCard violations, report them! > > http://www.mastercard.us/support/merchant-violations.html Is that policy worldwide or just for the US? -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Sun Jun 10 10:12:29 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 10 Jun 2012 17:12:29 +0200 (CEST) Subject: Our first inbound email via IPv6 In-Reply-To: References: Message-ID: On Sun, 10 Jun 2012, Randy Bush wrote: > the key question to me is when will my normal dns rbwls support ipv6? > in exim-speak > > and this time let's skip the usual round of telling me the worth of each > element of my selection. My thoughts on this is that unless ISPs start to announce what "one customer" is, this is pretty hard. It's a problem in IPv4, but even more so in IPv6. Wouldn't it help a lot if there was a way to publish that "in this /42, there is one customer per /56, and in this other /42, there is one customer per /48"? How can that be done via DNS (if that is still a favourable mechanism to distribute information like this)? Whois is not a good way... -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Sun Jun 10 10:20:07 2012 From: randy at psg.com (Randy Bush) Date: Sun, 10 Jun 2012 08:20:07 -0700 Subject: Our first inbound email via IPv6 In-Reply-To: References: Message-ID: >> the key question to me is when will my normal dns rbwls support ipv6? >> in exim-speak > My thoughts on this is that unless ISPs start to announce what "one > customer" is, this is pretty hard. It's a problem in IPv4, but even more > so in IPv6. i have assiduously avoided gaining serious anti-spam fu. but it seems to me that ipv6 does not create/enable significantly more spam-bots. randy From joelja at bogus.com Sun Jun 10 10:24:41 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 10 Jun 2012 08:24:41 -0700 Subject: Dear Linkedin, In-Reply-To: <028701cd46da$34debd80$9e9c3880$@sstar.com> References: <20120608223329.4683E80003B@ip-64-139-1-69.sjc.megapath.net> <3D17BF53-34C1-4CD3-9BD4-4343B5A44E95@gmail.com> <4FD446CF.30008@bogus.com> <028701cd46da$34debd80$9e9c3880$@sstar.com> Message-ID: <4FD4BC39.5070100@bogus.com> On 6/10/12 00:25 , John Souvestre wrote: > On 6/10/12, Joel jaeggli wrote: > >> How good does a password/phrase have to be in order to protect >> against brute-force or dictionary attacks against the password >> itself? ? Entropy in language. A typical english sentence has 1.2 >> bits of entropy per character, you need 107 characters to get a >> statistically random md5 hash. Using totally random english >> characters you need 28 characters. Using a random distribution of >> all 95 printable ascii characters you need 20 characters. ? >> Observation, good passwords are hard to come by. > > I don't disagree, except regarding dictionary attacks. If the attack > isn't random then math based on random events doesn't apply. In the > case of a purely dictionary attack if you choose a non-dictionary > word and you are 100.000% safe. :) the search space for 6 8 10 character passwords is entirely too small... > John > > John Souvestre - New Orleans LA - (504) 454-0899 > > > > From valdis.kletnieks at vt.edu Sun Jun 10 10:31:53 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 10 Jun 2012 11:31:53 -0400 Subject: Dear Linkedin, In-Reply-To: Your message of "Sun, 10 Jun 2012 08:24:41 -0700." <4FD4BC39.5070100@bogus.com> References: <20120608223329.4683E80003B@ip-64-139-1-69.sjc.megapath.net> <3D17BF53-34C1-4CD3-9BD4-4343B5A44E95@gmail.com> <4FD446CF.30008@bogus.com> <028701cd46da$34debd80$9e9c3880$@sstar.com> <4FD4BC39.5070100@bogus.com> Message-ID: <89026.1339342313@turing-police.cc.vt.edu> On Sun, 10 Jun 2012 08:24:41 -0700, Joel jaeggli said: > > I don't disagree, except regarding dictionary attacks. If the attack > > isn't random then math based on random events doesn't apply. In the > > case of a purely dictionary attack if you choose a non-dictionary > > word and you are 100.000% safe. :) > > the search space for 6 8 10 character passwords is entirely too small... Saw this over on Full-Disclosure. I'd love to know what inspired the HashCat software to *try* those 2 40-character passwords that broke... Subject: [Full-disclosure] Some stats about broken Linkedin passwds From: Georgi Guninski Date: Sun, 10 Jun 2012 17:55:10 +0300 To: full-disclosure at lists.grok.org.uk Stumbled upon this: http://pastebin.com/5pjjgbMt ======= LinkedIn Leaked hashes password statistics (@StefanVenken) Based on the leaked 6.5 Million hashes, 1.354.946 were recovered within a few hours time with HashCat / Jtr and publicly found wordlists on a customer grade laptop. This report was created with pipal from @Digininja ======== Ironically they broke some 40 chars pwd. Another list that contains seemingly non-dictionary pwds is at: http://pastebin.com/JmtNxcnB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From mysidia at gmail.com Sun Jun 10 10:42:16 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 10 Jun 2012 10:42:16 -0500 Subject: Dear Linkedin, In-Reply-To: <201206101058.q5AAwujs033602@aurora.sol.net> References: <17987295.8604.1339274600271.JavaMail.root@benjamin.baylink.com> <201206101058.q5AAwujs033602@aurora.sol.net> Message-ID: On 6/10/12, Joe Greco wrote: [snip] > That and a "minimum charge" are among the two most common merchant > For MasterCard violations, report them! In the US, Credit card processing networks were forbidden from prohibiting merchants from establishing certain "minimum charges" to use a CC, merchants may also charge an extra fee to use a CC; see, the Dodd-Frank Wall Street Reform and Consumer Protection act Of 2010; S 1075 page 693. " (3) LIMITATION ON RESTRICTIONS ON SETTING TRANSACTION MINIMUMS OR MAXIMUMS. (A) IN GENERAL.?A payment card network shall not, directly or through any agent, processor, or licensed member of the network, by contract, requirement, condition, penalty, or otherwise, inhibit the ability (i) of any person to set a minimum dollar value for the acceptance by that person of credit cards, to the extent that (I) such minimum dollar value does not differentiate between issuers or between payment card networks; and (II) such minimum dollar value does not exceed $10.00 ? " > violations I see. > For MasterCard violations, report them! > http://www.mastercard.us/support/merchant-violations.html > ... JG -- -JH From bzs at world.std.com Sun Jun 10 12:49:08 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 10 Jun 2012 13:49:08 -0400 Subject: CVV numbers In-Reply-To: References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> Message-ID: <20436.56852.634823.592729@world.std.com> On June 9, 2012 at 16:25 mysidia at gmail.com (Jimmy Hess) wrote: > I bet there is at least one small retailer out there who takes phone > orders and gathers CVV2, and at least one POS software developer out > there who is unaware of, has ignored, or has... Yes, but there are also penalties, including loss of merchant account and, I believe, fines, in the contract. > > In other words CVV2 is a "weak" physical "proof" mechanism that only > works if all parties involved obey the rules perfectly without error, Not at all, even if someone does store CVV2s in violation of their contract they would ALSO have to be revealed to an evildoer to cause any harm. And even then the evildoer has to leap any other security barriers. Probabilities, all about probabilities, and percentages. You're making the best the enemy of the good. We aren't dealing with military secrets here where one leak can undo all tactical advantage. We're dealing with fraudulent credit card charges where some amount of loss is considered acceptable and one just tries to minimize those losses. The goal is cost/benefit analysis, minimize losses while allowing the overall system to function as friction-free as possible, and doing that within a reasonable cost framework of around 1%-3% per transaction. No different than router bugs etc, if one packet in a billion (whatever) is dropped purely due to a software bug that may be acceptable for a $10K router if the other alternative is to hand-verify every line of code making the router cost $100K. I think this all may be more operationally relevant than some might protest, some here seem to have funny ideas about cost-benefits and security which maybe can at least be shaken loose a bit. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Sun Jun 10 13:16:10 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 10 Jun 2012 14:16:10 -0400 Subject: Dear Linkedin, In-Reply-To: References: <201206101058.q5AAwujs033602@aurora.sol.net> Message-ID: <20436.58474.786115.356761@world.std.com> I was under the impression (I should dig out my contract) that merchant contracts also forbid charging more for a charge than for cash or conversely "discount for cash!" but I see so many violations of that particularly at gas stations I wonder if that's negotiable in the contract. I remember my father buying a car and pulling out a credit card asking if they accepted them? The dealer said sure no problem so he said fine then take another 3% (whatever) off I'll pay cash/check. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From john.yocum at fluidhosting.com Sun Jun 10 13:22:12 2012 From: john.yocum at fluidhosting.com (John T. Yocum) Date: Sun, 10 Jun 2012 11:22:12 -0700 Subject: Dear Linkedin, In-Reply-To: <20436.58474.786115.356761@world.std.com> References: <201206101058.q5AAwujs033602@aurora.sol.net> <20436.58474.786115.356761@world.std.com> Message-ID: <4FD4E5D4.5080003@fluidhosting.com> A merchant can offer a cash discount. --John On 6/10/2012 11:16 AM, Barry Shein wrote: > > I was under the impression (I should dig out my contract) that > merchant contracts also forbid charging more for a charge than for > cash or conversely "discount for cash!" but I see so many violations > of that particularly at gas stations I wonder if that's negotiable in > the contract. > > I remember my father buying a car and pulling out a credit card asking > if they accepted them? The dealer said sure no problem so he said fine > then take another 3% (whatever) off I'll pay cash/check. > From mike at mtcc.com Sun Jun 10 13:25:35 2012 From: mike at mtcc.com (Michael Thomas) Date: Sun, 10 Jun 2012 11:25:35 -0700 Subject: Dear Linkedin, In-Reply-To: <4FD4E5D4.5080003@fluidhosting.com> References: <201206101058.q5AAwujs033602@aurora.sol.net> <20436.58474.786115.356761@world.std.com> <4FD4E5D4.5080003@fluidhosting.com> Message-ID: <4FD4E69F.10708@mtcc.com> On 06/10/2012 11:22 AM, John T. Yocum wrote: > A merchant can offer a cash discount. I believe that the law just recently changed on that account. I believe that what Barry says was the old reality. Mike > > --John > > On 6/10/2012 11:16 AM, Barry Shein wrote: >> >> I was under the impression (I should dig out my contract) that >> merchant contracts also forbid charging more for a charge than for >> cash or conversely "discount for cash!" but I see so many violations >> of that particularly at gas stations I wonder if that's negotiable in >> the contract. >> >> I remember my father buying a car and pulling out a credit card asking >> if they accepted them? The dealer said sure no problem so he said fine >> then take another 3% (whatever) off I'll pay cash/check. >> > From jra at baylink.com Sun Jun 10 13:33:03 2012 From: jra at baylink.com (Jay Ashworth) Date: Sun, 10 Jun 2012 14:33:03 -0400 (EDT) Subject: OT: Credit card policies (was Re: Dear Linkedin,) In-Reply-To: <4FD4E69F.10708@mtcc.com> Message-ID: <15933113.8720.1339353183227.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Thomas" > On 06/10/2012 11:22 AM, John T. Yocum wrote: > > A merchant can offer a cash discount. > > I believe that the law just recently changed on that account. I > believe that what Barry says was the old reality. Perhaps, but Cash/Credit for gas dates back to before I moved to Florida in 1981. Even Further Off-Topic, isn't "debit" supposed to be "cash"? Why do I pay the Credit price for it? Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From mike at mtcc.com Sun Jun 10 13:36:10 2012 From: mike at mtcc.com (Michael Thomas) Date: Sun, 10 Jun 2012 11:36:10 -0700 Subject: OT: Credit card policies (was Re: Dear Linkedin,) In-Reply-To: <15933113.8720.1339353183227.JavaMail.root@benjamin.baylink.com> References: <15933113.8720.1339353183227.JavaMail.root@benjamin.baylink.com> Message-ID: <4FD4E91A.2020402@mtcc.com> On 06/10/2012 11:33 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Michael Thomas" >> On 06/10/2012 11:22 AM, John T. Yocum wrote: >>> A merchant can offer a cash discount. >> I believe that the law just recently changed on that account. I >> believe that what Barry says was the old reality. > Perhaps, but Cash/Credit for gas dates back to before I moved to Florida in > 1981. Even Further Off-Topic, isn't "debit" supposed to be "cash"? Why do > I pay the Credit price for it? > I dunno, maybe they're an exception? Maybe it had something to do with competing with the old oil company credit cards? MIke From bonomi at mail.r-bonomi.com Sun Jun 10 13:40:37 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 10 Jun 2012 13:40:37 -0500 (CDT) Subject: Dear Linkedin, In-Reply-To: <20436.58474.786115.356761@world.std.com> Message-ID: <201206101840.q5AIebR1002864@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sun Jun 10 13:18:06 2012 > From: Barry Shein > Date: Sun, 10 Jun 2012 14:16:10 -0400 > To: Mikael Abrahamsson > Subject: Re: Dear Linkedin, > Cc: NANOG , Joe Greco > > > I was under the impression (I should dig out my contract) that > merchant contracts also forbid charging more for a charge than for > cash or conversely "discount for cash!" but I see so many violations > of that particularly at gas stations I wonder if that's negotiable in > the contract. The 'true explanation' is even simpler -- your impression is incorrect. In the U.S., Visa/Mastercard/Amex/Discover/Diners Club contracts all expressly forbid charging extra for a card transaction. Using language that applies only to a 'premium' or 'surcharge' applied to card transactions. They do *NOT* forbid giving a discount for cash payment. They do not state it =is= acceptable -- they are simply silent on the subject, which means that it is not proscribed. The logic: The card purchaser must be allowed to buy at the 'advertised' price. Prohibiting discounts gets into a 'restraint of trade' issue. Gas stations that offer a 'discount for cash' do not give that discount even for 'house brand' cards -- which do not have any fees that are payable to the issuer. From jra at baylink.com Sun Jun 10 13:45:31 2012 From: jra at baylink.com (Jay Ashworth) Date: Sun, 10 Jun 2012 14:45:31 -0400 (EDT) Subject: Dear Linkedin, In-Reply-To: <201206101840.q5AIebR1002864@mail.r-bonomi.com> Message-ID: <2392880.8728.1339353931852.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert Bonomi" > Gas stations that offer a 'discount for cash' do not give that discount > even for 'house brand' cards -- which do not have any fees that are > payable to the issuer. In fact, that's not true. Several chains, notably including Shell, have at one time or another advertised that their house card (not a house-branded credit card, but an actually gas charge card) took the cash price. Cheers -- jra -- Jay R. Ashworth Baylink jra at 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 From bonomi at mail.r-bonomi.com Sun Jun 10 13:49:51 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 10 Jun 2012 13:49:51 -0500 (CDT) Subject: Dear Linkedin, In-Reply-To: <4FD4E69F.10708@mtcc.com> Message-ID: <201206101849.q5AInpS0002972@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sun Jun 10 13:26:36 2012 > Date: Sun, 10 Jun 2012 11:25:35 -0700 > From: Michael Thomas > To: "John T. Yocum" > Subject: Re: Dear Linkedin, > Cc: nanog at nanog.org > > On 06/10/2012 11:22 AM, John T. Yocum wrote: > > A merchant can offer a cash discount. > > I believe that the law just recently changed on that account. I believe > that what Barry says was the old reality. You believe incorrectly. :) Merchants have NOT, per Visa/Mastercard/Amex/Discover/Diners Club contracts in the U.S., been prohibited from offering discounts for cash transactions for more than 20 years -- based on my direct kowledge of such contracts as a card-processing merchand.. TTBOMK, merchants were -never- so prohibited by such a contract. There are 'restraint of trade' issues involved if a contract attempts to place restrictions on transactions that do not involve all the parties to the contract. Forbidding surcharges on transactions paid for by the issuer's card -is-, on the other hand, fair game for the contract under which the issuer agrees to pay for certain purchases. Recently-enacted (2010) U.S. law *does* explicitly permit -- overriding any contract terms to the contrary -- setting a 'minimum purchase amount' for credit card transactions, as long as that amount does not exceed US$10. From stephen at sprunk.org Sun Jun 10 13:49:46 2012 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 10 Jun 2012 13:49:46 -0500 Subject: OT: Credit card policies (was Re: Dear Linkedin,) In-Reply-To: <15933113.8720.1339353183227.JavaMail.root@benjamin.baylink.com> References: <15933113.8720.1339353183227.JavaMail.root@benjamin.baylink.com> Message-ID: <4FD4EC4A.8080005@sprunk.org> On 10-Jun-12 13:33, Jay Ashworth wrote: > From: "Michael Thomas" >> On 06/10/2012 11:22 AM, John T. Yocum wrote: >>> A merchant can offer a cash discount. >> I believe that the law just recently changed on that account. I >> believe that what Barry says was the old reality. > Perhaps, but Cash/Credit for gas dates back to before I moved to Florida in 1981. Merchants have always been allowed to offer a cash discount. The ban is (was?) on surcharges for card purchases. In practical terms, this means that if you post only one price, it must be the card price, not the (possibly lower) cash price. > Even Further Off-Topic, isn't "debit" supposed to be "cash"? Why do I pay the Credit price for it? The "credit" price is subject to the merchant's discount rate, regardless of the nature of the particular card used. The "cash" price is the part of the "credit" price left after the discount rate is applied. Say gas is $4/gal and the merchant's discount rate is 4%. That means the merchant only gets paid $3.84/gal for card purchases. If the merchant charges cash customers $3.84/gal, which is legal, they get paid the same amount of money. However, it is illegal for the merchant to post /only /a price of $3.84/gal and then charge card users $4/gal to cover the card discount; that's an illegal surcharge. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2312 bytes Desc: S/MIME Cryptographic Signature URL: From bonomi at mail.r-bonomi.com Sun Jun 10 14:01:46 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 10 Jun 2012 14:01:46 -0500 (CDT) Subject: OT: Credit card policies (was Re: Dear Linkedin,) In-Reply-To: <15933113.8720.1339353183227.JavaMail.root@benjamin.baylink.com> Message-ID: <201206101901.q5AJ1kSJ003190@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sun Jun 10 13:34:06 2012 > Date: Sun, 10 Jun 2012 14:33:03 -0400 (EDT) > From: Jay Ashworth > To: NANOG > Subject: OT: Credit card policies (was Re: Dear Linkedin,) > > ----- Original Message ----- > > From: "Michael Thomas" > > > On 06/10/2012 11:22 AM, John T. Yocum wrote: > > > A merchant can offer a cash discount. > > > > I believe that the law just recently changed on that account. I > > believe that what Barry says was the old reality. > > Perhaps, but Cash/Credit for gas dates back to before I moved to Florida in > 1981. Even Further Off-Topic, isn't "debit" supposed to be "cash"? Why do > I pay the Credit price for it? It is, and *ISN'T*, 'cash'. Unlike cash (and like a credit card), it is simply an instruction to a third party to pay the retailer a specified amount. And as such, is subject to the terms of the contract between -those- parties as to how payment is made an what charges are imposed. Unlike a credit card, the money _is_ immediately dedecuted from your bank account. Like a credit card, it is the third-party clearinghouse that gets the mone from you, and passes it on to the retailer. AFTER extracting their charges for the service they provide. You pay the 'credit' price, because the card issuer, and the clearinghouse operations _charge_ the merchant the same amount for those transactions as for 'credit' ones. Thus the merchant does not receive any of the benefits of a 'cash' transaction, so there is no 'discount' to pass on to the buyer. At one point, VISA, charged -more- for debit transactions than credit ones. Despite the fact that there was -zero- risk to them on the debit transaction. VISA got sued over the matter, since (at that time) it was impossible to tell whether the card number presented was debit or credit. Thus the merchant could not determine, in advance, what their 'cost' for the transaction was. As a result of the lawsuit, the cost differential between credit and debit transactions was eliminated. From stephen at sprunk.org Sun Jun 10 14:23:42 2012 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 10 Jun 2012 14:23:42 -0500 Subject: OT: Credit card policies (was Re: Dear Linkedin,) In-Reply-To: <201206101901.q5AJ1kSJ003190@mail.r-bonomi.com> References: <201206101901.q5AJ1kSJ003190@mail.r-bonomi.com> Message-ID: <4FD4F43E.6060901@sprunk.org> On 10-Jun-12 14:01, Robert Bonomi wrote: >> From: Jay Ashworth >> >> Even Further Off-Topic, isn't "debit" supposed to be "cash"? Why do >> I pay the Credit price for it? > It is, and *ISN'T*, 'cash'. > > Unlike cash (and like a credit card), it is simply an instruction to a third party to pay the retailer a specified amount. And as such, is subject to the terms of the contract between -those- parties as to how payment is made an what charges are imposed. > > Unlike a credit card, the money _is_ immediately dedecuted from your bank account. All of the above is completely irrelevant to the merchant. > Like a credit card, it is the third-party clearinghouse that gets the mone from you, and passes it on to the retailer. AFTER extracting their charges for the service they provide. FWIW, this is known as the "discount" rate. > You pay the 'credit' price, because the card issuer, and the clearinghouse operations _charge_ the merchant the same amount for those transactions as for 'credit' ones. Thus the merchant does not receive any of the benefits of a 'cash' transaction, so there is no 'discount' to pass on to the buyer. The merchant's discount rate varies between card types. That's why many merchants don't accept AmEx, DC, CB and Nexus: their discount rates are higher than Visa and MC. For a low-margin business, the difference in rates can make the difference between profit and loss on a given sale. > At one point, VISA, charged -more- for debit transactions than credit ones. Despite the fact that there was -zero- risk to them on the debit transaction. Wrong. Even debit cards present a risk of chargeback due to fraud. However, the fraud rates are lower due to the us of PINs, so the discount rate is also lower. > VISA got sued over the matter, since (at that time) it was impossible to tell whether the card number presented was debit or credit. It's still impossible to tell, which is why most card terminals ask whether the card is credit or debit. If you press the "credit" button, even if the card is a debit card, it is processed as a credit card--with the credit card discount rate. That's why Visa's advertising and contests promote customers using signature (i.e. "credit") transactions: Visa gets more money that way (at the cost of their merchants). > As a result of the lawsuit, the cost differential between credit and debit transactions was eliminated. ... except it's still there, though perhaps in the other direction. The discount rate for "debit" transactions is lower, but a PIN must be used to get that rate. The exact rates vary between card networks, card processors and even merchants, but a few years ago the numbers I heard were 4% for "credit" (i.e. signature) transactions and 1% for "debit" (i.e. PIN) transactions. That is why those nifty PIN terminals appeared everywhere virtually overnight: saving 3% on every "debit" transaction easily paid for all those new terminals. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2312 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Sun Jun 10 14:29:46 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 10 Jun 2012 12:29:46 -0700 Subject: Dear Linkedin, In-Reply-To: <201206101058.q5AAwujs033602@aurora.sol.net> References: <201206101058.q5AAwujs033602@aurora.sol.net> Message-ID: The credit card companies should pull their heads out of their asses about this. It is much better from an anti-fraud perspective for a stolen card not to contain a specimen signature for the thief to learn to forge. It is far preferable for the merchant to request ID and verify that the signature matches the ID _AND_ the picture in the ID matches the customer. I've never had my card refused because I wrote SEE ID on the signature panel in lieu of my signature. I have been frequently asked for my ID and make a point of thanking the merchant for their diligence in each of those cases. I've only had one merchant get a little persnickety about the lack of a signature technically invalidating the card. I basically explained why I did it that way and informed them that they could cancel the transaction if they didn't like my methods. They chose not to cancel the transaction. (Which was a rather significant sale in a relatively small shop) Owen Sent from my iPad On Jun 10, 2012, at 3:58 AM, Joe Greco wrote: >> ----- Original Message ----- >>> From: "Barry Shein" >> >>> A friend would print in block letters in the sig area of his credit >>> cards "ASK FOR PHOTO ID". He said that almost always cashiers et al >>> would give a cursory glance like they were checking his signature and >>> say thank you and hand him back his card. >> >> This seems like an altogether excellent time to haul out *this* old >> chestnut: >> >> http://www.zug.com/pranks/credit/ >> >> FWIW, My cards have always said SEE ID, and I get about a 40% or so hit >> rate on that. It's been odd recently, cause I sometimes forget, and the >> privacy reflex kicks in and makes me want to say "Why??" :-) > > If your card is not signed, your card is invalid and should not be > accepted by any merchant. > > http://www.mastercard.com/us/merchant/pdf/MerchantAcceptanceGuide_Manual.pdf > > Page 8-2; "Unsigned Credit Cards". VISA has similar requirements. > > Writing "SEE ID" in the signature panel primarily makes your card invalid > *unless* your signature is also present. > > One of the design goals of the V/MC system is that a cardholder is not > supposed to need anything other than their card and the ability to sign. > The comparison of the signature provided to the card signature is > supposed to be one of the primary ways to validate a cardholder, but of > course these days, most vendors are lazy and don't. > > In fact, one of my favorite abusive merchant practices, trying to require > ID, is expressly prohibited: > > http://www.mastercard.com/us/merchant/pdf/BM-Entire_Manual_public.pdf > > Page 5-14, sec. 5.8.4, "Additional Cardholder Identification". > > They're allowed to ask, you're allowed to refuse, and absent a good > reason, they're not allowed to refuse your transaction. Now, if your > signature doesn't match or something else is particularly fishy, yes, > then they should require it, but they cannot require it by default for > all transactions they process. > > That and a "minimum charge" are among the two most common merchant > violations I see. > > For MasterCard violations, report them! > > http://www.mastercard.us/support/merchant-violations.html > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then I > won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) > With 24 million small businesses in the US alone, that's way too many apples. From joelja at bogus.com Sun Jun 10 14:32:56 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 10 Jun 2012 12:32:56 -0700 Subject: OT: Credit card policies (was Re: Dear Linkedin,) In-Reply-To: <4FD4F43E.6060901@sprunk.org> References: <201206101901.q5AJ1kSJ003190@mail.r-bonomi.com> <4FD4F43E.6060901@sprunk.org> Message-ID: <4FD4F668.8020606@bogus.com> On 6/10/12 12:23 , Stephen Sprunk wrote: > On 10-Jun-12 14:01, Robert Bonomi wrote: >>> From: Jay Ashworth > > All of the above is completely irrelevant to the merchant. Given that the thread now spans nine conversations threads and at least 122 messages and is buried in the finer details of merchant handling of gas cards I think it can stop now. Thanks from all of us. Joel From owen at delong.com Sun Jun 10 14:32:22 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 10 Jun 2012 12:32:22 -0700 Subject: Dear Linkedin, In-Reply-To: <20436.58474.786115.356761@world.std.com> References: <201206101058.q5AAwujs033602@aurora.sol.net> <20436.58474.786115.356761@world.std.com> Message-ID: <02429E6A-058D-466C-B69E-C5D51CD49312@delong.com> The agreements often prohibit minimums and cash discounts/card fees. However, the Dodd-Frank act trumps the agreements as law > contract. Owen Sent from my iPad On Jun 10, 2012, at 11:16 AM, Barry Shein wrote: > > I was under the impression (I should dig out my contract) that > merchant contracts also forbid charging more for a charge than for > cash or conversely "discount for cash!" but I see so many violations > of that particularly at gas stations I wonder if that's negotiable in > the contract. > > I remember my father buying a car and pulling out a credit card asking > if they accepted them? The dealer said sure no problem so he said fine > then take another 3% (whatever) off I'll pay cash/check. > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From lyndon at orthanc.ca Sun Jun 10 14:51:14 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sun, 10 Jun 2012 12:51:14 -0700 (PDT) Subject: Dear Linkedin, In-Reply-To: References: <201206101058.q5AAwujs033602@aurora.sol.net> Message-ID: > It is far preferable for the merchant to request ID and verify that the > signature matches the ID _AND_ the picture in the ID matches the > customer. In the late 1990s I had a Visa card from (I think) Citibank that had my picture embossed on the front of the card. I'm surprised this didn't catch on with more card issuers. I see that Bank of America offers this free of charge to their Visa clients, as do some US based credit unions. That card was never lost or stolen, so I don't know if the photo verification would fail as spectacularly as signatures do. --lyndon From jgreco at ns.sol.net Sun Jun 10 14:16:36 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Jun 2012 14:16:36 -0500 (CDT) Subject: Dear Linkedin, In-Reply-To: Message-ID: <201206101916.q5AJGaWZ037981@aurora.sol.net> > > That and a "minimum charge" are among the two most common merchant > > violations I see. > > > > For MasterCard violations, report them! > > > > http://www.mastercard.us/support/merchant-violations.html > > Is that policy worldwide or just for the US? http://www.mastercard.com/us/merchant/pdf/BM-Entire_Manual_public.pdf Despite the "/us/" in the URL, the guide has sections for geographic world regions, so it seems safe to conclude it's worldwide. I have not followed all the geographic subsections to discover what regional variations may exist; I leave that exercise for anyone who finds it of interest. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jgreco at ns.sol.net Sun Jun 10 14:25:00 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 10 Jun 2012 14:25:00 -0500 (CDT) Subject: Dear Linkedin, In-Reply-To: Message-ID: <201206101925.q5AJP05f038108@aurora.sol.net> > The credit card companies should pull their heads out of their asses about t= > his. > > It is much better from an anti-fraud perspective for a stolen card not to co= > ntain a specimen signature for the thief to learn to forge. > > It is far preferable for the merchant to request ID and verify that the sign= > ature matches the ID _AND_ the picture in the ID matches the customer. So, what ID do you consider to be acceptable? Especially when traveling, you've just opened up a can of worms. As a merchant, do you know what a Canadian driver's license is supposed to look like, for example? The reality is that forging signatures is not particularly easy, and since merchants generally don't check ANYWAYS, the whole issue is kind of nebulous. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jlewis at lewis.org Sun Jun 10 15:09:04 2012 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 10 Jun 2012 16:09:04 -0400 (EDT) Subject: Dear Linkedin, In-Reply-To: References: <201206101058.q5AAwujs033602@aurora.sol.net> Message-ID: On Sun, 10 Jun 2012, Lyndon Nerenberg wrote: > In the late 1990s I had a Visa card from (I think) Citibank that had my > picture embossed on the front of the card. I'm surprised this didn't catch > on with more card issuers. I see that Bank of America offers this free of > charge to their Visa clients, as do some US based credit unions. > > That card was never lost or stolen, so I don't know if the photo verification > would fail as spectacularly as signatures do. That's obviously only going to be of use in cases where the card is physically stolen and used in-person. I don't have the numbers, but I strongly suspect that sort of credit card fraud is a small minority, with the majority being CNP transactions. I've personally had several instances of one of my card numbers being used fraudulently (for everything from online casino gambling to tractor parts to hotel charges in countries I've never been to), but never via the card having physically been stolen. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From valdis.kletnieks at vt.edu Sun Jun 10 15:34:55 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 10 Jun 2012 16:34:55 -0400 Subject: Dear Linkedin, In-Reply-To: Your message of "Sun, 10 Jun 2012 12:29:46 -0700." References: <201206101058.q5AAwujs033602@aurora.sol.net> Message-ID: <101170.1339360495@turing-police.cc.vt.edu> On Sun, 10 Jun 2012 12:29:46 -0700, Owen DeLong said: > It is far preferable for the merchant to request ID and verify that the > signature matches the ID _AND_ the picture in the ID matches the customer. Maybe from the anti-fraud standpoint, but not necessarily from the merchant's viewpoint. It's only better if nobody's standing in line. If matching the ID and signature and picture reduces fraud from 4% to 3%, but increases the time to serve the customer by 5%, you're losing money due to fewer sales/hour. And the local supermarket can save a *whole* bunch of money if they can get me to scan my own stuff and pay with a debit card with minimal/no interaction with the staff. Sure, might be a bit higher fraud rate, but being able to run 4 almost-unattended checkout lines more than covers it. Figure a warm body costs $8/hour - as long as the added fraud is under $32/hour, they're coming out ahead. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bzs at world.std.com Sun Jun 10 16:17:33 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 10 Jun 2012 17:17:33 -0400 Subject: CVV numbers In-Reply-To: <20436.56852.634823.592729@world.std.com> References: <20120609070611.346CB80003B@ip-64-139-1-69.sjc.megapath.net> <4FD35A52.3030608@deaddrop.org> <5E216124-6B0C-4828-91C9-CDBD2AD39DD7@delong.com> <8EA21716-A7A5-4380-ADA6-0AC4449F43C3@miniguru.ca> <20436.56852.634823.592729@world.std.com> Message-ID: <20437.3821.238925.777636@world.std.com> Something else rarely considered in these discussions is that the cost of handling cash is upwards of 4%, particularly for larger operations like supermarkets. Someone has to be paid to count it, wrap it (or the bank will charge you to do that), often you have a security service pick it up to bring it to the bank which costs money, and of course there's theft of all sorts possible, cash is cash, counterfeit bills, etc. I guess it's a sunk cost so hard to factor into any single transaction, but it does add up or did back when most sales were cash. Until the early 90s (or thereabouts) it was illegal by state law to take credit cards at supermarkets in Massachusetts for example tho checks w/ id were ok, pain the neck, I remember it well. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Sun Jun 10 16:28:39 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 10 Jun 2012 17:28:39 -0400 Subject: OT: Credit card policies (was Re: Dear Linkedin,) In-Reply-To: <15933113.8720.1339353183227.JavaMail.root@benjamin.baylink.com> References: <4FD4E69F.10708@mtcc.com> <15933113.8720.1339353183227.JavaMail.root@benjamin.baylink.com> Message-ID: <20437.4487.599177.641381@world.std.com> On June 10, 2012 at 14:33 jra at baylink.com (Jay Ashworth) wrote: > ----- Original Message ----- > > From: "Michael Thomas" > > > On 06/10/2012 11:22 AM, John T. Yocum wrote: > > > A merchant can offer a cash discount. > > > > I believe that the law just recently changed on that account. I > > believe that what Barry says was the old reality. > > Perhaps, but Cash/Credit for gas dates back to before I moved to Florida in > 1981. Even Further Off-Topic, isn't "debit" supposed to be "cash"? Why do > I pay the Credit price for it? I think part of the problem is there's no uniform answer to these observations. I remember news reports with videos of cash/credit signs at gas stations saying these were illegal (well, violated their contracts) but no one was enforcing it, an urge to get attorneys-general in on the act since non-uniform contract enforcement could be a violation of some sort of commercial laws or grounds for a civil suit if an injured party has standing. Or maybe some gas companies had the leverage to get exceptions written into their contracts, etc. They're just contracts, they can say anything as long as it's legal. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From bzs at world.std.com Sun Jun 10 16:45:51 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 10 Jun 2012 17:45:51 -0400 Subject: Dear Linkedin, In-Reply-To: References: <201206101058.q5AAwujs033602@aurora.sol.net> Message-ID: <20437.5520.313077.906639@world.std.com> A few years ago I had a checkbook stolen. The genius bank branch decided it was sufficient to just print new checks starting at a much higher number and "put it in the system" rather than cancel the account number. I protested but hey so long as they were responsible for any fraud*. Then thousands of dollars of cashed checks began appearing. What was amusing was they each had info like my driver's license number and date of birth carefully hand-printed on them. EXCEPT, it wasn't *my* driver's license # or date of birth, it was all just kinda random. Which led us to believe (when talking to bank security) that they just have friends who work as cashiers, these were all at places like Wal-Mart, big retail stores, who just accept the bad checks for a cut. I agree it's all a matter of percentages but it says something about putting photos on credit cards etc. I had something similar happen with business checks (a small vendor was burglarized), similar result and conclusion: The crooks were working with bank tellers or other insiders, they even knew the magic amounts at each branch beyond which more security checks kick in, again, according to the bank security people I was clearing this up with. * I sort of regretted that because they managed to burn up quite a few hours of my time when it all went bad. They've got you at that point, show up here, show up now, fill out all these affidavits, etc or we won't cover the fraud. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From vixie at isc.org Sun Jun 10 16:46:14 2012 From: vixie at isc.org (Paul Vixie) Date: Sun, 10 Jun 2012 21:46:14 +0000 Subject: Our first inbound email via IPv6 In-Reply-To: (Randy Bush's message of "Sun, 10 Jun 2012 08:20:07 -0700") References: Message-ID: Randy Bush writes: > > ... > i have assiduously avoided gaining serious anti-spam fu. but it seems > to me that ipv6 does not create/enable significantly more spam-bots. the malware will generally have complete control over the bottom 64 bits of an ipv6 address. there's no reason to expect to ever receive more than one spam message from any single ipv6 source. so, we'll all be blackholing /64's. moreover, there are going to be more native endpoints in ipv6 than there were in ipv4, since the NAT incentives are very different in the larger address pool. so, we'll all need network operators to whitelist the parts of their address spaces that they plan to send e-mail from, so that we can avoid having to blackhole things one /64 at a time. as before: for more information see: http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electronic_mail/ paul From vixie at isc.org Sun Jun 10 16:53:55 2012 From: vixie at isc.org (Paul Vixie) Date: Sun, 10 Jun 2012 21:53:55 +0000 Subject: ROVER routing security - its not enumeration In-Reply-To: <4FCF9DD5.8040102@gmail.com> (Doug Montgomery's message of "Wed, 06 Jun 2012 14:13:41 -0400") References: <4FCF9DD5.8040102@gmail.com> Message-ID: Doug Montgomery writes: > > ... > > I think we debate the superficial here, and without sufficient imagination. > The enumerations vs query issue is a NOOP as far as I am concerned. With > a little imagination, one could envision building a box that takes a feed > of prefixes observed, builds an aged cache of prefixes of interest, queries > for their SRO records, re queries for those records before their TTLs > expire, and maintains a white list of "SRO valid" prefix/origin pairs that > it downloads to the router. this sounds like a steady state system. how would you initially populate it, given for example a newly installed core router having no routing table yet? if the answer is, rsync from somewhere, then i propose, rsync from RPKI. if the answer is, turn off security during bootup, then i claim, bad idea. > ... > > Point being, with a little imagination I think one could build components > with either approach with similar black box behavior. i don't think so. and i'm still waiting for a network operator to say what they think the merits of ROVER might be in comparison to the RPKI approach. (noting, arguments from non-operators should and do carry less weight.) -- Paul Vixie KI6YSY From gary.buhrmaster at gmail.com Sun Jun 10 17:02:58 2012 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sun, 10 Jun 2012 22:02:58 +0000 Subject: CVV numbers In-Reply-To: References: <11561027.8602.1339274171831.JavaMail.root@benjamin.baylink.com> Message-ID: On Sun, Jun 10, 2012 at 8:02 AM, Owen DeLong wrote: .... > The skimmers can use CVV1 and bypass the CVV2 protection in most > cases (though that requires them to gen up a fake or fraudulent card and > do card present transactions which does add risk for them). Not so much for them, but the sacrificial mules that go to the (physical) stores (and the mules, at best, know the location to meet their handler, who is not even the person/group responsible for the acquisition of the numbers, but just another middle person). > It costs almost nothing, so a few fraudulent transactions blocked is probably > enough. That doesn't change the fact that I believe there have to be more > effective methods that wouldn't cost much more. One of the CC industry "think tanks" (the think tank part of first data; to be honest, I am not sure that part still exists) has proposed various alternatives over the years (including a true non-traceable cash type of CC alternative that was sort of appealing), but the priority of the banks continues to be to insure convenience (with minimal losses for the banks), and almost all the of the alternative involved some sort of additional inconvenience to the customer. If you can come up with a good alternative, there are many many millions to be made. I am not smart enough to be able to come up with a clearly better alternative (other than a personal optimization to remember all the CC numbers, including the CVV2, as you stated you do). Gary From rbf+nanog at panix.com Sun Jun 10 17:06:05 2012 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 10 Jun 2012 17:06:05 -0500 Subject: Dear Linkedin, In-Reply-To: <101170.1339360495@turing-police.cc.vt.edu> References: <201206101058.q5AAwujs033602@aurora.sol.net> <101170.1339360495@turing-police.cc.vt.edu> Message-ID: <20120610220605.GA22422@panix.com> On Sun, Jun 10, 2012 at 04:34:55PM -0400, valdis.kletnieks at vt.edu wrote: > On Sun, 10 Jun 2012 12:29:46 -0700, Owen DeLong said: > > It is far preferable for the merchant to request ID and verify that the > > signature matches the ID _AND_ the picture in the ID matches the customer. > > Maybe from the anti-fraud standpoint, but not necessarily from the merchant's viewpoint. > > It's only better if nobody's standing in line. If matching the ID > and signature and picture reduces fraud from 4% to 3%, but increases > the time to serve the customer by 5%, you're losing money due to > fewer sales/hour. For the most part, fraud in a card present transaction isn't eaten by the merchant. But the same reasoning still applies. The card issuers don't want you have to show ID, becuase you might decide it's too much trouble, and just use some other method to pay. Eliminating fraud isn't an objective of card issuers. Making money is. Fraud reduction is only done when the savings from the reduced fraud exceeds both the cost of the fraud preventing measure and any revenue that is lost because of inconveniencing customers. And, sometimes, they'll choose to accept a higher rate of fraud if it will generate enough revenue to offset it ... consider how many places you can now avoid signing for small dollar purchases. The cost of accepting the additional fraud was considered worth it in comparison to the revenue generated from getting people to use their cards for small transactions. -- Brett From bonomi at mail.r-bonomi.com Sun Jun 10 17:21:43 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 10 Jun 2012 17:21:43 -0500 (CDT) Subject: OT: Credit card policies (was Re: Dear Linkedin,) In-Reply-To: <4FD4F43E.6060901@sprunk.org> Message-ID: <201206102221.q5AMLhJZ005318@mail.r-bonomi.com> Stephen Sprunk opined: > > On 10-Jun-12 14:01, Robert Bonomi wrote: > >> From: Jay Ashworth > >> > >> Even Further Off-Topic, isn't "debit" supposed to be "cash"? Why do > >> I pay the Credit price for it? > > > > It is, and *ISN'T*, 'cash'. > > > > Unlike cash (and like a credit card), it is simply an instruction to a > > third party to pay the retailer a specified amount. And as such, is > > subject to the terms of the contract between -those- parties as to how > > payment is made an what charges are imposed. > > > > Unlike a credit card, the money _is_ immediately dedecuted from your > > bank account. > > All of the above is completely irrelevant to the merchant. False to fact. The fact that it is an order for (deferred) third-party payment, vs 'cash in hand', is *very* relevant to the merchant. For starters, the purchase amount becomes a 'debt' owed to the merchant by the third party. There are massive legal ramifications to that distinction alone. > > Like a credit card, it is the third-party clearinghouse that gets the > > mone from you, and passes it on to the retailer. AFTER extracting their > > charges for the service they provide. > > FWIW, this is known as the "discount" rate. "Not exactly". There are typically three components to the total charge that the merchant pays on a given transaction. One is a charge based on a percentage of the transaction amount -- that _percentage_ figure is known as the discount rate, distinct from the dollar-amount deducted for that purpose. Over and above the 'percentage' amount, there are 'per transaction' charges - which are essentially independant of the size of the transation. On 'small' transactions, the 'per transaction' charges tend to swamp the 'percntage' charge. > > You pay the 'credit' price, because the card issuer, and the clearinghouse > > operations _charge_ the merchant the same amount for those transactions > > as for 'credit' ones. Thus the merchant does not receive any of the > > benefits of a 'cash' transaction, so there is no 'discount' to pass on to > > the buyer. > > The merchant's discount rate varies between card types. That's why many > merchants don't accept AmEx, DC, CB and Nexus: their discount rates are > higher than Visa and MC. For a low-margin business, the difference in > rates can make the difference between profit and loss on a given sale. > > > At one point, VISA, charged -more- for debit transactions than credit > > ones. Despite the fact that there was -zero- risk to them on the debit > > transaction. > > Wrong. Even debit cards present a risk of chargeback due to fraud. *SNICKER* According to the law, 'debit' cards (processed through the CC network) do -not- have any of the protections with regard to limit-of-liability that credit cards do. The account owner can assert 'fraud', but VISA is _not_ required to refund them any of the monies involved. For the 'debit' type transaction, VISA has the money in hand -before- they pay out to the merchant, the risk of them not getting the money is zero. Legally, the risk of having to return the money after an allegation of fraud is also zero, given that the merchant has followed the letter of the contract in processing the card. And, if the merchant has not don so, then VISA charges back the full amount to the merchant -- with the net risk to VISA being zero. The other kind of 'debit' items -- ATM transactions do not involve VISA at all, only the issuing bank. For these, With the proper PIN presented, 'fraud' charges are (sometimes) eaten by the bank involved as a 'customer relations' measure. Generally, the presentation of the proper PIN is taken as 'proof' that an authorized user did perform the transaction, *until* such time as the bank is notified that the card or PIN has been lost/stolen or otherwise compromised. > However, the fraud rates are lower due to the us of PINs, so the > discount rate is also lower. Sorry, but that is utter fiction. PIN-based payments are processed as ATM (Automatic Teller Machine) network transactions -- they are *NOT* 'debit' transactions via credit-card clearing- house network. > > VISA got sued over the matter, since (at that time) it was impossible to > > tell whether the card number presented was debit or credit. > > It's still impossible to tell, which is why most card terminals ask > whether the card is credit or debit. Incorrect. (this is mostly a terminology issue -- what has become 'common usage' is muddy at best and often misunderstood) The terminal has no 'need to know' whether it is a bank-issued credit or bank-issued debit card. It does NOT ask that -- contrary to what the buttons appear to imply. Terminals ask because many cards today are 'multi-function' -- they can act as a bank-issued credit (or debit, but not both) card _and_ as an ATM card. The _labels_ on the terminals are technically inaccurate, the proper labels should be 'Credit/Debit' and 'ATM'. There are -four- types of cards in existance in the U.S., today, with =two= unrelated, unconnected, types of processing networks. Many, but _not_ all, cards have 'dual credentials', and are usable on both networks. The four types of cards: 1) non-bank-issued credit cards. examples: Amex, Diners Club. 2) bank-issued 'association'-branded credit cards. example: Visa/MC. 3) bank-issued 'association'-branded debit cards. example: Visa/Mc. 4) bank-issued ATM cards. The two types of networks: 1) the inter-bank ATM networks e.g. STARZ, CIRRUS, 2) the credit-card clearinghouses. e.g. VISA/MC, AMEX, etc. A non-bank-issued card cannot be used on the ATM network. A bank-issued card can function as a debit or credit (but not both) card, as an ATM card, or as _both_. The point-of-sale terminal asks a question to determine 'which network' (ATM or credit/debit-card) to process the transaction over. When a card can be used on both networks, there is no way to determine which network should be used, =other= than to ask. As the old saw goes "ROM does *NOT* mean ead perator's ind" *grin* > If you press the "credit" button, > even if the card is a debit card, it is processed as a credit card--with > the credit card discount rate. TODAY, that is correct. Before the VISA lawsuit mentioned above, that was -not- the case. A VISA 'debit' card, _processed_as_a_credit_card_, was charged at materially higher rates than a VISA 'credit' card. $DAYJOB found that the clearing-house charged the same for processing the transaction, but the passed-through charges originating from VISA were over 40% higher. It was impossible to predict the charges, which meant it was impossible to automatically feed data into the accounting system. I had a major argument/fight with $DAYJOB's clearinghouse and with VISA corporate on this precise matter a few months before the above-mentioned lawsuit was filed. $DAYJOB was a small-fry operation and did not participate in the lawsuit. > That's why Visa's advertising and > contests promote customers using signature (i.e. "credit") transactions: > Visa gets more money that way (at the cost of their merchants). Actually, VISA gets _some_ money rather than none. They don't get anything on an ATM nextork (PIN-based) transaction. It also saves the purchaser from being assessed a charge for a 'foreign' ATM transaction by their bank -- typically at least $1, and possibly as much as $4. For a 'quality' merchant, the typicaal difference in transaction fees between the two networks (ATM vs VISA/MC) is a fraction of a percentage point. Small enough to be, generally, immaterial to the retailer. > > As a result of the lawsuit, the cost differential between credit and debit transactions was eliminated. > > ... except it's still there, though perhaps in the other direction. You don't know what you don't know. Starting with the difference between PIN-based ATM network transactions and PIN-less 'debit card' VISA/MC/etc network transactions. > The discount rate for "debit" transactions is lower, but a PIN must be > used to get that rate. Incorrect. That is an bank ATM card transaction -- not a merchant-account card transaction. It is procesed by an entirely different network, with an entirely different fee structure. Ususally including a fee of $1 or more, charged directly to the cardholder for using an 'off network' ATM machine. The VISA/MC network transaction rates are *identical* for VISA 'debit' and VISA 'credit' cards. Since the above-mentioned lawsuit, that is. > The exact rates vary between card networks, card > processors and even merchants, but a few years ago the numbers I heard > were 4% for "credit" (i.e. signature) transactions and 1% for "debit" > (i.e. PIN) transactions. I don't know where you heard those numbers but 4% on credit card transactions is typical of what the 'we provide credit card processing for *anybody*' sleazeball operations charge. The ones that fly-by-night internet-only pornography operators use. A sizable, established, brick-and-morter retailer with a an established record of few-to-no chargebacks will typically have rates of around 1.4%. $DAYJOBB got a discount rate of 1.9% after putting together only a six-month history with -zero- chargebacks. This was for an established 'MOTO' (mail-order/telephone-order) business, located in a downtown office building, gross reveues in the low 7 figures, but only a few thousand dollars a month in card charges. > That is why those nifty PIN terminals appeared > everywhere virtually overnight: saving 3% on every "debit" transaction > easily paid for all those new terminals. The PIN terminals appeared so that people could use bank ATM cards -without- having to have the 'name' credit card. Especially when those 'name' cards started applying significant 'annual fees' for the right to simply -have- the card. VISA/MC/etc 'debit' cards were usable at any location that took 'credit' cards of the same brand, with _no_ additional equipment (not even a PIN pad) long before widespread ATM networks existed. In the early days of ATM transactions, but after 'networks' were in place that allowed one to use an ATM card at any ATM of any 'cooperating' bank, there was -no- charge to either the bank or the ATM owner/operator. The assumption (borne out in practice, _then_) That there were roughly equal numbers of transactions by non-customers at bank-owned ATMs and transactions by bank customers at non-bank ATMs. As ATMs proliferated beyond bank sites, into retail establishments, and eventually integrated with the cash-register CC processing, that balance no longer held. And 'per transaction' charges were assessed. ATM operators charged 'foreign' customers a transaction fee for the privilege of using their machines, AND banks charged their customers a fee for using 'foreign' machines. From owen at delong.com Sun Jun 10 17:40:15 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 10 Jun 2012 15:40:15 -0700 Subject: Dear Linkedin, In-Reply-To: <201206101925.q5AJP05f038108@aurora.sol.net> References: <201206101925.q5AJP05f038108@aurora.sol.net> Message-ID: <40B347D9-4121-4CDE-AEE4-5F95EDFBAC48@delong.com> On Jun 10, 2012, at 12:25 PM, Joe Greco wrote: >> The credit card companies should pull their heads out of their asses about t= >> his. >> >> It is much better from an anti-fraud perspective for a stolen card not to co= >> ntain a specimen signature for the thief to learn to forge. >> >> It is far preferable for the merchant to request ID and verify that the sign= >> ature matches the ID _AND_ the picture in the ID matches the customer. > > So, what ID do you consider to be acceptable? Especially when traveling, > you've just opened up a can of worms. As a merchant, do you know what a > Canadian driver's license is supposed to look like, for example? From someone who supplies an out-of-country drivers license, I'd request to see their passport. From someone who supplies an out-of-state drivers license, I'd probably accept it, but the risks there are somewhat reduced at least. Mostly, I'd accept any domestic government issued photo ID and/or any passport. Generally when someone asks for my ID, I use my passport. > The reality is that forging signatures is not particularly easy, and since > merchants generally don't check ANYWAYS, the whole issue is kind of > nebulous. Sure. However, if you provide the forger a specimen of your signature on the card, you're just asking for trouble IMHO. If the merchant is going to go to the trouble of checking the signature, the extra step of matching that against ID that matches the cardholder name instead of just matching it to the back of the card is a negligible additional inconvenience while providing an additional layer of protection. Owen From owen at delong.com Sun Jun 10 17:44:12 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 10 Jun 2012 15:44:12 -0700 Subject: Dear Linkedin, In-Reply-To: <20437.5520.313077.906639@world.std.com> References: <201206101058.q5AAwujs033602@aurora.sol.net> <20437.5520.313077.906639@world.std.com> Message-ID: <5B94D2E7-154A-4E6D-A9A8-AA1650CED973@delong.com> In such a circumstance I use the following: "Close this account. Either send me a check for the remaining balance or deposit into my newly created account at your institution. Whichever you prefer." Owen On Jun 10, 2012, at 2:45 PM, Barry Shein wrote: > > A few years ago I had a checkbook stolen. The genius bank branch > decided it was sufficient to just print new checks starting at a much > higher number and "put it in the system" rather than cancel the > account number. I protested but hey so long as they were responsible > for any fraud*. > > Then thousands of dollars of cashed checks began appearing. > > What was amusing was they each had info like my driver's license > number and date of birth carefully hand-printed on them. > > EXCEPT, it wasn't *my* driver's license # or date of birth, it was all > just kinda random. > > Which led us to believe (when talking to bank security) that they just > have friends who work as cashiers, these were all at places like > Wal-Mart, big retail stores, who just accept the bad checks for a cut. > > I agree it's all a matter of percentages but it says something about > putting photos on credit cards etc. > > I had something similar happen with business checks (a small vendor > was burglarized), similar result and conclusion: The crooks were > working with bank tellers or other insiders, they even knew the magic > amounts at each branch beyond which more security checks kick in, > again, according to the bank security people I was clearing this up > with. > > > * I sort of regretted that because they managed to burn up quite a few > hours of my time when it all went bad. They've got you at that point, > show up here, show up now, fill out all these affidavits, etc or we > won't cover the fraud. > > > -- > -Barry Shein > > The World | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada > Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From owen at delong.com Sun Jun 10 17:47:20 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 10 Jun 2012 15:47:20 -0700 Subject: Dear Linkedin, In-Reply-To: <20120610220605.GA22422@panix.com> References: <201206101058.q5AAwujs033602@aurora.sol.net> <101170.1339360495@turing-police.cc.vt.edu> <20120610220605.GA22422@panix.com> Message-ID: On Jun 10, 2012, at 3:06 PM, Brett Frankenberger wrote: > On Sun, Jun 10, 2012 at 04:34:55PM -0400, valdis.kletnieks at vt.edu wrote: >> On Sun, 10 Jun 2012 12:29:46 -0700, Owen DeLong said: >>> It is far preferable for the merchant to request ID and verify that the >>> signature matches the ID _AND_ the picture in the ID matches the customer. >> >> Maybe from the anti-fraud standpoint, but not necessarily from the merchant's viewpoint. >> >> It's only better if nobody's standing in line. If matching the ID >> and signature and picture reduces fraud from 4% to 3%, but increases >> the time to serve the customer by 5%, you're losing money due to >> fewer sales/hour. > > For the most part, fraud in a card present transaction isn't eaten by > the merchant. > > But the same reasoning still applies. The card issuers don't want you > have to show ID, becuase you might decide it's too much trouble, and > just use some other method to pay. > > Eliminating fraud isn't an objective of card issuers. Making money is. > Fraud reduction is only done when the savings from the reduced fraud > exceeds both the cost of the fraud preventing measure and any revenue > that is lost because of inconveniencing customers. And, sometimes, > they'll choose to accept a higher rate of fraud if it will generate > enough revenue to offset it ... consider how many places you can now > avoid signing for small dollar purchases. The cost of accepting the > additional fraud was considered worth it in comparison to the revenue > generated from getting people to use their cards for small > transactions. > > -- Brett Right, but eliminating fraud should be an objective of consumers because ultimately, we are the ones paying for it regardless of who "eats it" on the actual transaction. If the merchant eats it, the merchant has to make up for it with increased prices. If the card processing company eats it, they have to use high discount rates or other fees to cover it. If the card issuing company eats it, they have to use fees and/or interest rates to make up for it. If the bank eats it, they have to make up for it in other fees, reduced services, reduced interest on accounts, increased interest rates, etc. Ultimately, no matter who eats it, it gets passed along to the consumer. So, any card company that starts getting their merchants to decline transactions based on my anti-fraud efforts will find that I consider their product too risky and will use an alternate form of payment. Owen From jra at baylink.com Sun Jun 10 18:11:54 2012 From: jra at baylink.com (Jay Ashworth) Date: Sun, 10 Jun 2012 19:11:54 -0400 (EDT) Subject: Dear Linkedin, In-Reply-To: <20120610220605.GA22422@panix.com> Message-ID: <610439.8746.1339369914325.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brett Frankenberger" > But the same reasoning still applies. The card issuers don't want you > have to show ID, becuase you might decide it's too much trouble, and > just use some other method to pay. Except for Amex, who have always *stringently* required this; I've even seen customer-facing advertising pointing it out. They have to do something to get merchants to take their card with the higher discount rate. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From rbf+nanog at panix.com Sun Jun 10 18:39:28 2012 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 10 Jun 2012 18:39:28 -0500 Subject: Dear Linkedin, In-Reply-To: References: <201206101058.q5AAwujs033602@aurora.sol.net> <101170.1339360495@turing-police.cc.vt.edu> <20120610220605.GA22422@panix.com> Message-ID: <20120610233927.GA9236@panix.com> On Sun, Jun 10, 2012 at 03:47:20PM -0700, Owen DeLong wrote: > > On Jun 10, 2012, at 3:06 PM, Brett Frankenberger wrote: > > > > Eliminating fraud isn't an objective of card issuers. Making money is. > > Fraud reduction is only done when the savings from the reduced fraud > > exceeds both the cost of the fraud preventing measure and any revenue > > that is lost because of inconveniencing customers. And, sometimes, > > they'll choose to accept a higher rate of fraud if it will generate > > enough revenue to offset it ... consider how many places you can now > > avoid signing for small dollar purchases. The cost of accepting the > > additional fraud was considered worth it in comparison to the revenue > > generated from getting people to use their cards for small > > transactions. > > Right, but eliminating fraud should be an objective of consumers > because ultimately, we are the ones paying for it regardless of who > "eats it" on the actual transaction. That assumes that minimizing cost is an objective of consumers. In general, it's not. Maximizing utility is. For some, minimizing cost is a major part of that. For me, I routinely trade money for convenience. And I'll gladly pay a percentage point or two more in exchange for all my credit transactions being handled more quickly. I'm far from the only one. Credit card companies keep making it easier to use their card, because they've found it more profitable to do so. There doesn't seem to be a market for a card that is harder to use, but saves consumers a little money through reduced fraud. -- Brett From oliver at g.garraux.net Sun Jun 10 19:14:18 2012 From: oliver at g.garraux.net (Oliver Garraux) Date: Sun, 10 Jun 2012 20:14:18 -0400 Subject: Timeframe for LinkedIn Attack? Message-ID: 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 From vixie at isc.org Sun Jun 10 19:17:23 2012 From: vixie at isc.org (Paul Vixie) Date: Mon, 11 Jun 2012 00:17:23 +0000 Subject: rate limiting (Re: Open DNS Resolver reflection attack Mitigation) In-Reply-To: <4FD24DD0.5000408@ttec.com> (Joe Maimon's message of "Fri, 08 Jun 2012 15:09:04 -0400") References: <4FD24DD0.5000408@ttec.com> Message-ID: Joe Maimon writes: > 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? rate limiting on recursive servers is complicated by the lack of caching in most stub resolvers and applications. this makes it hard to tell by pure automation when a request flow is a spoof-source attack and when not. for most of us this isn't a problem since we'll put access control lists on our recursive name servers, only allowing queries from on-campus or on-net. for intentionally open resolvers, i expect there's a lot of monitoring and hand tuning, and that many deliberately low-grade attacks get by. noting that there are at least 15 million open recursive servers (most in low-quality CPE boxes front-ending cable or DSL links), an attacker has a long menu of places to send a small number of queries (to each) so that any rate limiting done by any one of the open recursive servers would not defend any victims against spoofed-source. spoofed-source is becoming wildly more popular. that's probably where to fix this. also the 15 million open recursives would be good to see fixed. at the moment most attacks are using authority servers, where it's far easier to automatically tell attack flows from non-attack flows. -- Paul Vixie KI6YSY From bonomi at mail.r-bonomi.com Sun Jun 10 19:28:27 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 10 Jun 2012 19:28:27 -0500 (CDT) Subject: Timeframe for LinkedIn Attack? In-Reply-To: Message-ID: <201206110028.q5B0SRFQ006625@mail.r-bonomi.com> > From: Oliver Garraux > > Hey, I'm curious if anyone has heard of a possible timeframe for the > LinkedIn attack? > According to the reports in this group, the attack occured June 4, and was detected on the 4th or 5th. From apishdadi at gmail.com Sun Jun 10 19:47:49 2012 From: apishdadi at gmail.com (Ameen Pishdadi) Date: Sun, 10 Jun 2012 19:47:49 -0500 Subject: Dear Linkedin, In-Reply-To: <610439.8746.1339369914325.JavaMail.root@benjamin.baylink.com> References: <610439.8746.1339369914325.JavaMail.root@benjamin.baylink.com> Message-ID: <62982583-EF5C-4B21-B49A-14B9938C1D18@gmail.com> Don't know if someone already posted this but there forcing people the reset there passwords, but it let's you reset it to the same password as before... How many people are going to use the same pass? I'd say a good portion, LinkedIn needs some new isec employees On Jun 10, 2012, at 6:11 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Brett Frankenberger" > >> But the same reasoning still applies. The card issuers don't want you >> have to show ID, becuase you might decide it's too much trouble, and >> just use some other method to pay. > > Except for Amex, who have always *stringently* required this; I've even > seen customer-facing advertising pointing it out. > > They have to do something to get merchants to take their card with the > higher discount rate. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at 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 > From bzs at world.std.com Sun Jun 10 21:11:04 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 10 Jun 2012 22:11:04 -0400 Subject: Dear Linkedin, In-Reply-To: References: <201206101058.q5AAwujs033602@aurora.sol.net> <101170.1339360495@turing-police.cc.vt.edu> <20120610220605.GA22422@panix.com> Message-ID: <20437.21432.886988.85741@world.std.com> > > Eliminating fraud isn't an objective of card issuers. Making money is. > > Fraud reduction is only done when the savings from the reduced fraud > > exceeds both the cost of the fraud preventing measure and any revenue > > that is lost because of inconveniencing customers. > > Right, but eliminating fraud should be an objective of consumers because > ultimately, we are the ones paying for it regardless of who "eats it" on the > actual transaction. This applies just as well to fraud-prevention measures, a cost is a cost is a cost, your perceived morality of the cost makes no difference, money is fungible! Which means, money doesn't care! You'd have to make up the cost of all that fraud-prevention in the same way. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From jra at baylink.com Sun Jun 10 21:32:15 2012 From: jra at baylink.com (Jay Ashworth) Date: Sun, 10 Jun 2012 22:32:15 -0400 (EDT) Subject: Dear Linkedin, In-Reply-To: <20437.21432.886988.85741@world.std.com> Message-ID: <11456115.8756.1339381935291.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Barry Shein" > This applies just as well to fraud-prevention measures, a cost is a > cost is a cost, your perceived morality of the cost makes no > difference, money is fungible! Which means, money doesn't care! You'd > have to make up the cost of all that fraud-prevention in the same way. The money doesn't care... but the customers sure the hell do. Alas, getting the corporation in the middle to eat it out of profit -- I'm not clear why we're at a place where no one even considers that possibility, but we very clearly are; I'm sure the corporations are thrilled -- is next to impossible. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From bzs at world.std.com Sun Jun 10 21:36:42 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 10 Jun 2012 22:36:42 -0400 Subject: Dear Linkedin, In-Reply-To: <62982583-EF5C-4B21-B49A-14B9938C1D18@gmail.com> References: <610439.8746.1339369914325.JavaMail.root@benjamin.baylink.com> <62982583-EF5C-4B21-B49A-14B9938C1D18@gmail.com> Message-ID: <20437.22970.99377.799263@world.std.com> On June 10, 2012 at 19:47 apishdadi at gmail.com (Ameen Pishdadi) wrote: >Don't know if someone already posted this but there forcing people >the reset there passwords, but it let's you reset it to the same >password as before... How many people are going to use the same pass? >I'd say a good portion, LinkedIn needs some new isec employees It's only Linkedin not bank accounts -- not that most people's bank accounts are much to worry about either :-) But what's dumb is that what they're asking for with that policy is a big headache for themselves when accounts get messed up, whatever pranksterism or nefarious deed, I dunno, spamming from someone's cracked acct is a good example, and Linkedin's staff has to deal with each and every one. Maybe they lack imagination as to what they might be getting themselves into. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From jcdill.lists at gmail.com Sun Jun 10 21:47:59 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Sun, 10 Jun 2012 19:47:59 -0700 Subject: Password Safes In-Reply-To: References: <4FD25716.3000801@mtcc.com> <4FD258D3.8080907@paulgraydon.co.uk> <4FD25F06.6040801@mtcc.com> <142D8C95-5FA3-4404-B043-A7BDD52C100E@orthanc.ca> <4FD26378.9070900@mtcc.com> Message-ID: <4FD55C5F.7070407@gmail.com> On 08/06/12 2:01 PM, Lyndon Nerenberg wrote: > the Android client lets me pull up passwords on my phone when I'm on one of the systems that doesn't have a native 1Password client, or when I am on the road. Does the Android client know how to automagically login to 100001 different Android Apps with your 1Password saved passwords? Does the iDevice client know how to automagically login to 10000001 different Apple Apps with your 1Password-saved passwords? Because if it doesn't do this automagically, it's not going to work for most people. jc From a.harrowell at gmail.com Mon Jun 11 02:38:38 2012 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Mon, 11 Jun 2012 08:38:38 +0100 Subject: Dear Linkedin, In-Reply-To: <20437.22970.99377.799263@world.std.com> References: <610439.8746.1339369914325.JavaMail.root@benjamin.baylink.com> <62982583-EF5C-4B21-B49A-14B9938C1D18@gmail.com> <20437.22970.99377.799263@world.std.com> Message-ID: <201206110839.01560.a.harrowell@gmail.com> The Cambridge University Computer Lab has had a crack at this question in their Technical Report 817 on Web authentication: http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-817.html Their conclusion is to use the Mozilla password manager (or close analogue, but they like it because it's open source, free, and available). Anyway, it's well worth reading. A question: password managers are obviously a great idea, and password manager + synchronisation takes care of multiple devices. However, if the passwords themselves are poor, this doesn't help. As well as a browser vault, we need a Passwords API to let a Web site request the creation of a password. You will need: a MakePassword() action that creates a random, cryptographically strong password for the specified domain and specified username, with the specified TTL, and registers it in the vault. a same-domain constraint an SSL only constraint a RequestLogin() action, leading to either automatic login or a user dialog as desired a RevokePassword() action, that flushes the existing password and forces the creation of a new one. this can be explicitly invoked, for example after a security incident, or else activated when a TTL runs out. a user interface action that permits the user to invoke Revoke on all or a subset of the passwords. This addresses: making up passwords, not sharing passwords, remembering passwords, revoking compromised passwords. No, it won't help if the evil maid sprays liquid nitrogen into your laptop in suspend mode to render analysis of RAM easier yadda yadda, but nothing will*, and if you face that kind of threat, you're operating in a different league and passwords are the least of your worries. Because you're not using them...are you? Also, if the enemy can defeat SSL they can still phish you, but that's going to be a very hard one to eliminate entirely, whatever happens. (and how many security incidents are like that compared to ones involving password compromises?) Why didn't W3C do this 10 years ago? Kind of amazing, given how common a pattern username/password is, that there is no mention of the word here: http://www.w3.org/TR/ *you can of course encrypt the disk that contains the password vault, but in general, someone with physical access will win. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kilobit at gmail.com Mon Jun 11 06:08:07 2012 From: kilobit at gmail.com (bas) Date: Mon, 11 Jun 2012 13:08:07 +0200 Subject: Arbor Peakflow competitor? Message-ID: Hi All, Has anyone worked with GenieATM? http://www.genienrm.com/index.php/products/9-genieatm/genieatm-6000/21-genieatm-6000-isp-series It looks as it has the same functionality as Peakflow. I'm curious if anyone has tested or deployed the solution. And if so, what are your experiences? Thanks in advance, Bas From dougm.tlist at gmail.com Mon Jun 11 07:22:20 2012 From: dougm.tlist at gmail.com (Doug Montgomery) Date: Mon, 11 Jun 2012 08:22:20 -0400 Subject: ROVER routing security - its not enumeration In-Reply-To: Message-ID: On 6/10/12 5:53 PM, "Paul Vixie" wrote: >Doug Montgomery writes: > >> > ... >> >> I think we debate the superficial here, and without sufficient >>imagination. >> The enumerations vs query issue is a NOOP as far as I am concerned. >>With >> a little imagination, one could envision building a box that takes a >>feed >> of prefixes observed, builds an aged cache of prefixes of interest, >>queries >> for their SRO records, re queries for those records before their TTLs >> expire, and maintains a white list of "SRO valid" prefix/origin pairs >>that >> it downloads to the router. > >this sounds like a steady state system. how would you initially populate >it, >given for example a newly installed core router having no routing table >yet? > >if the answer is, rsync from somewhere, then i propose, rsync from RPKI. > >if the answer is, turn off security during bootup, then i claim, bad idea. Well, I should probably let the ROVER guys say what they have in mind. The above started from my imagination that if you did not want routers actually doing route-by-route queries, that it would be easy to build a validating cache that behaves similar to a RPKI validating cache, but pulling the info from rDNS as opposed to RPKI. Maybe the ROVER guys have something else in mind (e.g., routers doing the queries themselves, some other model of how the info ... Or its impacts ... Is effected on the router). IFF you do imagine that there is a SRO validating cache box - you can decompose the question of how one solves state skew between (1) rtr and cache, (2) cache and info authoritative source, and (3) how new authoritative information gets globally distributed/effected in the system. Looking at just (1) (your question I think), we have a couple of different questions to look at. a. How does a router with no origin info (new router, router reboot), synchronize with the cache (assuming the cache has state). The current machinery of rtr-to-cache would work fine here. Might need to add a bit or two, but the basic problem is the same. b. How does a cache with no state, build a list of prefix-origin pairs? Clearly if one builds a SRO validating cache box, the usual techniques of checkpointing state, having redundant cache's etc could be used ... But at some level the question of having to get initial state, and what the router does during that period (assuming that the stateless cache is his only source) must be answered. One way of thinking about these questions, is to ask how would it work in RPKI? If for origin validation we have a strict "don't fail open" during resets requirement, then there are a lot of initialization questions we must address in any system. I.e., what does the router do, if its only RPKI cache has to rebuild state from zero? What does such a router do if it looses contact with its cache? At this point, I could propose more ideas, but probably going further with my imagination is not important. The ROVER guys should tell us what they have in mind, or someone interested in building a ROVER validating cache should design one and tell us. But maybe stepping back one level of abstraction, you can think of things this way. We have a top-down-enumeration vs query model. One could put a cache in the the query model to make it approximate an enumeration model, but only to the point that one has, or can build a reasonably complete, list of prefixes of interest. If one admits that sometimes there will be cache misses (in the query/cache model) and one might have to query in those cases, then the trade off seems to be how often that occurs vs the responsiveness one would get out of such a system for situations when the authoritative information itself changes (case 3 above). I.e., how fast could you turn up a new prefix in each system? Maybe the ROVER guys don't believe in caches at all. In which case I return you to the original "OMG! Enumeration vs Query thread". I just don't think that is the most significant difference between the two approaches. dougm > >> ... >> >> Point being, with a little imagination I think one could build >>components >> with either approach with similar black box behavior. > >i don't think so. and i'm still waiting for a network operator to say what >they think the merits of ROVER might be in comparison to the RPKI >approach. >(noting, arguments from non-operators should and do carry less weight.) > >-- >Paul Vixie >KI6YSY > From Knut.Syed at bkk.no Mon Jun 11 07:32:40 2012 From: Knut.Syed at bkk.no (Syed Knut A.) Date: Mon, 11 Jun 2012 12:32:40 +0000 Subject: Problems connecting to Web-sites hosted by XO/Concentric Message-ID: Hi, Some of our customers (BKK Fiber is an ISP) are having problems connecting to Web-services (TCP port 80) hosted by XO/Concentric. tcpdump shows that no packets are returned. Ping and connection to the SMTP-service (TCP port 25) on the Webserver hosts are fine. The problem seem to be limited to customers within a certain /17 allocated to us. I have tried Customer Care to no help. Has anybody else experienced the same with XO/Conecentric? Does anybody have contact information to Concentric operations? Kind Regards, Knut A. Syed Senior Network Engineer BKK Fiber AS | Postboks 7050, 5020 Bergen | T: +47 55 12 75 53 | M: +47 916 39 767 | www.bkk.no ___________________________________________________ This message and any attachment is intended for the person(s) named above only. It may contain information that is confidential or legally privileged. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately. Thank You. This footnote confirms that the email and attachment(s) has been swept by our anti-virus solution for the presence of known computer viruses. From jra at baylink.com Mon Jun 11 10:13:22 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Jun 2012 11:13:22 -0400 (EDT) Subject: Whither Cometh BCP38? Message-ID: <6124019.8862.1339427602063.JavaMail.root@benjamin.baylink.com> Off a comment Vix made in another thread this weekend, what is the current status, to the degree to which anyone knows and is permitted to say, of the deployment of RFC 3704, BCP 38, to block IP address spoofing at the ingress edge of large consumer eyeball networks? When the BCP was first release, as I recall it, much noise was made to suggest that it was cost-ineffective and impractical to deploy it because the current state of edge devices was such that it wasn't a simple knob-turn. Is that still true (or not, as I expect), and if common edge concentrators do now support easy filtering to drop packets with improper or invalid source addresses, is this being utilized in the wide area... and if not, why the hell not? Or are spoofed-source-address attacks not, as Vix suggests, significant and trending upwards? Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From rdobbins at arbor.net Mon Jun 11 10:19:01 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 11 Jun 2012 15:19:01 +0000 Subject: Whither Cometh BCP38? In-Reply-To: <6124019.8862.1339427602063.JavaMail.root@benjamin.baylink.com> References: <6124019.8862.1339427602063.JavaMail.root@benjamin.baylink.com> Message-ID: <59F2B088-029A-42DC-8ADF-821D797B60D1@arbor.net> On Jun 11, 2012, at 10:13 PM, Jay Ashworth wrote: > Or are spoofed-source-address attacks not, as Vix suggests, significant and trending upwards? They're enjoying a renaissance because of attackers leveraging spoofing in order to enable DNS, SNMP, and ntp reflection/amplification DDoS attacks. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From swmike at swm.pp.se Mon Jun 11 10:24:36 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 11 Jun 2012 17:24:36 +0200 (CEST) Subject: Whither Cometh BCP38? In-Reply-To: <6124019.8862.1339427602063.JavaMail.root@benjamin.baylink.com> References: <6124019.8862.1339427602063.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, 11 Jun 2012, Jay Ashworth wrote: > Is that still true (or not, as I expect), and if common edge concentrators > do now support easy filtering to drop packets with improper or invalid > source addresses, is this being utilized in the wide area... I'd say most supports it, and if anyone buys one that isn't, they're doing something seriously wrong in their purchasing process. This is for IPv4, for IPv6 we're back 10 years again with very lacking support. -- Mikael Abrahamsson email: swmike at swm.pp.se From rbonica at juniper.net Mon Jun 11 10:26:44 2012 From: rbonica at juniper.net (Ronald Bonica) Date: Mon, 11 Jun 2012 11:26:44 -0400 Subject: Whither Cometh BCP38? In-Reply-To: <6124019.8862.1339427602063.JavaMail.root@benjamin.baylink.com> References: <6124019.8862.1339427602063.JavaMail.root@benjamin.baylink.com> Message-ID: <13205C286662DE4387D9AF3AC30EF456D76CAAFF09@EMBX01-WF.jnpr.net> > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Monday, June 11, 2012 11:13 AM > To: NANOG > Subject: Whither Cometh BCP38? > > Off a comment Vix made in another thread this weekend, what is the > current status, to the degree to which anyone knows and is permitted to > say, of the deployment of RFC 3704, BCP 38, to block IP address > spoofing at the ingress edge of large consumer eyeball networks? > Some statistics are available at http://spoofer.csail.mit.edu/ Ron From christopher.morrow at gmail.com Mon Jun 11 10:36:55 2012 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 11 Jun 2012 11:36:55 -0400 Subject: My view of the arin db boarked? In-Reply-To: <20120609151349.GA93705@gweep.net> References: <20120609151349.GA93705@gweep.net> Message-ID: On Sat, Jun 9, 2012 at 11:13 AM, Joe Provo wrote: > On Fri, Jun 08, 2012 at 04:27:29PM -0400, Christopher Morrow wrote: >> err, last 3 times I asked this I was shown the error of my ways, but >> here goes... >> >> 209.250.228.241 - seems to not have any records in ARIN's WHOIS >> database, everythign seems to roll up to the /8 record :( >> >> I see this routed as a /23: (from routeviews) >> ? BGP routing table entry for 209.250.228.0/23, version 2072545487 >> Paths: (33 available, best #19, table Default-IP-Routing-Table) >> ? Not advertised to any peer >> ? 3277 3267 174 27431 14037 >> ? ? 194.85.102.33 from 194.85.102.33 (194.85.4.4) >> ? ? ? Origin IGP, localpref 100, valid, external >> ? ? ? Community: 3277:3267 3277:65321 3277:65323 3277:65330 >> >> If I look at the ASN in particular: AS14037 >> no records exist for that in ARIN's WHOIS database either ;( If I look >> at all the networks announced by AS14037: >> 14037 ? | 204.8.216.0/21 ? ? ?| >> 14037 ? | 209.250.224.0/19 ? ?| >> 14037 ? | 209.250.228.0/23 ? ?| >> 14037 ? | 209.250.242.0/24 ? ?| >> 14037 ? | 209.250.247.0/24 ? ?| > > If you query filtergen.level3.com, they are expecting to see it from > this ASN: > > Prefix list for policy as14037 = > ?LEVEL3::AS14037 > > 204.8.216.0/21 > 209.250.224.0/20 > >> 14037 ? | 64.18.128.0/19 ? ? ?| >> 14037 ? | 64.18.159.0/24 ? ? ?| > > ...but not those, which are registered in ALTDB (as the /19)along > with the squatted 204.8.216.0/21 and 209.250.224.0/20 > > > route: ? ? ?64.18.128.0/19 > descr: ? ? ?RackVibe LLC > origin: ? ? AS14037 > admin-c: ? ?GC373-ARIN > tech-c: ? ? GC373-ARIN > notify: ? ? arin at 6gtech.com > mnt-by: ? ? MNT-6GTECH > changed: ? ?arin at 6gtech.com 20081007 > source: ? ? ALTDB > > >> none of them have any records in the ARIN WHOIS database :( The >> upstream for this network is ?AS 27431 - JTL Networks >> who seems to get transit/peer with 3356/174. > > Amusingly, AS27431 is still the RR contacts cording to the IRR. Score > another one in the 'inaccurate IRR' column. yea, automated filter generation from IRR's ... not always good :( >> It's nice to see folk who use IRR databases to filter their customers >> still permit this sort of thing to go on though: AS3356 I'm looking at >> you... > > Here's a clue of future prefixes to watch for 3356 allowing from > this particular nest: > > % whois -h filtergen.level3.com -- "-searchpath=ARIN;RIPE;RADB;ALTDB;LEVEL3 as27431" > Prefix list for policy as27431 = > ?ARIN::AS27431 ? LEVEL3::AS27431 ALTDB::AS27431 ?RADB::AS27431 > ?RIPE::AS27431 > > 66.132.44.0/24 > 66.132.45.0/24 > 66.132.47.0/24 > 69.36.0.0/20 > 209.41.200.0/24 > 209.41.202.0/24 > 209.115.40.0/24 > 209.115.41.0/24 > 209.115.42.0/24 > 209.115.43.0/24 > 209.115.108.0/24 > 216.28.47.0/24 > 216.28.134.0/24 > 216.29.53.0/24 > 216.29.115.0/24 > 216.29.116.0/24 > 216.29.117.0/24 > 216.29.121.0/24 > 216.29.122.0/24 > 216.29.152.0/24 > 216.29.194.0/24 > 216.29.247.0/24 > % > most (by random sample of queries to whois.arin.net) of these at least still had entries in the db. >> I think first: "Where are the records for this set of ip number resources?" >> and second: "Why are we still seeing this on the network with no way >> to contact the operators of the resources?" > > You can try and contact the entities that are called 'RackVibe' accordin > and '6G Tech' according to the various IRR registry entries for 14037 and > 46496. ?Sketchy things which geolocate to Seacaucus? Whoda thunk. yea :( I'd sort of prefer if the transit here would just stop accepting the announcement(s) in question (which they do today , several filter-gen runs since friday). -chris > -- > ? ? ? ? RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From ethern at ascc.net Mon Jun 11 10:47:29 2012 From: ethern at ascc.net (Ethern Lin) Date: Mon, 11 Jun 2012 23:47:29 +0800 Subject: Arbor Peakflow competitor? In-Reply-To: References: Message-ID: <4FD61311.9090207@ascc.net> We do use GenieNRM product for ISP(GenieATM 6k),one for collector and one for controller. We use it for traffic analysis like TOP 10 usage, ASN analysis, and interface matrix usage. It can use customize report fit your needs. cheers, Ethern ====================================== Ethern Lin Network Division Computing Center, ACADEMIA SINICA AS Number: 9264 Phone: +886-2-66149953 TANet VoIP: 93909953 Fax: +886-2-66146444 ====================================== ? 2012/6/11 ?? 07:08, bas ??: > Hi All, > > Has anyone worked with GenieATM? > http://www.genienrm.com/index.php/products/9-genieatm/genieatm-6000/21-genieatm-6000-isp-series > > It looks as it has the same functionality as Peakflow. > > I'm curious if anyone has tested or deployed the solution. > And if so, what are your experiences? > > Thanks in advance, > > Bas > > > > -- > ====================================== > Ethern Lin > Network Division > Computing Center, ACADEMIA SINICA > AS Number: 9264 > Phone: +886-2-66149953 > TANet VoIP: 93909953 > Fax: +886-2-66146444 > ====================================== From jra at baylink.com Mon Jun 11 11:09:18 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Jun 2012 12:09:18 -0400 (EDT) Subject: Whither Cometh BCP38? In-Reply-To: <59F2B088-029A-42DC-8ADF-821D797B60D1@arbor.net> Message-ID: <13150808.8880.1339430958423.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Roland Dobbins" > On Jun 11, 2012, at 10:13 PM, Jay Ashworth wrote: > > Or are spoofed-source-address attacks not, as Vix suggests, > > significant and trending upwards? > > They're enjoying a renaissance because of attackers leveraging > spoofing in order to enable DNS, SNMP, and ntp > reflection/amplification DDoS attacks. Ok, so your comment confirms that there's still a problem, and Mikael's, that the tools to stop it from actually being a problem can *reasonably* be expected to be in place in a reasonably large number of places where they're needed. So, are the knobs actually on? (I'm guessing "clearly, not") Why? Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From rdobbins at arbor.net Mon Jun 11 11:32:06 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 11 Jun 2012 16:32:06 +0000 Subject: Whither Cometh BCP38? In-Reply-To: <13150808.8880.1339430958423.JavaMail.root@benjamin.baylink.com> References: <13150808.8880.1339430958423.JavaMail.root@benjamin.baylink.com> Message-ID: <66F5BAD7-A7AD-428B-9FCF-F00A34DC2B62@arbor.net> On Jun 11, 2012, at 11:09 PM, Jay Ashworth wrote: > So, are the knobs actually on? (I'm guessing "clearly, not") In many cases, no, or we wouldn't be seeing many spoofed packets, would we? ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From MatlockK at exempla.org Mon Jun 11 11:35:49 2012 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Mon, 11 Jun 2012 10:35:49 -0600 Subject: Whither Cometh BCP38? In-Reply-To: <66F5BAD7-A7AD-428B-9FCF-F00A34DC2B62@arbor.net> References: <13150808.8880.1339430958423.JavaMail.root@benjamin.baylink.com> <66F5BAD7-A7AD-428B-9FCF-F00A34DC2B62@arbor.net> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C716AD0C01@LMC-MAIL2.exempla.org> There are plenty of 'knobs', but I doubt any read this list.... Ken Matlock Network Engineer 303-467-4671 matlockk at exempla.org -----Original Message----- From: Dobbins, Roland [mailto:rdobbins at arbor.net] Sent: Monday, June 11, 2012 10:32 AM To: NANOG Gripes List Subject: Re: Whither Cometh BCP38? On Jun 11, 2012, at 11:09 PM, Jay Ashworth wrote: > So, are the knobs actually on? (I'm guessing "clearly, not") In many cases, no, or we wouldn't be seeing many spoofed packets, would we? ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton *** SCLHS Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** SCLHS Confidentiality Notice *** From ralph.brandt at pateam.com Mon Jun 11 12:27:58 2012 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Mon, 11 Jun 2012 13:27:58 -0400 Subject: EBAY and AMAZON In-Reply-To: <20120608202022.GA5319@nm.lacutt.com> References: <20120608130834.BFE61BC0@m0005311.ppops.net> <20120608202022.GA5319@nm.lacutt.com> Message-ID: <51C66083768C2949A7EB14910C78B017019A30EE@embgsr24.pateam.com> I have received bogus emails from both of the above on Friday. These look like I bought something that in both cases I did not buy. The EBAY was a golf club for $887 and the Amazon was a novel for $82, far more than I would have spent on either. I think I looked at the novel on Amazon and I remember the golf club came up on a search with something else on Ebay. How this information could get to someone spoofing is a little disconcerting. I have changed EBAY and Paypal Passwords as instructed. Ralph Brandt Communications Engineer HP Enterprise Services Telephone +1 717.506.0802 FAX +1 717.506.4358 Email Ralph.Brandt at pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 From nick at flhsi.com Mon Jun 11 13:05:56 2012 From: nick at flhsi.com (Nick Olsen) Date: Mon, 11 Jun 2012 14:05:56 -0400 Subject: EBAY and AMAZON Message-ID: <2c604629$4f95022a$3c8188fd$@com> I think it might just be coincidence. I've gotten about 10 of them and haven't been to ebay or amazon in months. Most of them have been for >60 dollar books. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Brandt, Ralph" Sent: Monday, June 11, 2012 1:28 PM To: nanog at nanog.org Subject: EBAY and AMAZON I have received bogus emails from both of the above on Friday. These look like I bought something that in both cases I did not buy. The EBAY was a golf club for $887 and the Amazon was a novel for $82, far more than I would have spent on either. I think I looked at the novel on Amazon and I remember the golf club came up on a search with something else on Ebay. How this information could get to someone spoofing is a little disconcerting. I have changed EBAY and Paypal Passwords as instructed. Ralph Brandt Communications Engineer HP Enterprise Services Telephone +1 717.506.0802 FAX +1 717.506.4358 Email Ralph.Brandt at pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 From scott.brim at gmail.com Mon Jun 11 13:07:33 2012 From: scott.brim at gmail.com (Scott Brim) Date: Mon, 11 Jun 2012 14:07:33 -0400 Subject: EBAY and AMAZON In-Reply-To: <2c604629$4f95022a$3c8188fd$@com> References: <2c604629$4f95022a$3c8188fd$@com> Message-ID: I think it's a troll, trying to shock you into clicking on something. On Mon, Jun 11, 2012 at 2:05 PM, Nick Olsen wrote: > I think it might just be coincidence. I've gotten about 10 of them and > haven't been to ebay or amazon in months. > Most of them have been for >60 dollar books. > > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Brandt, Ralph" > Sent: Monday, June 11, 2012 1:28 PM > To: nanog at nanog.org > Subject: EBAY and AMAZON > > I have received bogus emails from both of the above on Friday. > > These look like I bought something that in both cases I did not buy. > The EBAY was a golf club for $887 and the Amazon was a novel for $82, > far more than I would have spent on either. > > I think I looked at the novel on Amazon and I remember the golf club > came up on a search with something else on Ebay. > > How this information could get to someone spoofing is a little > disconcerting. > > I have changed EBAY and Paypal Passwords as instructed. > > Ralph Brandt > Communications Engineer > HP Enterprise Services > Telephone +1 717.506.0802 > FAX +1 717.506.4358 > Email Ralph.Brandt at pateam.com > 5095 Ritter Rd > Mechanicsburg PA 17055 > > > From james.cutler at consultant.com Mon Jun 11 13:22:37 2012 From: james.cutler at consultant.com (Cutler James R) Date: Mon, 11 Jun 2012 14:22:37 -0400 Subject: EBAY and AMAZON In-Reply-To: References: <2c604629$4f95022a$3c8188fd$@com> Message-ID: Examination of the raw messages confirms phishing messages. Visible URLS do not match effective URLs. On Jun 11, 2012, at 2:07 PM, Scott Brim wrote: > I think it's a troll, trying to shock you into clicking on something. James R. Cutler james.cutler at consultant.com -top posted by OS X Mail From johnl at iecc.com Mon Jun 11 13:35:46 2012 From: johnl at iecc.com (John Levine) Date: 11 Jun 2012 18:35:46 -0000 Subject: Dear Linkedin, In-Reply-To: <40B347D9-4121-4CDE-AEE4-5F95EDFBAC48@delong.com> Message-ID: <20120611183546.50220.qmail@joyce.lan> >From someone who supplies an out-of-country drivers license, I'd request to >see their passport. From someone who supplies an out-of-state drivers >license, I'd probably accept it, but the risks there are somewhat reduced at >least. OK, someone shows you a Quebec driver's license. You ask for a passport, she says, I don't have one, and points at the blue word Plus after the words Permis de Conduire at the top of the license. Now what? Although banks have different tradeoffs in risk management than you might like, they're not dumb. I expect they figured that the increased volume from not slowing down transactions and demanding more than makes up for whatever the increased fraud. This theory is reinforced by my observation that at my local supermarket, they don't even ask for the signature that they don't look at for purchases under $50. R's, John From sparctacus at gmail.com Mon Jun 11 13:37:46 2012 From: sparctacus at gmail.com (Bryan Irvine) Date: Mon, 11 Jun 2012 11:37:46 -0700 Subject: EBAY and AMAZON In-Reply-To: References: <2c604629$4f95022a$3c8188fd$@com> Message-ID: Yup. They hope that the message contents are a coincidence and scare you into seeing (i.e. clicking on..) what's it's about. This happened to me a few years ago where I changed my ebay password, and about 30 minutes later got a phishing email that my password change failed. So I clicked the link and re-did it. As soon as I clicked on the submit button I noticed that the URl I was forwarded to was to some server in Russia. /facepalm. I went and sheepishly changed my ebay password AGAIN that very moment, with a bit of awe towards the clever con I had fallen into. Luckily I noticed. But how many others didn't? -B On Mon, Jun 11, 2012 at 11:07 AM, Scott Brim wrote: > I think it's a troll, trying to shock you into clicking on something. > > On Mon, Jun 11, 2012 at 2:05 PM, Nick Olsen wrote: > >> I think it might just be coincidence. I've gotten about 10 of them and >> haven't been to ebay or amazon in months. >> Most of them have been for >60 dollar books. >> >> Nick Olsen >> Network Operations (855) FLSPEED ?x106 >> >> ---------------------------------------- >> ?From: "Brandt, Ralph" >> Sent: Monday, June 11, 2012 1:28 PM >> To: nanog at nanog.org >> Subject: EBAY and AMAZON >> >> I have received bogus emails from both of the above on Friday. >> >> These look like I bought something that in both cases I did not buy. >> The EBAY was a golf club for $887 and the Amazon was a novel for $82, >> far more than I would have spent on either. >> >> I think I looked at the novel on Amazon and I remember the golf club >> came up on a search with something else on Ebay. >> >> How this information could get to someone spoofing is a little >> disconcerting. >> >> I have changed EBAY and Paypal Passwords as instructed. >> >> Ralph Brandt >> Communications Engineer >> HP Enterprise Services >> Telephone +1 717.506.0802 >> FAX +1 717.506.4358 >> Email Ralph.Brandt at pateam.com >> 5095 Ritter Rd >> Mechanicsburg PA 17055 >> >> >> From bkain1 at ford.com Mon Jun 11 13:39:44 2012 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Mon, 11 Jun 2012 18:39:44 +0000 Subject: EBAY and AMAZON In-Reply-To: <2c604629$4f95022a$3c8188fd$@com> References: <2c604629$4f95022a$3c8188fd$@com> Message-ID: <7DB845D64966DC44A1CC592780539B4BA57914@nafmbx47.exchange.ford.com> I have gotten them from "amazon" stating "order number X was cancelled and please click on the below file for more information". Because I order so much on amazon, I almost thought it was real and clicked on it but then went to the amazon site and looked at "my open orders". It always pays to goto the site, not believe email. -----Original Message----- From: Nick Olsen [mailto:nick at flhsi.com] Sent: Monday, June 11, 2012 2:06 PM To: Brandt, Ralph; nanog at nanog.org Subject: re: EBAY and AMAZON I think it might just be coincidence. I've gotten about 10 of them and haven't been to ebay or amazon in months. Most of them have been for >60 dollar books. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Brandt, Ralph" Sent: Monday, June 11, 2012 1:28 PM To: nanog at nanog.org Subject: EBAY and AMAZON I have received bogus emails from both of the above on Friday. These look like I bought something that in both cases I did not buy. The EBAY was a golf club for $887 and the Amazon was a novel for $82, far more than I would have spent on either. I think I looked at the novel on Amazon and I remember the golf club came up on a search with something else on Ebay. How this information could get to someone spoofing is a little disconcerting. I have changed EBAY and Paypal Passwords as instructed. Ralph Brandt Communications Engineer HP Enterprise Services Telephone +1 717.506.0802 FAX +1 717.506.4358 Email Ralph.Brandt at pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 From jared at puck.nether.net Mon Jun 11 13:48:21 2012 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 11 Jun 2012 14:48:21 -0400 Subject: Dear Linkedin, In-Reply-To: <20120611183546.50220.qmail@joyce.lan> References: <20120611183546.50220.qmail@joyce.lan> Message-ID: On Jun 11, 2012, at 2:35 PM, John Levine wrote: > OK, someone shows you a Quebec driver's license. You ask for a > passport, she says, I don't have one, and points at the blue word Plus > after the words Permis de Conduire at the top of the license. Now > what? Banks and most retailers actually have a book with photos and details of various security aspects of the license and ID cards in-use. For fun, I have presented my "Global Entry" ID card at the bank for a transaction to see if they had seen it before. The US Federal Government tried to standardize on HSPD-12, now about 5 years old. Making a secure document, or something that uses PKI such as this is harder than it may initially seem. This is why I'm not the one designing them. - Jared From jra at baylink.com Mon Jun 11 13:53:05 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Jun 2012 14:53:05 -0400 (EDT) Subject: Dear Linkedin, In-Reply-To: <20120611183546.50220.qmail@joyce.lan> Message-ID: <4435650.8944.1339440785346.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Levine" > Although banks have different tradeoffs in risk management than you > might like, they're not dumb. I expect they figured that the increased > volume from not slowing down transactions and demanding more than makes > up for whatever the increased fraud. This theory is reinforced by my > observation that at my local supermarket, they don't even ask for the > signature that they don't look at for purchases under $50. Another point here is that *just asking for ID, and observing the patron's mien when they give it to you* filters out 2 whole categories of low-hanging fruit attackers. Cheers, -- jr 'each user discovers a new category of bugs' a -- Jay R. Ashworth Baylink jra at 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 From owen at delong.com Mon Jun 11 14:05:26 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Jun 2012 12:05:26 -0700 Subject: Dear Linkedin, In-Reply-To: <20120611183546.50220.qmail@joyce.lan> References: <20120611183546.50220.qmail@joyce.lan> Message-ID: <0BAACA0E-E07E-43D3-A150-7B2C5CE05489@delong.com> Sent from my iPad On Jun 11, 2012, at 11:35 AM, "John Levine" wrote: >> From someone who supplies an out-of-country drivers license, I'd request to >> see their passport. From someone who supplies an out-of-state drivers >> license, I'd probably accept it, but the risks there are somewhat reduced at >> least. > > OK, someone shows you a Quebec driver's license. You ask for a > passport, she says, I don't have one, and points at the blue word Plus > after the words Permis de Conduire at the top of the license. Now > what? To the best of my knowledge, ICE stopped accepting DL for admission from Canada several years ago. So, I'd probably pass on the transaction unless she wanted to select another form of payment. > Although banks have different tradeoffs in risk management than you > might like, they're not dumb. I expect they figured that the increased > volume from not slowing down transactions and demanding more than makes > up for whatever the increased fraud. This theory is reinforced by my > observation that at my local supermarket, they don't even ask for the > signature that they don't look at for purchases under $50. Indeed, as I have said, for small purchases where the transaction rate can be high, swipe and go makes sense to me. I'm talking about larger purchases that involve a lengthier sales process anyway. Owen From simon.perreault at viagenie.ca Mon Jun 11 14:14:31 2012 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Mon, 11 Jun 2012 15:14:31 -0400 Subject: Dear Linkedin, In-Reply-To: <0BAACA0E-E07E-43D3-A150-7B2C5CE05489@delong.com> References: <20120611183546.50220.qmail@joyce.lan> <0BAACA0E-E07E-43D3-A150-7B2C5CE05489@delong.com> Message-ID: <4FD64397.1000804@viagenie.ca> On 2012-06-11 15:05, Owen DeLong wrote: >> OK, someone shows you a Quebec driver's license. You ask for a >> passport, she says, I don't have one, and points at the blue word Plus >> after the words Permis de Conduire at the top of the license. Now >> what? > > To the best of my knowledge, ICE stopped accepting DL for admission from Canada several years ago. Your knowledge needs an update! ;) http://www.saaq.gouv.qc.ca/en/driver_licence/licence_plus/licence_plus.php Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From rburtch3 at gmail.com Mon Jun 11 14:30:06 2012 From: rburtch3 at gmail.com (Ryan Burtch) Date: Mon, 11 Jun 2012 15:30:06 -0400 Subject: CBT Nuggets streaming account Message-ID: Could someone contact me off list if you have a CBT Nuggets streaming account and would be willing to help me in working towards my CCNP? From alter3d at alter3d.ca Mon Jun 11 14:35:22 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Mon, 11 Jun 2012 15:35:22 -0400 Subject: Dear Linkedin, In-Reply-To: <4FD64397.1000804@viagenie.ca> References: <20120611183546.50220.qmail@joyce.lan> <0BAACA0E-E07E-43D3-A150-7B2C5CE05489@delong.com> <4FD64397.1000804@viagenie.ca> Message-ID: <4FD6487A.8010500@alter3d.ca> On 12-06-11 03:14 PM, Simon Perreault wrote: > On 2012-06-11 15:05, Owen DeLong wrote: >>> OK, someone shows you a Quebec driver's license. You ask for a >>> passport, she says, I don't have one, and points at the blue word Plus >>> after the words Permis de Conduire at the top of the license. Now >>> what? >> >> To the best of my knowledge, ICE stopped accepting DL for admission >> from Canada several years ago. > > Your knowledge needs an update! ;) > > http://www.saaq.gouv.qc.ca/en/driver_licence/licence_plus/licence_plus.php > > > Simon Yup, various Canadian provinces now issue "newer, better" driver's licenses that are accepted by ICE for entry to the US by land or sea only (not by air, you still need a passport or NEXUS for that). Here in Ontario, they're called "Enhanced" driver's licenses, and only have minor differences from regular driver's licenses -- they have the word "Enhanced" on them, and they contain an RFID chip which is scanned at the border for ID & verification purposes. Oh, and they cost an extra $40 when you renew them. The enhanced licenses were rolled out at pretty much the same time as the US entry requirements changed, so if you were a keener and got an enhanced card when they were first available, absolutely nothing would have changed for you, except that your wallet is now a bit lighter and you have a shiny new card. It's left as an exercise to the reader as to whether the word "Enhanced" printed on a card and an RFID tag are, in fact, any more secure than what we had before.... - Pete From stephen at sprunk.org Mon Jun 11 14:37:01 2012 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 11 Jun 2012 14:37:01 -0500 Subject: Dear Linkedin, In-Reply-To: <0BAACA0E-E07E-43D3-A150-7B2C5CE05489@delong.com> References: <20120611183546.50220.qmail@joyce.lan> <0BAACA0E-E07E-43D3-A150-7B2C5CE05489@delong.com> Message-ID: <4FD648DD.3040708@sprunk.org> On 11-Jun-12 14:05, Owen DeLong wrote: > On Jun 11, 2012, at 11:35 AM, "John Levine" wrote: >> OK, someone shows you a Quebec driver's license. You ask for a passport, she says, I don't have one, and points at the blue word Plus after the words Permis de Conduire at the top of the license. Now what? > To the best of my knowledge, ICE stopped accepting DL for admission from Canada several years ago. Only non-enhanced ("plus" in Quebec) drivers licenses. See: http://www.dhs.gov/files/crossingborders/travelers.shtm S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2312 bytes Desc: S/MIME Cryptographic Signature URL: From gabe at teksavvy.ca Mon Jun 11 14:38:08 2012 From: gabe at teksavvy.ca (Gabriel Blanchard) Date: Mon, 11 Jun 2012 15:38:08 -0400 Subject: Dear Linkedin, In-Reply-To: <4FD64397.1000804@viagenie.ca> References: <20120611183546.50220.qmail@joyce.lan> <0BAACA0E-E07E-43D3-A150-7B2C5CE05489@delong.com> <4FD64397.1000804@viagenie.ca> Message-ID: <3E14FABE-64B7-48F1-9AC8-A3961124D82F@teksavvy.ca> On Jun 11, 2012, at 3:14 PM, Simon Perreault wrote: > On 2012-06-11 15:05, Owen DeLong wrote: >>> OK, someone shows you a Quebec driver's license. You ask for a >>> passport, she says, I don't have one, and points at the blue word Plus >>> after the words Permis de Conduire at the top of the license. Now >>> what? >> >> To the best of my knowledge, ICE stopped accepting DL for admission from Canada several years ago. > > Your knowledge needs an update! ;) > > http://www.saaq.gouv.qc.ca/en/driver_licence/licence_plus/licence_plus.php > How the heck did this conversation go from Linkedin to a Quebec drivers license? I'm not sure how relevant this is to NANOG. Both subject matters that is. -Gabe From surfer at mauigateway.com Mon Jun 11 14:41:50 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 11 Jun 2012 12:41:50 -0700 Subject: Dear Linkedin, Message-ID: <20120611124150.BFD7FC39@resin04.mta.everyone.net> --- gabe at teksavvy.ca wrote: From: Gabriel Blanchard How the heck did this conversation go from Linkedin to a Quebec drivers license? I'm not sure how relevant this is to NANOG. Both subject matters that is. ------------------------------ New to nanog, eh? ;-) scott From goemon at anime.net Mon Jun 11 14:39:13 2012 From: goemon at anime.net (goemon at anime.net) Date: Mon, 11 Jun 2012 12:39:13 -0700 (PDT) Subject: EBAY and AMAZON In-Reply-To: References: <2c604629$4f95022a$3c8188fd$@com> Message-ID: Sometimes I wonder how many nanog'ers would fall for a phishing email sent to this DL. I suspect the number is more than 0. -Dan On Mon, 11 Jun 2012, Bryan Irvine wrote: > Yup. They hope that the message contents are a coincidence and scare > you into seeing (i.e. clicking on..) what's it's about. > > This happened to me a few years ago where I changed my ebay password, > and about 30 minutes later got a phishing email that my password > change failed. So I clicked the link and re-did it. As soon as I > clicked on the submit button I noticed that the URl I was forwarded to > was to some server in Russia. /facepalm. > > I went and sheepishly changed my ebay password AGAIN that very moment, > with a bit of awe towards the clever con I had fallen into. Luckily I > noticed. But how many others didn't? > > -B > > On Mon, Jun 11, 2012 at 11:07 AM, Scott Brim wrote: >> I think it's a troll, trying to shock you into clicking on something. >> >> On Mon, Jun 11, 2012 at 2:05 PM, Nick Olsen wrote: >> >>> I think it might just be coincidence. I've gotten about 10 of them and >>> haven't been to ebay or amazon in months. >>> Most of them have been for >60 dollar books. >>> >>> Nick Olsen >>> Network Operations (855) FLSPEED ?x106 >>> >>> ---------------------------------------- >>> ?From: "Brandt, Ralph" >>> Sent: Monday, June 11, 2012 1:28 PM >>> To: nanog at nanog.org >>> Subject: EBAY and AMAZON >>> >>> I have received bogus emails from both of the above on Friday. >>> >>> These look like I bought something that in both cases I did not buy. >>> The EBAY was a golf club for $887 and the Amazon was a novel for $82, >>> far more than I would have spent on either. >>> >>> I think I looked at the novel on Amazon and I remember the golf club >>> came up on a search with something else on Ebay. >>> >>> How this information could get to someone spoofing is a little >>> disconcerting. >>> >>> I have changed EBAY and Paypal Passwords as instructed. >>> >>> Ralph Brandt >>> Communications Engineer >>> HP Enterprise Services >>> Telephone +1 717.506.0802 >>> FAX +1 717.506.4358 >>> Email Ralph.Brandt at pateam.com >>> 5095 Ritter Rd >>> Mechanicsburg PA 17055 >>> >>> >>> > > From aluisios at algartelecom.com.br Mon Jun 11 15:13:00 2012 From: aluisios at algartelecom.com.br (Aluisio da Silva) Date: Mon, 11 Jun 2012 17:13:00 -0300 Subject: Arbor Peakflow competitor? In-Reply-To: <4FD61311.9090207@ascc.net> References: <4FD61311.9090207@ascc.net>, Message-ID: From blake at pfankuch.me Mon Jun 11 15:51:19 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Mon, 11 Jun 2012 20:51:19 +0000 Subject: EBAY and AMAZON In-Reply-To: <7DB845D64966DC44A1CC592780539B4BA57914@nafmbx47.exchange.ford.com> References: <2c604629$4f95022a$3c8188fd$@com> <7DB845D64966DC44A1CC592780539B4BA57914@nafmbx47.exchange.ford.com> Message-ID: I have a spam pit email address which I monitor for trends to have a little bit of jump on the possible things users might touch at work. I started seeing the amazon, ebay and paypal ones a few weeks back. The other one I have started to see a lot of is the "Free or cheaper home phone service through magic jack" ones. Again as expected they link to some .ru domain and look just like the normal sign up page. Also my handy dandy virtual machine was instantly owned with malware just by loading the page. The VM runs Windows 7 as a non administrative user, UAC cranked up and IE9. Something like 10 installed apps showed up including "Adobe Flash Player Latest." The other cool one I have been seeing is along the lines of "How to better utilize your office phone system" or "New Business Phone systems" with supposed links to "popular new phone system trends". This one is rather crafty as it has an embedded image which is a nice weblink to an infected jpg. So you click show picture in outlook, or in your browser and you get another installed piece of nastyware. -----Original Message----- From: Kain, Rebecca (.) [mailto:bkain1 at ford.com] Sent: Monday, June 11, 2012 12:40 PM To: nick at flhsi.com; Brandt, Ralph; nanog at nanog.org Subject: RE: EBAY and AMAZON I have gotten them from "amazon" stating "order number X was cancelled and please click on the below file for more information". Because I order so much on amazon, I almost thought it was real and clicked on it but then went to the amazon site and looked at "my open orders". It always pays to goto the site, not believe email. -----Original Message----- From: Nick Olsen [mailto:nick at flhsi.com] Sent: Monday, June 11, 2012 2:06 PM To: Brandt, Ralph; nanog at nanog.org Subject: re: EBAY and AMAZON I think it might just be coincidence. I've gotten about 10 of them and haven't been to ebay or amazon in months. Most of them have been for >60 dollar books. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Brandt, Ralph" Sent: Monday, June 11, 2012 1:28 PM To: nanog at nanog.org Subject: EBAY and AMAZON I have received bogus emails from both of the above on Friday. These look like I bought something that in both cases I did not buy. The EBAY was a golf club for $887 and the Amazon was a novel for $82, far more than I would have spent on either. I think I looked at the novel on Amazon and I remember the golf club came up on a search with something else on Ebay. How this information could get to someone spoofing is a little disconcerting. I have changed EBAY and Paypal Passwords as instructed. Ralph Brandt Communications Engineer HP Enterprise Services Telephone +1 717.506.0802 FAX +1 717.506.4358 Email Ralph.Brandt at pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 From garrett at skjelstad.org Mon Jun 11 15:56:18 2012 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Mon, 11 Jun 2012 13:56:18 -0700 Subject: CBT Nuggets streaming account In-Reply-To: References: Message-ID: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> Don't spam the list looking for black market copies of training material. Use GNS3 and design your own labs and google the test topics. Plzkthx. Sent from my iPhone On Jun 11, 2012, at 12:30, Ryan Burtch wrote: > Could someone contact me off list if you have a CBT Nuggets streaming > account and would be willing to help me in working towards my CCNP? From quantumfoam at gmail.com Mon Jun 11 16:05:59 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Mon, 11 Jun 2012 17:05:59 -0400 Subject: CBT Nuggets streaming account In-Reply-To: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> References: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> Message-ID: GNS3 is completely insufficient for CCNP-level training and labs. You will need actual equipment. Fortunately, it has gotten a lot cheaper over the past few years and you don't need the latest and greatest. Check out Wendell Odom's website for tips. Also we have a CBTNuggets account at my company and I was unimpressed with their Cisco coverage, but that may be a matter of taste. Just my $0.02...as a CCNA working towards MY CCNP. --jono On Mon, Jun 11, 2012 at 4:56 PM, Garrett Skjelstad wrote: > Don't spam the list looking for black market copies of training material. > Use GNS3 and design your own labs and google the test topics. Plzkthx. > > Sent from my iPhone > > On Jun 11, 2012, at 12:30, Ryan Burtch wrote: > > > Could someone contact me off list if you have a CBT Nuggets streaming > > account and would be willing to help me in working towards my CCNP? > > From henry at AegisInfoSys.com Mon Jun 11 16:11:39 2012 From: henry at AegisInfoSys.com (Henry Yen) Date: Mon, 11 Jun 2012 17:11:39 -0400 Subject: EBAY and AMAZON In-Reply-To: <51C66083768C2949A7EB14910C78B017019A30EE@embgsr24.pateam.com> References: <20120608130834.BFE61BC0@m0005311.ppops.net> <20120608202022.GA5319@nm.lacutt.com> <51C66083768C2949A7EB14910C78B017019A30EE@embgsr24.pateam.com> Message-ID: <20120611211139.GD24272@nntp.AegisInfoSys.com> On Mon, Jun 11, 2012 at 13:27:58PM -0400, Brandt, Ralph wrote: > I have received bogus emails from both of the above on Friday. > > These look like I bought something that in both cases I did not buy. > The EBAY was a golf club for $887 and the Amazon was a novel for $82, > far more than I would have spent on either. Did the SMTP headers show the emails as coming from them? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From Curtis.Starnes at granburyisd.org Mon Jun 11 16:15:55 2012 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Mon, 11 Jun 2012 16:15:55 -0500 Subject: CBT Nuggets streaming account In-Reply-To: References: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> Message-ID: There is a reason Cisco certs are not considered "Paper Mill Certs" and that you have to recertify every few years to keep up with new equipment and technologies. That is what our community DOESN'T need, Cisco certs that are looked upon like lot of the other manufacturer certification courses. Do the CBTNuggets route and try a hands on exam and see how far it will get you. Curtis -----Original Message----- From: Jonathan Rogers [mailto:quantumfoam at gmail.com] Sent: Monday, June 11, 2012 4:06 PM To: Garrett Skjelstad Cc: nanog at nanog.org Subject: Re: CBT Nuggets streaming account GNS3 is completely insufficient for CCNP-level training and labs. You will need actual equipment. Fortunately, it has gotten a lot cheaper over the past few years and you don't need the latest and greatest. Check out Wendell Odom's website for tips. Also we have a CBTNuggets account at my company and I was unimpressed with their Cisco coverage, but that may be a matter of taste. Just my $0.02...as a CCNA working towards MY CCNP. --jono On Mon, Jun 11, 2012 at 4:56 PM, Garrett Skjelstad wrote: > Don't spam the list looking for black market copies of training material. > Use GNS3 and design your own labs and google the test topics. Plzkthx. > > Sent from my iPhone > > On Jun 11, 2012, at 12:30, Ryan Burtch wrote: > > > Could someone contact me off list if you have a CBT Nuggets > > streaming account and would be willing to help me in working towards my CCNP? > > From nicotine at warningg.com Mon Jun 11 16:38:49 2012 From: nicotine at warningg.com (Brandon Ewing) Date: Mon, 11 Jun 2012 16:38:49 -0500 Subject: CBT Nuggets streaming account In-Reply-To: References: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> Message-ID: <20120611213849.GQ4438@radiological.warningg.com> On Mon, Jun 11, 2012 at 05:05:59PM -0400, Jonathan Rogers wrote: > GNS3 is completely insufficient for CCNP-level training and labs. You will > need actual equipment. Fortunately, it has gotten a lot cheaper over the > past few years and you don't need the latest and greatest. Check out > Wendell Odom's website for tips. What topics are missing on GNS3 for CCNP? Is there that much switching covered in the exam? I was able to use dynamips/dynagen to study for CCIP (yay EOL'd certs) without issue last year. -- Brandon Ewing (nicotine at warningg.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From garrett at skjelstad.org Mon Jun 11 16:46:39 2012 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Mon, 11 Jun 2012 14:46:39 -0700 Subject: CBT Nuggets streaming account In-Reply-To: <20120611213849.GQ4438@radiological.warningg.com> References: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> <20120611213849.GQ4438@radiological.warningg.com> Message-ID: Many CCIE training providers also offer alternative workbooks for CCIE Routing and Switching based solely on GNS3. If the argument is there is no 15.x, then I would argue that the *current* exams offer minimal differences between releases at this time. (IOS-wise) I can understand the switch aspect though... Sent from my iPhone On Jun 11, 2012, at 14:38, Brandon Ewing wrote: > On Mon, Jun 11, 2012 at 05:05:59PM -0400, Jonathan Rogers wrote: >> GNS3 is completely insufficient for CCNP-level training and labs. You will >> need actual equipment. Fortunately, it has gotten a lot cheaper over the >> past few years and you don't need the latest and greatest. Check out >> Wendell Odom's website for tips. > > What topics are missing on GNS3 for CCNP? Is there that much switching > covered in the exam? I was able to use dynamips/dynagen to study for CCIP > (yay EOL'd certs) without issue last year. > > -- > Brandon Ewing (nicotine at warningg.com) From quantumfoam at gmail.com Mon Jun 11 17:01:48 2012 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Mon, 11 Jun 2012 18:01:48 -0400 Subject: CBT Nuggets streaming account In-Reply-To: References: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> <20120611213849.GQ4438@radiological.warningg.com> Message-ID: I would say part of the argument is old-fashioned (if you ain't touching it, you're not really learning), but there are other issues as well...such as where you get a legitimate copy of IOS to load into GNS3. Ultimately my personal feeling is that it is not an accurate representation of the real world. Cisco's official academy sim is much easier to use if you need a sim. Unfortunately, it is not easily acquired. --jono On Mon, Jun 11, 2012 at 5:46 PM, Garrett Skjelstad wrote: > Many CCIE training providers also offer alternative workbooks for CCIE > Routing and Switching based solely on GNS3. > > If the argument is there is no 15.x, then I would argue that the *current* > exams offer minimal differences between releases at this time. (IOS-wise) > > I can understand the switch aspect though... > > Sent from my iPhone > > On Jun 11, 2012, at 14:38, Brandon Ewing wrote: > > > On Mon, Jun 11, 2012 at 05:05:59PM -0400, Jonathan Rogers wrote: > >> GNS3 is completely insufficient for CCNP-level training and labs. You > will > >> need actual equipment. Fortunately, it has gotten a lot cheaper over the > >> past few years and you don't need the latest and greatest. Check out > >> Wendell Odom's website for tips. > > > > What topics are missing on GNS3 for CCNP? Is there that much switching > > covered in the exam? I was able to use dynamips/dynagen to study for > CCIP > > (yay EOL'd certs) without issue last year. > > > > -- > > Brandon Ewing ( > nicotine at warningg.com) > > From jrhett at netconsonance.com Mon Jun 11 17:28:04 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 11 Jun 2012 15:28:04 -0700 Subject: EBAY and AMAZON In-Reply-To: <51C66083768C2949A7EB14910C78B017019A30EE@embgsr24.pateam.com> References: <20120608130834.BFE61BC0@m0005311.ppops.net> <20120608202022.GA5319@nm.lacutt.com> <51C66083768C2949A7EB14910C78B017019A30EE@embgsr24.pateam.com> Message-ID: <54316672-FDCC-44BC-AD89-2B5B7A4BAB50@netconsonance.com> I'm still trying to figure out how to put golf clubs or even spam into my router configuration. Perhaps you intended this for a different list? On Jun 11, 2012, at 10:27 AM, Brandt, Ralph wrote: > I have received bogus emails from both of the above on Friday. > > These look like I bought something that in both cases I did not buy. > The EBAY was a golf club for $887 and the Amazon was a novel for $82, > far more than I would have spent on either. > > I think I looked at the novel on Amazon and I remember the golf club > came up on a search with something else on Ebay. > > How this information could get to someone spoofing is a little > disconcerting. > > I have changed EBAY and Paypal Passwords as instructed. > > > Ralph Brandt > Communications Engineer > HP Enterprise Services > Telephone +1 717.506.0802 > FAX +1 717.506.4358 > Email Ralph.Brandt at pateam.com > 5095 Ritter Rd > Mechanicsburg PA 17055 > > -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From paul4004 at gmail.com Mon Jun 11 17:34:36 2012 From: paul4004 at gmail.com (PC) Date: Mon, 11 Jun 2012 16:34:36 -0600 Subject: CBT Nuggets streaming account In-Reply-To: References: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> <20120611213849.GQ4438@radiological.warningg.com> Message-ID: You can rent CCIE-topology racks for $1.50/hr. Even though that's overkill for CCNP, you probably don't need that many hours. It sure beats dealing with buying then selling the stuff on ebay. On Mon, Jun 11, 2012 at 4:01 PM, Jonathan Rogers wrote: > I would say part of the argument is old-fashioned (if you ain't touching > it, you're not really learning), but there are other issues as well...such > as where you get a legitimate copy of IOS to load into GNS3. > > Ultimately my personal feeling is that it is not an accurate representation > of the real world. Cisco's official academy sim is much easier to use if > you need a sim. Unfortunately, it is not easily acquired. > > --jono > > On Mon, Jun 11, 2012 at 5:46 PM, Garrett Skjelstad >wrote: > > > Many CCIE training providers also offer alternative workbooks for CCIE > > Routing and Switching based solely on GNS3. > > > > If the argument is there is no 15.x, then I would argue that the > *current* > > exams offer minimal differences between releases at this time. (IOS-wise) > > > > I can understand the switch aspect though... > > > > Sent from my iPhone > > > > On Jun 11, 2012, at 14:38, Brandon Ewing wrote: > > > > > On Mon, Jun 11, 2012 at 05:05:59PM -0400, Jonathan Rogers wrote: > > >> GNS3 is completely insufficient for CCNP-level training and labs. You > > will > > >> need actual equipment. Fortunately, it has gotten a lot cheaper over > the > > >> past few years and you don't need the latest and greatest. Check out > > >> Wendell Odom's website for tips. > > > > > > What topics are missing on GNS3 for CCNP? Is there that much switching > > > covered in the exam? I was able to use dynamips/dynagen to study for > > CCIP > > > (yay EOL'd certs) without issue last year. > > > > > > -- > > > Brandon Ewing ( > > nicotine at warningg.com) > > > > > From tom at ninjabadger.net Mon Jun 11 17:41:40 2012 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 11 Jun 2012 23:41:40 +0100 Subject: CBT Nuggets streaming account In-Reply-To: References: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> Message-ID: <4FD67424.3030503@ninjabadger.net> On 11/06/12 22:15, STARNES, CURTIS wrote: > There is a reason Cisco certs are not considered "Paper Mill Certs" > and that you have to recertify every few years to keep up with new > equipment and technologies. That is what our community DOESN'T need, > Cisco certs that are looked upon like lot of the other manufacturer > certification courses. Too late, sorry. Every man and his dog has downloaded PASS4SURE and memorised the answers to pass the exams. You can do this once every three years, no problem. Sure, those candidates will be absolutely useless, but that doesn't stop the dilution of CCNA/CCNP certs in the market. What will it do? It'll make the CCIE more important. What have Cisco done about it? Oh, they released a more prestigious, more expensive cert, didn't they? :) Tom From jesler at sourcefire.com Mon Jun 11 17:43:34 2012 From: jesler at sourcefire.com (Joel Esler) Date: Mon, 11 Jun 2012 18:43:34 -0400 Subject: EBAY and AMAZON In-Reply-To: References: <2c604629$4f95022a$3c8188fd$@com> <7DB845D64966DC44A1CC592780539B4BA57914@nafmbx47.exchange.ford.com> Message-ID: These are exploit kit teasers. Black hole exploit kit specifically. I wouldn't click on any of the links in there. Anyone who would like to send me copies of these, I'll take. -- Joel Esler On Jun 11, 2012, at 4:51 PM, Blake Pfankuch wrote: > I have a spam pit email address which I monitor for trends to have a little bit of jump on the possible things users might touch at work. I started seeing the amazon, ebay and paypal ones a few weeks back. The other one I have started to see a lot of is the "Free or cheaper home phone service through magic jack" ones. Again as expected they link to some .ru domain and look just like the normal sign up page. Also my handy dandy virtual machine was instantly owned with malware just by loading the page. The VM runs Windows 7 as a non administrative user, UAC cranked up and IE9. Something like 10 installed apps showed up including "Adobe Flash Player Latest." > > The other cool one I have been seeing is along the lines of "How to better utilize your office phone system" or "New Business Phone systems" with supposed links to "popular new phone system trends". This one is rather crafty as it has an embedded image which is a nice weblink to an infected jpg. So you click show picture in outlook, or in your browser and you get another installed piece of nastyware. > > -----Original Message----- > From: Kain, Rebecca (.) [mailto:bkain1 at ford.com] > Sent: Monday, June 11, 2012 12:40 PM > To: nick at flhsi.com; Brandt, Ralph; nanog at nanog.org > Subject: RE: EBAY and AMAZON > > I have gotten them from "amazon" stating "order number X was cancelled and please click on the below file for more information". Because I order so much on amazon, I almost thought it was real and clicked on it but then went to the amazon site and looked at "my open orders". It always pays to goto the site, not believe email. > > > -----Original Message----- > From: Nick Olsen [mailto:nick at flhsi.com] > Sent: Monday, June 11, 2012 2:06 PM > To: Brandt, Ralph; nanog at nanog.org > Subject: re: EBAY and AMAZON > > I think it might just be coincidence. I've gotten about 10 of them and haven't been to ebay or amazon in months. > Most of them have been for >60 dollar books. > > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Brandt, Ralph" > Sent: Monday, June 11, 2012 1:28 PM > To: nanog at nanog.org > Subject: EBAY and AMAZON > > I have received bogus emails from both of the above on Friday. > > These look like I bought something that in both cases I did not buy. > The EBAY was a golf club for $887 and the Amazon was a novel for $82, far more than I would have spent on either. > > I think I looked at the novel on Amazon and I remember the golf club came up on a search with something else on Ebay. > > How this information could get to someone spoofing is a little disconcerting. > > I have changed EBAY and Paypal Passwords as instructed. > > Ralph Brandt > Communications Engineer > HP Enterprise Services > Telephone +1 717.506.0802 > FAX +1 717.506.4358 > Email Ralph.Brandt at pateam.com > 5095 Ritter Rd > Mechanicsburg PA 17055 > > > > From jeroen at mompl.net Mon Jun 11 19:29:46 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 11 Jun 2012 17:29:46 -0700 Subject: Configuration Systems In-Reply-To: <4FD216EE.6060906@invaluement.com> References: <0ee9f39dc582b64393b122a653d9fc0d@mail.dessus.com> <4FD216EE.6060906@invaluement.com> Message-ID: <4FD68D7A.3010003@mompl.net> Rob McEwen wrote: > Personally, I prefer paying a little extra for my own dedicated and/or > co-located servers... where I'm in total control of ALL aspects of > hardware/software. You are resisting the lure back to the mainframe paradime [sic], let go of your resistance and let yourself be gently wallowed back into the comfortable cosiness of the wooly dinosaur. -- Earthquake Magnitude: 4.7 Date: Monday, June 11, 2012 23:19:39 UTC Location: West Chile Rise Latitude: -41.3731; Longitude: -87.9630 Depth: 10.10 km From kmedcalf at dessus.com Mon Jun 11 19:35:56 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 11 Jun 2012 18:35:56 -0600 Subject: EBAY and AMAZON In-Reply-To: Message-ID: <1bc00f830ed0604ab77c4e99a60fa6b9@mail.dessus.com> Security Settings in the Trust Center: "Read as Plain Text" "Even Signed Messages as Plain Text" "Never Download Images" "Require Confirmation when Forwarding or Replying will Download Anything at all" Disable the AutoInfect options: "Turn off the Preview" "Turn off the Reading Pain" You will never fall for a phishing scam or other malicious e-mail message ever again. I could never quite understand how anyone could get "phished" by e-mail since I have never ever seen a "phishing" or other malicious message that was not obviously so, even when I don't have me spectacles on! And for everyone who sends you a web-page-by-email, tear them a new a**hole. If they do not mend their ways, get rid of em. Banish them to bh0 where they belong. If routing them to bh0 doesn't work, then at least send their drivel to /dev/nul. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > -----Original Message----- > From: Blake Pfankuch [mailto:blake at pfankuch.me] > Sent: Monday, 11 June, 2012 14:51 > To: Kain, Rebecca (.); nick at flhsi.com; Brandt, Ralph; nanog at nanog.org > Subject: RE: EBAY and AMAZON > > I have a spam pit email address which I monitor for trends to have a little > bit of jump on the possible things users might touch at work. I started > seeing the amazon, ebay and paypal ones a few weeks back. The other one I > have started to see a lot of is the "Free or cheaper home phone service > through magic jack" ones. Again as expected they link to some .ru domain and > look just like the normal sign up page. Also my handy dandy virtual machine > was instantly owned with malware just by loading the page. The VM runs > Windows 7 as a non administrative user, UAC cranked up and IE9. Something > like 10 installed apps showed up including "Adobe Flash Player Latest." > > The other cool one I have been seeing is along the lines of "How to better > utilize your office phone system" or "New Business Phone systems" with > supposed links to "popular new phone system trends". This one is rather > crafty as it has an embedded image which is a nice weblink to an infected > jpg. So you click show picture in outlook, or in your browser and you get > another installed piece of nastyware. > > -----Original Message----- > From: Kain, Rebecca (.) [mailto:bkain1 at ford.com] > Sent: Monday, June 11, 2012 12:40 PM > To: nick at flhsi.com; Brandt, Ralph; nanog at nanog.org > Subject: RE: EBAY and AMAZON > > I have gotten them from "amazon" stating "order number X was cancelled and > please click on the below file for more information". Because I order so > much on amazon, I almost thought it was real and clicked on it but then went > to the amazon site and looked at "my open orders". It always pays to goto > the site, not believe email. > > > -----Original Message----- > From: Nick Olsen [mailto:nick at flhsi.com] > Sent: Monday, June 11, 2012 2:06 PM > To: Brandt, Ralph; nanog at nanog.org > Subject: re: EBAY and AMAZON > > I think it might just be coincidence. I've gotten about 10 of them and > haven't been to ebay or amazon in months. > Most of them have been for >60 dollar books. > > Nick Olsen > Network Operations (855) FLSPEED x106 > > ---------------------------------------- > From: "Brandt, Ralph" > Sent: Monday, June 11, 2012 1:28 PM > To: nanog at nanog.org > Subject: EBAY and AMAZON > > I have received bogus emails from both of the above on Friday. > > These look like I bought something that in both cases I did not buy. > The EBAY was a golf club for $887 and the Amazon was a novel for $82, far > more than I would have spent on either. > > I think I looked at the novel on Amazon and I remember the golf club came up > on a search with something else on Ebay. > > How this information could get to someone spoofing is a little disconcerting. > > I have changed EBAY and Paypal Passwords as instructed. > > Ralph Brandt > Communications Engineer > HP Enterprise Services > Telephone +1 717.506.0802 > FAX +1 717.506.4358 > Email Ralph.Brandt at pateam.com > 5095 Ritter Rd > Mechanicsburg PA 17055 > > > From ray.qiu at gmail.com Mon Jun 11 20:04:20 2012 From: ray.qiu at gmail.com (Ray Qiu) Date: Mon, 11 Jun 2012 18:04:20 -0700 Subject: Google SDN slides @NANOG55 Message-ID: <7195572804000698353@unknownmsgid> Hi, Could someone please share the SDN slides that Google presented at NANOG55? It is still not on the web. Thanks! Regards, Ray Sent from my iPhone 4S From cboyd at gizmopartners.com Mon Jun 11 20:48:12 2012 From: cboyd at gizmopartners.com (Chris Boyd) Date: Mon, 11 Jun 2012 20:48:12 -0500 Subject: Google SDN slides @NANOG55 In-Reply-To: <7195572804000698353@unknownmsgid> References: <7195572804000698353@unknownmsgid> Message-ID: <6F1205D1-58B4-4C57-BAD5-0318B08FB0C5@gizmopartners.com> On Jun 11, 2012, at 8:04 PM, Ray Qiu wrote: > Hi, > > Could someone please share the SDN slides that Google presented at > NANOG55? It is still not on the web. Thanks! Please post a link to the list. Thanks! +1 --Chris From morrowc.lists at gmail.com Mon Jun 11 21:06:29 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 11 Jun 2012 22:06:29 -0400 Subject: Google SDN slides @NANOG55 In-Reply-To: <6F1205D1-58B4-4C57-BAD5-0318B08FB0C5@gizmopartners.com> References: <7195572804000698353@unknownmsgid> <6F1205D1-58B4-4C57-BAD5-0318B08FB0C5@gizmopartners.com> Message-ID: On Mon, Jun 11, 2012 at 9:48 PM, Chris Boyd wrote: > On Jun 11, 2012, at 8:04 PM, Ray Qiu wrote: > >> Hi, >> >> Could someone please share the SDN slides that Google presented at >> NANOG55? ?It is still not on the web. ?Thanks! > > > Please post a link to the list. ?Thanks! won't these just show up in time on the nanog site, like all other talks? From hmurray at megapathdsl.net Mon Jun 11 22:31:36 2012 From: hmurray at megapathdsl.net (Hal Murray) Date: Mon, 11 Jun 2012 20:31:36 -0700 Subject: EBAY and AMAZON Message-ID: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> [Snip good collection of security setting suggestions. Does anybody have others or a URL?] > I could never quite understand how anyone could get "phished" by e-mail > since I have never ever seen a "phishing" or other malicious message that > was not obviously so, even when I don't have me spectacles on! Your imagination needs serious recalibration. You are a geek, not a naive, dumb, or unfortunately, typical user. Windows security sucks. Most users will pick convenience over security. What fraction of users (customers) would be happy with your suggested settings? Phishers are smart. They are willing to work for high value targets. Google for >spear phishing<. After you have read a few of those, google for > spear phishing RSA<. >From the comments section of an Arstechnica article on the RSA event: >> So why do any workplace computers in sensitive environments >> have Flash in the first place? > Because the training materials are no doubt flash based. :) If you are interested in security, the whole comments section may be worth scanning. My probably naive view is that this type of problem could easily be solved by having the serious work done on a special class of well locked down machines and making a pool of more open systems available for checking mail or facebook or whatever. I've heard stories of people filling USB slots with epoxy so idiots can't insert thumb drives found in the parking lot or brought from home. I forget the context. -- These are my opinions. I hate spam. From kmedcalf at dessus.com Tue Jun 12 00:08:27 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 11 Jun 2012 23:08:27 -0600 Subject: EBAY and AMAZON In-Reply-To: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> Message-ID: <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> > Windows security sucks. The real problem with Windows is that there exist folks who believe that it is, or can be, secured. They believe the six-colour glossy, the Gartner Reports, and other (manufacturers') propaganda. As a consequence they do not act in a fashion which will keep them safe. > Most users will pick convenience over security. What fraction of users > (customers) would be happy with your suggested settings? More than you might think -- still a minority however. There's not 2.437 pounds yet. > My probably naive view is that this type of problem could easily be solved by > having the serious work done on a special class of well locked down machines > and making a pool of more open systems available for checking mail or > facebook or whatever. You would be surprised at the number of Fortune 500 companies that lock-down their policies into deliberately insecure settings, and refuse to permit more secure settings. I can't quite figure this out, except to observe that there is a very severe shortage of security clue in the world and an appalling over-abundance of ignorance and stupidity. > I've heard stories of people filling USB slots with epoxy so idiots can't > insert thumb drives found in the parking lot or brought from home. I forget > the context. This is, unfortunately, a typical reaction which arises from a failure to carry out proper root-cause analysis. The root cause of the issue is not "thumb drives", "baby fingernail drives", or whatever removable media type. The root cause is the propensity of Windows to engage in "magical" behaviour -- to put executable "data" everywhere and then to execute that "data", magically. And a failure to provide a "Magic Off" setting that actually works. Actually, there is -- it is called the power switch. Seriously though most of the magic can be turned off or bypassed, if you want to. Companies that engage in such behaviour are signing their own "all our base are belong to you" death warrants. Rather that voting with their wallets and insisting on correction of the root-cause of the problem, they instead continue to pour money down the crapper investing in never-ending supplies of draino and roto-rooters while at the same time continuing to financially reward the paper-towel flushers so they can buy and flush yet more clogging crap which requires yet more draino and roto-rooters. Shampoo, Lather, Rinse, Repeat. (Looking up the effects of adding those instructions to shampoo by Proctor & Gamble on their sales and profits is left as an exercize for the reader). Security does not require buying more draino and roto-rooters. It just requires that you not do stupid things inimical to security. Stop flushing paper towels down the toilet and you don't need draino and roto-rooters, nor will you need hazmat gear to clean the oozing excrement off the floor. Of course, it might be wise to keep a bottle of draino, a roto-rooter, and some hazmat gear on hand just in case -- but to concentrate on the symptoms rather than the underlying cause is just plain stupidity. Deliberately encouraging and financing those working to ensure the toilet is always plugged up and the crap is always running in the halls is sheer lunacy. Unfortunately, the lunatics are in charge of the asylum, and they have chosen the outcome they shall suffer. Now, back to our regularly scheduled programming, already in progress ... --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From randy at psg.com Tue Jun 12 02:27:16 2012 From: randy at psg.com (Randy Bush) Date: Tue, 12 Jun 2012 16:27:16 +0900 Subject: Google SDN slides @NANOG55 In-Reply-To: References: <7195572804000698353@unknownmsgid> <6F1205D1-58B4-4C57-BAD5-0318B08FB0C5@gizmopartners.com> Message-ID: > won't these just show up in time on the nanog site, like all other > talks? slides are suposed to be on the web site before the talk, usually just before. randy From mohta at necom830.hpcl.titech.ac.jp Tue Jun 12 03:16:19 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 12 Jun 2012 17:16:19 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1339106986.2754.37.camel@karl> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> Message-ID: <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> Karl Auer wrote: > BTW, I'm assuming here that by "multicast filtering" you mean "switching > that properly snoops on MLD and sends multicast packets only to the > correct listeners". Errrrr, do you want to say MLD noise is not a problem? > On this point I think you are wrong. Except for router advertisements, > most NDP packets are sent to a solicited node multicast address, and so > do NOT go to all nodes. It is "the same as broadcast" only in a network > with switches that do not do MLD snooping. But, MLD packets must go to all routers. >>> So I'm not sure how DAD traffic would exceed ARP traffic. >> >> I wouldn't expect it to. > > Nor would I - which was the point of my response to an original poster > who said it might. For the original poster, : I've seen links with up to 15k devices where ARP represented : a significant part of the link usage, but most weren't (yet) IPv6. MLD noise around a router is as bad as ARP/ND noise. That's how IPv6 along with SLAAC is totally broken. Masataka Ohta From kauer at biplane.com.au Tue Jun 12 04:25:45 2012 From: kauer at biplane.com.au (Karl Auer) Date: Tue, 12 Jun 2012 19:25:45 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> Message-ID: <1339493145.15324.229.camel@karl> On Tue, 2012-06-12 at 17:16 +0900, Masataka Ohta wrote: > Errrrr, do you want to say MLD noise is not a problem? I did not say or imply that MLD noise is (or is not) a problem. I took issue with the idea that DAD traffic - the specific kind of traffic mentioned by the original poster - was likely to exceed ARP traffic. > But, MLD packets must go to all routers. As I understand it, DAD is not MLD and does not itself cause any MLD traffic. The MLD that happens around the same time as DAD happens anyway, as the node adds itself to all-link-local-nodes and its own solicited-node-multicast group. Except in that DAD is NDP, and both NDP and MLD use ICMPv6 as their transport, DAD has nothing to do with MLD? You might be right that MLD is noisy, but I don't think that has anything to do with the original discussion. > : I've seen links with up to 15k devices where ARP represented > : a significant part of the link usage, but most weren't (yet) IPv6. > > MLD noise around a router is as bad as ARP/ND noise. Possibly true, but that's another discussion. And is the MLD traffic as bad *everywhere* on the link, as ARP is? I strongly suspect not, because the payoff for MLD is a lessening of traffic going to all nodes. > That's how IPv6 along with SLAAC is totally broken. I think we have different ideas of what constitutes "totally" broken. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From mohta at necom830.hpcl.titech.ac.jp Tue Jun 12 04:42:53 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 12 Jun 2012 18:42:53 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1339493145.15324.229.camel@karl> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> Message-ID: <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> Karl Auer wrote: >> : I've seen links with up to 15k devices where ARP represented >> : a significant part of the link usage, but most weren't (yet) IPv6. >> >> MLD noise around a router is as bad as ARP/ND noise. > > Possibly true, but that's another discussion. Then, you could have simply argued that there is no ARP problem with IPv6, because ND, not ARP, were another discussion. >> That's how IPv6 along with SLAAC is totally broken. > > I think we have different ideas of what constitutes "totally" broken. It is because you avoid to face the reality of MLD. Masataka Ohta From rjs at rob.sh Tue Jun 12 05:54:42 2012 From: rjs at rob.sh (Rob Shakir) Date: Tue, 12 Jun 2012 11:54:42 +0100 Subject: BGP Error Handling (Fwd: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04) References: Message-ID: <5C23A0E1-6966-4358-811F-7988BBF3B4B4@rob.sh> Hi NANOGers, Back at NANOG51 in Miami, I gave a presentation relating an IETF draft relating to improving the robustness of BGP-4 to meet the requirements of current operational deployments, and there was some good discussion following this. This document was then presented to the IETF IDR and GROW (Global Routing Operations WG), and we have since iterated the document to make it significantly clearer, and describe the desired operational behaviour. This work was particularly on the back of the issues that were seen in the Internet DFZ relating to malformed AS_PATH, invalid AS4_PATH, and the problematic RIPE NCC large optional-transitive advertisement. The discussion, and the requirements outlined have helped influence a number of new standards developments in BGP: - An IDR BGP error handling draft [0] is in progress to standardise the "treat-as-withdraw" behaviour, which allows session resets to be avoided based on erroneous BGP UPDATEs where possible. - Further drafts relating to extending ROUTE REFRESH [1] and Graceful Restart [2] have been proposed to allow recovery from inconsistent RIB states, and reduced impact to forwarding when a session reset cannot be avoided respectively. - The work that Tom Scholl, Richard Steenbergen, John Scudder, and David Freedman did on the ADVISORY message has been extended to handle some error handling cases, as well as the original use case [3]. The working group last call represents final agreement prior to publishing this work, which is valuable since it provides a framework of requirements which future developments are intended to solve. I would encourage anyone who has an interest in this area to review the document, and let the GROW mailing list (grow at ietf.org) know whether the requirements describe meet their use case, and/or any comments or deviations that should be noted. Many thanks in advance for doing so - there are a number of network scenarios that I think will be operationally improved by implementing this work. Kind regards, r. Begin forwarded message: > From: Christopher Morrow > Subject: [GROW] WGLC: draft-ietf-grow-ops-reqs-for-bgp-error-handling-04 > Date: 11 June 2012 21:21:49 GMT+01:00 > To: grow-chairs at tools.ietf.org, "grow at ietf.org grow at ietf.org" > > Hello GROW-WG folk, > Please take this message as the start of a 2 week, ending 6/25/2012 > (June 25, 2012) WGLC for the subject draft, link to current version: > > > Abstract: > "BGP-4 is utilised as a key intra- and inter-Autonomous System routing > protocol in modern IP networks. The failure modes as defined by the > original protocol standards are based on a number of assumptions > around the impact of session failure. Numerous incidents both in the > global Internet routing table and within Service Provider networks > have been caused by strict handling of a single invalid UPDATE > message causing large-scale failures in one or more Autonomous > Systems. > > This memo describes the current use of BGP-4 within Service Provider > networks, and outlines a set of requirements for further work to > enhance the mechanisms available to a BGP-4 implementation when > erroneous data is detected. Whilst this document does not provide > specification of any standard, it is intended as an overview of a set > of enhancements to BGP-4 to improve the protocol's robustness to suit > its current deployment." > > -Chris > co-chair > _______________________________________________ > GROW mailing list > GROW at ietf.org > https://www.ietf.org/mailman/listinfo/grow From rsk at gsp.org Tue Jun 12 06:35:47 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 12 Jun 2012 07:35:47 -0400 Subject: EBAY and AMAZON In-Reply-To: <7DB845D64966DC44A1CC592780539B4BA57914@nafmbx47.exchange.ford.com> References: <2c604629$4f95022a$3c8188fd$@com> <7DB845D64966DC44A1CC592780539B4BA57914@nafmbx47.exchange.ford.com> Message-ID: <20120612113547.GA19636@gsp.org> On Mon, Jun 11, 2012 at 06:39:44PM +0000, Kain, Rebecca (.) wrote: > It always pays to goto the site, not believe email. 1. This is why (particularly when dealing with older and/or non-technical people who are incredibly easy to scam) I recommend (a) bookmarking their critical sites, such as banks, and (b) training them to never, ever, EVER use anything but those bookmarks to get to those sites. 2. Of course, many of those same critical sites have been ardently training their customers to be phish victims by their appallingly stupid insistence on HTML markup in email, which is why (1) is necessary. ---rsk From jamie at photon.com Tue Jun 12 06:44:44 2012 From: jamie at photon.com (Jamie Bowden) Date: Tue, 12 Jun 2012 11:44:44 +0000 Subject: EBAY and AMAZON In-Reply-To: <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> Message-ID: <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> Apologies for lack of attribution beyond the first level, but the previous poster removed that. > From: Keith Medcalf [mailto:kmedcalf at dessus.com] > > > Windows security sucks. > > The real problem with Windows is that there exist folks who believe > that it is, or can be, secured. They believe the six-colour glossy, > the Gartner Reports, and other (manufacturers') propaganda. As a > consequence they do not act in a fashion which will keep them safe. While MS may be a favorite whipping boy, let's not pretend that if the dominant OS were Apple or some flavor of *nix, things would be any better. Those OS's are no more secure than a Windows box once you plug a few hundred million people into their consoles. Jamie From mohta at necom830.hpcl.titech.ac.jp Tue Jun 12 06:47:09 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 12 Jun 2012 20:47:09 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> Message-ID: <4FD72C3D.10709@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: > If you wish, you can also consider Alternate 3 for 9kB: > 72us at 1Gbps, 7.2us at 10Gbps, .72us at 100Gbps, .072us at 1Tbps. So? Have you learned enough about Moore's law that, at 10Gbps era, 72us of delay is often significant? Masataka Ohta From dave at temk.in Tue Jun 12 07:11:44 2012 From: dave at temk.in (David Temkin) Date: Tue, 12 Jun 2012 08:11:44 -0400 Subject: Google SDN slides @NANOG55 In-Reply-To: References: <7195572804000698353@unknownmsgid> <6F1205D1-58B4-4C57-BAD5-0318B08FB0C5@gizmopartners.com> Message-ID: <4FD73200.2070509@temk.in> On 6/11/12 10:06 PM, Christopher Morrow wrote: > On Mon, Jun 11, 2012 at 9:48 PM, Chris Boyd wrote: >> On Jun 11, 2012, at 8:04 PM, Ray Qiu wrote: >> >>> Hi, >>> >>> Could someone please share the SDN slides that Google presented at >>> NANOG55? It is still not on the web. Thanks! >> >> Please post a link to the list. Thanks! > won't these just show up in time on the nanog site, like all other talks? > The author of this talk requested that their slides not be posted, which is a request we honor for all speakers. Regards, -Dave Temkin (Chair, NANOG Program Committee) From mysidia at gmail.com Tue Jun 12 07:20:09 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 12 Jun 2012 07:20:09 -0500 Subject: EBAY and AMAZON In-Reply-To: <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> Message-ID: On 6/12/12, Keith Medcalf wrote: >> Windows security sucks. > > The real problem with Windows is that there exist folks who believe that it > is, or can be, secured. They believe the six-colour glossy, the Gartner [snip] Well, they are right. Windows can be secured. The problem is it It won't be secured in practice. Because that's too hard, and truly securing Windows will be rejected by the user, because many applications used in practice are not implemented securely on the platform. Users of Windows endpoints require functions such as Web Browsers, Flash, their favorite Office applications, PDF Viewers, and remote share access. >You would be surprised at the number of Fortune 500 companies that lock-down their >policies into deliberately insecure settings, and refuse to permit more secure settings. >.. This is because, while you would expect IT to understand the importance of security. "Lock Down" has a perception of security attached to it. In practice, "Lock-Down Policies" and standardization have nothing positive to do with security, but IT convenience, and reducing support costs, by attempting to enforce a standardized endpoint experience. They can lead to less security if done without extra security review. Hopefully they also include a backup/imaging system to recover, when the lock-down policy makes it break, however. > This is, unfortunately, a typical reaction which arises from a failure to > carry out proper root-cause analysis. The root cause of the issue is not > "thumb drives", "baby fingernail drives", or whatever removable media type. The windows shell is to blame, but you can provide an alternate shell that doesn't do that "magical executable code insertion" stuff and disable Explorer. -- -JH From Curtis.Starnes at granburyisd.org Tue Jun 12 07:23:22 2012 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Tue, 12 Jun 2012 07:23:22 -0500 Subject: CBT Nuggets streaming account In-Reply-To: <4FD67424.3030503@ninjabadger.net> References: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> <4FD67424.3030503@ninjabadger.net> Message-ID: Yea, I know. The one aspect of the whole thing is memorizing a brain dump is one thing; troubleshooting and fixing the problem with a supervisor screaming down your neck is another. Without the hands on experience, the "memorizing" of the brain dumps will show up real fast in a NOC! I was asked one time how long it took to learn networking, simple answer: How it is supposed to work, not very long; what can go wrong and how to troubleshoot and correct the issue(s), a whole lot longer. Curtis -----Original Message----- From: Tom Hill [mailto:tom at ninjabadger.net] Sent: Monday, June 11, 2012 5:42 PM To: nanog at nanog.org Subject: Re: CBT Nuggets streaming account On 11/06/12 22:15, STARNES, CURTIS wrote: > There is a reason Cisco certs are not considered "Paper Mill Certs" > and that you have to recertify every few years to keep up with new > equipment and technologies. That is what our community DOESN'T need, > Cisco certs that are looked upon like lot of the other manufacturer > certification courses. Too late, sorry. Every man and his dog has downloaded PASS4SURE and memorised the answers to pass the exams. You can do this once every three years, no problem. Sure, those candidates will be absolutely useless, but that doesn't stop the dilution of CCNA/CCNP certs in the market. What will it do? It'll make the CCIE more important. What have Cisco done about it? Oh, they released a more prestigious, more expensive cert, didn't they? :) Tom From rburtch3 at gmail.com Tue Jun 12 08:20:43 2012 From: rburtch3 at gmail.com (Ryan Burtch) Date: Tue, 12 Jun 2012 09:20:43 -0400 Subject: CBT Nuggets streaming account In-Reply-To: References: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> Message-ID: I used cbt nuggets conceptually in ccna and it gave me a good overview of the concepts. It may be my style of learning. That said, I was only asking if someone would be willing to help me with ccnp cbt nuggets training as I know that streaming accounts are multi user. On Jun 11, 2012 5:05 PM, "Jonathan Rogers" wrote: > > GNS3 is completely insufficient for CCNP-level training and labs. You will need actual equipment. Fortunately, it has gotten a lot cheaper over the past few years and you don't need the latest and greatest. Check out Wendell Odom's website for tips. > > Also we have a CBTNuggets account at my company and I was unimpressed with their Cisco coverage, but that may be a matter of taste. > > Just my $0.02...as a CCNA working towards MY CCNP. > > --jono > > > On Mon, Jun 11, 2012 at 4:56 PM, Garrett Skjelstad wrote: >> >> Don't spam the list looking for black market copies of training material. Use GNS3 and design your own labs and google the test topics. Plzkthx. >> >> Sent from my iPhone >> >> On Jun 11, 2012, at 12:30, Ryan Burtch wrote: >> >> > Could someone contact me off list if you have a CBT Nuggets streaming >> > account and would be willing to help me in working towards my CCNP? >> > From jcdill.lists at gmail.com Tue Jun 12 09:32:46 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 12 Jun 2012 07:32:46 -0700 Subject: Dear Linkedin, In-Reply-To: <201206110839.01560.a.harrowell@gmail.com> References: <610439.8746.1339369914325.JavaMail.root@benjamin.baylink.com> <62982583-EF5C-4B21-B49A-14B9938C1D18@gmail.com> <20437.22970.99377.799263@world.std.com> <201206110839.01560.a.harrowell@gmail.com> Message-ID: <4FD7530E.3050005@gmail.com> On 11/06/12 12:38 AM, Alexander Harrowell wrote: > A question: password managers are obviously a great idea, and password > manager + synchronisation takes care of multiple devices. Go ahead and use one of these password managers and load it with all your passwords. Then load it's smartphone app on your smartphone, and report back how well it works to load your secure password into the Facebook App, the Flickr App, the Twitter App, the (fill-in-the-blank) App for the 1001 Apps you have on your phone. To the best of my knowledge, there is no password manager that *seamlessly* syncs your password with a computer and with smartphone apps. And in case you haven't noticed, more and more computing (and logging in) is done with smartphone apps these days. This is still very much an un-solved problem. Fixing it so it works on just one computer (using a password manager) is solved. Fixing it so it works on several "regular" computers (synching password managers) is solved - although this also puts your passwords in the possession of another party (to allow the synching to work). Fixing it so you can login seamlessly and easily from all types of computers including computers you don't own (when visiting/traveling) is NOT a solved problem, and if you use a password manager and think it makes your life easy, then you suddenly find you can't login to anything (e.g. you are traveling and lose your phone and need to login to your email account, with a password you don't remember, you only have the secure password for your password manager) you will find out how NOT easy this solution really is. jc From adam.vitkovsky at swan.sk Tue Jun 12 09:36:13 2012 From: adam.vitkovsky at swan.sk (adam vitkovsky) Date: Tue, 12 Jun 2012 16:36:13 +0200 Subject: CBT Nuggets streaming account In-Reply-To: References: <800E5DF5-2190-423F-8897-CEAF235DD909@skjelstad.org> Message-ID: <009901cd48a8$b7657e40$26307ac0$@swan.sk> CBT Nuggets is just a quick overview of what you need to read and lab through in order to know your stuff adam -----Original Message----- From: Ryan Burtch [mailto:rburtch3 at gmail.com] Sent: Tuesday, June 12, 2012 3:21 PM To: Jonathan Rogers Cc: nanog at nanog.org Subject: Re: CBT Nuggets streaming account I used cbt nuggets conceptually in ccna and it gave me a good overview of the concepts. It may be my style of learning. That said, I was only asking if someone would be willing to help me with ccnp cbt nuggets training as I know that streaming accounts are multi user. On Jun 11, 2012 5:05 PM, "Jonathan Rogers" wrote: > > GNS3 is completely insufficient for CCNP-level training and labs. You will need actual equipment. Fortunately, it has gotten a lot cheaper over the past few years and you don't need the latest and greatest. Check out Wendell Odom's website for tips. > > Also we have a CBTNuggets account at my company and I was unimpressed with their Cisco coverage, but that may be a matter of taste. > > Just my $0.02...as a CCNA working towards MY CCNP. > > --jono > > > On Mon, Jun 11, 2012 at 4:56 PM, Garrett Skjelstad > wrote: >> >> Don't spam the list looking for black market copies of training material. Use GNS3 and design your own labs and google the test topics. Plzkthx. >> >> Sent from my iPhone >> >> On Jun 11, 2012, at 12:30, Ryan Burtch wrote: >> >> > Could someone contact me off list if you have a CBT Nuggets >> > streaming account and would be willing to help me in working towards my CCNP? >> > From alh-ietf at tndh.net Tue Jun 12 11:25:21 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 12 Jun 2012 09:25:21 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> Message-ID: <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> Masataka Ohta wrote: > Karl Auer wrote: > > >> : I've seen links with up to 15k devices where ARP represented > >> : a significant part of the link usage, but most weren't (yet) IPv6. > >> > >> MLD noise around a router is as bad as ARP/ND noise. > > > > Possibly true, but that's another discussion. > > Then, you could have simply argued that there is no ARP problem with IPv6, > because ND, not ARP, were another discussion. > > >> That's how IPv6 along with SLAAC is totally broken. > > > > I think we have different ideas of what constitutes "totally" broken. > > It is because you avoid to face the reality of MLD. MLD != ND MLD == IGMP ND ~= ARP ND is less overhead on end systems than ARP because it is only received by nodes that are subscribed to a specific multicast group rather than broadcast reception by all. There is no difference in L2 resolution traffic at the packet level on the network. There are multicast join messages for groups specific to ND use, but those should not be frequent, and were a specific tradeoff in minor additional network load to reduce significant end system load. There are DAD messages that impact group members, but in IPv4 there are gratuitous ARP broadcasts which impact all nodes, so while the number of messages for that function is the same, the system-wide impact is much lower. Multicast group management is inherently noisy, but a few more bits on the wire reduces the load on the significantly larger number of end systems. Get over it ... Tony From wayne at staff.msen.com Tue Jun 12 11:33:29 2012 From: wayne at staff.msen.com (Michael R. Wayne) Date: Tue, 12 Jun 2012 12:33:29 -0400 Subject: EBAY and AMAZON In-Reply-To: <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> Message-ID: <20120612163329.GY42080@manor.msen.com> On Tue, Jun 12, 2012 at 11:44:44AM +0000, Jamie Bowden wrote: > > While MS may be a favorite whipping boy, let's not pretend that if the dominant OS were Apple or some flavor of *nix, things would be any better. There is an inherent advantage for anything based upon *BSD. It was developed in an evironment where in order to continue to operate it was required to defend itself against many users who wished to exploit the O/S. Windows, being designed for a single-user environment, made a number of design decisions which directly conflict with security. Having spoken to MS security about this, there is no interest on their part in disturbing the "user experience" in exchange for drastic security improvements. Rather, they continue to gradually evolve their existing model to increase security which, in fact, has been improved, however slowly. It is important to understand that there is nothing inherent in the Windows experience which prohibits security. Rather, it is a deliberate design choice on the part of MS. From Fred.L.Templin at boeing.com Tue Jun 12 12:19:39 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 12 Jun 2012 10:19:39 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FD72C3D.10709@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <4FCD4751.1070408@necom830.hpcl.titech.ac.jp> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> <4FD72C3D.10709@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Tuesday, June 12, 2012 4:47 AM > To: Templin, Fred L > Cc: Owen DeLong; nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > > If you wish, you can also consider Alternate 3 for 9kB: > > 72us at 1Gbps, 7.2us at 10Gbps, .72us at 100Gbps, .072us at 1Tbps. > > So? > > Have you learned enough about Moore's law that, at 10Gbps > era, 72us of delay is often significant? I frankly haven't thought about it any further. You say 1280+ belongs in ITU, and I say 1280- belongs in ATM. Larger packets means fewer interrupts and fewer packets in flight, which is good Moore's law or no. Accommodation of MTU diversity is what matters. Fred fred.l.templin at boeing.com > Masataka Ohta From jamie at photon.com Tue Jun 12 12:19:52 2012 From: jamie at photon.com (Jamie Bowden) Date: Tue, 12 Jun 2012 17:19:52 +0000 Subject: EBAY and AMAZON In-Reply-To: <20120612163329.GY42080@manor.msen.com> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> <20120612163329.GY42080@manor.msen.com> Message-ID: <465966A5F5B867419F604CD3E604C1E505FB98D5@pra-ess-mail.pra.ray.com> > From: Michael R. Wayne [mailto:wayne at staff.msen.com] > On Tue, Jun 12, 2012 at 11:44:44AM +0000, Jamie Bowden wrote: > > While MS may be a favorite whipping boy, let's not pretend that if > > the dominant OS were Apple or some flavor of *nix, things would be any > > better. > There is an inherent advantage for anything based upon *BSD. It > was developed in an evironment where in order to continue to operate > it was required to defend itself against many users who wished to > exploit the O/S. Windows, being designed for a single-user environment, > made a number of design decisions which directly conflict with > security. I've been running FBSD since 1994, so I'm well aware of the development model, thanks. The *BSDs and Linux have all had their share of holes in them and more still continue to be found. The only thing saving them is lack of market share. Apple's increasing market share is a nice demonstration of this at work. As far as securing Windows, it can be done, and done well, but it requires policy enforcement at the hardware and personnel level, and that doesn't change no matter what OS you're running. I have hardened Windows systems, and they are no more of a pain the ass to use than the hardened *nix systems. When DSS is done with them, all OS's suck to use. Jamie From sylvie at newnog.org Tue Jun 12 15:08:29 2012 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Tue, 12 Jun 2012 16:08:29 -0400 Subject: [NANOG-announce] Board Announcement to the NANOG Community Message-ID: Colleagues: The NANOG Board of Directors has accepted the resignation of Richard Steenbergen on June 11, 2012. Richard wrote that '*recent personal and career changes have made it impossible to devote as much time and attention to NANOG** as is needed. Therefore, I must officially tender my resignation. It has been a privilege to work with you all, and I hope I have the opportunity to do so again in the future*.? Richard has served four years on the NANOG Program Committee and nearly two years on the NANOG Board during these important transition years. We are saddened to loose Richard and wish him every success in his new activities. On behalf of the Board I want to express to Richard our sincere thanks for his contribution to NANOG. Per our bylaws 8.7, the Board will be interviewing candidates and will soon appoint a replacement to serve until the next election. Sincerely, Sylvie -- Sylvie LaPerriere NANOG Chair - www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From lanning at lanning.cc Tue Jun 12 15:16:22 2012 From: lanning at lanning.cc (Robert Hajime Lanning) Date: Tue, 12 Jun 2012 13:16:22 -0700 Subject: EBAY and AMAZON In-Reply-To: References: <2c604629$4f95022a$3c8188fd$@com> <7DB845D64966DC44A1CC592780539B4BA57914@nafmbx47.exchange.ford.com> Message-ID: <4FD7A396.4080600@lanning.cc> Not too long ago I received 3 phone calls, with a strong Indian accent and broken english, claiming to be a computer support firm that has noticed virus activities on my Windows computer. First time I told them I don't have any Windows machines. They then hung up. The second time, I asked them what IP they saw this from. They didn't know. Then they hung up. The third time, I told them I had 15 machines, and asked which one. They hung up again. The calls came from different Los Angeles area codes, but had to be VoIP. On 06/11/12 13:51, Blake Pfankuch wrote: > I have a spam pit email address which I monitor for trends to have > a little bit of jump on the possible things users might touch at > work. I started seeing the amazon, ebay and paypal ones a few > weeks back. The other one I have started to see a lot of is the > "Free or cheaper home phone service through magic jack" ones. > Again as expected they link to some .ru domain and look just like > the normal sign up page. Also my handy dandy virtual machine was > instantly owned with malware just by loading the page. The VM > runs Windows 7 as a non administrative user, UAC cranked up and > IE9. Something like 10 installed apps showed up including > "Adobe Flash Player Latest." > > The other cool one I have been seeing is along the lines of > "How to better utilize your office phone system" or > "New Business Phone systems" with supposed links to > "popular new phone system trends". This one is rather crafty > as it has an embedded image which is a nice weblink to an > infected jpg. So you click show picture in outlook, or in your > browser and you get another installed piece of nastyware. > -- Mr. Flibble King of the Potato People From mohta at necom830.hpcl.titech.ac.jp Tue Jun 12 15:33:57 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Jun 2012 05:33:57 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> <4FD72C3D.10709@necom830.hpcl.titech.ac.jp> Message-ID: <4FD7A7B5.1070306@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: >> Have you learned enough about Moore's law that, at 10Gbps >> era, 72us of delay is often significant? > > I frankly haven't thought about it any further. That's your problem. > You say > 1280+ belongs in ITU, and I say 1280- belongs in ATM. As I already said, 9KB is fine for me. Small cell size (32~48B, not 1280-) of ATM is derived from slow (64Kbps voice) speed and short (0.1s) delay requirement with fair queuing and has no relevance to today's network. > Larger packets means fewer interrupts and fewer packets > in flight, which is good Moore's law or no. That is a basic misunderstanding of those who thought jumbograms were good. They (or you) thought supercomputers are vector computers, very slow to react against interrupts, and have no IO processors to take care of packet handling. The reality with Moore's law, however, is that NIC cards can take care of even TCP, which makes jumbograms totally unnecessary. Moreover, the huge number of scalar processors in modern supercomputers means communication granularity is (depending on computation algorithm) often tiny, which means networks in supercomputers must be able to handle small packets efficiently. Larger packets means, in addition to longer HOL blocking, more delay to pack more data in the packets, even though processors often want to receive data with less delay. Thus, as with other features of IPv6, jumbograms are no useful but harmful. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 12 15:49:32 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Jun 2012 05:49:32 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> Message-ID: <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> Tony Hain wrote: >> It is because you avoid to face the reality of MLD. > MLD != ND > MLD == IGMP OK. > ND ~= ARP Wrong, because ND requires MLD while ARP does not. > ND is less overhead on end systems than ARP Today, overhead in time is more serious than that in processor load. As ND requires MLD and DAD, overhead in time when addresses are assigned is very large (several seconds or more if multicast is not very reliable), which is harmful especially for quicking moving mobile hosts. > because it is only received by > nodes that are subscribed to a specific multicast group rather than > broadcast reception by all. Broadcast reception by all is good because that's how ARP can detect duplicated addresses without DAD overhead in time. > Multicast group management is inherently noisy, Thus, IPv6 is inherently noisy while IPv4 is not. > but a few more bits on the > wire reduces the load on the significantly larger number of end systems. Get > over it ... First of all, with CATENET model, there is no significantly large number of end systems in a link. Secondly, even if there are significantly large number of end systems in a link, with the end to end principle, network equipments must be dumb while end systems must be intelligent, which means MLD snooping is unnecessary and end systems must take care of themselves, violation of which results in inefficiencies and incompleteness of ND. Masataka Ohta From Fred.L.Templin at boeing.com Tue Jun 12 15:53:59 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 12 Jun 2012 13:53:59 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FD7A7B5.1070306@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <4FCE35BD.5020106@necom830.hpcl.titech.ac.jp> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> <4FD72C3D.10709@necom830.hpcl.titech.ac.jp> <4FD7A7B5.1070306@necom830.hpcl.titech.ac.jp> Message-ID: > As I already said, 9KB is fine for me. Then you will agree that accommodation of MTU diversity is a MUST (my point). Fred From mohta at necom830.hpcl.titech.ac.jp Tue Jun 12 16:11:47 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Jun 2012 06:11:47 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> <4FD72C3D.10709@necom830.hpcl.titech.ac.jp> <4FD7A7B5.1070306@necom830.hpcl.titech.ac.jp> Message-ID: <4FD7B093.3010808@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: >> As I already said, 9KB is fine for me. > > Then you will agree that accommodation of MTU diversity > is a MUST (my point). Not necessarily, as IPv4 can take care of itself and IPv6 is hopeless. Masataka Ohta From Fred.L.Templin at boeing.com Tue Jun 12 16:26:58 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 12 Jun 2012 14:26:58 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FD7B093.3010808@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <4FCE51AD.5050601@necom830.hpcl.titech.ac.jp> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> <4FD72C3D.10709@necom830.hpcl.titech.ac.jp> <4FD7A7B5.1070306@necom830.hpcl.titech.ac.jp> <4FD7B093.3010808@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Tuesday, June 12, 2012 2:12 PM > To: Templin, Fred L > Cc: Owen DeLong; nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > >> As I already said, 9KB is fine for me. > > > > Then you will agree that accommodation of MTU diversity > > is a MUST (my point). > > Not necessarily, as IPv4 can take care of itself and IPv6 > is hopeless. IPv4 can take care of it how - with broken PMTUD or with broken fragmentation/reassembly? And, you won't get any argument from me that IPv6 has been stuck for years for good reasons - but MTU failures can soon be taken off the list. Fred fred.l.templin at boeing.com From alh-ietf at tndh.net Tue Jun 12 17:26:39 2012 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 12 Jun 2012 15:26:39 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> Message-ID: <034c01cd48ea$711c0020$53540060$@tndh.net> Masataka Ohta > Tony Hain wrote: > > >> It is because you avoid to face the reality of MLD. > > > MLD != ND > > MLD == IGMP > > OK. > > > ND ~= ARP > > Wrong, because ND requires MLD while ARP does not. Note the ~ ... And ARP requires media level broadcast, which ND does not. Not all media support broadcast. > > > ND is less overhead on end systems than ARP > > Today, overhead in time is more serious than that in processor load. > > As ND requires MLD and DAD, overhead in time when addresses are > assigned is very large (several seconds or more if multicast is not very > reliable), which is harmful especially for quicking moving mobile hosts. So leveraging broadcast is why just about every implementation does a gratuitous ARP-and-wait multiple times, which is no different than DAD timing? MLD does not need to significantly increase time for address assignment. If hosts are moving quickly the fabric needs to be able to keep up with that anyway, so adding a new multicast member needs to be fast independent of IPv6 address assignment. > > > because it is only received by > > nodes that are subscribed to a specific multicast group rather than > > broadcast reception by all. > > Broadcast reception by all is good because that's how ARP can detect > duplicated addresses without DAD overhead in time. BS ... Broadcasts are dropped all the time, so some nodes miss them and they need to be repeated which causes further delay. On top of that, the widespread practice of a gratuitous ARP was the precedent for the design of DAD. > > > Multicast group management is inherently noisy, > > Thus, IPv6 is inherently noisy while IPv4 is not. > > > but a few more bits on the > > wire reduces the load on the significantly larger number of end > > systems. Get over it ... > > First of all, with CATENET model, there is no significantly large number of end > systems in a link. Clearly you have never looked at some networks with > 64k nodes on a link. Not all nodes move, and not all networks are a handful of end systems per segment. > > Secondly, even if there are significantly large number of end systems in a > link, with the end to end principle, network equipments must be dumb while > end systems must be intelligent, which means MLD snooping is unnecessary > and end systems must take care of themselves, violation of which results in > inefficiencies and incompleteness of ND. MLD snooping was a recent addition to deal with intermediate network devices that want to insert themselves into a process that was designed to bypass them. That is not a violation of the end systems taking care of themselves, it is an efficiency issue some devices chose to assert that isn't strictly required for end-to-end operation. Just because you have never liked the design choices and tradeoffs made in developing IPv6 doesn't make them wrong. I don't know anybody that is happy with all aspects of the process, but that is also true for all the bolt-on's developed to keep IPv4 running over the last 30 years. IPv4 had its day, and it is time to move on. Continuing to complain about existing IPv6 design does nothing productive. If there are constructive suggestions to make the outcome better, take them to the IETF just like all the constructive changes made to IPv4. Tony From gary.buhrmaster at gmail.com Tue Jun 12 17:53:51 2012 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Tue, 12 Jun 2012 22:53:51 +0000 Subject: EBAY and AMAZON In-Reply-To: <20120612163329.GY42080@manor.msen.com> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> <20120612163329.GY42080@manor.msen.com> Message-ID: On Tue, Jun 12, 2012 at 4:33 PM, Michael R. Wayne wrote: ... > It is important to understand that there is nothing inherent in the > Windows experience which prohibits security. Rather, it is a > deliberate design choice on the part of MS. Windows. A strange game. The only winning move is not to play. How about a nice game of FreeBSD? From mohta at necom830.hpcl.titech.ac.jp Tue Jun 12 18:24:35 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Jun 2012 08:24:35 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <034c01cd48ea$711c0020$53540060$@tndh.net> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> Message-ID: <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> Tony Hain wrote: > Note the ~ ... And ARP requires media level broadcast, which ND does not. Any multicast capable link is broadcast capable. > Not all media support broadcast. A fundamental misunderstanding of people designed IPv6 is that they believed ATM not broadcast capable but multicast capable. >> As ND requires MLD and DAD, overhead in time when addresses are >> assigned is very large (several seconds or more if multicast is not very >> reliable), which is harmful especially for quicking moving mobile hosts. > > So leveraging broadcast is why just about every implementation does a > gratuitous ARP-and-wait multiple times, Not at all. IPv4 over something does not have to be ARP. IPv6 is broken eventually requiring all link use ND, even though ND was designed for stational hosts with only Ethernet, PPP and ATM (with a lot of misunderstanding) in mind. > MLD does not need to significantly increase time for address > assignment. That DAD latency is already too bad does not validate additional latency of MLD. > If hosts are moving quickly the fabric needs to be able to keep > up with that anyway, so adding a new multicast member needs to be fast > independent of IPv6 address assignment. If only IPv6 over something were defined reflecting link specific properties. Instead, universal timing specification of ND and MLD ignoring various links in the world makes it impossible to be fast. > BS ... Broadcasts are dropped all the time, On Ethernet, broadcast is as reliable as unicast. > MLD snooping was a recent addition MLD snooping ~= IGMP snooping. > it is an efficiency issue some devices chose to assert that isn't strictly > required for end-to-end operation. There certainly are many problems, including but not limited to efficiency ones, caused by ND ignoring the end to end principle to make routers more intelligent than hosts, against which MLD snooping cloud be a half solution. But, so what? > Just because you have never liked the design choices and tradeoffs made in > developing IPv6 doesn't make them wrong. It is the ignorance on the end to end principle which makes IPv6 wrong. > Continuing to complain about existing IPv6 design > does nothing productive. Insisting on broken IPv6 design does nothing productive. > If there are constructive suggestions to make the > outcome better, take them to the IETF just like all the > constructive changes made to IPv4. IPv6 is a proof that IETF has lost the power to make the world better. Masataka Ohta From owen at delong.com Tue Jun 12 20:13:51 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 12 Jun 2012 18:13:51 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> Message-ID: On Jun 12, 2012, at 4:24 PM, Masataka Ohta wrote: > Tony Hain wrote: > >> Note the ~ ... And ARP requires media level broadcast, which ND does not. > > Any multicast capable link is broadcast capable. BZZT! but thank you for playing. Many NBMA topologies support multicast. > >> Not all media support broadcast. > > A fundamental misunderstanding of people designed IPv6 is that > they believed ATM not broadcast capable but multicast capable. > This is, in fact, true. Yes, you can synthesize ATM broadcast-like behavior, but it is not broadcast. >>> As ND requires MLD and DAD, overhead in time when addresses are >>> assigned is very large (several seconds or more if multicast is not very >>> reliable), which is harmful especially for quicking moving mobile hosts. >> >> So leveraging broadcast is why just about every implementation does a >> gratuitous ARP-and-wait multiple times, > > Not at all. IPv4 over something does not have to be ARP. > IPv4 over anything requires some form of L2 address resolution in any case where L2 addresses must be discovered. > IPv6 is broken eventually requiring all link use ND, even > though ND was designed for stational hosts with only Ethernet, > PPP and ATM (with a lot of misunderstanding) in mind. > Not really. >> BS ... Broadcasts are dropped all the time, > > On Ethernet, broadcast is as reliable as unicast. > BS. >> Just because you have never liked the design choices and tradeoffs made in >> developing IPv6 doesn't make them wrong. > > It is the ignorance on the end to end principle which makes > IPv6 wrong. > End-to-end is significantly more broken in IPv4 because of the need for NAT than it is in IPv6. IIRC, you were the one promoting even more borked forms of NAT to try and compensate for this. >> If there are constructive suggestions to make the >> outcome better, take them to the IETF just like all the >> constructive changes made to IPv4. > > IPv6 is a proof that IETF has lost the power to make > the world better. IPv6 is quite a bit better than IPv4 in many ways. It could be better still, but, it is definitely superior to current IPv4 implementations and vastly superior to the IPv4 implementations that existed when IPv6 was designed. Owen From sylvie at newnog.org Tue Jun 12 20:58:51 2012 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Tue, 12 Jun 2012 21:58:51 -0400 Subject: [NANOG-announce] Board Member Replacement Process - close June 20 23:59 PDT Message-ID: *Colleagues, If you are interested in the board replacement position please read on, if not, you may stop now. Following our announcement, many of you are pinging me to serve as the replacement on the Board. Your interest in our organization is amazing and truly encouraging! The process for Board replacement is laid out in our bylaws in Section 8.7. and the intent is to keep a functioning Board running until the next elections. Per our presentation at the NANOG 55 Community meeting we have a full list of deliverables until then. So basically the replacement position is 5-8 hours/week of volunteering inclusive of regular board meetings. 8.7 Vacancies If a Board of Directors member resigns or a Board of Directors seat otherwise becomes vacant more than two months before the next election, the remaining members of the Board of Directors will appoint a replacement to serve until the next election, at which point if there is any additional time remaining in the term a member will be elected to fill the vacancy. If a vacancy occurs less than two months before an election, the seat will remain vacant until the election As we are more than 2 months away from our next elections, the Board has to appoint a replacement (a member in good standing) for the interim. The replacement will serve on the Board until the next election only. Continuance on the Board will be dependent on being properly elected next October, per our election process described in Section 8. Board of Directors. Who are we looking for? * *The short answer is ?a good election candidate (per the below)? plus ?a high degree of familiarity with NANOG?. A good candidate will have experience with Internet engineering, operations, and governance organizations as well as the principles and practices which guide them. A strong candidate should have experience with NANOG through meeting attendance, meeting presentations, serving on a committee, and have been an active member of the NANOG mailing list for a minimum of 3 years. Consensus organizing, leadership, outreach and communication skills are prized, and a willingness to be engaged in the governance process is required. A board member (committee liaisons) is expected to volunteer 5 hours per week while a board officer (Chair, vice-chair, treasurer, secretary) is expected to volunteer 5-8 hours per week, all year round. How do you apply? We are reaching out to members and if you want to be a candidate for this replacement with a term of about 3 months, please write to board at newnog.orgbefore June 20 23:59 PDT and state your name, your affiliation and describe your readiness, your ability (check with your employer if you can afford the time!) and motivation to serve for this interim. You will have to demonstrate familiarity with our activities and be available to attend our bi-weekly Board meetings held Fridays from 14:00-15:00 EDT from June 22 to September 28. (sorry, we cannot move the time to suit your schedule - you are jumping on a cruising ship.) How is the selection made? The Board will review the candidacies and appoint. Decision will be final and announced on June 22 to nanog-announce at nanog.org. There is more than the replacement position. Bear in mind that the election process will be initiated in early August when we will have 3 vacant board positions to fill. Check http://www.nanog.org/governance/elections/ late July and we will communicate the elections process via nanog-announce at nanog.org. We trust this answers your questions about the replacement and thank you for your consideration and interest for NANOG. Sylvie* -- Sylvie LaPerriere NANOG Chair - www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From mohta at necom830.hpcl.titech.ac.jp Tue Jun 12 23:23:35 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Jun 2012 13:23:35 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> Message-ID: <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: >> Any multicast capable link is broadcast capable. > > BZZT! but thank you for playing. > > Many NBMA topologies support multicast. When you specify a "link" as a small subset of NBMA, it is broadcast capable, as was demonstrated by history of CLIP. If you want to have a large (as large as broadcast is not practical) "link" in NBMA, multicast control messages badly implode. >>> So leveraging broadcast is why just about every implementation does a >>> gratuitous ARP-and-wait multiple times, >> Not at all. IPv4 over something does not have to be ARP. > IPv4 over anything requires some form of L2 address resolution in any case > where L2 addresses must be discovered. For a mobile link around a base station, during link set up, the base station and mobile hosts know MAC addresses of each other. The base station can (or, must, in case of hidden terminals) relay packets between mobile hosts attacked to it. There is no ARP nor ARP-and-wait necessary. >> IPv6 is broken eventually requiring all link use ND, even >> though ND was designed for stational hosts with only Ethernet, >> PPP and ATM (with a lot of misunderstanding) in mind. > Not really. I know it happening within WG discussions. > End-to-end is significantly more broken in IPv4 because of > the need for NAT than it is in IPv6. More? So, even you think IPv6 is more or less broken. > IIRC, you were the one promoting even more borked forms > of NAT to try and compensate for this. I just need a UPnP capable NAT to restore the end to end transparency. > IPv6 is quite a bit better than IPv4 in many ways. It could be better still, but, it is definitely superior > to current IPv4 implementations and vastly superior to the IPv4 implementations that existed when > IPv6 was designed. That is a commonly heard propaganda. However, these days, few believe it. Actually in this thread, your statement is proven to be untrue w.r.t. amount of noises on link bandwidth in large links. Masataka Ohta From davehart at gmail.com Tue Jun 12 23:50:30 2012 From: davehart at gmail.com (Dave Hart) Date: Wed, 13 Jun 2012 04:50:30 +0000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Jun 13, 2012 at 4:23 AM, Masataka Ohta wrote: > I just need a UPnP capable NAT to restore the end to end > transparency. You're not restoring transparency, you're restoring communication after stateful reconfiguration of the network for each service. It is not transparent when you have to negotiate an inbound path for each service. Even for apps that work today through local NATs, the future is dim. Increasing use of carrier NAT will force apps to additionally try Port Control Protocol to overcome evolving IPv4 brokenness. UPnP is inadequate for carrier NAT due to its model assuming the NAT trusts its clients. When TCP headers are being rewritten, it's a strong hint that transparency has been lost, even if some communication remains possible. Cheers, Dave Hart From mohta at necom830.hpcl.titech.ac.jp Wed Jun 13 00:47:35 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Jun 2012 14:47:35 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> Message-ID: <4FD82977.20904@necom830.hpcl.titech.ac.jp> Dave Hart wrote: > It is > not transparent when you have to negotiate an inbound path for each > service. I mean, for applications, global address and global port numbers are visible. > UPnP > is inadequate for carrier NAT due to its model assuming the NAT trusts > its clients. UPnP gateway configured with purely static port mapping needs no security. Assuming shared global address of 131.112.32.132, TCP/UDP port 100 to 199 may be forwarded to port 100 to 199 of 192.168.1.1, port 200 to 299 be forwarded to port 200 to 299 of 192.168.1.2, ... > When TCP headers are being rewritten, it's a strong hint that > transparency has been lost, even if some communication remains > possible. UPnP provides information for clients to restore IP and TCP headers from local ones back to global ones, which is visible to applications. See the following protocol stack. UPnP capable NAT GW Client +---------+ | public | | appli- | | cation | information +---------+ +------+ for reverse translation | public | | UPnP |-------------------------->|transport| +---------+---------+ +---------+ | public | private | | private | |transport|transport| |transport| +---------+---------+ +---------+ +---------+ | public | private | | private | | private | | IP | IP | | IP | | IP | +---------+-----------------------+-----------------------+ | privatte datalink | private datalink | +-----------------------+-----------------------+ Masataka Ohta From fernando at gont.com.ar Wed Jun 13 01:52:46 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 13 Jun 2012 03:52:46 -0300 Subject: Article: IPv6 host scanning attacks Message-ID: <4FD838BE.6050705@gont.com.ar> Folks, TechTarget has published an article I've authored for them, entitled "Analysis: Vast IPv6 address space actually enables IPv6 attacks". The aforementioned article is available at: (FWIW, it's a human-readable version of the IETF Internet-Draft I published a month ago or so about IPv6 host scanning (see: )) You can get "news" about this sort of stuff by following @SI6Networks on Twitter. Cheers, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rsk at gsp.org Wed Jun 13 06:55:37 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 13 Jun 2012 07:55:37 -0400 Subject: EBAY and AMAZON In-Reply-To: <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> Message-ID: <20120613115537.GA14599@gsp.org> On Tue, Jun 12, 2012 at 11:44:44AM +0000, Jamie Bowden wrote: > While MS may be a favorite whipping boy, let's not pretend that if the > dominant OS were Apple or some flavor of *nix, things would be any better. I've heard this argument many times, and I reject it this time as I have before. If popularity were the measure of relative OS security, then we would expect to see infection rates proportional to deployment rates: thus if operating systems A, B and C respectively accounted for 85%, 10%, and 5% of deployments, we should see those numbers reflected in infection rates. But we don't. For example, passive OS fingerprinting of about a decade's worth of spam-spewing botnets indicates that they are running Windows to at least six 9's, quite possibly more -- which is a markedly higher fraction than we would expect if this hypotheis were true. Windows is not attacked because it's the most popular. Windows is attacked because it's the weakest. (And yes, if it instantly disappeared -- oh happy day! -- the next-most-weakest would take its place, but at least we would have incrementally improved the state of security.) ---rsk From astrodog at gmx.com Wed Jun 13 07:17:49 2012 From: astrodog at gmx.com (Astro Dog) Date: Wed, 13 Jun 2012 08:17:49 -0400 Subject: EBAY and AMAZON Message-ID: <20120613121749.227060@gmx.com> (Sorry for the top post. Mail client is being obnoxious.) Why? The prevalence of malware for a given OS is going to, generally, be a matter of most return for least work. If you're writing malware to steal credit card numbers, say, you're much better served writing it for Windows than you are OSX or Linux, even if it were slightly more difficult to do, because that will get you the largest number of card numbers, simply because more people use Windows. It's generally safe to assume that malware writers want to target as many machines as possible, thus they will focus on Windows, reg ardless of the relative ease or difficulty of the other platforms. There is no reason to believe that the platform distribution of malware would have a linear relationship with general usage rates or ease of exploitation, given the motivations and methods involved. --- Harrison ----- Original Message ----- From: Rich Kulawiec Sent: 06/13/12 06:55 AM To: nanog at nanog.org Subject: Re: EBAY and AMAZON On Tue, Jun 12, 2012 at 11:44:44AM +0000, Jamie Bowden wrote: > While MS may be a favorite whipping boy, let's not pretend that if the > dominant OS were Apple or some flavor of *nix, things would be any better. I've heard this argument many times, and I reject it this time as I have before. If popularity were the measure of relative OS security, then we would expect to see infection rates proportional to deployment rates: thus if operating systems A, B and C respectively accounted for 85%, 10%, and 5% of deployments, we should see those numbers reflected in infection rates. From asullivan at dyn.com Wed Jun 13 07:33:22 2012 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 13 Jun 2012 08:33:22 -0400 Subject: vulnerability and popularity (was: EBAY and AMAZON) In-Reply-To: <20120613115537.GA14599@gsp.org> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> <20120613115537.GA14599@gsp.org> Message-ID: <20120613123322.GC26088@mail.yitter.info> On Wed, Jun 13, 2012 at 07:55:37AM -0400, Rich Kulawiec wrote: > If popularity were the measure of relative OS security, then we would > expect to see infection rates proportional to deployment rates I don't buy that premise, or at least not without reservation. The OS market happens to be a superstar economy. On desktops and laptops, which still happen to be the majority of devices, the overwhelming winner is Windows. Therefore, if you are going to invest in any product for which you want ubiquitous deployment, Windows is the first platform you aim for. You only aim for the others if you're chasing a niche. There is no reason whatever to chase a niche market if your goal is spewing spam, collecting credit cards, or whatever. Perhaps fortunately, we're about to have an empirical trial of these different possibilities. If the above analysis is correct, then we should expect malware targetting iOS and Android in about equal proportions as those sorts of devices displace laptops and desktops as the majority (though there will be some bias and therefore lag in favour of Windows just because of the fact that people already have tools and techniques built around Windows). If you're right that the primary issue is the fundamental security of the target, then perhaps we will not see that pattern emerge. Best, A -- Andrew Sullivan Dyn Labs asullivan at dyn.com From tdurack at gmail.com Wed Jun 13 07:38:45 2012 From: tdurack at gmail.com (Tim Durack) Date: Wed, 13 Jun 2012 08:38:45 -0400 Subject: XO/DTAG Contact? Message-ID: Looking for a technical contact within XO and/or DTAG, preferably one who can interpret a traceroute accurately :-) Please hit me up offline. Thanks, -- Tim:> From aledm at qix.co.uk Wed Jun 13 07:44:54 2012 From: aledm at qix.co.uk (Aled Morris) Date: Wed, 13 Jun 2012 13:44:54 +0100 Subject: vulnerability and popularity (was: EBAY and AMAZON) In-Reply-To: <20120613123322.GC26088@mail.yitter.info> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> <20120613115537.GA14599@gsp.org> <20120613123322.GC26088@mail.yitter.info> Message-ID: On 13 June 2012 13:33, Andrew Sullivan wrote: > On Wed, Jun 13, 2012 at 07:55:37AM -0400, Rich Kulawiec wrote: > > > If popularity were the measure of relative OS security, then we would > > expect to see infection rates proportional to deployment rates > > I don't buy that premise, or at least not without reservation. The OS > market happens to be a superstar economy. On desktops and laptops, > which still happen to be the majority of devices, the overwhelming > winner is Windows. Therefore, if you are going to invest in any > product for which you want ubiquitous deployment, Windows is the first > platform you aim for. You only aim for the others if you're chasing a > niche. > I note also that many so-called operating system vulnerabilities are actually flaws in third-party subsystems like Flash or Java. Unix has traditionally had a better isolation model than Windows and so exploits via these attack vectors would be able to infiltrate the Windows core operating system whereas on Linux or OS-X platforms, the attacks might technically be more limited in their impact - not that this would be much consolation to the end user. Aled From rsk at gsp.org Wed Jun 13 07:47:19 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 13 Jun 2012 08:47:19 -0400 Subject: Heads-up: spammer Scott Whittle/iptechlabs.com/iptechnologylabs.com hitting addresses harvested from NANOG list Message-ID: <20120613124719.GA25761@gsp.org> Spammer Scott Whittle has harvested not only email addresses from the NANOG list archives, but also Message-IDs, and is busily trying to abuse the hell out of them. I've seen 6 (edit: 11) (edit: 14) copies so far this morning, and no doubt more are on the way. He identifies himself thusly: IP Technology Labs Network Communications Simplified Scott Whittle | President | T: +1 301 570 6611 x601 | M/SMS: +1 301 339 3237 | E: scott at IpTechnologyLabs.com | W: http://iptechnologylabs.com Although the spam itself carries a return address of Return-Path: So blocking on the latter should suffice, at least for this round. ---rsk p.s. Pro tip: proofread your spam content before sending: "I am looking contact your Product Manager/Sales Manager regarding possible distribution of our USA made and designed Plug-and-Play VPN products. We are the are a channel friendly company, can offer account protection, and ensure your margins." From astrodog at gmx.com Wed Jun 13 08:05:09 2012 From: astrodog at gmx.com (Astro Dog) Date: Wed, 13 Jun 2012 09:05:09 -0400 Subject: vulnerability and popularity (was: EBAY and AMAZON) Message-ID: <20120613130509.227060@gmx.com> ----- Original Message ----- From: Andrew Sullivan Sent: 06/13/12 07:33 AM To: nanog at nanog.org Subject: vulnerability and popularity (was: EBAY and AMAZON) On Wed, Jun 13, 2012 at 07:55:37AM -0400, Rich Kulawiec wrote: > If popularity were the measure of relative OS security, then we would > expect to see infection rates proportional to deployment rates I don't buy that premise, or at least not without reservation. The OS market happens to be a superstar economy. On desktops and laptops, which still happen to be the majority of devices, the overwhelming winner is Windows. Therefore, if you are going to invest in any product for which you want ubiquitous deployment, Windows is the first platform you aim for. You only aim for the others if you're chasing a niche. There is no reason whatever to chase a niche market if your goal is spewing spam, collecting credit cards, or whatever. Perhaps fortunately, we're about to have an empirical trial of these different possibilities. If the above analysis is correct, then we should expect malware targetting iOS and Android in about equal proportions as those sorts of devices displace laptops and desktops as the majority (though there will be some bias and therefore lag in favour of Windows just because of the fact that people already have tools and techniques built around Windows). If you're right that the primary issue is the fundamental security of the target, then perhaps we will not see that pattern emerge. Best, A -- Andrew Sullivan Dyn Labs asullivan at dyn.com I'm not sure the iOS/Android situation provides a great emperical test, either. Where a duality exists... (or something aproximating one), the security situation may play a massive role in determining what platforms malware authors target, whereas when one platform has a massive majority, the security environment likely plays a very small role in what platforms will be targeted. An added issue is the difference in how people use mobile devices versus their "stuck to desk" counterparts. They may have less useful information or behave in ways that are easier to exploit when using a mobile device than they would on their PCs. Interestingly, from the persective of a malware author, the user-level isolation provided by the *nix variants may make much less of a difference than one might expect. Presumably, they're interested in either stealing information, or sending spam. Neither one of these activities requires administrative access. Presumably *most* users, on Windows or Linux conduct the majority of their online transactions from a single account. An exploit that gives them control of that user account is just as damaging, in as far as short term stealing your information (or opening network sockets) is concerned, as gaining root or administrative access. Considering that, combined with the fact that it's rarely Windows itself being exploited, but the applications and plugins themselves, it seems more likely that a change in dominant platform would be more likely to result in multi-platform payloads. The basic targets would probably still be the browsers, plugins, etc, which would presumably exist on most/all of the platforms involved. That being said, I've rarely seen a *nix machine trashed by malware or exploits to quite the same degree as Windows hosts. --- Harrison From dougb at dougbarton.us Wed Jun 13 08:17:28 2012 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 13 Jun 2012 06:17:28 -0700 Subject: EBAY and AMAZON In-Reply-To: <20120613115537.GA14599@gsp.org> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> <20120613115537.GA14599@gsp.org> Message-ID: <4FD892E8.2040905@dougbarton.us> On 06/13/2012 04:55 AM, Rich Kulawiec wrote: > But we don't. For example, passive OS fingerprinting of about a decade's > worth of spam-spewing botnets indicates that they are running Windows to > at least six 9's, quite possibly more -- which is a markedly higher > fraction than we would expect if this hypotheis were true. > > Windows is not attacked because it's the most popular. Windows is > attacked because it's the weakest. Mostly right, except that it is really a weighted average of factors including installed base (read, popularity), likely success of the infection, likelihood of the infection being successfully detected by the user, likelihood of the infection being removable, overall utility of the system to the spammer once it is infected ... I'm probably forgetting a few things. But your basic point, it's not just about the popularity, is sound. The cautionary tale is that merely improving one of those factors isn't going to get the job done. Doug From owen at delong.com Wed Jun 13 08:34:49 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Jun 2012 06:34:49 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FD82977.20904@necom830.hpcl.titech.ac.jp> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> <4FD82977.20904@necom830.hpcl.titech.ac.jp> Message-ID: <3AFDBCF3-F34F-48EE-A714-ECF419EB3C9A@delong.com> On Jun 12, 2012, at 10:47 PM, Masataka Ohta wrote: > Dave Hart wrote: > >> It is >> not transparent when you have to negotiate an inbound path for each >> service. > > I mean, for applications, global address and global port > numbers are visible. > Showing that you don't actually understand what everyone else means when they say "end-to-end". >> UPnP >> is inadequate for carrier NAT due to its model assuming the NAT trusts >> its clients. > > UPnP gateway configured with purely static port mapping needs > no security. > > Assuming shared global address of 131.112.32.132, TCP/UDP port > 100 to 199 may be forwarded to port 100 to 199 of 192.168.1.1, > port 200 to 299 be forwarded to port 200 to 299 of 192.168.1.2, > ... > No carrier is going to implement that for obvious reasons. Besides, that's not transparent end-to-end, that's predictably opaque end-to-end. >> When TCP headers are being rewritten, it's a strong hint that >> transparency has been lost, even if some communication remains >> possible. > > UPnP provides information for clients to restore IP and TCP > headers from local ones back to global ones, which is visible > to applications. > But it doesn't work across multiple layers of NAT. > See the following protocol stack. > > UPnP capable NAT GW Client > +---------+ > | public | > | appli- | > | cation | > information +---------+ > +------+ for reverse translation | public | > | UPnP |-------------------------->|transport| > +---------+---------+ +---------+ > | public | private | | private | > |transport|transport| |transport| > +---------+---------+ +---------+ +---------+ > | public | private | | private | | private | > | IP | IP | | IP | | IP | > +---------+-----------------------+-----------------------+ > | privatte datalink | private datalink | > +-----------------------+-----------------------+ Now, redraw the diagram for the real world scenario: host <-> UPnP NAT <-> Carrier NAT <-> Internet <-> Carrier NAT <-> UPnP NAT <-> host Tell me again how the application signaling from UPnP survives through all that and comes up with correct answers? Yeah, thought so. Owen From owen at delong.com Wed Jun 13 08:42:12 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Jun 2012 06:42:12 -0700 Subject: vulnerability and popularity (was: EBAY and AMAZON) In-Reply-To: <20120613123322.GC26088@mail.yitter.info> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> <20120613115537.GA14599@gsp.org> <20120613123322.GC26088@mail.yitter.info> Message-ID: <34C85F7F-9466-400D-B293-912AA1C59FC4@delong.com> On Jun 13, 2012, at 5:33 AM, Andrew Sullivan wrote: > On Wed, Jun 13, 2012 at 07:55:37AM -0400, Rich Kulawiec wrote: > >> If popularity were the measure of relative OS security, then we would >> expect to see infection rates proportional to deployment rates > > I don't buy that premise, or at least not without reservation. The OS > market happens to be a superstar economy. On desktops and laptops, > which still happen to be the majority of devices, the overwhelming > winner is Windows. Therefore, if you are going to invest in any > product for which you want ubiquitous deployment, Windows is the first > platform you aim for. You only aim for the others if you're chasing a > niche. > > There is no reason whatever to chase a niche market if your goal is > spewing spam, collecting credit cards, or whatever. > > Perhaps fortunately, we're about to have an empirical trial of these > different possibilities. If the above analysis is correct, then we > should expect malware targetting iOS and Android in about equal > proportions as those sorts of devices displace laptops and desktops as > the majority (though there will be some bias and therefore lag in > favour of Windows just because of the fact that people already have > tools and techniques built around Windows). If you're right that the > primary issue is the fundamental security of the target, then perhaps > we will not see that pattern emerge. > If that were true, the webserver attacks would be aimed at windows while the vast majority of them are aimed at IIS. Attackers aim for the softest targets with sufficient numbers to get what they want. When it comes to target hardness, Micr0$0ft builds porridge in a world of thick sludgy oatmeal. Owen From fernando at gont.com.ar Wed Jun 13 09:02:13 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 13 Jun 2012 11:02:13 -0300 Subject: Heads up: IETF 6man poll for adoption of RA-Guard/firewalling/monitoring-related I-Ds Message-ID: <4FD89D65.8080007@gont.com.ar> Folks, Just wanted to send a heads up regarding two IETF 6man wg polls that have just been started for adoption of these documents: * draft-gont-6man-oversized-header-chain-02 (Security and Interoperability Implications of Oversized IPv6 Header Chains) * draft-gont-6man-nd-extension-headers-03 (Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery) draft-gont-6man-oversized-header-chain-02 requires that when packets are fragmented, the first fragment must contain the entire IPv6 header chain. This is important for a number of reasons: it allows for stateless filtering (both at firewalls and at RA-Guard-like devices), prevents stateless translators from breaking, etc. The poll for this document is available at: draft-gont-6man-nd-extension-headers-03 forbids the use of fragmentation with Neighbor Discovery. This essentially enables Neighbor Discovery monitoring in IPv6, thus providing feature parity with IPv4 (think about arpwatch and the like) -- not to mention that it obviously mitigates fragmentation-based attacks against Neighbor Discovery and SEND. The poll for this document is available at: IMO, these two I-Ds propose small spec updates which could result in concrete operational and security benefits. Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From randy at psg.com Wed Jun 13 09:12:04 2012 From: randy at psg.com (Randy Bush) Date: Wed, 13 Jun 2012 23:12:04 +0900 Subject: Heads-up: spammer Scott Whittle/iptechlabs.com/iptechnologylabs.com hitting addresses harvested from NANOG list In-Reply-To: <20120613124719.GA25761@gsp.org> References: <20120613124719.GA25761@gsp.org> Message-ID: > Spammer Scott Whittle has harvested not only email addresses from the > NANOG list archives, but also Message-IDs and draft-foo at ietf.org addresses randy From streiner at cluebyfour.org Wed Jun 13 10:43:28 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 13 Jun 2012 11:43:28 -0400 (EDT) Subject: Whither Cometh BCP38? In-Reply-To: References: <6124019.8862.1339427602063.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, 11 Jun 2012, Mikael Abrahamsson wrote: > This is for IPv4, for IPv6 we're back 10 years again with very lacking > support. Amen to that. At first glance, building IPv6 ACLs/firewall rules/filters isn't much different from building IPv4 equivalents in many environments, but there are lots of vendor-specific 'gotcha's out there that make for more work to get to a point of sanity with IPv6. To be fair, at the application level, things are still pretty similar - the sun still rises in the east, HTTP still normally works on well-known destination port tcp/80, etc. Examples: 1. Junos firewall filters can be bypassed in some cases with appropriately crafted extension headers, depending on how the filter is built. In the case of border ingress/egress filters, which are often written in a "deny specific types of traffic, but permit everything else" fashion, re-working the order of the filter elements is often not practical. 2. Cisco's handling of ICMPv6 on the ASA platform still seems a bit 'green' to me. Hopefully the kinks will get worked out as everyone (vendors included) get more operational experience with IPv6. I'm basing this on my efforts to develop a set of basic firewall rules for our IPv6 deployment templates, with the goal being to allow necessary ICMPv6 traffic through, while limiting the exposure of the hosts behind the firewall. A lot of this has been based on RFC 4890 as a starting point. 3. Some devices leak link-local traffic beyond the link, in violation of RFC 4192, sec 2.5.6. This can have implications for filter/acl/ruleset design, since the assumption that devices will always 'do the right thing' with link-local traffic is not valid. jms From patrick at ianai.net Wed Jun 13 10:56:56 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 13 Jun 2012 11:56:56 -0400 Subject: Heads-up: spammer Scott Whittle/iptechlabs.com/iptechnologylabs.com hitting addresses harvested from NANOG list In-Reply-To: References: <20120613124719.GA25761@gsp.org> Message-ID: <47ADC0F9-47A3-43C6-B4C8-4BA16BB568A1@ianai.net> On Jun 13, 2012, at 10:12 , Randy Bush wrote: >> Spammer Scott Whittle has harvested not only email addresses from the >> NANOG list archives, but also Message-IDs > > and draft-foo at ietf.org addresses Is his upstream, or the upstream of his hosting provider, on NANOG or IETF? Or is he using a botnet? (I got a couple dozen, but deleted them.) -- TTFN, patrick From valdis.kletnieks at vt.edu Wed Jun 13 11:14:30 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 13 Jun 2012 12:14:30 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: Your message of "Wed, 13 Jun 2012 14:47:35 +0900." <4FD82977.20904@necom830.hpcl.titech.ac.jp> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> <4FD82977.20904@necom830.hpcl.titech.ac.jp> Message-ID: <4766.1339604070@turing-police.cc.vt.edu> On Wed, 13 Jun 2012 14:47:35 +0900, Masataka Ohta said: > Dave Hart wrote: > > is inadequate for carrier NAT due to its model assuming the NAT trusts > > its clients. > > UPnP gateway configured with purely static port mapping needs > no security. > > Assuming shared global address of 131.112.32.132, TCP/UDP port > 100 to 199 may be forwarded to port 100 to 199 of 192.168.1.1, > port 200 to 299 be forwarded to port 200 to 299 of 192.168.1.2, And you tell the rest of the world that customer A's SMTP port is on 125, and B's is on 225, and Z's is up at 2097, how? (HInt - we haven't solved that problem for NAT yet, it's one of the big reasons that NAT breaks stuff) (Totally overlooking the debugging issues that arise when a customer tries to run a combination of applications that in aggregate have 101 ports open..) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From davehart at gmail.com Wed Jun 13 12:28:47 2012 From: davehart at gmail.com (Dave Hart) Date: Wed, 13 Jun 2012 17:28:47 +0000 Subject: Article: IPv6 host scanning attacks In-Reply-To: <4FD838BE.6050705@gont.com.ar> References: <4FD838BE.6050705@gont.com.ar> Message-ID: On Wed, Jun 13, 2012 at 6:52 AM, Fernando Gont wrote: > Folks, > > TechTarget has published an article I've authored for them, entitled > "Analysis: Vast IPv6 address space actually enables IPv6 attacks". > > The aforementioned article is available at: > "published" and "available" are misleading at best. The article is teased with a sentence and a half, truncated by a demand for an email address with tiny legalese mentioning a privacy policy and terms of use that undoubtedly would take far longer to read than Gont's valuable content. > (FWIW, it's a human-readable version ?of the IETF Internet-Draft I > published a month ago or so about IPv6 host scanning (see: > )) I guess I'll take a look at this to see what you're smoking. > You can get "news" about this sort of stuff by following @SI6Networks on > Twitter. "news" in quotes is appropriate given it's really eyeball harvesting for marketing purposes. Cheers, Dave Hart From cboyd at gizmopartners.com Wed Jun 13 12:30:09 2012 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 13 Jun 2012 12:30:09 -0500 Subject: Heads-up: spammer Scott Whittle/iptechlabs.com/iptechnologylabs.com hitting addresses harvested from NANOG list In-Reply-To: <47ADC0F9-47A3-43C6-B4C8-4BA16BB568A1@ianai.net> References: <20120613124719.GA25761@gsp.org> <47ADC0F9-47A3-43C6-B4C8-4BA16BB568A1@ianai.net> Message-ID: On Jun 13, 2012, at 10:56 AM, Patrick W. Gilmore wrote: > Is his upstream, or the upstream of his hosting provider, on NANOG or IETF? My sample came via GoDaddy: Return-Path: Received: from p3plsmtps2ded01-02.prod.phx3.secureserver.net (p3plsmtps2ded01.prod.phx3.secureserver.net [208.109.80.58]) by gandalf.gizmopartners.com (8.14.3/8.14.3) with SMTP id q5D5ERPD029411 for ; Wed, 13 Jun 2012 00:14:58 -0500 (CDT) (envelope-from scott.whittle at iptechlabs.com) --Chris From bzs at world.std.com Wed Jun 13 12:36:09 2012 From: bzs at world.std.com (Barry Shein) Date: Wed, 13 Jun 2012 13:36:09 -0400 Subject: EBAY and AMAZON In-Reply-To: <20120612163329.GY42080@manor.msen.com> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> <20120612163329.GY42080@manor.msen.com> Message-ID: <20440.53129.640938.891199@world.std.com> On June 12, 2012 at 12:33 wayne at staff.msen.com (Michael R. Wayne) wrote: > On Tue, Jun 12, 2012 at 11:44:44AM +0000, Jamie Bowden wrote: > > > > While MS may be a favorite whipping boy, let's not pretend that if the dominant OS were Apple or some flavor of *nix, things would be any better. That assumes the security architectures of all these OS's is similar which is simply not true. There have been security flaws in Microsoft OS's which led to the spread of malware which would have been almost impossible on any unix-like operating system. One of the biggest problems was creating the first and often only user on MS systems with administrator privileges allowing any piece of software they ran to do anything on the system. Even Microsoft recognized this to be a huge flaw beginning with Vista, no need to be more catholic than the pope. The problem at this point is that even with improvements in newer Windows systems there are probably on the order of a billion systems out there, attached to the net, and still running these deeply flawed OS's which can be taken over by just clicking on the wrong mail message. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From fernando at gont.com.ar Wed Jun 13 12:42:41 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 13 Jun 2012 14:42:41 -0300 Subject: Article: IPv6 host scanning attacks In-Reply-To: References: <4FD838BE.6050705@gont.com.ar> Message-ID: <4FD8D111.4010203@gont.com.ar> On 06/13/2012 02:28 PM, Dave Hart wrote: >> The aforementioned article is available at: >> > >> > "published" and "available" are misleading at best. It is not. Just scroll down the page, and you'll find the whole article. -- it was easy to talk crap than to do that, right? > The article is > teased with a sentence and a half, truncated by a demand for an > email address with tiny legalese mentioning a privacy policy and > terms of use that undoubtedly would take far longer to read than > Gont's valuable content. You don't need to read that to scroll the page down past it. >> (FWIW, it's a human-readable version of the IETF Internet-Draft I >> published a month ago or so about IPv6 host scanning (see: >> )) > > I guess I'll take a look at this to see what you're smoking. I find it amazing the number of people that will talk crap when one publishes something when compared to the number of people that provides technical comments or criticism (even if it's "you're completely wrong because of this and that). Read the article. Have something to add or complain about the technical contents? -- Do it. But otherwise try to keep a good signal/noise ratio, please. >> You can get "news" about this sort of stuff by following >> @SI6Networks on Twitter. > > "news" in quotes is appropriate given it's really eyeball harvesting > for marketing purposes. Please do the math regarding the number of posts/tweets announcing publications to the number of posts/tweets doing marketing (probably just those about trainings). Then comment. Cheers, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From pgp+nanog at psu.edu Wed Jun 13 13:05:36 2012 From: pgp+nanog at psu.edu (Phil Pishioneri) Date: Wed, 13 Jun 2012 14:05:36 -0400 Subject: LinkedIn password database compromised In-Reply-To: <20120608232215.GB20888@luke.xen.prgmr.com> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> Message-ID: <4FD8D670.8010800@psu.edu> On 6/8/12 7:22 PM, Luke S. Crawford wrote: > I haven't found any way that is as simple and as portable as using > ssh that works in a web browser. The Enigform Firefox Add-on (plus mod_openpgp on Apache httpd) seems similar: http://wordpress.org/extend/plugins/wp-enigform-authentication/ > Enigform is a Firefox Add-On which uses OpenPGP to digitally sign > outgoing HTTP requests and Securely login to remote web sites, as long > as the remote web server is Enigform-compliant. -Phil From jcdill.lists at gmail.com Wed Jun 13 13:08:25 2012 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 13 Jun 2012 11:08:25 -0700 Subject: EBAY and AMAZON In-Reply-To: <20120613121749.227060@gmx.com> References: <20120613121749.227060@gmx.com> Message-ID: <4FD8D719.1070704@gmail.com> On 13/06/12 5:17 AM, Astro Dog wrote: > (Sorry for the top post. Mail client is being obnoxious.) > > > Why? The prevalence of malware for a given OS is going to, generally, be a matter of most return for least work. > If you're writing malware to steal credit card numbers, say, you're much better served writing it for Windows than you are OSX or Linux, Really? I'm positive that there are far more credit card numbers stored on various flavors of *nix systems (web servers) than windows systems. And you only have to crack one to get a plethora of credit card numbers. If both flavors were equally easy to exploit, according to your theory above we would see more exploits on the *nix servers. Yet server-side exploits are seen on Windows servers far more often than *nix servers, despite the fact that more web pages are served by *nix servers than Windows servers. I'm really surprised to see this "Windows is more popular, that's why it's exploited more often" misinformation being spewed on a technical list like NANOG. I thought people here had more clue. jc From patrick at ianai.net Wed Jun 13 13:15:36 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 13 Jun 2012 14:15:36 -0400 Subject: Heads-up: spammer Scott Whittle/iptechlabs.com/iptechnologylabs.com hitting addresses harvested from NANOG list In-Reply-To: References: <20120613124719.GA25761@gsp.org> <47ADC0F9-47A3-43C6-B4C8-4BA16BB568A1@ianai.net> Message-ID: <5B998EA2-CD3E-4F35-AC0C-A7E8ABF31A1D@ianai.net> On Jun 13, 2012, at 13:30 , Chris Boyd wrote: > On Jun 13, 2012, at 10:56 AM, Patrick W. Gilmore wrote: >> Is his upstream, or the upstream of his hosting provider, on NANOG or IETF? > > My sample came via GoDaddy: GoDaddy is not blind to these problems. Has anyone asked them to look into this? -- TTFN, patrick From davehart at gmail.com Wed Jun 13 13:20:16 2012 From: davehart at gmail.com (Dave Hart) Date: Wed, 13 Jun 2012 18:20:16 +0000 Subject: EBAY and AMAZON In-Reply-To: <20440.53129.640938.891199@world.std.com> References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> <20120612163329.GY42080@manor.msen.com> <20440.53129.640938.891199@world.std.com> Message-ID: On Wed, Jun 13, 2012 at 5:36 PM, Barry Shein wrote: > ?> On Tue, Jun 12, 2012 at 11:44:44AM +0000, Jamie Bowden wrote: > ?> > While MS may be a favorite whipping boy, let's not pretend that if the dominant OS were Apple or some flavor of *nix, things would be any better. > > That assumes the security architectures of all these OS's is similar > which is simply not true. You're right. Windows has an architecture that's easier to secure, with auditing, ACLs, and capabilities ("privileges") part of every NT-derived release. This means everything interesting doesn't have to be "root", for which there is no equivalent in Windows -- no magic user which bypasses access checks. > There have been security flaws in Microsoft OS's which led to the > spread of malware which would have been almost impossible on any > unix-like operating system. > > One of the biggest problems was creating the first and often only user > on MS systems with administrator privileges allowing any piece of > software they ran to do anything on the system. Is it not common to install unix-like operating systems similarly, with setup completed after a root password is chosen but before any human-named accounts are created? I'm not impartial, I once worked for the architect of NT's security. Discount my opinion appropriately. My opinion is 20 years of hardening have likely made Windows a tougher nut to crack than other mass-market OSes. It could hardly be otherwise -- there have been large piles of money fueling a free market in 0-day Windows exploits for many years now. Windows has grown over that time, of course, and more code means more holes, but other OSes have been growing as well. Meanwhile, the most security-sensitive parts of Windows have slower to change and grow. Yes, Windows evolved from an essentially security-ignorant single-user environment. Unix evolved from an essentially security-ignorant multiuser environment. The baseline of unix security with magic root, setuid apps, and primitive access permissions are nonetheless inferior to the baseline of NT-derived Windows. There are varying degrees of ACL support in some unix-like systems, and wide support for capabilities that allow services to start as a non-root user, or "drop root" after starting as such. There is not, across the POSIX world, a strong security infrastructure that can be relied on to be universal. On the other hand, with the death in the wild of the Windows 9x/ME house of cards, today Windows does provide that universal security infrastructure. Unix systems can be secured. So can Windows systems. No OS can simultaneously provide lazy users with power tools and completely protect those users from self-injury. Security costs overhead for too-often no perceived benefit until someone gets hurt. When you are forced to deal with it, it's nice to have the best in class infrastructure under your feet. Cheers, Dave Hart From davehart at gmail.com Wed Jun 13 13:39:20 2012 From: davehart at gmail.com (Dave Hart) Date: Wed, 13 Jun 2012 18:39:20 +0000 Subject: Article: IPv6 host scanning attacks In-Reply-To: <4FD8D111.4010203@gont.com.ar> References: <4FD838BE.6050705@gont.com.ar> <4FD8D111.4010203@gont.com.ar> Message-ID: On Wed, Jun 13, 2012 at 5:42 PM, Fernando Gont wrote: > On 06/13/2012 02:28 PM, Dave Hart wrote: > >>> The aforementioned article is available at: >>> >> >>> >> "published" and "available" are misleading at best. > > It is not. Just scroll down the page, and you'll find the whole article. > -- it was easy to talk crap than to do that, right? Yes, I'm an idiot for believing what I read on that site: "Requires Free Membership to View" Of course I should have expected that means "scroll past me and the page of whitespace to view." >>> (FWIW, it's a human-readable version of the IETF Internet-Draft I >>> published a month ago or so about IPv6 host scanning (see: >>> )) >> >> I guess I'll take a look at this to see what you're smoking. > > I find it amazing the number of people that will talk crap when one > publishes something when compared to the number of people that provides > technical comments or criticism (even if it's "you're completely wrong > because of this and that). The draft and the article raise valid points about the predictability of widely-used MAC-derived IIDs, but it does not in any way justify the headline "Analysis: Vast IPv6 address space actually enables IPv6 attacks." Whomever wrote that should share their stash. Cheers, Dave Hart From valdis.kletnieks at vt.edu Wed Jun 13 13:42:20 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 13 Jun 2012 14:42:20 -0400 Subject: EBAY and AMAZON In-Reply-To: Your message of "Wed, 13 Jun 2012 11:08:25 -0700." <4FD8D719.1070704@gmail.com> References: <20120613121749.227060@gmx.com> <4FD8D719.1070704@gmail.com> Message-ID: <12654.1339612940@turing-police.cc.vt.edu> On Wed, 13 Jun 2012 11:08:25 -0700, JC Dill said: > If both flavors were equally easy to exploit, according to your theory > above we would see more exploits on the *nix servers. Yet server-side > exploits are seen on Windows servers far more often than *nix servers, > despite the fact that more web pages are served by *nix servers than > Windows servers. I suspect the *real* issue is that for really large systems, it's not so much "exploits" as "one-off customized attacks". The chances of pwning Bank of America with an off-the-shelf attack are pretty low - but finding a blind SQL injection and leveraging it are a bit higher. And given all the 'XYZ got pwned' news stories, I suspect that in fact the *nix boxes *are* being attacked - just not with COTS attack tools. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bzs at world.std.com Wed Jun 13 14:18:04 2012 From: bzs at world.std.com (Barry Shein) Date: Wed, 13 Jun 2012 15:18:04 -0400 Subject: EBAY and AMAZON In-Reply-To: References: <20120612033136.9060C80003B@ip-64-139-1-69.sjc.megapath.net> <5445871dd2b6ff408453cc68a0290f44@mail.dessus.com> <465966A5F5B867419F604CD3E604C1E505FB7543@pra-ess-mail.pra.ray.com> <20120612163329.GY42080@manor.msen.com> <20440.53129.640938.891199@world.std.com> Message-ID: <20440.59244.999216.351211@world.std.com> On June 13, 2012 at 18:20 davehart at gmail.com (Dave Hart) wrote: > On Wed, Jun 13, 2012 at 5:36 PM, Barry Shein wrote: > > ?> On Tue, Jun 12, 2012 at 11:44:44AM +0000, Jamie Bowden wrote: > > ?> > While MS may be a favorite whipping boy, let's not pretend that if the dominant OS were Apple or some flavor of *nix, things would be any better. > > > > That assumes the security architectures of all these OS's is similar > > which is simply not true. > > You're right. Windows has an architecture that's easier to secure, It didn't occur to me that the original comment was referring to professionally secured sites only. I think one of the huge complaints about Windows systems is their appearance by the tens of millions in botnets which tend to be a problem with non-professionally run systems. > with auditing, ACLs, and capabilities ("privileges") part of every > NT-derived release. This means everything interesting doesn't have to > be "root", for which there is no equivalent in Windows -- no magic > user which bypasses access checks. > > > There have been security flaws in Microsoft OS's which led to the > > spread of malware which would have been almost impossible on any > > unix-like operating system. > > > > One of the biggest problems was creating the first and often only user > > on MS systems with administrator privileges allowing any piece of > > software they ran to do anything on the system. > > Is it not common to install unix-like operating systems similarly, > with setup completed after a root password is chosen but before any > human-named accounts are created? Apparently not, given the relative absence of un*x (which includes for example MacOS and Linux) systems in being pwned by clicking "open this attachment" in an email message. But the worst from Windows was the decades when they allowed any app to inject code into the kernel typically for graphics speed-up. Which of course could be any code, and that any code could own the system instantly. The rest is talking around the actual, measurable problem of botnets etc. Where do you think all that spam which pounds your mailbox relentlessly comes from? Botted Windows systems. I don't think saying that a professionally secured Windows 8 release candidate is much better than past systems when we're suffering under excuses or even mitigates the situation. The worst is that many of those features which made Windows so insecure were not removed because they provided marketing advantage (e.g., making any user admin, injecting graphics code for app speed-up.) So MS agonized for years about how to deal with this and not cut into their or their favored vendors' profit model while the rest of the net suffered gabillions of dollars in damage. MS, in effect, made many tens of billions on the flaws in their OS's, at the expense of everyone else. (I'm done but I'll leave the rest of the msg...) > I'm not impartial, I once worked for the architect of NT's security. > Discount my opinion appropriately. My opinion is 20 years of > hardening have likely made Windows a tougher nut to crack than other > mass-market OSes. It could hardly be otherwise -- there have been > large piles of money fueling a free market in 0-day Windows exploits > for many years now. Windows has grown over that time, of course, and > more code means more holes, but other OSes have been growing as well. > Meanwhile, the most security-sensitive parts of Windows have slower to > change and grow. > > Yes, Windows evolved from an essentially security-ignorant single-user > environment. Unix evolved from an essentially security-ignorant > multiuser environment. The baseline of unix security with magic root, > setuid apps, and primitive access permissions are nonetheless inferior > to the baseline of NT-derived Windows. There are varying degrees of > ACL support in some unix-like systems, and wide support for > capabilities that allow services to start as a non-root user, or "drop > root" after starting as such. There is not, across the POSIX world, a > strong security infrastructure that can be relied on to be universal. > On the other hand, with the death in the wild of the Windows 9x/ME > house of cards, today Windows does provide that universal security > infrastructure. > > Unix systems can be secured. So can Windows systems. No OS can > simultaneously provide lazy users with power tools and completely > protect those users from self-injury. Security costs overhead for > too-often no perceived benefit until someone gets hurt. When you are > forced to deal with it, it's nice to have the best in class > infrastructure under your feet. > > Cheers, > Dave Hart -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From shortdudey123 at gmail.com Wed Jun 13 14:54:59 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 13 Jun 2012 14:54:59 -0500 Subject: LinkedIn password database compromised In-Reply-To: <4FD8D670.8010800@psu.edu> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> Message-ID: Hi Everyone, I thought that i would share an IEEE article about LinkenIn and eHarmony. http://spectrum.ieee.org/riskfactor/telecom/security/linkedin-and-eharmony-hacked-8-million-passwords-taken/?utm_source=computerwise&utm_medium=email&utm_campaign=061312 -Grant On Wed, Jun 13, 2012 at 1:05 PM, Phil Pishioneri wrote: > On 6/8/12 7:22 PM, Luke S. Crawford wrote: > >> I haven't found any way that is as simple and as portable as using >> ssh that works in a web browser. >> > > The Enigform Firefox Add-on (plus mod_openpgp on Apache httpd) seems > similar: > > http://wordpress.org/extend/**plugins/wp-enigform-**authentication/ > > Enigform is a Firefox Add-On which uses OpenPGP to digitally sign >> outgoing HTTP requests and Securely login to remote web sites, as long >> as the remote web server is Enigform-compliant. >> > > -Phil > > From Curtis.Starnes at granburyisd.org Wed Jun 13 15:22:10 2012 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Wed, 13 Jun 2012 15:22:10 -0500 Subject: Article: IPv6 host scanning attacks In-Reply-To: References: <4FD838BE.6050705@gont.com.ar> Message-ID: It seems I saw that title came through an article somewhere but I have a slight problem with stating that "Vast IPv6 address space actually enables IPv6 attacks". Going from an IPv4 32 bit address space to a IPv6 128 bit address space like you mentioned in the article would be a tedious effort to scan. But you also make the following assumptions: A number of options are available for selecting the Interface ID (the low-order 64 bits of an IPv6 address), including: .Embed the MAC address; .Employ low-byte addresses; .Embed the IPv4 address; .Use a "wordy" address; .Use a privacy or temporary address; .Rely on a transition or coexistence technology. Unfortunately, each of these options reduces the potential search space, making IPv6 host-scanning attacks easier and potentially more successful. That sounds fine and dandy but in reality, Internet facing IPv6 native or dual-stack systems that are installed with any security forethought at all would not embed any of these options with the exception of the last one (transitional or coexistence) only if forced to do so. I agree that some IPv6 addresses are set up to have catchy names, but why set up hundreds or even thousands of IPv6 addresses with IPv6 addresses that you try to remember like we did with IPv4? I will also concede that Microsoft has not helped with issuing multiple IPv6 addresses using "privacy" settings even if a static IPv6 address is set. In general, I just don't agree with your conclusions, and with proper IPv6 firewall rules, the network should still be as secure as the IPv4 systems. Not more insecure just because they run an IPv6 stack. Curtis -----Original Message----- From: Dave Hart [mailto:davehart at gmail.com] Sent: Wednesday, June 13, 2012 12:29 PM To: Fernando Gont Cc: NANOG Subject: Re: Article: IPv6 host scanning attacks On Wed, Jun 13, 2012 at 6:52 AM, Fernando Gont wrote: > Folks, > > TechTarget has published an article I've authored for them, entitled > "Analysis: Vast IPv6 address space actually enables IPv6 attacks". > > The aforementioned article is available at: > pace-actually-enables-IPv6-attacks> "published" and "available" are misleading at best. The article is teased with a sentence and a half, truncated by a demand for an email address with tiny legalese mentioning a privacy policy and terms of use that undoubtedly would take far longer to read than Gont's valuable content. > (FWIW, it's a human-readable version ?of the IETF Internet-Draft I > published a month ago or so about IPv6 host scanning (see: > )) I guess I'll take a look at this to see what you're smoking. > You can get "news" about this sort of stuff by following @SI6Networks > on Twitter. "news" in quotes is appropriate given it's really eyeball harvesting for marketing purposes. Cheers, Dave Hart From shortdudey123 at gmail.com Wed Jun 13 16:39:01 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 13 Jun 2012 16:39:01 -0500 Subject: Flame virus Message-ID: Hi Everyone, I realize this is not directly network related, but i thought i would pass the article along anyways. The authors of the Flame virus have started to destroy its existence. http://spectrum.ieee.org/riskfactor/telecom/security/flame-ordered-to-flame-out/?utm_source=computerwise&utm_medium=email&utm_campaign=061312 -Grant From randy at psg.com Wed Jun 13 17:05:57 2012 From: randy at psg.com (Randy Bush) Date: Thu, 14 Jun 2012 07:05:57 +0900 Subject: very confusing. In-Reply-To: References: Message-ID: NANOG, i strongly desire to restrain this slimeball idiot's trade. please tell me if you have any ideas on how to do so. --- > Be advised that Im following your posts and have your threating > messages to me. If there is an ddos or restraint of trade due to my > ACCIDENTAL email I'll escalate to commerce and FBI. LOL. you are not only a slimeball (who the ietf and nanog admins are scraping out), but an idiot. but do please tell me how i can restrain your trade. would love to discuss your spam with the DoC and FBI. randy From rgolodner at infratection.com Wed Jun 13 17:10:55 2012 From: rgolodner at infratection.com (Richard Golodner) Date: Wed, 13 Jun 2012 17:10:55 -0500 Subject: very confusing. In-Reply-To: References: Message-ID: <1339625455.2015.18.camel@Andromeda> On Thu, 2012-06-14 at 07:05 +0900, > ACCIDENTAL email How can my company get six accidental emails? Not even an idiot sends six emails by mistake. Spammertechnology labs is more like it. From nick at foobar.org Wed Jun 13 17:12:38 2012 From: nick at foobar.org (Nick Hilliard) Date: Wed, 13 Jun 2012 23:12:38 +0100 Subject: very confusing. In-Reply-To: References: Message-ID: <4FD91056.3030206@foobar.org> >> Be advised that Im following your posts and have your threating >> messages to me. If there is an ddos or restraint of trade due to my >> ACCIDENTAL email I'll escalate to commerce and FBI. 1. spam a big pile of network operators 2. threaten legals on aforementioned prospective customers 3. profit!!11!! awesome. Nick From deleskie at gmail.com Wed Jun 13 17:13:07 2012 From: deleskie at gmail.com (jim deleskie) Date: Wed, 13 Jun 2012 19:13:07 -0300 Subject: very confusing. In-Reply-To: <1339625455.2015.18.camel@Andromeda> References: <1339625455.2015.18.camel@Andromeda> Message-ID: Accidental, he didn't mean to get caught :) On Wed, Jun 13, 2012 at 7:10 PM, Richard Golodner wrote: > On Thu, 2012-06-14 at 07:05 +0900, >> ACCIDENTAL email > > How can my company get six accidental emails? Not even an idiot sends > six emails by mistake. > > Spammertechnology labs is more like it. > > From marka at isc.org Wed Jun 13 17:34:05 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 14 Jun 2012 08:34:05 +1000 Subject: very confusing. In-Reply-To: Your message of "Wed, 13 Jun 2012 23:12:38 +0100." <4FD91056.3030206@foobar.org> References: <4FD91056.3030206@foobar.org> Message-ID: <20120613223405.1A02A218F201@drugs.dv.isc.org> In message <4FD91056.3030206 at foobar.org>, Nick Hilliard writes: > >> Be advised that Im following your posts and have your threating > >> messages to me. If there is an ddos or restraint of trade due to my > >> ACCIDENTAL email I'll escalate to commerce and FBI. > > 1. spam a big pile of network operators > 2. threaten legals on aforementioned prospective customers > 3. profit!!11!! > > awesome. > > Nick Complain to you Congress and House Representatives that CAN-SPAM is too unbalanced. The current US law lets you get away with single shots. It should be a offence to send to someone you don't have consent from. Look at the Australian SPAM act for a more balanced act. As long as US law allows companies to harvest addresses and send to them this sort of thing will continue to happen. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From fernando at gont.com.ar Wed Jun 13 17:46:51 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 13 Jun 2012 19:46:51 -0300 Subject: Article: IPv6 host scanning attacks In-Reply-To: References: <4FD838BE.6050705@gont.com.ar> <4FD8D111.4010203@gont.com.ar> Message-ID: <4FD9185B.1060302@gont.com.ar> On 06/13/2012 03:37 PM, Dave Hart wrote: >>> "published" and "available" are misleading at best. >> >> It is not. Just scroll down the page, and you'll find the whole article. >> -- it was easy to talk crap than to do that, right? > > Yes, I'm an idiot for believing what I read on that site: > > "Requires Free Membership to View" > > Of course I should have expected that means "scroll past me and the > page of whitespace to view." I wouldn't "announce" the publication of an article that implies the hassle of a registration in order to read it. While it's certainly not "as good as it can get" to have a banner saying "require free membership to view" inserted in the middle of the article body, it's still "acceptable" for me. (Since you're not the first one to think that the article was not free, next time I'll probably make this explicit such that possible trouble is avoided]). >> I find it amazing the number of people that will talk crap when one >> publishes something when compared to the number of people that provides >> technical comments or criticism (even if it's "you're completely wrong >> because of this and that). > > The draft and the article raise valid points about the predictability > of widely-used MAC-derived IIDs, but it does not in any way justify > the headline "Analysis: Vast IPv6 address space actually enables IPv6 > attacks." Whomever wrote that should share their stash. FWIW, the headline was replaced prior to publication. Put another way: I agree with your comment regarding the headline. Cheers, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From cmorris at cs.odu.edu Wed Jun 13 17:47:37 2012 From: cmorris at cs.odu.edu (Charles Morris) Date: Wed, 13 Jun 2012 18:47:37 -0400 Subject: very confusing. In-Reply-To: <20120613223405.1A02A218F201@drugs.dv.isc.org> References: <4FD91056.3030206@foobar.org> <20120613223405.1A02A218F201@drugs.dv.isc.org> Message-ID: Don't get me wrong, I greatly dislike spam, but next thing you know it will be against the law to send packets to someone you don't have consent from... or hand out pamphlets / talk to someone on the street you don't have consent from... I figure the solution here that fits with the best interests of the people, or really with any internet problem, is a defensive or cryptographic one; instead of an offensive or law-based punitive solution. e.g. Requiring proof-of-work headers for email that doesn't want a speedy descent into /dev/null From nanog at hostleasing.net Wed Jun 13 18:03:28 2012 From: nanog at hostleasing.net (Randy Epstein) Date: Wed, 13 Jun 2012 19:03:28 -0400 Subject: very confusing. In-Reply-To: Message-ID: Folks, This content is great .. for another list. I know you're not happy with receiving unsolicited mail, and yes, it's likely your addresses were scraped from either the mailing list itself or various archives that are kept, but this list is not the best place to discuss this. Please refrain from these types of discussions on the NANOG mailing list. We are doing everything in our power to keep the list on-topic and stop abuse when we see it. We don't take situations like this lightly. Thank you all in advance and if you have any issue with this, please contact me or the Communications Committee directly. Regards, Randy Epstein Acting Chair, NANOG CC From shrdlu at deaddrop.org Wed Jun 13 18:11:20 2012 From: shrdlu at deaddrop.org (Lynda) Date: Wed, 13 Jun 2012 16:11:20 -0700 Subject: very confusing. In-Reply-To: References: Message-ID: <4FD91E18.5050103@deaddrop.org> On 6/13/2012 3:05 PM, Randy Bush wrote: > NANOG, i strongly desire to restrain this slimeball idiot's trade. > please tell me if you have any ideas on how to do so. I have plenty of ideas. Unfortunately, I am not permitted to do those things. I promise it would not be painful, though. I'm not cruel, just methodical. >> Be advised that Im following your posts and have your threating >> messages to me. If there is an ddos or restraint of trade due to my >> ACCIDENTAL email I'll escalate to commerce and FBI. > > LOL. you are not only a slimeball (who the ietf and nanog admins are > scraping out), but an idiot. > > but do please tell me how i can restrain your trade. would love to > discuss your spam with the DoC and FBI. Of the many, many subscribers here on the list, I gently point out to the moh-ron in question that there are any number of current and former members of various federal agencies *also* following the list. Oh, dearest slimeball, be careful what you wish for. Not said in jest. What the heck, at least it isn't yet another interminable discussion of ebay and amazon spam. -- Start wearing purple wearing purple Start wearing purple for me now All your sanity and wits they will all vanish I promise, it's just a matter of time... From kauer at biplane.com.au Wed Jun 13 18:24:09 2012 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 14 Jun 2012 09:24:09 +1000 Subject: Article: IPv6 host scanning attacks In-Reply-To: References: <4FD838BE.6050705@gont.com.ar> Message-ID: <1339629849.4657.55.camel@karl> On Wed, 2012-06-13 at 15:22 -0500, STARNES, CURTIS wrote: > I have a slight problem with stating that "Vast IPv6 address space > actually enables IPv6 attacks". So do I. Compared to IPv4, scanning IPv6 is much, much harder, and that is (I think) the most important thing to know. The analysis was good in that it offered a bit of consideration to the scanning issue, but... "Some estimates peg the length of time for a host-scanning attack on a single IPv6 subnet at 500,000,000 years!" It's not an estimate. It's a approximation based on scanning a /64 subnet at a thousand probes per second. 18 billion billion (addresses in one /64) divided by one thousand, divided by 31536000 (the number of seconds in a year) - works out to about 500,000,000. > .Embed the MAC address; > .Employ low-byte addresses; > .Embed the IPv4 address; > .Use a "wordy" address; > .Use a privacy or temporary address; > .Rely on a transition or coexistence technology. Why do you not mention DHCP in this list? You do mention it elsewhere. DHCPv6 will in general supply random addresses. You say that "some" DHCPv6 servers produce sequential addresses - could you please give an example? I use Nominum's DCS, which certainly does NOT do this very foolish thing. Low-byte addresses are generally going to be on high-value devices, which will usually be servers (whose existence is thus public knowledge anyway) or network fabric devices (who will be very solidly protected by firewalls, generally requiring no access from outside at all, or even access from most of the inside network either). Embedded IPv4 addresses are going to be a reducing problem, and in the scenario you mention, as well as in most other scenarios, again mostly on machines that have very strong protections from firewalls and their own packet filters. Wordy addresses will be an issue for some vanishingly small percentage of systems, and generally systems that their owners want people to see (Facebook being a good example). These are generally going to be systems whose existence is public knowledge anyway. All transition technologies are a reducing problem. The primary transition technology - dual stack - has no technology-specific problems in respect of scanning (except perhaps that the scanner, at least in theory, gets two bites at the cherry). I think you are making a minor issue look far bigger than it is. I feel the privacy issues around SLAAC are far more significant in the real world than any threat from scanning. Regards, K. PS: I still like your RFC about stable privacy addresses. PPS: There seems to be a diagram missing in the discussion of embedded MAC addresses, after the word "syntax". -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From Wade.Peacock at visioncritical.com Wed Jun 13 18:47:24 2012 From: Wade.Peacock at visioncritical.com (Wade Peacock) Date: Wed, 13 Jun 2012 23:47:24 +0000 Subject: Patch Management - Windows & RHEL/CentOS based on Date Message-ID: <1FED9134A6AFF44581924E5576E4DD863609A4BC@VCVANMAILMB1.vci.local> Hi All, Does anyone know of a patch management system that will allow us to control the roll out of patches, specifically for Windows but Linux would be nice too, that can use a date to limit whether a patch is rolled out. Ie. Patch to date set to 2012-06-10 So all patches released up to 2012-06-10 will be offer to requesting client. Any patches released after 2012-06-10 will be hidden/not offered until the "Patch to Date" is moved forward. Wade Peacock Production IT | Vision Critical direct 604.629.9358 mobile 604.363.8137 www.visioncritical.com New York | London | Vancouver | Paris | Sydney | Chicago | San Francisco | Toronto | Montreal | Calgary From lathama at gmail.com Wed Jun 13 18:50:22 2012 From: lathama at gmail.com (Andrew Latham) Date: Wed, 13 Jun 2012 19:50:22 -0400 Subject: Patch Management - Windows & RHEL/CentOS based on Date In-Reply-To: <1FED9134A6AFF44581924E5576E4DD863609A4BC@VCVANMAILMB1.vci.local> References: <1FED9134A6AFF44581924E5576E4DD863609A4BC@VCVANMAILMB1.vci.local> Message-ID: On Wed, Jun 13, 2012 at 7:47 PM, Wade Peacock wrote: > Hi All, > > Does anyone know of a patch management system that will allow us to control the roll out of patches, specifically for Windows but Linux would be nice too, that can use a date to limit whether a patch is rolled out. > > Ie. > > Patch to date set to ? ?2012-06-10 > > So all patches released up to 2012-06-10 will be offer to requesting client. Any patches released after 2012-06-10 will be hidden/not offered until the "Patch to Date" is moved forward. > > Wade Peacock > Production IT | Vision Critical > direct ?604.629.9358 > mobile ?604.363.8137 > > www.visioncritical.com > > New York ?| ?London ?| ?Vancouver | ?Paris ?| Sydney ?| ?Chicago | ?San Francisco | Toronto | Montreal | Calgary > I am unsure of some details but will blindly suggest you look at wpkg.org as a method of deployment for Microsoft Windows products. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From paul at paulgraydon.co.uk Wed Jun 13 18:56:34 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Wed, 13 Jun 2012 13:56:34 -1000 Subject: Patch Management - Windows & RHEL/CentOS based on Date In-Reply-To: <1FED9134A6AFF44581924E5576E4DD863609A4BC@VCVANMAILMB1.vci.local> References: <1FED9134A6AFF44581924E5576E4DD863609A4BC@VCVANMAILMB1.vci.local> Message-ID: <4FD928B2.9010301@paulgraydon.co.uk> On 06/13/2012 01:47 PM, Wade Peacock wrote: > Hi All, > > Does anyone know of a patch management system that will allow us to control the roll out of patches, specifically for Windows but Linux would be nice too, that can use a date to limit whether a patch is rolled out. > > Ie. > > Patch to date set to 2012-06-10 > > So all patches released up to 2012-06-10 will be offer to requesting client. Any patches released after 2012-06-10 will be hidden/not offered until the "Patch to Date" is moved forward. > > Wade Peacock > Production IT | Vision Critical > direct 604.629.9358 > mobile 604.363.8137 > > www.visioncritical.com > > New York | London | Vancouver | Paris | Sydney | Chicago | San Francisco | Toronto | Montreal | Calgary > There are a number of different solutions depending on your environment and how much you might be prepared to spend. A few that spring to mind: PatchLink, works with Windows and RedHat, not sure if they sorted out CentOS support. I've used PatchLink in the past for managing patch deployment to several hundreds of servers, (split up into groups for a final bit of paranoia). ManageEngine have tools, but I believe that's Windows only. RedHat have Satellite that patches and a whole lot more but that comes at a premium. There is also SpaceWalk from them: http://spacewalk.redhat.com/ that manages RedHat, CentOS and Scientific Linux patching. Paul From reed at reedloden.com Wed Jun 13 18:57:40 2012 From: reed at reedloden.com (Reed Loden) Date: Wed, 13 Jun 2012 16:57:40 -0700 Subject: Patch Management - Windows & RHEL/CentOS based on Date In-Reply-To: <1FED9134A6AFF44581924E5576E4DD863609A4BC@VCVANMAILMB1.vci.local> References: <1FED9134A6AFF44581924E5576E4DD863609A4BC@VCVANMAILMB1.vci.local> Message-ID: <20120613165740.53f1cb60@sydney.pretender.us> On Wed, 13 Jun 2012 23:47:24 +0000 Wade Peacock wrote: > Does anyone know of a patch management system that will allow us to > control the roll out of patches, specifically for Windows but Linux > would be nice too, that can use a date to limit whether a patch is > rolled out. I don't know of a good software product that does *both* Windows and RHEL/CentOS, but for Windows, have you looked at Microsoft's WSUS [0]? For RHEL/CentOS, use Spacewalk [1]. Hope that helps! ~reed [0] http://technet.microsoft.com/en-us/windowsserver/bb332157.aspx [1] http://spacewalk.redhat.com/ From os10rules at gmail.com Wed Jun 13 19:53:36 2012 From: os10rules at gmail.com (Greg Ihnen) Date: Wed, 13 Jun 2012 20:23:36 -0430 Subject: very confusing. In-Reply-To: References: Message-ID: <5588BF23-E54A-47DF-99D5-E9B5F215B44B@gmail.com> A trick to do on mail (USPS) spammers is take the prepaid mailing envelope they often include and tape it to a brick wrapped in brown paper and drop it off at the post office. They have to pay the shipping. If enough people do it, they go out of business. In this case, do anything you can to waste his time and resources. Call up and act interested in his services and have them go through their sales pitch as many times as you can. Ask for them to mail you literature. Have them write up proposals and quotes. Then when the last step left is to actually commit to their service tell them you were just pulling their chain, and why. If you eat up enough of their time they end up attending to too few real paying customers and they go out of business. Greg On Jun 13, 2012, at 5:35 PM, Randy Bush wrote: > NANOG, i strongly desire to restrain this slimeball idiot's trade. > please tell me if you have any ideas on how to do so. > > --- > >> Be advised that Im following your posts and have your threating >> messages to me. If there is an ddos or restraint of trade due to my >> ACCIDENTAL email I'll escalate to commerce and FBI. > > LOL. you are not only a slimeball (who the ietf and nanog admins are > scraping out), but an idiot. > > but do please tell me how i can restrain your trade. would love to > discuss your spam with the DoC and FBI. > > randy > From jgreco at ns.sol.net Wed Jun 13 20:01:57 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 13 Jun 2012 20:01:57 -0500 (CDT) Subject: very confusing. In-Reply-To: <5588BF23-E54A-47DF-99D5-E9B5F215B44B@gmail.com> Message-ID: <201206140101.q5E11vRt096707@aurora.sol.net> > A trick to do on mail (USPS) spammers is take the prepaid mailing = > envelope they often include and tape it to a brick wrapped in brown = > paper and drop it off at the post office. They have to pay the shipping. = > If enough people do it, they go out of business. That's simply false; local postmasters have had the discretion to discard your bricks for years, AND THEY DO. > In this case, do anything you can to waste his time and resources. Call = > up and act interested in his services and have them go through their = > sales pitch as many times as you can. Ask for them to mail you = > literature. Have them write up proposals and quotes. Then when the last = > step left is to actually commit to their service tell them you were just = > pulling their chain, and why. If you eat up enough of their time they = > end up attending to too few real paying customers and they go out of = > business. But that, on the other hand ... ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From rayw at rayw.net Wed Jun 13 21:17:37 2012 From: rayw at rayw.net (Ray Wong) Date: Wed, 13 Jun 2012 19:17:37 -0700 Subject: Patch Management - Windows & RHEL/CentOS based on Date In-Reply-To: <1FED9134A6AFF44581924E5576E4DD863609A4BC@VCVANMAILMB1.vci.local> References: <1FED9134A6AFF44581924E5576E4DD863609A4BC@VCVANMAILMB1.vci.local> Message-ID: If you're using Active Directory I think you can actually do that with the Policy Manager thingy, but i'm not really a windows guy to be sure. -R> On Wed, Jun 13, 2012 at 4:47 PM, Wade Peacock wrote: > Hi All, > > Does anyone know of a patch management system that will allow us to control the roll out of patches, specifically for Windows but Linux would be nice too, that can use a date to limit whether a patch is rolled out. > > Ie. > > Patch to date set to ? ?2012-06-10 > > So all patches released up to 2012-06-10 will be offer to requesting client. Any patches released after 2012-06-10 will be hidden/not offered until the "Patch to Date" is moved forward. > > Wade Peacock > Production IT | Vision Critical > direct ?604.629.9358 > mobile ?604.363.8137 > > www.visioncritical.com > > New York ?| ?London ?| ?Vancouver | ?Paris ?| Sydney ?| ?Chicago | ?San Francisco | Toronto | Montreal | Calgary > From kmedcalf at dessus.com Wed Jun 13 21:21:49 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 13 Jun 2012 20:21:49 -0600 Subject: EBAY and AMAZON In-Reply-To: <20440.53129.640938.891199@world.std.com> Message-ID: > The problem at this point is that even with improvements in newer > Windows systems there are probably on the order of a billion systems > out there, attached to the net, and still running these deeply flawed > OS's which can be taken over by just clicking on the wrong mail > message. There have been no improvements in Windows security. The Microsoft "execute payload with NT AUTHORITY\SYSTEM" ip option was sheer brilliance, and that *only* appeared in their new-and-improved Operating Systems. Don't believe the propaganda. --- ?u?op-?p?sdn s? ?o??uo? ?no? 's??? p??? u?? no? ?? From owen at delong.com Wed Jun 13 21:39:24 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Jun 2012 22:39:24 -0400 Subject: very confusing. In-Reply-To: <201206140101.q5E11vRt096707@aurora.sol.net> References: <201206140101.q5E11vRt096707@aurora.sol.net> Message-ID: <4689BE5F-B3F9-49E6-A402-690537117256@delong.com> Sent from my iPad On Jun 13, 2012, at 9:01 PM, Joe Greco wrote: >> A trick to do on mail (USPS) spammers is take the prepaid mailing = >> envelope they often include and tape it to a brick wrapped in brown = >> paper and drop it off at the post office. They have to pay the shipping. = >> If enough people do it, they go out of business. > > That's simply false; local postmasters have had the discretion to discard > your bricks for years, AND THEY DO. > Yes... Bricks don't work any more. You have to get more creative. http://www.dogdoo.com offers a selection of products ideally suited for this purpose. >> In this case, do anything you can to waste his time and resources. Call = >> up and act interested in his services and have them go through their = >> sales pitch as many times as you can. Ask for them to mail you = >> literature. Have them write up proposals and quotes. Then when the last = >> step left is to actually commit to their service tell them you were just = >> pulling their chain, and why. If you eat up enough of their time they = >> end up attending to too few real paying customers and they go out of = >> business. > > But that, on the other hand ... > Not mutually exclusive. Owen From george.herbert at gmail.com Wed Jun 13 22:08:59 2012 From: george.herbert at gmail.com (George Herbert) Date: Wed, 13 Jun 2012 20:08:59 -0700 Subject: very confusing. In-Reply-To: <4689BE5F-B3F9-49E6-A402-690537117256@delong.com> References: <201206140101.q5E11vRt096707@aurora.sol.net> <4689BE5F-B3F9-49E6-A402-690537117256@delong.com> Message-ID: <5EB36387-79B4-4911-BF22-42B6D31DE293@gmail.com> I am as amused by antispam efforts as anyone, but can we stay on list topic? George William Herbert Sent from my iPhone On Jun 13, 2012, at 19:39, Owen DeLong wrote: > > > Sent from my iPad > > On Jun 13, 2012, at 9:01 PM, Joe Greco wrote: > >>> A trick to do on mail (USPS) spammers is take the prepaid mailing = >>> envelope they often include and tape it to a brick wrapped in brown = >>> paper and drop it off at the post office. They have to pay the shipping. = >>> If enough people do it, they go out of business. >> >> That's simply false; local postmasters have had the discretion to discard >> your bricks for years, AND THEY DO. >> > > Yes... Bricks don't work any more. You have to get more creative. > > http://www.dogdoo.com offers a selection of products ideally suited for this purpose. > >>> In this case, do anything you can to waste his time and resources. Call = >>> up and act interested in his services and have them go through their = >>> sales pitch as many times as you can. Ask for them to mail you = >>> literature. Have them write up proposals and quotes. Then when the last = >>> step left is to actually commit to their service tell them you were just = >>> pulling their chain, and why. If you eat up enough of their time they = >>> end up attending to too few real paying customers and they go out of = >>> business. >> >> But that, on the other hand ... >> > > Not mutually exclusive. > > Owen > > From shortdudey123 at gmail.com Wed Jun 13 22:29:15 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 13 Jun 2012 22:29:15 -0500 Subject: HE IPv6 tunnel inbound Message-ID: Hi, I have a Hurricane Electric v6 tunnel setup on an AWS (amazon web services) instance so that i can have ipv6 connectivity. I can ping and traceroute out of the tunnel fine, but am unable to access the tunnel from outside. For example, i am unable to traceroute to the tunnel address outside the tunnel address, even with the AWS instance firewall completely open. I would like to host a website accessible via IPv6, hence the tunnel setup. Is this possible? if so, what could i be doing wrong? Or is there a better was to go about this? Thanks, Grant From morrowc.lists at gmail.com Wed Jun 13 22:35:51 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Jun 2012 23:35:51 -0400 Subject: HE IPv6 tunnel inbound In-Reply-To: References: Message-ID: On Wed, Jun 13, 2012 at 11:29 PM, Grant Ridder wrote: > Hi, > > I have a Hurricane Electric v6 tunnel setup on an AWS (amazon web services) > instance so that i can have ipv6 connectivity. ?I can ping and traceroute > out of the tunnel fine, but am unable to access the tunnel from outside. > ?For example, i am unable to traceroute to the tunnel address outside the > tunnel address, even with the AWS instance firewall completely open. ?I > would like to host a website accessible via IPv6, hence the tunnel setup. > ?Is this possible? if so, what could i be doing wrong? ?Or is there a > better was to go about this? > google/bing/yahoo/webcrawler search result: > Thanks, > Grant From cb.list6 at gmail.com Wed Jun 13 23:10:06 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 13 Jun 2012 21:10:06 -0700 Subject: HE IPv6 tunnel inbound In-Reply-To: References: Message-ID: On Jun 13, 2012 8:29 PM, "Grant Ridder" wrote: > > Hi, > > I have a Hurricane Electric v6 tunnel setup on an AWS (amazon web services) > instance so that i can have ipv6 connectivity. I can ping and traceroute > out of the tunnel fine, but am unable to access the tunnel from outside. > For example, i am unable to traceroute to the tunnel address outside the > tunnel address, even with the AWS instance firewall completely open. I > would like to host a website accessible via IPv6, hence the tunnel setup. > Is this possible? if so, what could i be doing wrong? Or is there a > better was to go about this? > > Thanks, > Grant Sigh. Or you could take your business to the dozen or so cloud / vps providers that support ipv6. ... Softlayer and Arpnetworks come to mind. I have used both with a high level of sucess CB From alejandroacostaalamo at gmail.com Wed Jun 13 23:57:01 2012 From: alejandroacostaalamo at gmail.com (alejandroacostaalamo at gmail.com) Date: Thu, 14 Jun 2012 04:57:01 +0000 Subject: HE IPv6 tunnel inbound In-Reply-To: References: Message-ID: <2094080928-1339649819-cardhu_decombobulator_blackberry.rim.net-314286082-@b26.c3.bise6.blackberry> Also: www.cloudflare.com (for free) Este mensaje ha sido enviado gracias al servicio BlackBerry de Movilnet -----Original Message----- From: Cameron Byrne Date: Wed, 13 Jun 2012 21:10:06 To: Grant Ridder Cc: Subject: Re: HE IPv6 tunnel inbound On Jun 13, 2012 8:29 PM, "Grant Ridder" wrote: > > Hi, > > I have a Hurricane Electric v6 tunnel setup on an AWS (amazon web services) > instance so that i can have ipv6 connectivity. I can ping and traceroute > out of the tunnel fine, but am unable to access the tunnel from outside. > For example, i am unable to traceroute to the tunnel address outside the > tunnel address, even with the AWS instance firewall completely open. I > would like to host a website accessible via IPv6, hence the tunnel setup. > Is this possible? if so, what could i be doing wrong? Or is there a > better was to go about this? > > Thanks, > Grant Sigh. Or you could take your business to the dozen or so cloud / vps providers that support ipv6. ... Softlayer and Arpnetworks come to mind. I have used both with a high level of sucess CB From sadiq at asininetech.com Thu Jun 14 07:50:30 2012 From: sadiq at asininetech.com (Sadiq Saif) Date: Thu, 14 Jun 2012 08:50:30 -0400 Subject: HE IPv6 tunnel inbound In-Reply-To: References: Message-ID: On Thu, Jun 14, 2012 at 12:10 AM, Cameron Byrne wrote: > On Jun 13, 2012 8:29 PM, "Grant Ridder" wrote: >> >> Hi, >> >> I have a Hurricane Electric v6 tunnel setup on an AWS (amazon web > services) >> instance so that i can have ipv6 connectivity. ?I can ping and traceroute >> out of the tunnel fine, but am unable to access the tunnel from outside. >> ?For example, i am unable to traceroute to the tunnel address outside the >> tunnel address, even with the AWS instance firewall completely open. ?I >> would like to host a website accessible via IPv6, hence the tunnel setup. >> ?Is this possible? if so, what could i be doing wrong? ?Or is there a >> better was to go about this? >> >> Thanks, >> Grant > > Sigh. > > Or you could take your business to the dozen or so cloud / vps providers > that support ipv6. ... Softlayer and Arpnetworks come to mind. I have used > both with a high level of sucess > > CB To add to that list, I highly suggest Linode. Amazing provider with the best customer service I've seen. -- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From shortdudey123 at gmail.com Thu Jun 14 08:07:40 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 14 Jun 2012 08:07:40 -0500 Subject: HE IPv6 tunnel inbound In-Reply-To: References: Message-ID: Hi, Thanks for all the replies. I will look at Chris's solution to see if that will work. I had found similar instructions, but none as extensive. Also, I am using the AWS free tier right now, hence the choice, but i am open to other suggestions. Thanks, Grant On Thu, Jun 14, 2012 at 7:54 AM, seth wrote: > > > > > On Jun 13, 2012, at 11:10 PM, Cameron Byrne wrote: > > > On Jun 13, 2012 8:29 PM, "Grant Ridder" wrote: > >> > >> Hi, > >> > >> I have a Hurricane Electric v6 tunnel setup on an AWS (amazon web > > services) > >> instance so that i can have ipv6 connectivity. I can ping and > traceroute > >> out of the tunnel fine, but am unable to access the tunnel from outside. > >> For example, i am unable to traceroute to the tunnel address outside the > >> tunnel address, even with the AWS instance firewall completely open. I > >> would like to host a website accessible via IPv6, hence the tunnel > setup. > >> Is this possible? if so, what could i be doing wrong? Or is there a > >> better was to go about this? > >> > >> Thanks, > >> Grant > > > > Sigh. > > > > Or you could take your business to the dozen or so cloud / vps providers > > that support ipv6. ... Softlayer and Arpnetworks come to mind. I have > used > > both with a high level of sucess > > > > CB > > But everybody knows that "amazon" and "cloud" are synonyms. From sethm at rollernet.us Thu Jun 14 11:25:56 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 14 Jun 2012 09:25:56 -0700 Subject: HE IPv6 tunnel inbound In-Reply-To: References: Message-ID: <4FDA1094.40302@rollernet.us> On 6/13/12 9:10 PM, Cameron Byrne wrote: > On Jun 13, 2012 8:29 PM, "Grant Ridder" wrote: >> >> Hi, >> >> I have a Hurricane Electric v6 tunnel setup on an AWS (amazon web > services) >> instance so that i can have ipv6 connectivity. I can ping and traceroute >> out of the tunnel fine, but am unable to access the tunnel from outside. >> For example, i am unable to traceroute to the tunnel address outside the >> tunnel address, even with the AWS instance firewall completely open. I >> would like to host a website accessible via IPv6, hence the tunnel setup. >> Is this possible? if so, what could i be doing wrong? Or is there a >> better was to go about this? >> >> Thanks, >> Grant > > Sigh. > > Or you could take your business to the dozen or so cloud / vps providers > that support ipv6. ... Softlayer and Arpnetworks come to mind. I have used > both with a high level of sucess > VR.org (Host Virtual) as well. I've asked about IPv6 BGP support and while I haven't tried it yet they say that can do that too. ~Seth From owen at delong.com Thu Jun 14 11:43:43 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Jun 2012 12:43:43 -0400 Subject: HE IPv6 tunnel inbound In-Reply-To: <4FDA1094.40302@rollernet.us> References: <4FDA1094.40302@rollernet.us> Message-ID: Sent from my iPad On Jun 14, 2012, at 12:25 PM, Seth Mattinen wrote: > On 6/13/12 9:10 PM, Cameron Byrne wrote: >> On Jun 13, 2012 8:29 PM, "Grant Ridder" wrote: >>> >>> Hi, >>> >>> I have a Hurricane Electric v6 tunnel setup on an AWS (amazon web >> services) >>> instance so that i can have ipv6 connectivity. I can ping and traceroute >>> out of the tunnel fine, but am unable to access the tunnel from outside. >>> For example, i am unable to traceroute to the tunnel address outside the >>> tunnel address, even with the AWS instance firewall completely open. I >>> would like to host a website accessible via IPv6, hence the tunnel setup. >>> Is this possible? if so, what could i be doing wrong? Or is there a >>> better was to go about this? >>> >>> Thanks, >>> Grant >> >> Sigh. >> >> Or you could take your business to the dozen or so cloud / vps providers >> that support ipv6. ... Softlayer and Arpnetworks come to mind. I have used >> both with a high level of sucess >> > > > VR.org (Host Virtual) as well. I've asked about IPv6 BGP support and > while I haven't tried it yet they say that can do that too. > > ~Seth VR is fully dual stack support throughout their network and a good bunch of guys. With LINODE, they're mixed since some of the colos they are in have IPv6 (like HE, for example) and some don't. So if you go with LINODE, make sure they know to put you in a location with IPv6. (note this may be out of date and they may have IPv6 everywhere by now, as I know they were working on it) To the best of my knowledge, both provide excellent services at competitive prices. There's a soft spot in my heart for VR because I have done some work for them and I like the two guys that run it. Owen From sadiq at asininetech.com Thu Jun 14 11:50:07 2012 From: sadiq at asininetech.com (Sadiq Saif) Date: Thu, 14 Jun 2012 12:50:07 -0400 Subject: HE IPv6 tunnel inbound In-Reply-To: References: <4FDA1094.40302@rollernet.us> Message-ID: On Thu, Jun 14, 2012 at 12:43 PM, Owen DeLong wrote: > > > Sent from my iPad > > On Jun 14, 2012, at 12:25 PM, Seth Mattinen wrote: > >> On 6/13/12 9:10 PM, Cameron Byrne wrote: >>> On Jun 13, 2012 8:29 PM, "Grant Ridder" wrote: >>>> >>>> Hi, >>>> >>>> I have a Hurricane Electric v6 tunnel setup on an AWS (amazon web >>> services) >>>> instance so that i can have ipv6 connectivity. ?I can ping and traceroute >>>> out of the tunnel fine, but am unable to access the tunnel from outside. >>>> For example, i am unable to traceroute to the tunnel address outside the >>>> tunnel address, even with the AWS instance firewall completely open. ?I >>>> would like to host a website accessible via IPv6, hence the tunnel setup. >>>> Is this possible? if so, what could i be doing wrong? ?Or is there a >>>> better was to go about this? >>>> >>>> Thanks, >>>> Grant >>> >>> Sigh. >>> >>> Or you could take your business to the dozen or so cloud / vps providers >>> that support ipv6. ... Softlayer and Arpnetworks come to mind. I have used >>> both with a high level of sucess >>> >> >> >> VR.org (Host Virtual) as well. I've asked about IPv6 BGP support and >> while I haven't tried it yet they say that can do that too. >> >> ~Seth > > VR is fully dual stack support throughout their network and a good bunch of guys. > > With LINODE, they're mixed since some of the colos they are in have IPv6 (like HE, for example) and some don't. So if you go with LINODE, make sure they know to put you in a location with IPv6. (note this may be out of date and they may have IPv6 everywhere by now, as I know they were working on it) > > To the best of my knowledge, both provide excellent services at competitive prices. There's a soft spot in my heart for VR because I have done some work for them and I like the two guys that run it. > > Owen > > Linode now has IPv6 in all the DCs they colo in - http://blog.linode.com/2012/02/28/native-ipv6-now-available-in-all-locations/ -- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From khomyakov.andrey at gmail.com Thu Jun 14 14:50:39 2012 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Thu, 14 Jun 2012 15:50:39 -0400 Subject: WLC vlan size and management Message-ID: Hi list, If I may ask for your advice, I have a Cisco 5508 WLC. Need to use it to manage APs at multiple buildings which I plan on doing using AP Groups. I understand that if I have one SSID mapped to one VLAN I can do it within the AP group and all is well. In my case, I have to provide a single SSID, but be able to assign clients into vlans based on their credentials. ACS 5.2 takes care of that with Tunnel-Private-Group-ID. Currently, I only have it managing one building, so the problem is only looming, but need to start converting my fat APs to LWAPs in other places. That means "way more clients than I can fit into a /24 or even a /23". The way I have it configured right now is as follows: 1. I have interfaces created in the WLC with names corresponding to the value that gets sent in Tunnel-Private-Group-ID (this is done because there are multiple controllers, but I can adjust to a tag instead. Though I don't think this will help in my case) 2. I have these interfaces grouped into an interface group. 3. I have the WLAN created and mapped to the interface group (which I'm pretty sure is not important, since AP group overrides this) 4. I have an AP Group with my APs in just this one building and that has that very same WLAN mapped to the same interface group mentioned above 5. ACS sends back the interface name in Tunnel-Private-Group-ID and the client gets placed into an appropriate vlan based on client's credentials Now the issue 1. I need to add other buildings full of APs, so I'm guessing more AP groups (one per building) 2. If I map the next new AP group to the same interface group it will work and the clients will get placed into the same vlans as the clients above 3. The issue is that at some point I will exhaust the DHCP scopes. I'm thinking that somehow I need to be able to place clients into an appropriate vlan based no only on credentials but also on location (that is building). What I can't find is how to match clients based on AP location in my WLC 7.0 + ACS 5.2 setup. The best I could come up with is tracking all AP's mac addresses and match Called-Station-ID based on those address, but that's a nightmare in my opinion. How do others do it? I would imaging there are some kind of "spill over" features that have to exist out there or some other technique Thanks, --Andrey From source_route at yahoo.com Thu Jun 14 15:04:19 2012 From: source_route at yahoo.com (Philip Lavine) Date: Thu, 14 Jun 2012 13:04:19 -0700 (PDT) Subject: best practives multi-homed BGP 2 physical locations Message-ID: <1339704259.96937.YahooMailNeo@web162903.mail.bf1.yahoo.com> ?Is there any best practices documentation on how to run BGP multihoming accross two phyiscally seperated sites. From betty at newnog.org Thu Jun 14 15:16:51 2012 From: betty at newnog.org (Betty Burke ) Date: Thu, 14 Jun 2012 16:16:51 -0400 Subject: [NANOG-announce] Survey Reminder Message-ID: NANOGers; Thank you to those recently participating in NANOG 55, Vancouver. Either as an on-site or remote attendee, speaker, sponsor, or member, your opinions are valued. If you have not yet completed the NANOG 55 survey(s), we would greatly appreciate you taking the time to complete them by visiting the NANOG 55 Survey http://www.nanog.org/meetings/nanog55/surveys.html The surveys will close at end of day Friday, June 15, 2012. Remember, your feedback will help us take action to continuously improve the NANG meeting experience! Sincerely, Betty -- Betty Burke NANOG Executive Director -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From jeroen at mompl.net Thu Jun 14 15:20:17 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 14 Jun 2012 13:20:17 -0700 Subject: EBAY and AMAZON In-Reply-To: <4FD8D719.1070704@gmail.com> References: <20120613121749.227060@gmx.com> <4FD8D719.1070704@gmail.com> Message-ID: <4FDA4781.8010807@mompl.net> JC Dill wrote: > I'm really surprised to see this "Windows is more popular, that's why > it's exploited more often" misinformation being spewed on a technical > list like NANOG. I thought people here had more clue. I don't think a individual opinion is representative for the whole 10000+ (?) member list. Besides there were very knowledgeable people expressing the opposite view. And this is a network operators list. I figure the subject of operating system security is less prevalent on here than it would be on a systems administrator list (is there one like nanog?), and compared to, say, IPv6 :-) For the record I too do disagree wholeheartedly with the "Windows is more popular, that's why it's exploited more often" sentiment. It is patently untrue which others already explained rather well. Greetings, Jeroen -- Earthquake Magnitude: 3.5 Date: Thursday, June 14, 2012 06:25:03 UTC Location: Central Alaska Latitude: 63.1165; Longitude: -151.8971 Depth: 4.10 km From gietzen at gmail.com Thu Jun 14 16:01:33 2012 From: gietzen at gmail.com (Chad Gietzen) Date: Thu, 14 Jun 2012 17:01:33 -0400 Subject: best practives multi-homed BGP 2 physical locations In-Reply-To: <1339704259.96937.YahooMailNeo@web162903.mail.bf1.yahoo.com> References: <1339704259.96937.YahooMailNeo@web162903.mail.bf1.yahoo.com> Message-ID: I found the following helpful, presented by Philip Smith at NANOG 41 http://www.nanog.org/meetings/nanog41/presentations/BGPMultihoming.pdf Chad On Thu, Jun 14, 2012 at 4:04 PM, Philip Lavine wrote: > ?Is there any best practices documentation on how to run BGP multihoming accross two phyiscally seperated sites. From source_route at yahoo.com Thu Jun 14 16:40:52 2012 From: source_route at yahoo.com (Philip Lavine) Date: Thu, 14 Jun 2012 14:40:52 -0700 (PDT) Subject: best practives multi-homed BGP 2 physical locations In-Reply-To: References: <1339704259.96937.YahooMailNeo@web162903.mail.bf1.yahoo.com> Message-ID: <1339710052.1594.YahooMailNeo@web162905.mail.bf1.yahoo.com> Does this include Multi Site?+ Multi Homed ________________________________ From: Chad Gietzen To: Philip Lavine Cc: "nanog at nanog.org" Sent: Thursday, June 14, 2012 2:01 PM Subject: Re: best practives multi-homed BGP 2 physical locations I found the following helpful, presented by Philip Smith at NANOG 41 http://www.nanog.org/meetings/nanog41/presentations/BGPMultihoming.pdf Chad On Thu, Jun 14, 2012 at 4:04 PM, Philip Lavine wrote: > ?Is there any best practices documentation on how to run BGP multihoming accross two phyiscally seperated sites. From source_route at yahoo.com Thu Jun 14 17:33:58 2012 From: source_route at yahoo.com (Philip Lavine) Date: Thu, 14 Jun 2012 15:33:58 -0700 (PDT) Subject: best practives multi-homed BGP 2 physical locations In-Reply-To: References: <1339704259.96937.YahooMailNeo@web162903.mail.bf1.yahoo.com> Message-ID: <1339713238.72911.YahooMailNeo@web162904.mail.bf1.yahoo.com> Easy part: I need to provide my users acces to the internet from my HQ site via a local Internet connection or via a?colo.? ? Hard part: I also need to provide incoming access to hosted apps (HTTP, FTP, SMTP) from either location, so if the colo internet connection goes down the traffic can re-route to the HQ server farm and visa versa. I am in the process of purchasing an AS and ip space. Is it advisable to use the same IP space at both locations and run iBGP over a dedicated L2 connection between the sites. ? P ? ________________________________ From: Mick O'Rourke To: Philip Lavine Cc: "nanog at nanog.org" Sent: Thursday, June 14, 2012 2:48 PM Subject: Re: best practives multi-homed BGP 2 physical locations As in - use of multi or single AS? - private, vpn or other dci? - etc What's the purpose of the site? Or what end result are you trying to achieve? On Jun 15, 2012 6:04 AM, "Philip Lavine" wrote: ?Is there any best practices documentation on how to run BGP multihoming accross two phyiscally seperated sites. > From randy_94108 at yahoo.com Thu Jun 14 20:22:35 2012 From: randy_94108 at yahoo.com (Randy) Date: Thu, 14 Jun 2012 18:22:35 -0700 (PDT) Subject: best practives multi-homed BGP 2 physical locations In-Reply-To: <1339713238.72911.YahooMailNeo@web162904.mail.bf1.yahoo.com> Message-ID: <1339723355.50736.YahooMailClassic@web181109.mail.ne1.yahoo.com> so, say you end up with a /24 and your ASN split up your /24 into hq-/25 and colo-/25 from colo: 1) announce /24 as a standard adv 2) announce colo-/25 with *no-export* community set from hq: 1) announce /24 as a standard adv 2) announce hq-/25 with *no-export* community set Run iBGP over a dedicated link b/w colo and hq (I don't like allow-as in! but it is another option) ./Randy --- On Thu, 6/14/12, Philip Lavine wrote: > From: Philip Lavine > Subject: Re: best practives multi-homed BGP 2 physical locations > To: "Mick O'Rourke" > Cc: "nanog at nanog.org" > Date: Thursday, June 14, 2012, 3:33 PM > Easy part: > I need to provide my users acces to the internet from my HQ > site via a local Internet connection or via a?colo.? > ? > Hard part: > I also need to provide incoming access to hosted apps > (HTTP, FTP, SMTP) from either location, so if the colo > internet connection goes down the traffic can re-route to > the HQ server farm and visa versa. > I am in the process of purchasing an AS and ip space. Is it > advisable to use the same IP space at both locations and run > iBGP over a dedicated L2 connection between the sites. > ? > P > ? > > ________________________________ > From: Mick O'Rourke > To: Philip Lavine > > Cc: "nanog at nanog.org" > > > Sent: Thursday, June 14, 2012 2:48 PM > Subject: Re: best practives multi-homed BGP 2 physical > locations > ? > > As in > - use of multi or single AS? > - private, vpn or other dci? > - etc > What's the purpose of the site? Or what end result are you > trying to achieve? > > On Jun 15, 2012 6:04 AM, "Philip Lavine" > wrote: > > ?Is there any best practices documentation on how to run > BGP multihoming accross two phyiscally seperated sites. > > > From davidpeahi at gmail.com Thu Jun 14 20:40:11 2012 From: davidpeahi at gmail.com (david peahi) Date: Thu, 14 Jun 2012 18:40:11 -0700 Subject: best practives multi-homed BGP 2 physical locations In-Reply-To: <1339713238.72911.YahooMailNeo@web162904.mail.bf1.yahoo.com> References: <1339704259.96937.YahooMailNeo@web162903.mail.bf1.yahoo.com> <1339713238.72911.YahooMailNeo@web162904.mail.bf1.yahoo.com> Message-ID: I'm fortunate to have a /16, and advertise 2 /18s from the primary, and 4 /17s from the backup collo, /16 from both with AS Prepend on backup /16, and depend on BGP longest prefix route selection to create symmetric Internet routing back to my locations. I run IBGP between geographically diverse locations internally, over an L2 VLAN extended over a GiGE dot1q trunk. Internet-facing load-balancers select the best server from distributed server farms spread across the 2 sites. I think this is a fairly standard configuration. On Thu, Jun 14, 2012 at 3:33 PM, Philip Lavine wrote: > Easy part: > I need to provide my users acces to the internet from my HQ site via a > local Internet connection or via a colo. > > Hard part: > I also need to provide incoming access to hosted apps (HTTP, FTP, SMTP) > from either location, so if the colo internet connection goes down the > traffic can re-route to the HQ server farm and visa versa. > I am in the process of purchasing an AS and ip space. Is it advisable to > use the same IP space at both locations and run iBGP over a dedicated L2 > connection between the sites. > > P > > > ________________________________ > From: Mick O'Rourke > To: Philip Lavine > Cc: "nanog at nanog.org" > Sent: Thursday, June 14, 2012 2:48 PM > Subject: Re: best practives multi-homed BGP 2 physical locations > > > As in > - use of multi or single AS? > - private, vpn or other dci? > - etc > What's the purpose of the site? Or what end result are you trying to > achieve? > > On Jun 15, 2012 6:04 AM, "Philip Lavine" wrote: > > Is there any best practices documentation on how to run BGP multihoming > accross two phyiscally seperated sites. > > > From righa.shake at gmail.com Fri Jun 15 01:41:30 2012 From: righa.shake at gmail.com (Righa Shake) Date: Fri, 15 Jun 2012 09:41:30 +0300 Subject: Peeringdb down? In-Reply-To: References: Message-ID: Hey, Anybody able to access peeringdb today? Regards, Righa Shake On Fri, Jun 8, 2012 at 7:04 PM, Darius Jahandarie wrote: > On Fri, Jun 8, 2012 at 12:03 PM, Darius Jahandarie > wrote: > > However, when the web interface goes down, usually you can still get > > information with the whois and finger interfaces: > > And of course, this is what I meant by the finger interface: > > d82h214:~ Darius$ finger as4436 at peeringdb.com > > > > Still early. > > -- > Darius Jahandarie > > From ethern at ascc.net Fri Jun 15 02:08:05 2012 From: ethern at ascc.net (Ethern Lin) Date: Fri, 15 Jun 2012 15:08:05 +0800 Subject: Peeringdb down? In-Reply-To: References: Message-ID: <4FDADF55.4090009@ascc.net> web site is down but traceroute is ok. Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 140.109.1.1 0.0% 10 1.2 3.4 1.2 6.4 2.0 2. 140.109.255.213 0.0% 10 0.7 0.7 0.4 1.1 0.3 3. 202.169.174.77 0.0% 10 0.5 0.5 0.4 0.9 0.1 4. 202.169.174.226 0.0% 10 130.4 130.6 130.4 131.0 0.2 5. 64.209.107.45 0.0% 10 131.1 141.0 130.5 226.0 30.0 6. 69.31.111.222 20.0% 10 193.5 193.5 191.7 195.0 1.4 7. 69.31.111.137 0.0% 10 193.9 193.8 193.7 193.9 0.1 8. 69.31.111.6 0.0% 10 190.6 190.9 190.6 191.3 0.3 9. 75.102.0.114 0.0% 10 193.0 192.5 190.9 198.2 2.1 10. 205.234.211.82 0.0% 10 191.1 190.8 190.4 191.3 0.3 port 80 does open but not work: % tcptraceroute www.peeringdb.com Selected device le0, address 140.109.1.6, port 51755 for outgoing packets Tracing the path to www.peeringdb.com (205.234.211.82) on TCP port 80, 30 hops max 1 fe-1-1-br5.ascc.net (140.109.1.1) 6.804 ms 9.758 ms 9.510 ms 2 140.109.255.213 (140.109.255.213) 9.994 ms 9.585 ms 10.506 ms 3 202.169.174.77 (202.169.174.77) 9.477 ms 9.629 ms 9.992 ms 4 202.169.174.226 (202.169.174.226) 130.602 ms 130.264 ms 130.229 ms 5 64.209.107.45 (64.209.107.45) 130.324 ms 130.345 ms 133.022 ms 6 * * * 7 ae1-40g.cr1.ord1.us.nlayer.net (69.31.111.133) 190.646 ms 190.187 ms 228.519 ms 8 po6.ar1.ord1.us.scnet.net (69.31.111.58) 190.645 ms 190.590 ms 246.995 ms 9 ge0-49.aggr4302.ord2.us.scnet.net (75.102.0.110) 198.134 ms 199.110 ms 195.075 ms 10 www.peeringdb.com (205.234.211.82) [open] 190.322 ms 190.450 ms 190.454 ms % telnet www.peeringdb.com 80 Trying 205.234.211.82... Connected to www.peeringdb.com. Escape character is '^]'. Connection closed by foreign host. cheers, Ethern ====================================== Ethern Lin Network Division Computing Center, ACADEMIA SINICA AS Number: 9264 Phone: +886-2-66149953 TANet VoIP: 93909953 Fax: +886-2-66146444 ====================================== ? 2012/6/15 ?? 02:41, Righa Shake ??: > Hey, > > Anybody able to access peeringdb today? > > Regards, > Righa Shake > > On Fri, Jun 8, 2012 at 7:04 PM, Darius Jahandariewrote: > >> On Fri, Jun 8, 2012 at 12:03 PM, Darius Jahandarie >> wrote: >>> However, when the web interface goes down, usually you can still get >>> information with the whois and finger interfaces: >> And of course, this is what I meant by the finger interface: >> >> d82h214:~ Darius$ finger as4436 at peeringdb.com >> >> >> >> Still early. >> >> -- >> Darius Jahandarie >> >> > > -- > ====================================== > Ethern Lin > Network Division > Computing Center, ACADEMIA SINICA > AS Number: 9264 > Phone: +886-2-66149953 > TANet VoIP: 93909953 > Fax: +886-2-66146444 > ====================================== From mohamed.abosree at gmail.com Fri Jun 15 04:56:05 2012 From: mohamed.abosree at gmail.com (mohamed Osama Saad Abo sree) Date: Fri, 15 Jun 2012 11:56:05 +0200 Subject: IPv6 Lo. for 6PE/6VPE Message-ID: Hello, I was just wondering , while I'm planning my network to support 6PE/6VPE why should i assign an IPv6 for Loopbacks? Maybe it's needed for Point-Point links or external interfaces between my peers, but anyone here know why i should assign IPv6 for all my Routers inside my ISP if we will run PE/6VPE not dual stack. BR, Mohamed From dr at cluenet.de Fri Jun 15 05:32:07 2012 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 15 Jun 2012 12:32:07 +0200 Subject: IPv6 Lo. for 6PE/6VPE In-Reply-To: References: Message-ID: <20120615103207.GA20157@srv03.cluenet.de> On Fri, Jun 15, 2012 at 11:56:05AM +0200, mohamed Osama Saad Abo sree wrote: > I was just wondering , while I'm planning my network to support 6PE/6VPE > why should i assign an IPv6 for Loopbacks? > > Maybe it's needed for Point-Point links or external interfaces between my > peers, but anyone here know why i should assign IPv6 for all my Routers > inside my ISP if we will run PE/6VPE not dual stack. Otherwise the intermediate P devices do not have an address to source ICMPv6 "hop count exceeded" error replies => traceroute doesn't work properly. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From james at freedomnet.co.nz Fri Jun 15 05:48:40 2012 From: james at freedomnet.co.nz (james jones) Date: Fri, 15 Jun 2012 06:48:40 -0400 Subject: IPv6 Lo. for 6PE/6VPE In-Reply-To: <20120615103207.GA20157@srv03.cluenet.de> References: <20120615103207.GA20157@srv03.cluenet.de> Message-ID: @Daniel +1 On Fri, Jun 15, 2012 at 6:32 AM, Daniel Roesen wrote: > On Fri, Jun 15, 2012 at 11:56:05AM +0200, mohamed Osama Saad Abo sree > wrote: > > I was just wondering , while I'm planning my network to support 6PE/6VPE > > why should i assign an IPv6 for Loopbacks? > > > > Maybe it's needed for Point-Point links or external interfaces between my > > peers, but anyone here know why i should assign IPv6 for all my Routers > > inside my ISP if we will run PE/6VPE not dual stack. > > Otherwise the intermediate P devices do not have an address to source > ICMPv6 "hop count exceeded" error replies => traceroute doesn't work > properly. > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > > From naikumar at cisco.com Fri Jun 15 05:52:17 2012 From: naikumar at cisco.com (Nagendra Kumar (naikumar)) Date: Fri, 15 Jun 2012 10:52:17 +0000 Subject: IPv6 Lo. for 6PE/6VPE In-Reply-To: <20120615103207.GA20157@srv03.cluenet.de> References: <20120615103207.GA20157@srv03.cluenet.de> Message-ID: <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> Hi, Per my understanding, it is not required to have ipv6 address in loopback intf on all P routers inorder to have 6PE work. If I remember it correctly, P router will use ::FFFF:: while originating ICMPv6 error message. -Nagendra -----Original Message----- From: Daniel Roesen [mailto:dr at cluenet.de] Sent: Friday, June 15, 2012 4:02 PM To: nanog at nanog.org Subject: Re: IPv6 Lo. for 6PE/6VPE On Fri, Jun 15, 2012 at 11:56:05AM +0200, mohamed Osama Saad Abo sree wrote: > I was just wondering , while I'm planning my network to support > 6PE/6VPE why should i assign an IPv6 for Loopbacks? > > Maybe it's needed for Point-Point links or external interfaces between > my peers, but anyone here know why i should assign IPv6 for all my > Routers inside my ISP if we will run PE/6VPE not dual stack. Otherwise the intermediate P devices do not have an address to source ICMPv6 "hop count exceeded" error replies => traceroute doesn't work properly. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From adam.vitkovsky at swan.sk Fri Jun 15 06:29:57 2012 From: adam.vitkovsky at swan.sk (adam vitkovsky) Date: Fri, 15 Jun 2012 13:29:57 +0200 Subject: IPv6 Lo. for 6PE/6VPE In-Reply-To: <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> References: <20120615103207.GA20157@srv03.cluenet.de> <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> Message-ID: <015c01cd4aea$31a063d0$94e12b70$@swan.sk> Right the ::FFFF:: sounds familiar I guess there was also an option that the P router would just label switch the packet towards the exit PE and the PE would than originate the ICMP back to source Or you can turn off TTL propagation across the core -so the ICMP could only time out at the PEs adam -----Original Message----- From: Nagendra Kumar (naikumar) [mailto:naikumar at cisco.com] Sent: Friday, June 15, 2012 12:52 PM To: Daniel Roesen; nanog at nanog.org Subject: RE: IPv6 Lo. for 6PE/6VPE Hi, Per my understanding, it is not required to have ipv6 address in loopback intf on all P routers inorder to have 6PE work. If I remember it correctly, P router will use ::FFFF:: while originating ICMPv6 error message. -Nagendra -----Original Message----- From: Daniel Roesen [mailto:dr at cluenet.de] Sent: Friday, June 15, 2012 4:02 PM To: nanog at nanog.org Subject: Re: IPv6 Lo. for 6PE/6VPE On Fri, Jun 15, 2012 at 11:56:05AM +0200, mohamed Osama Saad Abo sree wrote: > I was just wondering , while I'm planning my network to support > 6PE/6VPE why should i assign an IPv6 for Loopbacks? > > Maybe it's needed for Point-Point links or external interfaces between > my peers, but anyone here know why i should assign IPv6 for all my > Routers inside my ISP if we will run PE/6VPE not dual stack. Otherwise the intermediate P devices do not have an address to source ICMPv6 "hop count exceeded" error replies => traceroute doesn't work properly. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From mohamed.abosree at gmail.com Fri Jun 15 06:39:05 2012 From: mohamed.abosree at gmail.com (mohamed Osama Saad Abo sree) Date: Fri, 15 Jun 2012 13:39:05 +0200 Subject: IPv6 Lo. for 6PE/6VPE In-Reply-To: <015c01cd4aea$31a063d0$94e12b70$@swan.sk> References: <20120615103207.GA20157@srv03.cluenet.de> <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> <015c01cd4aea$31a063d0$94e12b70$@swan.sk> Message-ID: Thanks all, That's sound more logic to me, so we assign IPv6 for lo0 on every hop, so it can understand ICMP control packet. But who would use these packets? If I'm at my 6PE then i ping using Lo0 IPv4 address because we are not enabling IPV6 Routing/Dual stack so it can carry IPv6 addresses across my backbone. I mean to use IPv6 on loopbacks then i need to advertise them on some routing protocol BGP/OPSF but actually we are not enabling these protocols in the Core. An i correct in my logic? BR, Mohamed On Fri, Jun 15, 2012 at 1:29 PM, adam vitkovsky wrote: > Right the ::FFFF:: sounds familiar > I guess there was also an option that the P router would just label switch > the packet towards the exit PE and the PE would than originate the ICMP > back > to source > Or you can turn off TTL propagation across the core -so the ICMP could only > time out at the PEs > > adam > -----Original Message----- > From: Nagendra Kumar (naikumar) [mailto:naikumar at cisco.com] > Sent: Friday, June 15, 2012 12:52 PM > To: Daniel Roesen; nanog at nanog.org > Subject: RE: IPv6 Lo. for 6PE/6VPE > > Hi, > > Per my understanding, it is not required to have ipv6 address in loopback > intf on all P routers inorder to have 6PE work. If I remember it correctly, > P router will use ::FFFF:: while originating ICMPv6 error > message. > > -Nagendra > > -----Original Message----- > From: Daniel Roesen [mailto:dr at cluenet.de] > Sent: Friday, June 15, 2012 4:02 PM > To: nanog at nanog.org > Subject: Re: IPv6 Lo. for 6PE/6VPE > > On Fri, Jun 15, 2012 at 11:56:05AM +0200, mohamed Osama Saad Abo sree > wrote: > > I was just wondering , while I'm planning my network to support > > 6PE/6VPE why should i assign an IPv6 for Loopbacks? > > > > Maybe it's needed for Point-Point links or external interfaces between > > my peers, but anyone here know why i should assign IPv6 for all my > > Routers inside my ISP if we will run PE/6VPE not dual stack. > > Otherwise the intermediate P devices do not have an address to source > ICMPv6 "hop count exceeded" error replies => traceroute doesn't work > properly. > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > > > > > -- Live As If You Were To Die Tomorrow. Learn As If You Were To Live Forever. From owen at delong.com Fri Jun 15 06:35:51 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Jun 2012 04:35:51 -0700 Subject: IPv6 Lo. for 6PE/6VPE In-Reply-To: <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> References: <20120615103207.GA20157@srv03.cluenet.de> <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> Message-ID: <2811C7BC-3A02-4DF7-A1DC-933DB3C4537D@delong.com> If it does, that's bad... You should never see IPv4 mapped addresses on the wire. They should only be an internal representation of an IPv4 packet within the host. Owen On Jun 15, 2012, at 3:52 AM, Nagendra Kumar (naikumar) wrote: > Hi, > > Per my understanding, it is not required to have ipv6 address in loopback intf on all P routers inorder to have 6PE work. If I remember it correctly, P router will use ::FFFF:: while originating ICMPv6 error message. > > -Nagendra > > -----Original Message----- > From: Daniel Roesen [mailto:dr at cluenet.de] > Sent: Friday, June 15, 2012 4:02 PM > To: nanog at nanog.org > Subject: Re: IPv6 Lo. for 6PE/6VPE > > On Fri, Jun 15, 2012 at 11:56:05AM +0200, mohamed Osama Saad Abo sree wrote: >> I was just wondering , while I'm planning my network to support >> 6PE/6VPE why should i assign an IPv6 for Loopbacks? >> >> Maybe it's needed for Point-Point links or external interfaces between >> my peers, but anyone here know why i should assign IPv6 for all my >> Routers inside my ISP if we will run PE/6VPE not dual stack. > > Otherwise the intermediate P devices do not have an address to source > ICMPv6 "hop count exceeded" error replies => traceroute doesn't work properly. > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 > From dr at cluenet.de Fri Jun 15 07:57:34 2012 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 15 Jun 2012 14:57:34 +0200 Subject: IPv6 Lo. for 6PE/6VPE In-Reply-To: <2811C7BC-3A02-4DF7-A1DC-933DB3C4537D@delong.com> References: <20120615103207.GA20157@srv03.cluenet.de> <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> <2811C7BC-3A02-4DF7-A1DC-933DB3C4537D@delong.com> Message-ID: <20120615125734.GA5575@srv03.cluenet.de> On Fri, Jun 15, 2012 at 04:35:51AM -0700, Owen DeLong wrote: > If it does, that's bad... You should never see IPv4 mapped addresses > on the wire. ... and some networks filter packets with source address in the mapped range, so traceroute will be broken for 6PE intermediate P hops. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From robert at mckay.com Fri Jun 15 08:07:15 2012 From: robert at mckay.com (Robert McKay) Date: Fri, 15 Jun 2012 14:07:15 +0100 Subject: IPv6 Lo. for 6PE/6VPE In-Reply-To: <2811C7BC-3A02-4DF7-A1DC-933DB3C4537D@delong.com> References: <20120615103207.GA20157@srv03.cluenet.de> <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> <2811C7BC-3A02-4DF7-A1DC-933DB3C4537D@delong.com> Message-ID: You mean like this? ;) 1. ??? 2. ldn-ipv6-b1.ipv6.telia.net 0.0% 3 1.0 1.2 1.0 1.4 0.2 3. cogent-ic-125507-ldn-b5.c.telia.net 0.0% 2 40.6 40.4 40.2 40.6 0.3 4. ::ffff:154.54.57.102 0.0% 2 129.1 129.1 129.1 129.1 0.0 5. ::ffff:154.54.30.129 0.0% 2 120.2 120.0 119.8 120.2 0.3 6. 2001:550::100 0.0% 2 120.2 120.3 120.2 120.5 0.2 7. ::ffff:154.54.5.253 0.0% 2 120.5 120.3 120.1 120.5 0.3 8. ??? 9. cogentco.com 0.0% 2 119.9 119.9 119.9 119.9 0.0 Rob On Fri, 15 Jun 2012 04:35:51 -0700, Owen DeLong wrote: > If it does, that's bad... You should never see IPv4 mapped addresses > on the wire. > They should only be an internal representation of an IPv4 packet > within the host. > > Owen > > On Jun 15, 2012, at 3:52 AM, Nagendra Kumar (naikumar) wrote: > >> Hi, >> >> Per my understanding, it is not required to have ipv6 address in >> loopback intf on all P routers inorder to have 6PE work. If I remember >> it correctly, P router will use ::FFFF:: while originating >> ICMPv6 error message. >> >> -Nagendra >> >> -----Original Message----- >> From: Daniel Roesen [mailto:dr at cluenet.de] >> Sent: Friday, June 15, 2012 4:02 PM >> To: nanog at nanog.org >> Subject: Re: IPv6 Lo. for 6PE/6VPE >> >> On Fri, Jun 15, 2012 at 11:56:05AM +0200, mohamed Osama Saad Abo >> sree wrote: >>> I was just wondering , while I'm planning my network to support >>> 6PE/6VPE why should i assign an IPv6 for Loopbacks? >>> >>> Maybe it's needed for Point-Point links or external interfaces >>> between >>> my peers, but anyone here know why i should assign IPv6 for all my >>> Routers inside my ISP if we will run PE/6VPE not dual stack. >> >> Otherwise the intermediate P devices do not have an address to >> source >> ICMPv6 "hop count exceeded" error replies => traceroute doesn't work >> properly. >> >> Best regards, >> Daniel >> >> -- >> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 >> From valdis.kletnieks at vt.edu Fri Jun 15 08:07:20 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 15 Jun 2012 09:07:20 -0400 Subject: IPv6 Lo. for 6PE/6VPE In-Reply-To: Your message of "Fri, 15 Jun 2012 10:52:17 -0000." <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> References: <20120615103207.GA20157@srv03.cluenet.de> <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> Message-ID: <44984.1339765640@turing-police.cc.vt.edu> On Fri, 15 Jun 2012 10:52:17 -0000, "Nagendra Kumar (naikumar)" said: > Per my understanding, it is not required to have ipv6 address in loopback > intf on all P routers inorder to have 6PE work. If I remember it correctly, P > router will use ::FFFF:: while originating ICMPv6 error message. How the heck is that supposed to work in an all-IPv6 network where you don't *have* an ipv4-addr? Plus, as Owen noted, leaking those on the wire is considered bad form. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From fernando at gont.com.ar Fri Jun 15 09:56:03 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 15 Jun 2012 11:56:03 -0300 Subject: IETF I-D: Current issues with DNS Configuration Options for SLAAC Message-ID: <4FDB4D03.2020301@gont.com.ar> Folks, We have published a new IETF I-D entitled "Current issues with DNS Configuration Options for SLAAC", about existing problems with the DNS configuration options used with SLAAC. The I-D is available at: . Abstract: ---- cut here ---- RFC 6106 specifies two Neighbor Discovery options that can be included in Router Advertisement messages to convey information about DNS recursive servers and DNS Search Lists. Small lifetime values for the aforementioned options have been found to cause interoperability problems in those network scenarios in which these options are used to convey DNS-related information. This document analyzes the aforementioned problem, and formally updates RFC 6106 such that these issues are mitigated. ---- cut here ---- This version of the I-D discusses different *alternative* mitigations for the forementioned problem. Your input will be very appreciated. Thanks! Best regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando at gont.com.ar Fri Jun 15 10:34:54 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 15 Jun 2012 12:34:54 -0300 Subject: Article: IPv6 host scanning attacks In-Reply-To: <1339629849.4657.55.camel@karl> References: <4FD838BE.6050705@gont.com.ar> <1339629849.4657.55.camel@karl> Message-ID: <4FDB561E.6080402@gont.com.ar> On 06/13/2012 08:24 PM, Karl Auer wrote: > On Wed, 2012-06-13 at 15:22 -0500, STARNES, CURTIS wrote: >> I have a slight problem with stating that "Vast IPv6 address space >> actually enables IPv6 attacks". > > So do I. As noted, so do I. :-) > Compared to IPv4, scanning IPv6 is much, much harder, and that > is (I think) the most important thing to know. IMO, the important thing to know is that IPv6 host scanning attacks are not infeasible -- even when it has been used as a marketing argument for years. > The analysis was good in that it offered a bit of consideration to the > scanning issue, but... > > "Some estimates peg the length of time for a host-scanning attack on a > single IPv6 subnet at 500,000,000 years!" > > It's not an estimate. It's a approximation based on scanning a /64 > subnet at a thousand probes per second. 18 billion billion (addresses in > one /64) divided by one thousand, divided by 31536000 (the number of > seconds in a year) - works out to about 500,000,000. Exactly. Nice math, but it suffers from an incorrect assumption: that attacker will do brute force scans in the same way that they did for v4. In v4, the scale of the "problem" was small enough that even doing a bad job a la "brute force" was good enough. With v6, one needs to put more brains into the scanning logic, or else won't be able to get away with it. > >> .Embed the MAC address; >> .Employ low-byte addresses; >> .Embed the IPv4 address; >> .Use a "wordy" address; >> .Use a privacy or temporary address; >> .Rely on a transition or coexistence technology. > > Why do you not mention DHCP in this list? You do mention it elsewhere. > DHCPv6 will in general supply random addresses. You say that "some" > DHCPv6 servers produce sequential addresses - could you please give an > example? I use Nominum's DCS, which certainly does NOT do this very > foolish thing. Let me check what I'm running in my test lab (I will come back to you regarding this one) -- most likely KAME's implementation? > Low-byte addresses are generally going to be on high-value devices, > which will usually be servers (whose existence is thus public knowledge > anyway) There's a subtle detail here: One thing is having individual addresses being publicly available, but another is being able to find them all very easily. Example: Say I'm running hundreds of web sites on the same subnet (just an *example*).. You might argue that each of those addresses is 2public knowledge". However, that doesn't mean it's trivial for an attacker to (easily) find out all "alive" sites on a given subnet. If you use predictable addresses, that becomes possible. > Embedded IPv4 addresses are going to be a reducing problem, and in the > scenario you mention, as well as in most other scenarios, again mostly > on machines that have very strong protections from firewalls and their > own packet filters. I tend to disagree about "strong protection". For instance, recent findings seem to indicate lack of parity in filtering rules for v6 and v4 -- i.e., unfortunately, it's quite common that something that is blocked in v4 is *allowed* on v6. > Wordy addresses will be an issue for some vanishingly small percentage > of systems, and generally systems that their owners want people to see > (Facebook being a good example). These are generally going to be systems > whose existence is public knowledge anyway. Agreed. > All transition technologies are a reducing problem. The primary > transition technology - dual stack - has no technology-specific problems > in respect of scanning (except perhaps that the scanner, at least in > theory, gets two bites at the cherry). Agreed. > I think you are making a minor issue look far bigger than it is. IMO, IPv6 host scanning attacks being feasible is not e big thing by itself -- for instance, we have "survived" this problem for v4, so at least in theory there's no reason to believe that the sky is going to fall for the v6 case. What *is* important, IMO, is the amount of IPv6 mythology that there is out there, which leads to incorrect assumptions, and eventually to negative implications. >From the general "security considered during the design of the protocol rather than as an 'add on'" to "scanning attacks are impossible". When it comes to scanning, IMO it's more of "oh, yeah, it's feasible.. and the fix is obvious... let's fix it", than "let's gets scared about ipv6 host scannign". > I feel > the privacy issues around SLAAC are far more significant in the real > world than any threat from scanning. Unfortunately, one still hears in IETF corridors things like "not everyone needs privacy" from some mobile vendors... (sigh) > PS: I still like your RFC about stable privacy addresses. Thanks. That's where the "meat" is.. FWIW, articles such as the one I forwarded are mostly meant to raise awareness, such that folks in the position of implementing stuff such as draft-ietf-6man-stable-privacy-addresses actually do it. > PPS: There seems to be a diagram missing in the discussion of embedded > MAC addresses, after the word "syntax". Will check. Thanks! Cheers, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando at gont.com.ar Fri Jun 15 10:49:03 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Fri, 15 Jun 2012 12:49:03 -0300 Subject: Article: IPv6 host scanning attacks In-Reply-To: References: <4FD838BE.6050705@gont.com.ar> Message-ID: <4FDB596F.6080101@gont.com.ar> On 06/13/2012 05:22 PM, STARNES, CURTIS wrote: > Going from an IPv4 32 bit address space to a IPv6 128 bit address > space like you mentioned in the article would be a tedious effort to > scan. (tedious != infeasible) && (tedious < 500000000 years) -- that's the point the article is trying to make. > That sounds fine and dandy but in reality, Internet facing IPv6 > native or dual-stack systems that are installed with any security > forethought at all would not embed any of these options with the > exception of the last one (transitional or coexistence) only if > forced to do so. Well, as far as I've measured, they do. > I agree that some IPv6 addresses are set up to have catchy names, but > why set up hundreds or even thousands of IPv6 addresses with IPv6 > addresses that you try to remember like we did with IPv4? Because that's what you're used to? -- and no, I'm not arguing in favor of that, but rather accepting human's resistance to change. > In general, I just don't agree with your conclusions, and with proper > IPv6 firewall rules, the network should still be as secure as the > IPv4 systems. Not more insecure just because they run an IPv6 > stack. Your making a much broader claim here. When it comes to scanning attacks, they are likely to be harder than for the IPv4 case. However, when it comes to IPv6 security vs. IPv4 security, I'd expect v6 to be worse than v4, not (necessarily/only) for the protocol itself -- please see slide 8 of Cheers, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jra at baylink.com Fri Jun 15 10:59:26 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 15 Jun 2012 11:59:26 -0400 (EDT) Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! Message-ID: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From valdis.kletnieks at vt.edu Fri Jun 15 11:25:16 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 15 Jun 2012 12:25:16 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: Your message of "Fri, 15 Jun 2012 11:59:26 -0400." <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> Message-ID: <8211.1339777516@turing-police.cc.vt.edu> On Fri, 15 Jun 2012 11:59:26 -0400, Jay Ashworth said: > http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ So everybody who's ever not bothered SWIP'ing an IPv4 allocation is helping the terrorists? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From johnl at iecc.com Fri Jun 15 11:34:02 2012 From: johnl at iecc.com (John Levine) Date: 15 Jun 2012 16:34:02 -0000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <8211.1339777516@turing-police.cc.vt.edu> Message-ID: <20120615163402.7773.qmail@joyce.lan> >So everybody who's ever not bothered SWIP'ing an IPv4 allocation is helping the terrorists? Yes, of course. Mindless, irrational reactions to overblown threats are everyone's job. R's, John PS: Why do you hate America? From lists at mtin.net Fri Jun 15 12:24:16 2012 From: lists at mtin.net (Justin Wilson) Date: Fri, 15 Jun 2012 13:24:16 -0400 Subject: Simple Peering Agreement Message-ID: Does anyone have a simple (1-2 page) peering agreement in plain English they would care to share offlist? Thanks, Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter From isabeldias1 at yahoo.com Fri Jun 15 12:36:22 2012 From: isabeldias1 at yahoo.com (Isabel Dias) Date: Fri, 15 Jun 2012 10:36:22 -0700 (PDT) Subject: Simple Peering Agreement In-Reply-To: Message-ID: <1339781782.26360.YahooMailClassic@web121606.mail.ne1.yahoo.com> are you any good in Maths? ? ? http://www.stanford.edu/~milgrom/publishedarticles/Advances%20in%20Routing%20Technologies%20and%20Internet%20Peering%20Agr.%202001.pdf ? ? ? maybe a PhD will find a point in using this part of their self-development ? how far can you go and what is your position in the world? ? I guess linking countries is easy if you are offer the position but you can't move from there can you?? so the revenue in peering agreements not free peering but private peering is maybe what they look fw to achieve. ? ? i guess a new model might be under research as this one is an old IPv4 one and IPv6 peering agreements are in production ......maybe with internet 2 too....... --- On Fri, 6/15/12, Justin Wilson wrote: From: Justin Wilson Subject: Simple Peering Agreement To: "NANOG (nanog at nanog.org)" Date: Friday, June 15, 2012, 7:24 PM Does anyone have a simple (1-2 page) peering agreement in plain English they would care to share offlist? Thanks, Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter From nick at foobar.org Fri Jun 15 12:37:17 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 15 Jun 2012 18:37:17 +0100 Subject: Simple Peering Agreement In-Reply-To: References: Message-ID: <4FDB72CD.6060309@foobar.org> On 15/06/2012 18:24, Justin Wilson wrote: > Does anyone have a simple (1-2 page) peering agreement in plain English they > would care to share offlist? http://www.google.com/search?q=peering%20agreement%20%2Bfiletype%3Adoc Nick From william.mccall at gmail.com Fri Jun 15 12:40:02 2012 From: william.mccall at gmail.com (William McCall) Date: Fri, 15 Jun 2012 12:40:02 -0500 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120615163402.7773.qmail@joyce.lan> References: <8211.1339777516@turing-police.cc.vt.edu> <20120615163402.7773.qmail@joyce.lan> Message-ID: On Fri, Jun 15, 2012 at 11:34 AM, John Levine wrote: >>So everybody who's ever not bothered SWIP'ing an IPv4 allocation is helping the terrorists? > > Yes, of course. ?Mindless, irrational reactions to overblown threats are > everyone's job. I want some of that stupid for breakfast too. What brand is it? -- William McCall From garrett at skjelstad.org Fri Jun 15 12:39:19 2012 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Fri, 15 Jun 2012 10:39:19 -0700 Subject: Simple Peering Agreement In-Reply-To: <4FDB72CD.6060309@foobar.org> References: <4FDB72CD.6060309@foobar.org> Message-ID: <2C6C5164-77EB-45D7-B065-A25225CB5F52@skjelstad.org> Also: s/doc/PDF/g Sent from my iPhone On Jun 15, 2012, at 10:37, Nick Hilliard wrote: > On 15/06/2012 18:24, Justin Wilson wrote: >> Does anyone have a simple (1-2 page) peering agreement in plain English they >> would care to share offlist? > > http://www.google.com/search?q=peering%20agreement%20%2Bfiletype%3Adoc > > Nick > From woody at pch.net Fri Jun 15 12:57:24 2012 From: woody at pch.net (Bill Woodcock) Date: Fri, 15 Jun 2012 10:57:24 -0700 Subject: Simple Peering Agreement In-Reply-To: <1339781782.26360.YahooMailClassic@web121606.mail.ne1.yahoo.com> References: <1339781782.26360.YahooMailClassic@web121606.mail.ne1.yahoo.com> Message-ID: <6EBBD5C5-0B09-42EE-9C6B-DEF2E4FA9F6C@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Jun 15, 2012, at 10:36 AM, Isabel Dias wrote: > are you any good in Maths? > http://www.stanford.edu/~milgrom/publishedarticles/Advances%20in%20Routing%20Technologies%20and%20Internet%20Peering%20Agr.%202001.pdf If you're good in maths, you'll realize that the simple peering agreement is the one that covers 99.5% of interconnections, and is well enough understood that it need not be committed to paper. :-) http://www.pch.net/resources/papers/peering-survey/PCH-Peering-Survey-2011.pdf -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJP23eFAAoJEG+kcEsoi3+HSJ8P+wTeik0+xr1o5R8hTVsCKsrI +xwxAOzE5yjt8MXqAKqOWCFqWBWy1xaXcetUiKW/0SKjK+5Uz2OVUsPHnDc6xX/k clhM5b2rsB7T5NkRzBO26kfCMXEAL1v9peafxzc3XWjXuOtbf6UnBwH6+OIgiLrM +1Sbj/fVI/CwFYhpRRPW77itttfS6srka5uz06vB0XN69VQ7mn/bESOChaypf31K Vn3MZhn6byCVDcyrEOH5QtK5DAW1EQrZLbZA9e6VwrrartSjiwP9N9QuVGZ0fXhr uKnlQwxJXX1z/hC1REQcYLN4yuRcEFvKJj1t/3yuOoA00TvWZyYiKtzdTnUNmK5c BFPImwyod/X0qZHTfzik+dIHbO5vlS31jL/I4xmKn5PYKjNXSODx4viN+C39Je+r IR07ppVUv8du4cwDzxDVldFuT8HGv3X3fS5NI1iJUiJFqD5fR/6y1E4EOhGZkVa3 DI1WwEcSS/mJiW0BgHhuWmHAK++mXANP8qKWZcVNmP7BDwJ8hUKg4tltepVkyvUp VyPc4vOns/06TvEM3F8i2nCuCxDxhftsvHnGepYijvSPko25NDCOE5g2VBlITCf2 neGZ8xttsnTiAqGG5oHYsMWyMg1kjodGHMR2oBzPeNUTUMyOJFM2Ro8TfDvX9b1/ 43LgwdG9N3ExiUpAmKcO =lm/u -----END PGP SIGNATURE----- From lists at mtin.net Fri Jun 15 13:10:14 2012 From: lists at mtin.net (Justin Wilson) Date: Fri, 15 Jun 2012 14:10:14 -0400 Subject: Simple Peering Agreement In-Reply-To: <6EBBD5C5-0B09-42EE-9C6B-DEF2E4FA9F6C@pch.net> Message-ID: I need paperwork to justify several things the bean counters want to see on paper. It's hard to present why you need 5 additional 10Gig ports when you have nothing on paper of why those ports are being used. Justin -----Original Message----- From: Bill Woodcock Date: Friday, June 15, 2012 1:57 PM To: "NANOG (nanog at nanog.org)" Subject: Re: Simple Peering Agreement >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > > >On Jun 15, 2012, at 10:36 AM, Isabel Dias wrote: >> are you any good in Maths? >> >>http://www.stanford.edu/~milgrom/publishedarticles/Advances%20in%20Routin >>g%20Technologies%20and%20Internet%20Peering%20Agr.%202001.pdf > >If you're good in maths, you'll realize that the simple peering agreement >is the one that covers 99.5% of interconnections, and is well enough >understood that it need not be committed to paper. :-) > >http://www.pch.net/resources/papers/peering-survey/PCH-Peering-Survey-2011 >.pdf > > -Bill > > > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >Comment: GPGTools - http://gpgtools.org > >iQIcBAEBCAAGBQJP23eFAAoJEG+kcEsoi3+HSJ8P+wTeik0+xr1o5R8hTVsCKsrI >+xwxAOzE5yjt8MXqAKqOWCFqWBWy1xaXcetUiKW/0SKjK+5Uz2OVUsPHnDc6xX/k >clhM5b2rsB7T5NkRzBO26kfCMXEAL1v9peafxzc3XWjXuOtbf6UnBwH6+OIgiLrM >+1Sbj/fVI/CwFYhpRRPW77itttfS6srka5uz06vB0XN69VQ7mn/bESOChaypf31K >Vn3MZhn6byCVDcyrEOH5QtK5DAW1EQrZLbZA9e6VwrrartSjiwP9N9QuVGZ0fXhr >uKnlQwxJXX1z/hC1REQcYLN4yuRcEFvKJj1t/3yuOoA00TvWZyYiKtzdTnUNmK5c >BFPImwyod/X0qZHTfzik+dIHbO5vlS31jL/I4xmKn5PYKjNXSODx4viN+C39Je+r >IR07ppVUv8du4cwDzxDVldFuT8HGv3X3fS5NI1iJUiJFqD5fR/6y1E4EOhGZkVa3 >DI1WwEcSS/mJiW0BgHhuWmHAK++mXANP8qKWZcVNmP7BDwJ8hUKg4tltepVkyvUp >VyPc4vOns/06TvEM3F8i2nCuCxDxhftsvHnGepYijvSPko25NDCOE5g2VBlITCf2 >neGZ8xttsnTiAqGG5oHYsMWyMg1kjodGHMR2oBzPeNUTUMyOJFM2Ro8TfDvX9b1/ >43LgwdG9N3ExiUpAmKcO >=lm/u >-----END PGP SIGNATURE----- > > From valdis.kletnieks at vt.edu Fri Jun 15 13:17:35 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 15 Jun 2012 14:17:35 -0400 Subject: Simple Peering Agreement In-Reply-To: Your message of "Fri, 15 Jun 2012 14:10:14 -0400." References: Message-ID: <14168.1339784255@turing-police.cc.vt.edu> On Fri, 15 Jun 2012 14:10:14 -0400, Justin Wilson said: > I need paperwork to justify several things the bean counters want to see > on paper. It's hard to present why you need 5 additional 10Gig ports when > you have nothing on paper of why those ports are being used. If you can't already enumerate the use of those 5 ports, a piece of paper isn't going to help fix the real problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From isabeldias1 at yahoo.com Fri Jun 15 13:53:48 2012 From: isabeldias1 at yahoo.com (Isabel Dias) Date: Fri, 15 Jun 2012 11:53:48 -0700 (PDT) Subject: Simple Peering Agreement In-Reply-To: Message-ID: <1339786428.86673.YahooMailClassic@web121601.mail.ne1.yahoo.com> http://www.as9009.net/policy/ --- On Fri, 6/15/12, Justin Wilson wrote: From: Justin Wilson Subject: Re: Simple Peering Agreement To: "NANOG (nanog at nanog.org)" Date: Friday, June 15, 2012, 8:10 PM ??? I need paperwork to justify several things the bean counters want to see on paper.? It's hard to present why you need 5 additional 10Gig ports when you have nothing on paper of why those ports are being used. ??? Justin -----Original Message----- From: Bill Woodcock Date: Friday, June 15, 2012 1:57 PM To: "NANOG (nanog at nanog.org)" Subject: Re: Simple Peering Agreement >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > > >On Jun 15, 2012, at 10:36 AM, Isabel Dias wrote: >> are you any good in Maths? >> >>http://www.stanford.edu/~milgrom/publishedarticles/Advances%20in%20Routin >>g%20Technologies%20and%20Internet%20Peering%20Agr.%202001.pdf > >If you're good in maths, you'll realize that the simple peering agreement >is the one that covers 99.5% of interconnections, and is well enough >understood that it need not be committed to paper.? :-) > >http://www.pch.net/resources/papers/peering-survey/PCH-Peering-Survey-2011 >.pdf > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -Bill > > > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >Comment: GPGTools - http://gpgtools.org > >iQIcBAEBCAAGBQJP23eFAAoJEG+kcEsoi3+HSJ8P+wTeik0+xr1o5R8hTVsCKsrI >+xwxAOzE5yjt8MXqAKqOWCFqWBWy1xaXcetUiKW/0SKjK+5Uz2OVUsPHnDc6xX/k >clhM5b2rsB7T5NkRzBO26kfCMXEAL1v9peafxzc3XWjXuOtbf6UnBwH6+OIgiLrM >+1Sbj/fVI/CwFYhpRRPW77itttfS6srka5uz06vB0XN69VQ7mn/bESOChaypf31K >Vn3MZhn6byCVDcyrEOH5QtK5DAW1EQrZLbZA9e6VwrrartSjiwP9N9QuVGZ0fXhr >uKnlQwxJXX1z/hC1REQcYLN4yuRcEFvKJj1t/3yuOoA00TvWZyYiKtzdTnUNmK5c >BFPImwyod/X0qZHTfzik+dIHbO5vlS31jL/I4xmKn5PYKjNXSODx4viN+C39Je+r >IR07ppVUv8du4cwDzxDVldFuT8HGv3X3fS5NI1iJUiJFqD5fR/6y1E4EOhGZkVa3 >DI1WwEcSS/mJiW0BgHhuWmHAK++mXANP8qKWZcVNmP7BDwJ8hUKg4tltepVkyvUp >VyPc4vOns/06TvEM3F8i2nCuCxDxhftsvHnGepYijvSPko25NDCOE5g2VBlITCf2 >neGZ8xttsnTiAqGG5oHYsMWyMg1kjodGHMR2oBzPeNUTUMyOJFM2Ro8TfDvX9b1/ >43LgwdG9N3ExiUpAmKcO >=lm/u >-----END PGP SIGNATURE----- > > From isabeldias1 at yahoo.com Fri Jun 15 13:55:22 2012 From: isabeldias1 at yahoo.com (Isabel Dias) Date: Fri, 15 Jun 2012 11:55:22 -0700 (PDT) Subject: Simple Peering Agreement In-Reply-To: <6EBBD5C5-0B09-42EE-9C6B-DEF2E4FA9F6C@pch.net> Message-ID: <1339786522.35403.YahooMailClassic@web121604.mail.ne1.yahoo.com> http://gogonetlive.com/pdf/gogonet_live2/chris_grundemann.pdf --- On Fri, 6/15/12, Bill Woodcock wrote: From: Bill Woodcock Subject: Re: Simple Peering Agreement To: "NANOG (nanog at nanog.org)" Date: Friday, June 15, 2012, 7:57 PM -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Jun 15, 2012, at 10:36 AM, Isabel Dias wrote: > are you any good in Maths? > http://www.stanford.edu/~milgrom/publishedarticles/Advances%20in%20Routing%20Technologies%20and%20Internet%20Peering%20Agr.%202001.pdf If you're good in maths, you'll realize that the simple peering agreement is the one that covers 99.5% of interconnections, and is well enough understood that it need not be committed to paper.? :-) http://www.pch.net/resources/papers/peering-survey/PCH-Peering-Survey-2011.pdf ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJP23eFAAoJEG+kcEsoi3+HSJ8P+wTeik0+xr1o5R8hTVsCKsrI +xwxAOzE5yjt8MXqAKqOWCFqWBWy1xaXcetUiKW/0SKjK+5Uz2OVUsPHnDc6xX/k clhM5b2rsB7T5NkRzBO26kfCMXEAL1v9peafxzc3XWjXuOtbf6UnBwH6+OIgiLrM +1Sbj/fVI/CwFYhpRRPW77itttfS6srka5uz06vB0XN69VQ7mn/bESOChaypf31K Vn3MZhn6byCVDcyrEOH5QtK5DAW1EQrZLbZA9e6VwrrartSjiwP9N9QuVGZ0fXhr uKnlQwxJXX1z/hC1REQcYLN4yuRcEFvKJj1t/3yuOoA00TvWZyYiKtzdTnUNmK5c BFPImwyod/X0qZHTfzik+dIHbO5vlS31jL/I4xmKn5PYKjNXSODx4viN+C39Je+r IR07ppVUv8du4cwDzxDVldFuT8HGv3X3fS5NI1iJUiJFqD5fR/6y1E4EOhGZkVa3 DI1WwEcSS/mJiW0BgHhuWmHAK++mXANP8qKWZcVNmP7BDwJ8hUKg4tltepVkyvUp VyPc4vOns/06TvEM3F8i2nCuCxDxhftsvHnGepYijvSPko25NDCOE5g2VBlITCf2 neGZ8xttsnTiAqGG5oHYsMWyMg1kjodGHMR2oBzPeNUTUMyOJFM2Ro8TfDvX9b1/ 43LgwdG9N3ExiUpAmKcO =lm/u -----END PGP SIGNATURE----- From jra at baylink.com Fri Jun 15 14:00:20 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 15 Jun 2012 15:00:20 -0400 (EDT) Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <8211.1339777516@turing-police.cc.vt.edu> Message-ID: <2304851.9586.1339786820216.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "valdis kletnieks" > On Fri, 15 Jun 2012 11:59:26 -0400, Jay Ashworth said: > > http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ > > So everybody who's ever not bothered SWIP'ing an IPv4 allocation is > helping the terrorists? That was my evaluation, yes. Mr Curran: were you quoted accurately in this piece? Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From cscora at apnic.net Fri Jun 15 14:05:08 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Jun 2012 05:05:08 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201206151905.q5FJ58BP008471@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 Jun, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 413957 Prefixes after maximum aggregation: 175177 Deaggregation factor: 2.36 Unique aggregates announced to Internet: 201673 Total ASes present in the Internet Routing Table: 41298 Prefixes per ASN: 10.02 Origin-only ASes present in the Internet Routing Table: 33296 Origin ASes announcing only one prefix: 15667 Transit ASes present in the Internet Routing Table: 5521 Transit-only ASes present in the Internet Routing Table: 139 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 28 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 413 Unregistered ASNs in the Routing Table: 140 Number of 32-bit ASNs allocated by the RIRs: 2842 Number of 32-bit ASNs visible in the Routing Table: 2481 Prefixes from 32-bit ASNs in the Routing Table: 6297 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 331 Number of addresses announced to Internet: 2566262828 Equivalent to 152 /8s, 246 /16s and 16 /24s Percentage of available address space announced: 69.2 Percentage of allocated address space announced: 69.3 Percentage of available address space allocated: 99.9 Percentage of address space in use by end-sites: 92.9 Total number of prefixes smaller than registry allocations: 143956 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 100691 Total APNIC prefixes after maximum aggregation: 32639 APNIC Deaggregation factor: 3.08 Prefixes being announced from the APNIC address blocks: 101099 Unique aggregates announced from the APNIC address blocks: 41731 APNIC Region origin ASes present in the Internet Routing Table: 4707 APNIC Prefixes per ASN: 21.48 APNIC Region origin ASes announcing only one prefix: 1248 APNIC Region transit ASes present in the Internet Routing Table: 742 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 227 Number of APNIC addresses announced to Internet: 702947456 Equivalent to 41 /8s, 230 /16s and 32 /24s Percentage of available APNIC address space announced: 82.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 151879 Total ARIN prefixes after maximum aggregation: 77226 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 152854 Unique aggregates announced from the ARIN address blocks: 68024 ARIN Region origin ASes present in the Internet Routing Table: 15161 ARIN Prefixes per ASN: 10.08 ARIN Region origin ASes announcing only one prefix: 5752 ARIN Region transit ASes present in the Internet Routing Table: 1600 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 16 Number of ARIN addresses announced to Internet: 1081034368 Equivalent to 64 /8s, 111 /16s and 70 /24s Percentage of available ARIN address space announced: 57.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 103555 Total RIPE prefixes after maximum aggregation: 54773 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 105450 Unique aggregates announced from the RIPE address blocks: 66502 RIPE Region origin ASes present in the Internet Routing Table: 16625 RIPE Prefixes per ASN: 6.34 RIPE Region origin ASes announcing only one prefix: 8065 RIPE Region transit ASes present in the Internet Routing Table: 2664 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1645 Number of RIPE addresses announced to Internet: 630722692 Equivalent to 37 /8s, 152 /16s and 16 /24s Percentage of available RIPE address space announced: 91.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 42038 Total LACNIC prefixes after maximum aggregation: 8316 LACNIC Deaggregation factor: 5.06 Prefixes being announced from the LACNIC address blocks: 44471 Unique aggregates announced from the LACNIC address blocks: 21854 LACNIC Region origin ASes present in the Internet Routing Table: 1603 LACNIC Prefixes per ASN: 27.74 LACNIC Region origin ASes announcing only one prefix: 436 LACNIC Region transit ASes present in the Internet Routing Table: 306 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 588 Number of LACNIC addresses announced to Internet: 110613672 Equivalent to 6 /8s, 151 /16s and 212 /24s Percentage of available LACNIC address space announced: 65.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9310 Total AfriNIC prefixes after maximum aggregation: 2159 AfriNIC Deaggregation factor: 4.31 Prefixes being announced from the AfriNIC address blocks: 9752 Unique aggregates announced from the AfriNIC address blocks: 3261 AfriNIC Region origin ASes present in the Internet Routing Table: 546 AfriNIC Prefixes per ASN: 17.86 AfriNIC Region origin ASes announcing only one prefix: 166 AfriNIC Region transit ASes present in the Internet Routing Table: 119 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 40404480 Equivalent to 2 /8s, 104 /16s and 134 /24s Percentage of available AfriNIC address space announced: 40.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2672 11116 1158 Korea Telecom (KIX) 17974 1929 531 82 PT TELEKOMUNIKASI INDONESIA 7545 1684 301 86 TPG Internet Pty Ltd 4755 1593 386 155 TATA Communications formerly 9829 1300 1085 28 BSNL National Internet Backbo 9583 1183 89 509 Sify Limited 4808 1103 2049 314 CNCGROUP IP network: China169 7552 1089 1062 11 Vietel Corporation 24560 1031 385 163 Bharti Airtel Ltd., Telemedia 9498 966 291 63 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3405 3791 191 bellsouth.net, inc. 7029 3298 986 159 Windstream Communications Inc 18566 2091 382 181 Covad Communications 1785 1919 681 132 PaeTec Communications, Inc. 22773 1649 2911 121 Cox Communications, Inc. 20115 1643 1570 613 Charter Communications 4323 1574 1043 385 Time Warner Telecom 30036 1433 266 752 Mediacom Communications Corp 7018 1226 10014 825 AT&T WorldNet Services 11492 1189 216 356 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1771 544 16 Corbina telecom 2118 1239 97 14 EUnet/RELCOM Autonomous Syste 12479 745 713 90 Uni2 Autonomous System 34984 708 188 172 BILISIM TELEKOM 31148 685 37 9 FreeNet ISP 20940 676 222 528 Akamai Technologies European 6830 661 2219 427 UPC Distribution Services 8551 575 364 61 Bezeq International 3320 489 8442 402 Deutsche Telekom AG 3292 475 2108 408 TDC Tele Danmark Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1967 342 205 TVCABLE BOGOTA 28573 1917 1188 52 NET Servicos de Comunicao S.A 6503 1527 418 65 AVANTEL, S.A. 8151 1487 3068 336 UniNet S.A. de C.V. 7303 1440 901 195 Telecom Argentina Stet-France 26615 900 696 35 Tim Brasil S.A. 27947 705 73 93 Telconet S.A 11172 646 91 74 Servicios Alestra S.A de C.V 3816 584 245 92 Empresa Nacional de Telecomun 22047 583 326 15 VTR PUNTO NET S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1254 958 13 TEDATA 24863 854 274 35 LINKdotNET AS number 6713 497 649 18 Itissalat Al-MAGHRIB 24835 321 80 8 RAYA Telecom - Egypt 3741 262 905 223 The Internet Solution 33776 210 12 21 Starcomms Nigeria Limited 12258 197 28 62 Vodacom Internet Company 16637 171 664 87 MTN Network Solutions 29975 167 571 19 Vodacom 29571 157 15 16 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3405 3791 191 bellsouth.net, inc. 7029 3298 986 159 Windstream Communications Inc 4766 2672 11116 1158 Korea Telecom (KIX) 18566 2091 382 181 Covad Communications 10620 1967 342 205 TVCABLE BOGOTA 17974 1929 531 82 PT TELEKOMUNIKASI INDONESIA 1785 1919 681 132 PaeTec Communications, Inc. 28573 1917 1188 52 NET Servicos de Comunicao S.A 8402 1771 544 16 Corbina telecom 7545 1684 301 86 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3298 3139 Windstream Communications Inc 18566 2091 1910 Covad Communications 28573 1917 1865 NET Servicos de Comunicao S.A 17974 1929 1847 PT TELEKOMUNIKASI INDONESIA 1785 1919 1787 PaeTec Communications, Inc. 10620 1967 1762 TVCABLE BOGOTA 8402 1771 1755 Corbina telecom 7545 1684 1598 TPG Internet Pty Ltd 22773 1649 1528 Cox Communications, Inc. 4766 2672 1514 Korea Telecom (KIX) Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser 32873 UNALLOCATED 12.46.102.0/24 10912 InterNAP Network Ser 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.83.16.0/21 35362 Best ISP 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:13 /10:28 /11:83 /12:236 /13:462 /14:834 /15:1508 /16:12304 /17:6324 /18:10705 /19:20805 /20:29533 /21:31182 /22:40852 /23:38649 /24:216623 /25:1232 /26:1440 /27:848 /28:169 /29:68 /30:18 /31:0 /32:22 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2679 3298 Windstream Communications Inc 18566 2040 2091 Covad Communications 6389 1876 3405 bellsouth.net, inc. 8402 1465 1771 Corbina telecom 30036 1373 1433 Mediacom Communications Corp 11492 1152 1189 Cable One 22773 1081 1649 Cox Communications, Inc. 6503 1061 1527 AVANTEL, S.A. 1785 1032 1919 PaeTec Communications, Inc. 8452 1023 1254 TEDATA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:529 2:767 3:1 4:13 5:60 6:3 8:426 12:2016 13:1 14:625 15:12 16:3 17:5 20:25 23:183 24:1777 27:1311 31:990 32:56 33:2 34:2 36:9 37:722 38:811 40:127 41:3113 42:135 44:3 46:1420 47:2 49:392 50:562 52:13 54:12 55:10 56:1 57:34 58:964 59:496 60:260 61:1213 62:1007 63:2007 64:4218 65:2251 66:4453 67:2007 68:1160 69:3172 70:981 71:509 72:1825 74:2599 75:478 76:329 77:958 78:979 79:491 80:1222 81:947 82:658 83:541 84:504 85:1190 86:424 87:926 88:337 89:1723 90:293 91:4931 92:572 93:1384 94:1591 95:1227 96:373 97:315 98:902 99:38 100:17 101:248 103:1163 106:103 107:186 108:332 109:1376 110:778 111:922 112:418 113:618 114:637 115:849 116:950 117:732 118:922 119:1223 120:350 121:692 122:1671 123:1090 124:1393 125:1254 128:559 129:199 130:250 131:633 132:289 133:22 134:244 135:61 136:215 137:239 138:334 139:191 140:494 141:253 142:416 143:377 144:531 145:73 146:510 147:292 148:768 149:314 150:161 151:176 152:472 153:173 154:16 155:447 156:223 157:381 158:188 159:603 160:350 161:268 162:352 163:190 164:641 165:416 166:588 167:473 168:862 169:127 170:882 171:138 172:4 173:1779 174:599 175:429 176:544 177:803 178:1455 180:1262 181:97 182:1018 183:229 184:535 185:1 186:2307 187:1106 188:1348 189:1842 190:5589 192:6010 193:5529 194:4539 195:3411 196:1222 197:156 198:3664 199:4787 200:5889 201:1948 202:8651 203:8543 204:4349 205:2539 206:2810 207:2795 208:4012 209:3608 210:2774 211:1548 212:2034 213:1931 214:868 215:86 216:5114 217:1565 218:553 219:312 220:1237 221:570 222:317 223:362 End of report From surfer at mauigateway.com Fri Jun 15 14:23:40 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 15 Jun 2012 12:23:40 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! Message-ID: <20120615122340.EEE7551A@m0005296.ppops.net> > On Fri, 15 Jun 2012 11:59:26 -0400, Jay Ashworth said: > > http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ The article sure does have a lot of threatening and smack-down tones toward service providers (us): "We're looking at a problem that's about to occur,""It occurs as service providers start to roll out V6." Our fault, no one else's... ------------------------------------ "This is not a question of willful rejection,""ISPs are happy to do this. They're just lazy...It doesn't have a direct impact on them and their ability to get new address space because they don't need new address space." Yep, we're definitely the lazy ones. No one else. ------------------------------------ "We're hoping through all of this you can come up with some self-regulatory method in which you can do it," "Because otherwise, there will be other things that people are going to consider." That's definitely a threat. ------------------------------------- "We're hoping that people in the community seize the opportunity to work and to have that self-regulation, because, if not, if all of the different governments then get involved, it could get uglier." Yeah, that one, too. ------------------------------------- Yep, that's the kind of attitude that fosters community cooperation. Yep. That's it... scott From owen at delong.com Fri Jun 15 15:03:56 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Jun 2012 13:03:56 -0700 Subject: IPv6 Lo. for 6PE/6VPE In-Reply-To: References: <20120615103207.GA20157@srv03.cluenet.de> <47E76F08F1BCF5458111C1939C7B9C4602999F@xmb-rcd-x03.cisco.com> <2811C7BC-3A02-4DF7-A1DC-933DB3C4537D@delong.com> Message-ID: <4CC108F1-958F-4215-A0A5-35EE017024D5@delong.com> Yes... That shouldn't happen. Whoever is responsible for the routers at 154.54.{57.102,30.129,5.253} should fix their configurations. Owen On Jun 15, 2012, at 6:07 AM, Robert McKay wrote: > You mean like this? ;) > > 1. ??? > 2. ldn-ipv6-b1.ipv6.telia.net 0.0% 3 1.0 1.2 1.0 1.4 0.2 > 3. cogent-ic-125507-ldn-b5.c.telia.net 0.0% 2 40.6 40.4 40.2 40.6 0.3 > 4. ::ffff:154.54.57.102 0.0% 2 129.1 129.1 129.1 129.1 0.0 > 5. ::ffff:154.54.30.129 0.0% 2 120.2 120.0 119.8 120.2 0.3 > 6. 2001:550::100 0.0% 2 120.2 120.3 120.2 120.5 0.2 > 7. ::ffff:154.54.5.253 0.0% 2 120.5 120.3 120.1 120.5 0.3 > 8. ??? > 9. cogentco.com 0.0% 2 119.9 119.9 119.9 119.9 0.0 > > Rob > > On Fri, 15 Jun 2012 04:35:51 -0700, Owen DeLong wrote: >> If it does, that's bad... You should never see IPv4 mapped addresses >> on the wire. >> They should only be an internal representation of an IPv4 packet >> within the host. >> >> Owen >> >> On Jun 15, 2012, at 3:52 AM, Nagendra Kumar (naikumar) wrote: >> >>> Hi, >>> >>> Per my understanding, it is not required to have ipv6 address in loopback intf on all P routers inorder to have 6PE work. If I remember it correctly, P router will use ::FFFF:: while originating ICMPv6 error message. >>> >>> -Nagendra >>> >>> -----Original Message----- >>> From: Daniel Roesen [mailto:dr at cluenet.de] >>> Sent: Friday, June 15, 2012 4:02 PM >>> To: nanog at nanog.org >>> Subject: Re: IPv6 Lo. for 6PE/6VPE >>> >>> On Fri, Jun 15, 2012 at 11:56:05AM +0200, mohamed Osama Saad Abo sree wrote: >>>> I was just wondering , while I'm planning my network to support >>>> 6PE/6VPE why should i assign an IPv6 for Loopbacks? >>>> >>>> Maybe it's needed for Point-Point links or external interfaces between >>>> my peers, but anyone here know why i should assign IPv6 for all my >>>> Routers inside my ISP if we will run PE/6VPE not dual stack. >>> >>> Otherwise the intermediate P devices do not have an address to source >>> ICMPv6 "hop count exceeded" error replies => traceroute doesn't work properly. >>> >>> Best regards, >>> Daniel >>> >>> -- >>> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 >>> > From rob at invaluement.com Fri Jun 15 15:30:31 2012 From: rob at invaluement.com (Rob McEwen) Date: Fri, 15 Jun 2012 16:30:31 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> Message-ID: <4FDB9B67.3080209@invaluement.com> On 6/15/2012 11:59 AM, Jay Ashworth wrote: > http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ I don't know how much of this has been covered on NANOG, and I personally have a healthy innate distrust of government power grabs and intrusive government information grabs. However, having said that, as someone on the anti-spam front lines, I think that IPv6 may well be a tremendous gift to spammers if accepting mail from IPv6 becomes a free-for-all, as I understand it to be. First, it is NOT a problem to accept your own authenticated user's mail via their IPv6 connection to your server. Therefore, for the point I'm raising, consider that the millions of a large ISP's *own* customers can transition to sending their mail through that ISP's mail server vi IPv6 without any problems. (if problems arise, it would probably be more a problem with weak authentication?) But for all other mail, such as mail sent from valid mail servers to other valid mail servers... then the following two suggestions would go a long way: (1) simple don't accept IPv6 mail for the foreseeable future. (In this case, scarcity of IPv4 addresses is a FEATURE, not a bug.) (2) And/or limit (what would be considered) valid IPv6 mail servers to those assigned a particular IP on particularly large-sized block... then sending IP not within those specs. (3) MANY hosters who aren't deliberate spammers, but really don't care to police abusive customers much except when dragged kicking and screaming... and there are MANY such hosters... have a motivation to keep their IPv4 mail server addresses "clean". in an IPv6 world, I think they'll not care because they'll get these huge allocations where they'll figure that they have YEARS of IP blocks to burn through before recycling them. As it stands now, if they get too sloppy, then their next customer isn't happy when senderbase.org has their new IPs as already in the "poor" category. Again, THAT is a feature, not a bug. Moreover, as I said, scarcity of IPs, with regards to mail servers, is a feature... not a bug. If these suggestions are not followed/heeded, MANY reading this right now will look back a decade from now and say, "wouldn't it have been great if we could have somehow created a situation where valid mail server IPs for IPv6 could have been more scarce and not a free-for-all?" In the "free for all" world, a spammer could send thousands or even millions of spams, each from a different IPv6 address... with each IP indexed back to the sender (to aid in "listwashing" of recipient addresses that triggered blacklistings), and not use a single IP twice. Furthermore, even if the IPs are blacklisted at the /64 level, as I understand it, some of the allocations happening are so generous, this statement could still be somewhat true where the spammer send each spam from a separate /64 block? Certainly, 65,536 /64 blocks in a /24 allocation is a hell of a lot more /64 blocks to burn through than the 256 IPs in an IPv4 /24 allocation!!! Again, keep in mind that the massive expansion of sending IP from a customer that is routed via to their own ISP's mail server, hopefully using authentication, is unaffected by this suggestion. So your future refrigerator and oven can STILL send you an e-mail from its IPv6 ip address. -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From rob at invaluement.com Fri Jun 15 15:33:42 2012 From: rob at invaluement.com (Rob McEwen) Date: Fri, 15 Jun 2012 16:33:42 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <4FDB9B67.3080209@invaluement.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <4FDB9B67.3080209@invaluement.com> Message-ID: <4FDB9C26.3010203@invaluement.com> On 6/15/2012 4:30 PM, Rob McEwen wrote: > And/or limit (what would be considered) valid IPv6 mail servers to > those assigned a particular IP on particularly large-sized block... then > sending IP not within those specs. oops. typo. That last part should have been: "then block sending IPs not within those specs" -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From rob at invaluement.com Fri Jun 15 15:35:26 2012 From: rob at invaluement.com (Rob McEwen) Date: Fri, 15 Jun 2012 16:35:26 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <4FDB9B67.3080209@invaluement.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <4FDB9B67.3080209@invaluement.com> Message-ID: <4FDB9C8E.1070906@invaluement.com> On 6/15/2012 4:30 PM, Rob McEwen wrote: > Certainly, 65,536 /64 blocks in a /24 > allocation another typo. I meant: Certainly, 65,536 /64 blocks in a /48 allocation -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From owen at delong.com Fri Jun 15 15:43:47 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Jun 2012 13:43:47 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120615122340.EEE7551A@m0005296.ppops.net> References: <20120615122340.EEE7551A@m0005296.ppops.net> Message-ID: <5F1321EE-4120-47C3-B2B8-9F945498EBD5@delong.com> On Jun 15, 2012, at 12:23 PM, Scott Weeks wrote: > > >> On Fri, 15 Jun 2012 11:59:26 -0400, Jay Ashworth said: >>> http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ > > The article sure does have a lot of threatening and smack-down tones toward service providers (us): > > > > "We're looking at a problem that's about to occur,""It occurs as service providers start to roll out V6." > > Our fault, no one else's... > ------------------------------------ Who else would you blame for failing to update whois? > "This is not a question of willful rejection,""ISPs are happy to do this. They're just lazy...It doesn't have a direct impact on them and their ability to get new address space because they don't need new address space." > > Yep, we're definitely the lazy ones. No one else. > ------------------------------------ Again, when it comes to failing to update whois, that's kind of where the buck stops. > "We're hoping through all of this you can come up with some self-regulatory method in which you can do it," "Because otherwise, there will be other things that people are going to consider." > > That's definitely a threat. > ------------------------------------- Reality is that we have always lived in an environment where adequate self regulation is the only thing that prevents us from being subjected to dramatically worse government-based regulation. So, as it is a threat, it is also a statement of the reality that exists. Personally, I think that the article is counter-productive for the FBI in what they are trying to achieve. It is interesting that not one ISP stepped up to say "Our policy is to keep whois up to date for our IPv6 delegations just as we do now with our IPv4 delegations." Had CNET contacted HE, that's the answer they would have received. Is it really so hard? > "We're hoping that people in the community seize the opportunity to work and to have that self-regulation, because, if not, if all of the different governments then get involved, it could get uglier." > > Yeah, that one, too. > ------------------------------------- Sure, it's a threat. In case you haven't noticed, threats are the primary tool of law enforcement. The FBI is a law enforcement agency. Nothing to see here. Move along. > Yep, that's the kind of attitude that fosters community cooperation. Yep. That's it... When people carrying guns threaten the community, it does, in fact tend to foster community cooperation, at least at that very moment. Owen From goemon at anime.net Fri Jun 15 16:31:30 2012 From: goemon at anime.net (goemon at anime.net) Date: Fri, 15 Jun 2012 14:31:30 -0700 (PDT) Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120615122340.EEE7551A@m0005296.ppops.net> References: <20120615122340.EEE7551A@m0005296.ppops.net> Message-ID: On Fri, 15 Jun 2012, Scott Weeks wrote: > "This is not a question of willful rejection,""ISPs are happy to do this. They're just lazy...It doesn't have a direct impact on them and their ability to get new address space because they don't need new address space." > > Yep, we're definitely the lazy ones. No one else. this is indeed supported with plenty of evidence. > "We're hoping through all of this you can come up with some self-regulatory method in which you can do it," "Because otherwise, there will be other things that people are going to consider." > > That's definitely a threat. ignore it at your own risk. > "We're hoping that people in the community seize the opportunity to work and to have that self-regulation, because, if not, if all of the different governments then get involved, it could get uglier." > > Yeah, that one, too. ditto. > Yep, that's the kind of attitude that fosters community cooperation. Yep. That's it... nothing else has worked so far. keep complaining and do nothing, the decision will be made for you. or you can fix the problem that has been festering for 10+ years. the choice is yours. -Dan From surfer at mauigateway.com Fri Jun 15 16:55:45 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 15 Jun 2012 14:55:45 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! Message-ID: <20120615145545.EEE724C1@m0005296.ppops.net> >>> http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ > > The article sure does have a lot of threatening and smack-down tones toward service providers (us): > > > > "We're looking at a problem that's about to occur,""It occurs as service providers start to roll out V6." > > Our fault, no one else's... > ------------------------------------ :: Who else would you blame for failing to update whois? -------------------------------------------------------- At the risk of 10k flamethrowers turning my way... It is no difference than in v4. Those that do in v4 will do in v6 and those that don't in v4 won't in v6, so why make v6 the culprit? That isn't helpful. :: Personally, I think that the article is counter-productive for the FBI in what they are trying to achieve. ---------------------------------------------------------- yes scott From surfer at mauigateway.com Fri Jun 15 16:57:17 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 15 Jun 2012 14:57:17 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! Message-ID: <20120615145717.EEE73B15@m0005296.ppops.net> --- goemon at anime.net wrote: or you can fix the problem that has been festering for 10+ years. ----------------------------------- Yeah, that. Why make it seem that v6 is the problem when it isn't. scott From cidr-report at potaroo.net Fri Jun 15 17:00:03 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Jun 2012 22:00:03 GMT Subject: BGP Update Report Message-ID: <201206152200.q5FM03Rp000104@wattle.apnic.net> BGP Update Report Interval: 07-Jun-12 -to- 14-Jun-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8452 101223 8.0% 125.1 -- TE-AS TE-AS 2 - AS8402 32599 2.6% 35.5 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS9829 30376 2.4% 42.2 -- BSNL-NIB National Internet Backbone 4 - AS24560 27097 2.1% 48.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - AS8359 23598 1.9% 786.6 -- MTS MTS OJSC 6 - AS19318 20799 1.6% 1155.5 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 7 - AS12479 20176 1.6% 280.2 -- UNI2-AS France Telecom Espana SA 8 - AS35994 20108 1.6% 1546.8 -- AKAMAI-AS - Akamai Technologies, Inc. 9 - AS17813 17505 1.4% 159.1 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 10 - AS6503 16116 1.3% 16.3 -- Axtel, S.A.B. de C.V. 11 - AS13118 13500 1.1% 843.8 -- ASN-YARTELECOM OJSC Rostelecom 12 - AS27947 10599 0.8% 15.1 -- Telconet S.A 13 - AS7552 10181 0.8% 10.3 -- VIETEL-AS-AP Vietel Corporation 14 - AS17451 10045 0.8% 60.9 -- BIZNET-AS-AP BIZNET ISP 15 - AS5713 9837 0.8% 9.4 -- SAIX-NET 16 - AS9835 9598 0.8% 71.1 -- GITS-TH-AS-AP Government Information Technology Services 17 - AS17621 8982 0.7% 8982.0 -- CNCGROUP-SH China Unicom Shanghai network 18 - AS1660 8835 0.7% 113.3 -- ANS-CORP-NY - ANS Communications 19 - AS23966 8830 0.7% 43.7 -- LDN-AS-PK LINKdotNET Telecom Limited 20 - AS26615 6781 0.5% 7.7 -- Tim Celular S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17621 8982 0.7% 8982.0 -- CNCGROUP-SH China Unicom Shanghai network 2 - AS45264 4120 0.3% 4120.0 -- BAJAJALLIANZLIFE-AS-AP Bajaj Allianz Life Insurance Company Ltd 3 - AS47069 2087 0.2% 2087.0 -- LYON-LABS - Lyon Labs, Inc 4 - AS19406 3330 0.3% 1665.0 -- TWRS-MA - Towerstream I, Inc. 5 - AS35994 20108 1.6% 1546.8 -- AKAMAI-AS - Akamai Technologies, Inc. 6 - AS30202 1161 0.1% 1161.0 -- LEVEL-IV - Level IV 7 - AS19318 20799 1.6% 1155.5 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 8 - AS30944 916 0.1% 916.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD" 9 - AS42678 2535 0.2% 845.0 -- MEGANET-AS JSC "Meganet" 10 - AS13118 13500 1.1% 843.8 -- ASN-YARTELECOM OJSC Rostelecom 11 - AS25513 6744 0.5% 843.0 -- ASN-MGTS-USPD OJS Moscow city telephone network 12 - AS8359 23598 1.9% 786.6 -- MTS MTS OJSC 13 - AS55665 671 0.1% 671.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 14 - AS37349 1302 0.1% 651.0 -- Aptus 15 - AS6197 634 0.1% 634.0 -- BATI-ATL - BellSouth Network Solutions, Inc 16 - AS11652 2741 0.2% 548.2 -- TFCL-2 - TERRA FIRMA COMMUNICATIONS, LLC 17 - AS15734 540 0.0% 540.0 -- IDH Telvent Global Services S.A. 18 - AS57201 527 0.0% 527.0 -- EDF-AS Estonian Defence Forces 19 - AS17370 1339 0.1% 446.3 -- MCAFEE-COM - McAfee, Inc. 20 - AS14670 3503 0.3% 437.9 -- SOLAR-VPS - Solar VPS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 13457 1.0% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 220.196.26.0/24 8982 0.7% AS17621 -- CNCGROUP-SH China Unicom Shanghai network 3 - 69.31.106.0/23 8344 0.6% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 4 - 41.43.147.0/24 8175 0.6% AS8452 -- TE-AS TE-AS 5 - 62.36.252.0/22 5971 0.5% AS12479 -- UNI2-AS France Telecom Espana SA 6 - 23.65.27.0/24 5870 0.4% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 7 - 23.2.6.0/23 5870 0.4% AS35994 -- AKAMAI-AS - Akamai Technologies, Inc. 8 - 62.36.249.0/24 4896 0.4% AS12479 -- UNI2-AS France Telecom Espana SA 9 - 62.36.241.0/24 4632 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 59.177.48.0/20 4507 0.3% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 11 - 62.36.210.0/24 4497 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 12 - 202.90.40.0/24 4120 0.3% AS45264 -- BAJAJALLIANZLIFE-AS-AP Bajaj Allianz Life Insurance Company Ltd 13 - 69.38.178.0/24 3327 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 14 - 202.56.215.0/24 3279 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 15 - 59.177.64.0/18 2368 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 16 - 59.177.144.0/20 2158 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 17 - 74.115.31.0/24 2087 0.2% AS47069 -- LYON-LABS - Lyon Labs, Inc 18 - 59.180.0.0/16 2028 0.1% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 19 - 69.10.32.0/19 1901 0.1% AS19318 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 20 - 202.53.73.0/24 1901 0.1% AS19318 -- NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 15 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Jun 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201206152200.q5FM00lu099983@wattle.apnic.net> This report has been generated at Fri Jun 15 21:12:58 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-06-12 415656 241841 09-06-12 415380 242374 10-06-12 415742 242529 11-06-12 415914 242557 12-06-12 415866 242541 13-06-12 415698 242541 14-06-12 416188 242464 15-06-12 416421 242486 AS Summary 41430 Number of ASes in routing system 17294 Number of ASes announcing only one prefix 3405 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113099232 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 15Jun12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 416640 242484 174156 41.8% All ASes AS6389 3405 194 3211 94.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3339 1781 1558 46.7% WINDSTREAM - Windstream Communications Inc AS22773 1649 137 1512 91.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2688 1256 1432 53.3% KIXS-AS-KR Korea Telecom AS18566 2091 706 1385 66.2% COVAD - Covad Communications Co. AS28573 1876 557 1319 70.3% NET Servicos de Comunicao S.A. AS2118 1239 14 1225 98.9% RELCOM-AS OOO "NPO Relcom" AS10620 1967 744 1223 62.2% Telmex Colombia S.A. AS4323 1575 387 1188 75.4% TWTC - tw telecom holdings, inc. AS1785 1919 811 1108 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1592 539 1053 66.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7303 1440 459 981 68.1% Telecom Argentina S.A. AS7552 1093 214 879 80.4% VIETEL-AS-AP Vietel Corporation AS26615 899 35 864 96.1% Tim Celular S.A. AS8151 1492 672 820 55.0% Uninet S.A. de C.V. AS17974 1929 1162 767 39.8% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4808 1103 346 757 68.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS18101 947 208 739 78.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS13977 840 124 716 85.2% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS9394 848 160 688 81.1% CRNET CHINA RAILWAY Internet(CRNET) AS3356 1101 467 634 57.6% LEVEL3 Level 3 Communications AS17676 691 74 617 89.3% GIGAINFRA Softbank BB Corp. AS30036 1433 817 616 43.0% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS4780 842 246 596 70.8% SEEDNET Digital United Inc. AS19262 998 405 593 59.4% VZGNI-TRANSIT - Verizon Online LLC AS22561 1015 426 589 58.0% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 997 439 558 56.0% GBLX Global Crossing Ltd. AS22047 583 31 552 94.7% VTR BANDA ANCHA S.A. AS24560 1031 483 548 53.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8452 1255 736 519 41.4% TE-AS TE-AS Total 43877 14630 29247 66.7% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.188.64.0/18 AS29544 MAURITEL-AS Mauritanian Telecommunication Company 41.188.96.0/21 AS8346 SONATEL-AS Autonomous System 41.188.104.0/21 AS8346 SONATEL-AS Autonomous System 41.188.112.0/21 AS8346 SONATEL-AS Autonomous System 46.96.0.0/22 AS31733 46.96.4.0/22 AS31733 46.96.8.0/22 AS31733 46.96.12.0/22 AS31733 46.96.16.0/22 AS31733 46.96.20.0/22 AS31733 46.96.24.0/22 AS31733 46.96.28.0/22 AS31733 46.96.32.0/22 AS31733 46.96.36.0/22 AS31733 46.96.40.0/22 AS31733 46.96.44.0/22 AS31733 46.96.48.0/22 AS31733 46.96.52.0/22 AS31733 46.96.56.0/22 AS31733 46.96.60.0/22 AS31733 46.96.64.0/22 AS31733 46.96.68.0/22 AS31733 46.96.72.0/22 AS31733 46.96.76.0/22 AS31733 46.96.80.0/22 AS31733 46.96.84.0/22 AS31733 46.96.88.0/22 AS31733 46.96.92.0/22 AS31733 46.96.96.0/22 AS31733 46.96.100.0/22 AS31733 46.96.104.0/22 AS31733 46.96.108.0/22 AS31733 46.96.112.0/22 AS31733 46.96.116.0/22 AS31733 46.96.120.0/22 AS31733 46.96.124.0/22 AS31733 46.96.128.0/22 AS31733 46.96.132.0/22 AS31733 46.96.136.0/22 AS31733 46.96.140.0/22 AS31733 46.96.144.0/22 AS31733 46.96.148.0/22 AS31733 46.96.152.0/22 AS31733 46.96.156.0/22 AS31733 46.96.160.0/22 AS31733 46.96.164.0/22 AS31733 46.96.168.0/22 AS31733 46.96.172.0/22 AS31733 46.96.176.0/22 AS31733 46.96.180.0/22 AS31733 46.96.184.0/22 AS31733 46.96.188.0/22 AS31733 46.96.192.0/22 AS31733 46.96.196.0/22 AS31733 46.96.200.0/22 AS31733 46.96.204.0/22 AS31733 46.96.208.0/22 AS31733 46.96.212.0/22 AS31733 46.96.216.0/22 AS31733 46.96.220.0/22 AS31733 46.96.224.0/22 AS31733 46.96.228.0/22 AS31733 46.96.232.0/22 AS31733 46.96.236.0/22 AS31733 46.96.240.0/22 AS31733 46.96.244.0/22 AS31733 46.96.248.0/22 AS31733 46.96.252.0/22 AS31733 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.136.17.0/24 AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.14.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.15.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 176.119.232.0/21 AS43050 CHOKOLOVKA-AS Ivankov Daniil Eliseevich 188.164.0.0/22 AS31733 188.164.4.0/22 AS31733 188.164.8.0/22 AS31733 188.164.12.0/22 AS31733 188.164.16.0/22 AS31733 188.164.20.0/22 AS31733 188.164.24.0/22 AS31733 188.164.28.0/22 AS31733 188.164.32.0/22 AS31733 188.164.36.0/22 AS31733 188.164.40.0/22 AS31733 188.164.44.0/22 AS31733 188.164.48.0/22 AS31733 188.164.52.0/22 AS31733 188.164.56.0/22 AS31733 188.164.60.0/22 AS31733 188.164.64.0/22 AS31733 188.164.68.0/22 AS31733 188.164.72.0/22 AS31733 188.164.76.0/22 AS31733 188.164.80.0/22 AS31733 188.164.84.0/22 AS31733 188.164.88.0/22 AS31733 188.164.92.0/22 AS31733 188.164.96.0/22 AS31733 188.164.100.0/22 AS31733 188.164.104.0/22 AS31733 188.164.108.0/22 AS31733 188.164.112.0/22 AS31733 188.164.116.0/22 AS31733 188.164.120.0/22 AS31733 188.164.124.0/22 AS31733 188.164.128.0/22 AS31733 188.164.132.0/22 AS31733 188.164.136.0/22 AS31733 188.164.140.0/22 AS31733 188.164.144.0/22 AS31733 188.164.148.0/22 AS31733 188.164.152.0/22 AS31733 188.164.156.0/22 AS31733 188.164.160.0/22 AS31733 188.164.164.0/22 AS31733 188.164.168.0/22 AS31733 188.164.172.0/22 AS31733 188.164.176.0/22 AS31733 188.164.180.0/22 AS31733 188.164.184.0/22 AS31733 188.164.188.0/22 AS31733 188.164.192.0/22 AS31733 188.164.196.0/22 AS31733 188.164.200.0/22 AS31733 188.164.204.0/22 AS31733 188.164.208.0/22 AS31733 188.164.212.0/22 AS31733 188.164.216.0/22 AS31733 188.164.220.0/22 AS31733 188.164.224.0/22 AS31733 188.164.228.0/22 AS31733 188.164.232.0/22 AS31733 188.164.236.0/22 AS31733 188.164.240.0/22 AS31733 188.164.244.0/22 AS31733 188.164.248.0/22 AS31733 188.164.252.0/22 AS31733 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/21 AS14754 Telgua 200.106.128.0/20 AS3257 TINET-BACKBONE Tinet SpA 200.115.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.122.134.0/24 AS38615 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.202.0/24 AS8513 SKYVISION SkyVision Global Networks Ltd 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From owen at delong.com Fri Jun 15 17:47:47 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Jun 2012 15:47:47 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120615145545.EEE724C1@m0005296.ppops.net> References: <20120615145545.EEE724C1@m0005296.ppops.net> Message-ID: <272B6D89-E68A-4973-9A5B-B8BDD2DF1157@delong.com> On Jun 15, 2012, at 2:55 PM, Scott Weeks wrote: > >>>> http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ >> >> The article sure does have a lot of threatening and smack-down tones toward service providers (us): >> >> >> >> "We're looking at a problem that's about to occur,""It occurs as service providers start to roll out V6." >> >> Our fault, no one else's... >> ------------------------------------ > > :: Who else would you blame for failing to update whois? > -------------------------------------------------------- > > At the risk of 10k flamethrowers turning my way... > > It is no difference than in v4. Those that do in v4 will do > in v6 and those that don't in v4 won't in v6, so why make v6 > the culprit? That isn't helpful. > The perception, right, wrong, or indifferent is that many that do in IPv4 do only when forced to in order to get their next "fix" of IPv4 addresses to feed their legacy protocol habit. Since IPv6 policy allows them to get many many years worth of addresses and not come back for more for a very long time, if ever, that is the driving difference that the article is discussing. I don't agree with the article, but, the underlying problem of service providers being lazy about updating whois can, indeed, be greatly exacerbated by current IPv6 policy. The worst possible outcome of this problem would be IPv6 policy that restores the whois incentives contained in IPv4 policy. Owen From goemon at anime.net Fri Jun 15 17:53:48 2012 From: goemon at anime.net (goemon at anime.net) Date: Fri, 15 Jun 2012 15:53:48 -0700 (PDT) Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120615145717.EEE73B15@m0005296.ppops.net> References: <20120615145717.EEE73B15@m0005296.ppops.net> Message-ID: On Fri, 15 Jun 2012, Scott Weeks wrote: > --- goemon at anime.net wrote: > or you can fix the problem that has been festering for 10+ years. > ----------------------------------- > > Yeah, that. Why make it seem that v6 is the problem when it isn't. if arin would clamp down and revoke allocations that had provably wrong/fraudulent whois data, we would probably get 50% IPv4 space back. without incentives, we have proven it results in no action. -Dan From dedelman at iname.com Fri Jun 15 18:37:10 2012 From: dedelman at iname.com (Dave Edelman) Date: Fri, 15 Jun 2012 19:37:10 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <5F1321EE-4120-47C3-B2B8-9F945498EBD5@delong.com> References: <20120615122340.EEE7551A@m0005296.ppops.net> <5F1321EE-4120-47C3-B2B8-9F945498EBD5@delong.com> Message-ID: <285679E2-608B-4EBF-8419-A09113DCA6C8@iname.com> Dave Edelman On Jun 15, 2012, at 16:43, Owen DeLong wrote: > > On Jun 15, 2012, at 12:23 PM, Scott Weeks wrote: > >> >> >>> On Fri, 15 Jun 2012 11:59:26 -0400, Jay Ashworth said: >>>> http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ >> >> The article sure does have a lot of threatening and smack-down tones toward service providers (us): >> >> >> >> "We're looking at a problem that's about to occur,""It occurs as service providers start to roll out V6." >> >> Our fault, no one else's... >> ------------------------------------ > > Who else would you blame for failing to update whois? > >> "This is not a question of willful rejection,""ISPs are happy to do this. They're just lazy...It doesn't have a direct impact on them and their ability to get new address space because they don't need new address space." >> >> Yep, we're definitely the lazy ones. No one else. >> ------------------------------------ > > Again, when it comes to failing to update whois, that's kind of where the buck stops. > >> "We're hoping through all of this you can come up with some self-regulatory method in which you can do it," "Because otherwise, there will be other things that people are going to consider." >> >> That's definitely a threat. >> ------------------------------------- > > Reality is that we have always lived in an environment where adequate self regulation is the only thing that prevents us from being subjected to dramatically worse government-based regulation. So, as it is a threat, it is also a statement of the reality that exists. > > Personally, I think that the article is counter-productive for the FBI in what they are trying to achieve. > > It is interesting that not one ISP stepped up to say "Our policy is to keep whois up to date for our IPv6 delegations just as we do now with our IPv4 delegations." Had CNET contacted HE, that's the answer they would have received. Is it really so hard? > >> "We're hoping that people in the community seize the opportunity to work and to have that self-regulation, because, if not, if all of the different governments then get involved, it could get uglier." >> >> Yeah, that one, too. >> ------------------------------------- > > Sure, it's a threat. In case you haven't noticed, threats are the primary tool of law enforcement. The FBI is a law enforcement agency. Nothing to see here. Move along. > >> Yep, that's the kind of attitude that fosters community cooperation. Yep. That's it... > > When people carrying guns threaten the community, it does, in fact tend to foster community cooperation, at least at that very moment. > > Owen > > Compliance maybe, cooperation not really. --Dave From snoble at sonn.com Fri Jun 15 19:05:09 2012 From: snoble at sonn.com (Steven Noble) Date: Fri, 15 Jun 2012 17:05:09 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <20120615145717.EEE73B15@m0005296.ppops.net> Message-ID: <0A3A7F18-3DED-4785-B882-D75584B07174@sonn.com> Sent from my iPhone On Jun 15, 2012, at 3:53 PM, goemon at anime.net wrote: > On Fri, 15 Jun 2012, Scott Weeks wrote: > > if arin would clamp down and revoke allocations that had provably wrong/fraudulent whois data, we would probably get 50% IPv4 space back. Part of the issue is how hard it is to update ARIN, they gladly take your money but it's like pulling teeth to get anything updated and sometimes you run out of teeth. I don't know if this is true about apnic, ripe and the others. From jcurran at arin.net Fri Jun 15 20:53:26 2012 From: jcurran at arin.net (John Curran) Date: Sat, 16 Jun 2012 01:53:26 +0000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <0A3A7F18-3DED-4785-B882-D75584B07174@sonn.com> References: <20120615145717.EEE73B15@m0005296.ppops.net> <0A3A7F18-3DED-4785-B882-D75584B07174@sonn.com> Message-ID: On Jun 15, 2012, at 8:05 PM, Steven Noble wrote: > > Part of the issue is how hard it is to update ARIN, they gladly take your money but it's like pulling teeth to get anything updated and sometimes you run out of teeth. Steve - Suggestions for improvement are welcome; either formally through the ARIN suggestion process or directly to me. We're happy to make it easier to you to update this info, but need to know how you'd like us to do that. With respect to updating Whois, it is true that many ISPs do not update their sub-delegations until applying for their next IPv4 block. Whether this is also the case with IPV6 or not remains to be seen, but given IPv6 allocation size, it would not be good. FYI, /John John Curran President and CEO ARIN From valdis.kletnieks at vt.edu Sat Jun 16 02:17:22 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sat, 16 Jun 2012 03:17:22 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: Your message of "Fri, 15 Jun 2012 15:53:48 -0700." References: <20120615145717.EEE73B15@m0005296.ppops.net> Message-ID: <22799.1339831042@turing-police.cc.vt.edu> On Fri, 15 Jun 2012 15:53:48 -0700, goemon at anime.net said: > if arin would clamp down and revoke allocations that had provably > wrong/fraudulent whois data, we would probably get 50% IPv4 space back. 50%? I'd have estimated 10-15% tops. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From snoble at sonn.com Sat Jun 16 12:56:17 2012 From: snoble at sonn.com (Steven Noble) Date: Sat, 16 Jun 2012 10:56:17 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <20120615145717.EEE73B15@m0005296.ppops.net> <0A3A7F18-3DED-4785-B882-D75584B07174@sonn.com> Message-ID: <25ED4295-C071-4AEE-BF45-4261BFE391C5@sonn.com> On Jun 15, 2012, at 6:53 PM, John Curran wrote: > On Jun 15, 2012, at 8:05 PM, Steven Noble wrote: >> >> Part of the issue is how hard it is to update ARIN, they gladly take your money but it's like pulling teeth to get anything updated and sometimes you run out of teeth. > > Steve - > > Suggestions for improvement are welcome; either formally through > the ARIN suggestion process > or directly to me. We're happy to make it easier to you to update > this info, but need to know how you'd like us to do that. I want to personally thank John for taking the time to look at my issue in private conversations. It is not super complex but once we get it resolved I will be more open to talking about it. From surfer at mauigateway.com Sat Jun 16 18:07:38 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 16 Jun 2012 16:07:38 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! Message-ID: <20120616160738.EEE097C4@resin05.mta.everyone.net> --- jcurran at arin.net wrote: From: John Curran With respect to updating Whois, it is true that many ISPs do not update their sub-delegations until applying for their next IPv4 block. Whether this is also the case with IPV6 or not remains to be seen, but given IPv6 allocation size, it would not be good. ---------------------------------------------------- What is going to make folks change their behavior? scott From lists at internetpolicyagency.com Sun Jun 17 04:43:26 2012 From: lists at internetpolicyagency.com (Roland Perry) Date: Sun, 17 Jun 2012 10:43:26 +0100 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120616160738.EEE097C4@resin05.mta.everyone.net> References: <20120616160738.EEE097C4@resin05.mta.everyone.net> Message-ID: In article <20120616160738.EEE097C4 at resin05.mta.everyone.net>, Scott Weeks writes >What is going to make folks change their behavior? If all else fails, perhaps a regulator fining the ISP $1000 for every allocation (I agree that whether it's IPv4 or IPv6 isn't relevant) where the WHOIS information is shown to be false or significantly out of date. They could send compliance teams in to check, just like the IRS does for the accounts. -- Roland Perry From bmanning at vacation.karoshi.com Sun Jun 17 04:59:06 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 17 Jun 2012 09:59:06 +0000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <20120616160738.EEE097C4@resin05.mta.everyone.net> Message-ID: <20120617095906.GA32028@vacation.karoshi.com.> Internet Regulator? /bill On Sun, Jun 17, 2012 at 10:43:26AM +0100, Roland Perry wrote: > In article <20120616160738.EEE097C4 at resin05.mta.everyone.net>, Scott > Weeks writes > > >What is going to make folks change their behavior? > > If all else fails, perhaps a regulator fining the ISP $1000 for every > allocation (I agree that whether it's IPv4 or IPv6 isn't relevant) where > the WHOIS information is shown to be false or significantly out of date. > > They could send compliance teams in to check, just like the IRS does for > the accounts. > -- > Roland Perry From jcurran at arin.net Sun Jun 17 06:16:21 2012 From: jcurran at arin.net (John Curran) Date: Sun, 17 Jun 2012 11:16:21 +0000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120616160738.EEE097C4@resin05.mta.everyone.net> References: <20120616160738.EEE097C4@resin05.mta.everyone.net> Message-ID: On Jun 16, 2012, at 7:07 PM, Scott Weeks wrote: > From: John Curran >> >> With respect to updating Whois, it is true that many ISPs do not >> update their sub-delegations until applying for their next IPv4 >> block. Whether this is also the case with IPV6 or not remains >> to be seen, but given IPv6 allocation size, it would not be good. > > What is going to make folks change their behavior? One would hope that industry self-regulation and the small amount of self-interest would suffice here, but it's hard to be optimistic. Even if keeping this information up to date is commonly recognized as a best practice, our collectively track record in community pressure for compliance to best practices is uneven at best; i.e. I can imagine someone saying "Um, can we at least use MD5 on this session" or "You're giving us a lot of needless deaggregates with the same path info" but can't quite believe that "We happened to review all your address blocks and noticed you don't have a lot of the subassignments listed" is going to be a frequent phrase heard in peering discussions... Net result is that we may just have to live with lax practices by some, since many other potential solutions have real potential for consequences worse than the problem itself. FYI, /John John Curran President and CEO ARIN From cb.list6 at gmail.com Sun Jun 17 08:27:52 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 17 Jun 2012 06:27:52 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <20120616160738.EEE097C4@resin05.mta.everyone.net> Message-ID: But whois info is really the linchpin for LEAs trying to find criminals? I find that very hard to believe. CB From joseph.snyder at gmail.com Sun Jun 17 08:39:43 2012 From: joseph.snyder at gmail.com (joseph.snyder at gmail.com) Date: Sun, 17 Jun 2012 09:39:43 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <20120616160738.EEE097C4@resin05.mta.everyone.net> Message-ID: <8dd341e5-4b52-4d72-be1a-ca8342689424@email.android.com> It's about time and cost. If it's an emergency situation, trying to guess who might own the address waste time to get confirmation, if it is a complete guessing game. Then a warrant has to be gotten. You need to know who to put on the warrant to make a request. Cameron Byrne wrote: But whois info is really the linchpin for LEAs trying to find criminals? I find that very hard to believe. CB From jcurran at arin.net Sun Jun 17 09:12:12 2012 From: jcurran at arin.net (John Curran) Date: Sun, 17 Jun 2012 14:12:12 +0000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <8dd341e5-4b52-4d72-be1a-ca8342689424@email.android.com> References: <20120616160738.EEE097C4@resin05.mta.everyone.net> <8dd341e5-4b52-4d72-be1a-ca8342689424@email.android.com> Message-ID: On Jun 17, 2012, at 9:39 AM, joseph.snyder at gmail.com wrote: > It's about time and cost. If it's an emergency situation, trying to guess who might own the address waste time to get confirmation, if it is a complete guessing game. Then a warrant has to be gotten. You need to know who to put on the warrant to make a request. Exactly. If you start with an IP address and you're trying to get to some real-world entity, then you can check routing of the block or the Whois entry... this will get your to an ISP, but then you get to repeat the process by contacting that ISP and repeating the query (and potentially again if their customer is an even smaller ISP or hosting firm, etc.) With reasonable Whois update practices, Whois will get you to the ultimate non-residential organization much faster (which can make a difference in many situations.) The entire process can be pursued via contacting ISPs serially and asking them to check their routing and customer records, but that approach is definitely slower and far most costly for both government and industry. FYI, /John John Curran President and CEO ARIN From arturo.servin at gmail.com Sun Jun 17 12:10:59 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 17 Jun 2012 13:10:59 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> Message-ID: <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> Wouldn't BCP38 help? /as On 15 Jun 2012, at 11:59, Jay Ashworth wrote: > http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ > > > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at 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 From valdis.kletnieks at vt.edu Sun Jun 17 12:24:03 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 17 Jun 2012 13:24:03 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: Your message of "Sun, 17 Jun 2012 13:10:59 -0400." <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> Message-ID: <27626.1339953843@turing-police.cc.vt.edu> On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said: > Wouldn't BCP38 help? The mail I'm replying to has as the first Received: line: Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT) Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote that literally last century. ;) So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO find that info quickly if they need to figure out who to hand a warrant to? *THAT* is the problem that needs solving. (And who *does* own that IP? I admit not knowing. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From joelja at bogus.com Sun Jun 17 12:53:52 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 17 Jun 2012 10:53:52 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <27626.1339953843@turing-police.cc.vt.edu> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> Message-ID: <4FDE19B0.80800@bogus.com> On 6/17/12 10:24 , valdis.kletnieks at vt.edu wrote: > On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said: >> Wouldn't BCP38 help? > > The mail I'm replying to has as the first Received: line: > > Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT) > Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be > spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly > enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote > that literally last century. ;) > > So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO > find that info quickly if they need to figure out who to hand a warrant to? so first of you introduced a typo 2800:af:ba30:e8cf:4881:973a:c68 2800:af:ba30:e8cf:d06f:4881:973a:c68 which like the wrong address in a search warrant can be a problem. jjaeggli at cXX-XX-XX0> show route table inet6.0 2800:af:ba30:e8cf:4881:973a:c68 ^ invalid ip address or hostname: 2800:af:ba30:e8cf:4881:973a:c68 at '2800:af:ba30:e8cf:4881:973a:c68' jjaeggli at cXX-XX-XX0> show route table inet6.0 2800:af:ba30:e8cf:d06f:4881:973a:c68 inet6.0: 9674 destinations, 38494 routes (9674 active, 0 holddown, 19088 hidden) + = Active Route, - = Last Active, * = Both 2800:a0::/28 *[BGP/170] 1w2d 00:00:21, MED 50, localpref 200, from 2620:102:8004::10 AS path: 7922 12956 6057 I XXXX-XXXXX:~ jjaeggli$ whois -h whois.lacnic.net 2800:af:ba30:e8cf:d06f:4881:973a:c68 inetnum: 2800:a0::/28 status: allocated aut-num: N/A owner: Administracion Nacional de Telecomunicaciones ownerid: UY-ANTA-LACNIC responsible: ANTELDATA ANTEL URUGUAY address: Treinta y Tres, 1418, P.3 address: 11000 - Montevideo - country: UY phone: +598 2 9028819 [] owner-c: ANU tech-c: ANU abuse-c: ANU inetrev: 2800:a0::/28 nserver: NS1.ANTELV6.NET.UY nsstat: 20120615 AA nslastaa: 20120615 created: 20070115 changed: 20070115 nic-hdl: ANU person: ANTELDATA ANTEL URUGUAY e-mail: ipadmin at ANTEL.NET.UY address: Mercedes, 876, P. 2 address: 11100 - Montevideo - country: UY phone: +598 2 9002877 [] created: 20020910 changed: 20111014 scopes it to not being a problem you can solve with policy in the arin region. > *THAT* is the problem that needs solving. > > (And who *does* own that IP? I admit not knowing. ;) was trivial enough to find the origin, I have nothing to indicate that any of that information is wrong. From arturo.servin at gmail.com Sun Jun 17 13:36:23 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 17 Jun 2012 14:36:23 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <27626.1339953843@turing-police.cc.vt.edu> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> Message-ID: <980D26F1-DE06-443D-BEC6-AE2B73A41DCB@gmail.com> You would go to the whois: whois -h whois.lacnic.net 2800:af::/32 You will find that it is assigned to ISP "Whatever". If you are the cops you will find who I am asking them. BCP 38 would work. The problem is that many ISPs do not ingress filter, so I can use whatever unnallocated IPv6 space (2F10:baba:ba30:e8cf:d06f:4881:973a:c68) to SPAM and then go invisible and use another one (2E10:baba:ba30:e8cf:d06f:4881:973a:c68) Regards, as On 17 Jun 2012, at 13:24, Valdis.Kletnieks at vt.edu wrote: > On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said: >> Wouldn't BCP38 help? > > The mail I'm replying to has as the first Received: line: > > Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT) > > Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be > spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly > enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote > that literally last century. ;) > > So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO > find that info quickly if they need to figure out who to hand a warrant to? > > *THAT* is the problem that needs solving. > > (And who *does* own that IP? I admit not knowing. ;) From johnl at iecc.com Sun Jun 17 14:41:41 2012 From: johnl at iecc.com (John Levine) Date: 17 Jun 2012 19:41:41 -0000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <980D26F1-DE06-443D-BEC6-AE2B73A41DCB@gmail.com> Message-ID: <20120617194141.97263.qmail@joyce.lan> > BCP 38 would work. The problem is that many ISPs do not ingress filter, so I >can use whatever unnallocated IPv6 space >(2F10:baba:ba30:e8cf:d06f:4881:973a:c68) to SPAM and then go invisible and use >another one (2E10:baba:ba30:e8cf:d06f:4881:973a:c68) How do you plan to get the return packets? DNS bombing with forged address UDP packets is one thing, but anything that runs over TCP won't work without return routes. If the bad guy can inject routes, you have worse problems than lack of SWIP. (This assumes the target is not using a 20 year old TCP stack with predictable sequence numbers, but in the IPv6 world we should be able to assume that particular security hole is closed.) I expect bad guys to hop around within a /64 or whatever size allocation the ISP assigns to customers, but that's still easily handled by SWIP, or by subpoena to the ISP if they didn't get around to SWIP. R's, John From arturo.servin at gmail.com Sun Jun 17 14:53:47 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Sun, 17 Jun 2012 15:53:47 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120617194141.97263.qmail@joyce.lan> References: <20120617194141.97263.qmail@joyce.lan> Message-ID: If the ISP fails to filter my bogus space and leak that route to the Internet (which happens today everyday with IPv4, and will with IPv6) I would get my return path. Again, if every ISP followed BCP 38 that would not happen (IPv6 and IPv4). But they are not, and probably they won't. .as On 17 Jun 2012, at 15:41, John Levine wrote: >> BCP 38 would work. The problem is that many ISPs do not ingress filter, so I >> can use whatever unnallocated IPv6 space >> (2F10:baba:ba30:e8cf:d06f:4881:973a:c68) to SPAM and then go invisible and use >> another one (2E10:baba:ba30:e8cf:d06f:4881:973a:c68) > > How do you plan to get the return packets? DNS bombing with forged > address UDP packets is one thing, but anything that runs over TCP > won't work without return routes. If the bad guy can inject routes, > you have worse problems than lack of SWIP. > > (This assumes the target is not using a 20 year old TCP stack with > predictable sequence numbers, but in the IPv6 world we should be able > to assume that particular security hole is closed.) > > I expect bad guys to hop around within a /64 or whatever size > allocation the ISP assigns to customers, but that's still easily > handled by SWIP, or by subpoena to the ISP if they didn't get around > to SWIP. > > R's, > John > > From vinny at abellohome.net Sun Jun 17 15:01:57 2012 From: vinny at abellohome.net (Vinny Abello) Date: Sun, 17 Jun 2012 16:01:57 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> Message-ID: <4FDE37B5.4030809@abellohome.net> On 6/15/2012 11:59 AM, Jay Ashworth wrote: > http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/ > > > > Cheers, > -- jra I fail to see the problem the media and FBI are worried about. If the regional registries are accurately documenting who they are allocating assignments to, the authorities have somewhere to start. Even if everything is properly documented via SWIP or WHOIS, the FBI requests far more information in a subpena from ISP's than is provided by those tools and I don't think they generally really even rely on them to be accurate. They go straight to the ISP from what I've seen. They don't want the criminal to know the FBI is on to them and won't first go direct to the end user. A /64, /56 or even /48 will be one customer, so regardless if a criminal keeps changing IP's inside those blocks, it still points to that customer which the ISP can provide to the FBI. Where is the issue? I don't see how this is that hard to track down. What's the difference with an ISP that didn't SWIP an IPv4 /29 allocation to a company with all RFC1918 space behind the address. How oh how will they ever find the criminal within all of that IPv4 address space behind the ISP assigned /29 without someone documenting the RFC1918 space in the customer's network??!?! If anything, I feel like this is a ploy by the FBI feeding the media to get criminals to adopt IPv6 thinking they're harder to track and drop their guard so they'll be easier to catch. -Vinny From valdis.kletnieks at vt.edu Sun Jun 17 15:22:11 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Sun, 17 Jun 2012 16:22:11 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: Your message of "Sun, 17 Jun 2012 10:53:52 -0700." <4FDE19B0.80800@bogus.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> Message-ID: <35465.1339964531@turing-police.cc.vt.edu> On Sun, 17 Jun 2012 10:53:52 -0700, Joel jaeggli said: > On 6/17/12 10:24 , valdis.kletnieks at vt.edu wrote: > > So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO > > find that info quickly if they need to figure out who to hand a warrant to? > > so first of you introduced a typo Aha. Somebody's paying attention :) That's exactly the sort of thing you'll end up seeing a lot more of if you have to start chasing through 2 and 3 hops of provider-customer-subcustomer. It's easy to notice that an IPv4 address is missing an octet - a lot harder to tell you have 7 chunks rather than 8, plus you're left wondering whether you dropped 16 bits, or if one of the : should be a :: instead. But Joel - you *really* need to get out more. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From joelja at bogus.com Sun Jun 17 16:02:18 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 17 Jun 2012 14:02:18 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <35465.1339964531@turing-police.cc.vt.edu> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> <35465.1339964531@turing-police.cc.vt.edu> Message-ID: <4FDE45DA.6030808@bogus.com> On 6/17/12 13:22 , valdis.kletnieks at vt.edu wrote: > On Sun, 17 Jun 2012 10:53:52 -0700, Joel jaeggli said: >> On 6/17/12 10:24 , valdis.kletnieks at vt.edu wrote: > >>> So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO >>> find that info quickly if they need to figure out who to hand a warrant to? >> >> so first of you introduced a typo > > Aha. Somebody's paying attention :) That's exactly the sort of thing you'll end > up seeing a lot more of if you have to start chasing through 2 and 3 hops > of provider-customer-subcustomer. Yes, in a previous $job I have been served court authorized requests that are incorrect. I have provided helpful advice. > It's easy to notice that an IPv4 address > is missing an octet - a lot harder to tell you have 7 chunks rather than 8, > plus you're left wondering whether you dropped 16 bits, or if one of the : > should be a :: instead. If one enters the wrong number the right answer will rarely be forthcoming. > But Joel - you *really* need to get out more. ;) yes From jcurran at arin.net Sun Jun 17 18:16:33 2012 From: jcurran at arin.net (John Curran) Date: Sun, 17 Jun 2012 23:16:33 +0000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <4FDE37B5.4030809@abellohome.net> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <4FDE37B5.4030809@abellohome.net> Message-ID: <7057D99E-FC38-4AD0-8FD6-EDE0F718984F@corp.arin.net> On Jun 17, 2012, at 4:01 PM, Vinny Abello wrote: > I fail to see the problem the media and FBI are worried about. If the > regional registries are accurately documenting who they are allocating > assignments to, the authorities have somewhere to start. Even if > everything is properly documented via SWIP or WHOIS, the FBI requests > far more information in a subpena from ISP's than is provided by those > tools and I don't think they generally really even rely on them to be > accurate. Indeed, there are subpoenas which request a lot more information, (particularly if you are in a lengthy investigation.) However, if they are trying to figure out where a missing kid or person in danger person might be located based on email headers, then time can be of the essence and being able to follow the subassignments (that are already supposed to be in Whois) can make the difference. I would not say they rely on Whois to be accurate, but they certainly take its contents into consideration in some situations along with all the other various data points they may have. > They go straight to the ISP from what I've seen. They don't > want the criminal to know the FBI is on to them and won't first go > direct to the end user. Depends on circumstance. If you're talking about investigations of front companies for various nefarious commercial activities, then that is indeed the case, but that is not the only type of law enforcement activity. > A /64, /56 or even /48 will be one customer, so > regardless if a criminal keeps changing IP's inside those blocks, it > still points to that customer which the ISP can provide to the FBI. If the ISP has a lawful response desk which is available at 3 PM on a Sunday afternoon or holiday weekend, then going to the ISP would indeed be equivalent. Also, this presumes that the ISP in question isn't serving a smaller ISP or hosting firm which would then also need to be queried to find the actual customer. > Where is the issue? I don't see how this is that hard to track down. > What's the difference with an ISP that didn't SWIP an IPv4 /29 > allocation to a company with all RFC1918 space behind the address. > How oh how will they ever find the criminal within all of that > IPv4 address space behind the ISP assigned /29 without someone > documenting the RFC1918 space in the customer's network??!?! There is no difference. The question is whether the ISP who had to SWIP the /29 under IPv4 as part of showing utilization to get their next block will bother to record subdelegations under IPv6 when they don't need to come back for _a long time_... > If anything, I feel like this is a ploy by the FBI feeding the media to > get criminals to adopt IPv6 thinking they're harder to track and drop > their guard so they'll be easier to catch. No, it's a real concern that law enforcement has with the current incentives for keeping the Whois up to date, and what happens with IPv6. Feel free to come to an ARIN meeting and chat with the folks from US, Canada, and various Caribbean governments about their issue. By the way, it is not that there is _no_ incentive... Any _large_ ISP ends up having to provide lawful response duties (often the same team that handles spam/abuse/copyright issues) and that means staff. For networks that put subdelegations into Whois reliably, there are less requests for routine information (ergo less staff & less co$t needed to respond.) Not many ISPs are the size where such inquires are routine enough for having a dedicated team, but those who do generally realize the pleasant side effect of keeping Whois up-to-date. This isn't really seen by ISPs who only get the occasional LEA request, so it's not a meaningful incentive on its own for many service providers. FYI, /John John Curran President and CEO ARIN From owen at delong.com Sun Jun 17 18:29:45 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Jun 2012 16:29:45 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <4FDE19B0.80800@bogus.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> Message-ID: On Jun 17, 2012, at 10:53 AM, Joel jaeggli wrote: > On 6/17/12 10:24 , valdis.kletnieks at vt.edu wrote: >> On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said: >>> Wouldn't BCP38 help? >> >> The mail I'm replying to has as the first Received: line: >> >> Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT) > > >> Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be >> spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly >> enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote >> that literally last century. ;) >> >> So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO >> find that info quickly if they need to figure out who to hand a warrant to? > > so first of you introduced a typo > > 2800:af:ba30:e8cf:4881:973a:c68 > > 2800:af:ba30:e8cf:d06f:4881:973a:c68 > > which like the wrong address in a search warrant can be a problem. > > jjaeggli at cXX-XX-XX0> show route table inet6.0 > 2800:af:ba30:e8cf:4881:973a:c68 > ^ > invalid ip address or hostname: 2800:af:ba30:e8cf:4881:973a:c68 at > '2800:af:ba30:e8cf:4881:973a:c68' > > jjaeggli at cXX-XX-XX0> show route table inet6.0 > 2800:af:ba30:e8cf:d06f:4881:973a:c68 > > inet6.0: 9674 destinations, 38494 routes (9674 active, 0 holddown, 19088 > hidden) > + = Active Route, - = Last Active, * = Both > > 2800:a0::/28 *[BGP/170] 1w2d 00:00:21, MED 50, localpref 200, from > 2620:102:8004::10 > AS path: 7922 12956 6057 I > > XXXX-XXXXX:~ jjaeggli$ whois -h whois.lacnic.net > 2800:af:ba30:e8cf:d06f:4881:973a:c68 > > scopes it to not being a problem you can solve with policy in the arin > region. Lather rinse repeat with a better choice of address... 2001:550:3ee3:f329:102a3:2aff:fe23:1f69 This is in the ARIN region... It's from within a particular ISP's /32. Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. Have they delegated it to an end user? Again, if so, it's not in whois. Same for 2001:550:10:20:62a3:3eff:fe19:2909 I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong in this particular case, but if they have been delegated and not registered in whois, that's a real problem when it comes time to get a search warrant if speed is of the essence. Owen From james at smithwaysecurity.com Sun Jun 17 18:37:58 2012 From: james at smithwaysecurity.com (James) Date: Sun, 17 Jun 2012 20:37:58 -0300 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> Message-ID: <4FDE6A56.1010808@smithwaysecurity.com> Hello everyone, Yes the FBI can't just rely on Whois for apart of their investigation. yes I will agree it's a big part but also those records are spoofed alot. But reverse Ip looks I can understand. James Smith CEO, CEH SmithwaySecurity Toronto, Canada On 12-06-17 08:29 PM, Owen DeLong wrote: > On Jun 17, 2012, at 10:53 AM, Joel jaeggli wrote: > >> On 6/17/12 10:24 , valdis.kletnieks at vt.edu wrote: >>> On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said: >>>> Wouldn't BCP38 help? >>> The mail I'm replying to has as the first Received: line: >>> >>> Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT) >> >>> Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be >>> spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly >>> enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote >>> that literally last century. ;) >>> >>> So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO >>> find that info quickly if they need to figure out who to hand a warrant to? >> so first of you introduced a typo >> >> 2800:af:ba30:e8cf:4881:973a:c68 >> >> 2800:af:ba30:e8cf:d06f:4881:973a:c68 >> >> which like the wrong address in a search warrant can be a problem. >> >> jjaeggli at cXX-XX-XX0> show route table inet6.0 >> 2800:af:ba30:e8cf:4881:973a:c68 >> ^ >> invalid ip address or hostname: 2800:af:ba30:e8cf:4881:973a:c68 at >> '2800:af:ba30:e8cf:4881:973a:c68' >> >> jjaeggli at cXX-XX-XX0> show route table inet6.0 >> 2800:af:ba30:e8cf:d06f:4881:973a:c68 >> >> inet6.0: 9674 destinations, 38494 routes (9674 active, 0 holddown, 19088 >> hidden) >> + = Active Route, - = Last Active, * = Both >> >> 2800:a0::/28 *[BGP/170] 1w2d 00:00:21, MED 50, localpref 200, from >> 2620:102:8004::10 >> AS path: 7922 12956 6057 I >> >> XXXX-XXXXX:~ jjaeggli$ whois -h whois.lacnic.net >> 2800:af:ba30:e8cf:d06f:4881:973a:c68 >> >> scopes it to not being a problem you can solve with policy in the arin >> region. > Lather rinse repeat with a better choice of address... > > 2001:550:3ee3:f329:102a3:2aff:fe23:1f69 > > This is in the ARIN region... > > It's from within a particular ISP's /32. > > Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. > Have they delegated it to an end user? Again, if so, it's not in whois. > > Same for 2001:550:10:20:62a3:3eff:fe19:2909 > > I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong > in this particular case, but if they have been delegated and not registered in whois, that's > a real problem when it comes time to get a search warrant if speed is of the essence. > > Owen > > From joelja at bogus.com Sun Jun 17 20:34:31 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 17 Jun 2012 18:34:31 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> Message-ID: <4FDE85A7.2050700@bogus.com> On 6/17/12 16:29 , Owen DeLong wrote: > > On Jun 17, 2012, at 10:53 AM, Joel jaeggli wrote: > >> On 6/17/12 10:24 , valdis.kletnieks at vt.edu wrote: >>> On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said: >>>> Wouldn't BCP38 help? >>> >>> The mail I'm replying to has as the first Received: line: >>> >>> Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68? ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 10:11:06 -0700 (PDT) >> >> >>> Obviously BCP38 doesn't help, as it's an established TCP connection so it can't be >>> spoofed traffic (gotta ACK Google's ISN from the SYN-ACK) - unless Google is silly >>> enough to *still* not be doing RFC1948 properly. I mean, Steve Bellovin wrote >>> that literally last century. ;) >>> >>> So - who owns 2800:af:ba30:e8cf:4881:973a:c68? And how does an LEO >>> find that info quickly if they need to figure out who to hand a warrant to? >> >> so first of you introduced a typo >> >> 2800:af:ba30:e8cf:4881:973a:c68 >> >> 2800:af:ba30:e8cf:d06f:4881:973a:c68 >> >> which like the wrong address in a search warrant can be a problem. >> >> jjaeggli at cXX-XX-XX0> show route table inet6.0 >> 2800:af:ba30:e8cf:4881:973a:c68 >> ^ >> invalid ip address or hostname: 2800:af:ba30:e8cf:4881:973a:c68 at >> '2800:af:ba30:e8cf:4881:973a:c68' >> >> jjaeggli at cXX-XX-XX0> show route table inet6.0 >> 2800:af:ba30:e8cf:d06f:4881:973a:c68 >> >> inet6.0: 9674 destinations, 38494 routes (9674 active, 0 holddown, 19088 >> hidden) >> + = Active Route, - = Last Active, * = Both >> >> 2800:a0::/28 *[BGP/170] 1w2d 00:00:21, MED 50, localpref 200, from >> 2620:102:8004::10 >> AS path: 7922 12956 6057 I >> >> XXXX-XXXXX:~ jjaeggli$ whois -h whois.lacnic.net >> 2800:af:ba30:e8cf:d06f:4881:973a:c68 >> >> scopes it to not being a problem you can solve with policy in the arin >> region. > > Lather rinse repeat with a better choice of address... > > 2001:550:3ee3:f329:102a3:2aff:fe23:1f69 > > This is in the ARIN region... Actually it's not a valid address at all, because it also has a typo. one might assume with a typo that the most significant bits are probably correct but potentially compounding errors doesn't sound like a good idea. > It's from within a particular ISP's /32. > > Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. > Have they delegated it to an end user? Again, if so, it's not in whois. > > Same for 2001:550:10:20:62a3:3eff:fe19:2909 > > I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong > in this particular case, but if they have been delegated and not registered in whois, that's > a real problem when it comes time to get a search warrant if speed is of the essence. If you're asserting that cogent is not swiping their delegations then do so. they have certain obligations as an LIR under the policy under which resources were delegated to them. future prefix assignments will clearly require that the demonstrate utilization much as they are required to in ipv4. > Owen > > From owen at delong.com Sun Jun 17 21:08:57 2012 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Jun 2012 19:08:57 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <4FDE85A7.2050700@bogus.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> <4FDE85A7.2050700@bogus.com> Message-ID: <8B15B8AA-0F48-4EAE-816B-D8A973C93076@delong.com> >> Lather rinse repeat with a better choice of address... >> >> 2001:550:3ee3:f329:102a3:2aff:fe23:1f69 >> >> This is in the ARIN region... > > Actually it's not a valid address at all, because it also has a typo. > one might assume with a typo that the most significant bits are probably > correct but potentially compounding errors doesn't sound like a good idea. > Yes... Should have been 2001:550:3ee3:f329:02a3:2aff:fe23:1f69. Not sure how the extra 1 got in there. >> It's from within a particular ISP's /32. >> >> Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. >> Have they delegated it to an end user? Again, if so, it's not in whois. >> >> Same for 2001:550:10:20:62a3:3eff:fe19:2909 >> >> I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong >> in this particular case, but if they have been delegated and not registered in whois, that's >> a real problem when it comes time to get a search warrant if speed is of the essence. > > If you're asserting that cogent is not swiping their delegations then do > so. they have certain obligations as an LIR under the policy under which > resources were delegated to them. future prefix assignments will > clearly require that the demonstrate utilization much as they are > required to in ipv4. > I'm making no assertion about cogent whatsoever. Since I don't know whether those addresses I chose at random within the ARIN region happen to be delegated or not, I have no ability to determine whether they should be registered as delegated or not. I said this in the above paragraph you quoted. I was attempting to demonstrate the potential problem, not point to an extant example as I do not have an extant example handy, though I suspect such do actually exist. Owen From mysidia at gmail.com Sun Jun 17 21:22:18 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 17 Jun 2012 21:22:18 -0500 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <4FDE85A7.2050700@bogus.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> <4FDE85A7.2050700@bogus.com> Message-ID: On 6/17/12, Joel jaeggli wrote: [snip] > resources were delegated to them. future prefix assignments will > clearly require that the demonstrate utilization much as they are > required to in ipv4. Sure. But they don't necessarily have to have WHOIS listings up to date in order to successfully demonstrate utilization; it is possible they provide private documentation or utilize the spreadsheet method of demonstrating utilization, without publishing details in WHOIS, and indicate they themselves serve as contact. The IP address WHOIS database is a system for identifying valid network contacts to report connectivity and operational issues to, and the contact listed in WHOIS for a network does not necessarily have to be an organization capable of identifying an individual user or customer. WHOIS is not a system for tracing IP addresses down to an individual user level, not with IPv6, not with IPv4. >> Owen -- -JH From vinny at abellohome.net Sun Jun 17 21:30:34 2012 From: vinny at abellohome.net (Vinny Abello) Date: Sun, 17 Jun 2012 22:30:34 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <7057D99E-FC38-4AD0-8FD6-EDE0F718984F@corp.arin.net> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <4FDE37B5.4030809@abellohome.net> <7057D99E-FC38-4AD0-8FD6-EDE0F718984F@corp.arin.net> Message-ID: <4FDE92CA.2010505@abellohome.net> Hey John, Thanks for taking the time for the detailed response. I always enjoy reading your posts. On 6/17/2012 7:16 PM, John Curran wrote: > On Jun 17, 2012, at 4:01 PM, Vinny Abello wrote: >> If anything, I feel like this is a ploy by the FBI feeding the media to >> get criminals to adopt IPv6 thinking they're harder to track and drop >> their guard so they'll be easier to catch. > > No, it's a real concern that law enforcement has with the current > incentives for keeping the Whois up to date, and what happens with > IPv6. Feel free to come to an ARIN meeting and chat with the folks > from US, Canada, and various Caribbean governments about their issue. It would seem to me if the if law enforcement is concerned about incentives to make networks do this, then it should be made a law within their operating jurisdiction to enforce this compliance. Failure to comply would have legal and possibly financial consequences in the form of fines or other penalties. We have many more obtuse laws about us (at least in the US that I'm familiar with) that this doesn't seem infeasible or impractical of a goal that will benefit the majority of people via law enforcement's ability to protect and serve. Hoping for a technical solution or self governing "document IPv6 allocations just because we're supposed to, even though there is no consequence either way" won't result in any action. Incentives are also not equally received among 100% of the population. Not everyone likes cookies. :) > By the way, it is not that there is _no_ incentive... Any _large_ ISP > ends up having to provide lawful response duties (often the same team > that handles spam/abuse/copyright issues) and that means staff. For > networks that put subdelegations into Whois reliably, there are less > requests for routine information (ergo less staff & less co$t needed > to respond.) Not many ISPs are the size where such inquires are routine > enough for having a dedicated team, but those who do generally realize > the pleasant side effect of keeping Whois up-to-date. This isn't really > seen by ISPs who only get the occasional LEA request, so it's not a > meaningful incentive on its own for many service providers. That right there is the problem. The Internet isn't just large ISP's (thank God). You're never going to get an incentive that appeals equally across all types of businesses to comply. Some just don't have the resources like you stated, to even document the allocations despite being required to. If a company were to downsize and looked at someone's job who SWIP'ed allocations or maintained WHOIS, the question would be asked of what would happen if they stopped. In IPv6 land for the small to medium ISP, the answer would be nothing as is illustrated by this article. They would be let go by upper management that didn't know any better, and the company would stop documenting even if they initially did the right thing. Even if ARIN refunded 100% of the fees to networks who properly documented everything and only charged those who were not in compliance, you'd still find people not documenting because it costs less to pay the fee than pay someone to manage that. Incentives are not the solution. Congress should consider passing a law in the US if this of that much concern. I'm unfamiliar with other jurisdiction's law processes covered within the ARIN region, but from the US standpoint, that's the only way I see something actually happening. Technical problems are frequently solved best by technical solutions; legal problems by legal solutions. This is a law enforcement problem and I feel it should be properly solved by a legal solution, but I'm sure someone will be glad to oppose my stated opinion with their own. :) I'm also sure a die hard technical advocate of some technology who is much smarter than myself will illustrate just how technology can solve the problem, so please prove me wrong so we don't need to rely on more government "solutions". I beg of you! :) -Vinny From vinny at abellohome.net Sun Jun 17 21:46:21 2012 From: vinny at abellohome.net (Vinny Abello) Date: Sun, 17 Jun 2012 22:46:21 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> <4FDE85A7.2050700@bogus.com> Message-ID: <4FDE967D.8020703@abellohome.net> On 6/17/2012 10:22 PM, Jimmy Hess wrote: > On 6/17/12, Joel jaeggli wrote: > [snip] >> resources were delegated to them. future prefix assignments will >> clearly require that the demonstrate utilization much as they are >> required to in ipv4. > > Sure. But they don't necessarily have to have WHOIS listings up to > date in order to successfully demonstrate utilization; it is possible > they provide private documentation or utilize the spreadsheet method > of demonstrating utilization, without publishing details in WHOIS, > and indicate they themselves serve as contact. > > > The IP address WHOIS database is a system for identifying valid > network contacts to report connectivity and operational issues to, > and the contact listed in WHOIS for a network does not necessarily > have to be an organization capable of identifying an individual user > or customer. > > WHOIS is not a system for tracing IP addresses down to an individual user level, > not with IPv6, not with IPv4. Thanks for clearly stating this, Jimmy. This is largely my point with WHOIS as well, although I may not have expressed it clearly. Along the same lines, WHOIS is not Geolocation (as poorly as that technology works, frequently because it's partly or mostly built on WHOIS data to begin with). The registered place of business an assignment points to, which may be completely accurate for valid network contacts at a company headquarters, doesn't dictate satellite offices are at the same address, city, state or country which may make up 90% of the use of the entire allocation... just as one example. This is abundant in enterprises. -Vinny From surfer at mauigateway.com Sun Jun 17 21:48:31 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Sun, 17 Jun 2012 19:48:31 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! Message-ID: <20120617194831.EEE2C03B@resin09.mta.everyone.net> --- vinny at abellohome.net wrote: From: Vinny Abello : It would seem to me if the if law enforcement is concerned about : incentives to make networks do this, then it should be made a law : within their operating jurisdiction to enforce this compliance. : This is a law enforcement problem and I feel it should be properly : solved by a legal solution, ------------------------------------------------------- Worst case solution. Guaranteed. scott From vinny at abellohome.net Sun Jun 17 21:51:14 2012 From: vinny at abellohome.net (Vinny Abello) Date: Sun, 17 Jun 2012 22:51:14 -0400 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120617194831.EEE2C03B@resin09.mta.everyone.net> References: <20120617194831.EEE2C03B@resin09.mta.everyone.net> Message-ID: <4FDE97A2.30409@abellohome.net> On 6/17/2012 10:48 PM, Scott Weeks wrote: > > --- vinny at abellohome.net wrote: > From: Vinny Abello > > : It would seem to me if the if law enforcement is concerned about > : incentives to make networks do this, then it should be made a law > : within their operating jurisdiction to enforce this compliance. > > : This is a law enforcement problem and I feel it should be properly > : solved by a legal solution, > ------------------------------------------------------- > > > Worst case solution. Guaranteed. > > scott So again, please propose a better one and save us, because you know this is what will happen. :) -Vinny From cb.list6 at gmail.com Sun Jun 17 21:56:02 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 17 Jun 2012 19:56:02 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <4FDE967D.8020703@abellohome.net> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> <4FDE85A7.2050700@bogus.com> <4FDE967D.8020703@abellohome.net> Message-ID: On Jun 17, 2012 7:46 PM, "Vinny Abello" wrote: > > On 6/17/2012 10:22 PM, Jimmy Hess wrote: > > On 6/17/12, Joel jaeggli wrote: > > [snip] > >> resources were delegated to them. future prefix assignments will > >> clearly require that the demonstrate utilization much as they are > >> required to in ipv4. > > > > Sure. But they don't necessarily have to have WHOIS listings up to > > date in order to successfully demonstrate utilization; it is possible > > they provide private documentation or utilize the spreadsheet method > > of demonstrating utilization, without publishing details in WHOIS, > > and indicate they themselves serve as contact. > > > > > > The IP address WHOIS database is a system for identifying valid > > network contacts to report connectivity and operational issues to, > > and the contact listed in WHOIS for a network does not necessarily > > have to be an organization capable of identifying an individual user > > or customer. > > > > WHOIS is not a system for tracing IP addresses down to an individual > user level, > > not with IPv6, not with IPv4. > Thanks for clearly stating this, Jimmy. This is largely my point with > WHOIS as well, although I may not have expressed it clearly. > > Along the same lines, WHOIS is not Geolocation (as poorly as that > technology works, frequently because it's partly or mostly built on > WHOIS data to begin with). The registered place of business an > assignment points to, which may be completely accurate for valid network > contacts at a company headquarters, doesn't dictate satellite offices > are at the same address, city, state or country which may make up 90% of > the use of the entire allocation... just as one example. This is > abundant in enterprises. > > -Vinny +1 to Jimmy and Vinny, and going back to the OP. .. This is why the article is poorly formed. Whois evolution and practices are NOT a speedbump for ipv6 deployment. Traceroute is likely more informative than whois. ...or looking at a bgp as path... For both ipv4 and ipv6 You think whois traceability is a problem in ipv6? It is nothing compared to ipv4 CGN traceability challenges.... Which the article also mentions. CB From randy at psg.com Sun Jun 17 22:23:21 2012 From: randy at psg.com (Randy Bush) Date: Mon, 18 Jun 2012 12:23:21 +0900 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <4FDE97A2.30409@abellohome.net> References: <20120617194831.EEE2C03B@resin09.mta.everyone.net> <4FDE97A2.30409@abellohome.net> Message-ID: >>> This is a law enforcement problem and I feel it should be properly >>> solved by a legal solution, >> Worst case solution. Guaranteed. > So again, please propose a better one and save us, because you know > this is what will happen. :) o terms such as "regulation" and "governance" presuppose a centralized hierarchic view of the universe. the internet has grown, exploded, and constructively disrupted because we "coordinate" and we "cooperate." those who wish to stifle growth and disruption (of their saurian business models) try to get us to assume the culture of control, centralization, and hierarchy. o to quote jeff schiller Law enforcement was not supposed to be easy. Where it is easy, it's called a police state. o so my interest in accurate registry data is not for law enforcement, the mpa, riaa, et alia. it is so we can better and more efficiently operate the internet. o i want to be able to contact the routing, abuse, whatever desks of the isp responsible for some address space. i have no desire to contact a dsl consumer as they have no fracking clue. the routing and abuse desks of the isp are sufficiently daunting. o if we believe ipv6 space to be effectively infinite, then the rirs really do not need to know usage data, do they? randy From Jonathon.Exley at kordia.co.nz Sun Jun 17 22:50:16 2012 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Mon, 18 Jun 2012 03:50:16 +0000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <0A3A7F18-3DED-4785-B882-D75584B07174@sonn.com> References: <20120615145717.EEE73B15@m0005296.ppops.net> <0A3A7F18-3DED-4785-B882-D75584B07174@sonn.com> Message-ID: APNIC has a web based whois form that is pretty easy to drive. Jonathon > -----Original Message----- > From: Steven Noble [mailto:snoble at sonn.com] > Sent: Saturday, 16 June 2012 12:05 p.m. > To: goemon at anime.net > Cc: nanog at nanog.org > Subject: Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! > > > > Sent from my iPhone > > On Jun 15, 2012, at 3:53 PM, goemon at anime.net wrote: > > > On Fri, 15 Jun 2012, Scott Weeks wrote: > > > > if arin would clamp down and revoke allocations that had provably > wrong/fraudulent whois data, we would probably get 50% IPv4 space back. > > Part of the issue is how hard it is to update ARIN, they gladly take your > money but it's like pulling teeth to get anything updated and sometimes > you run out of teeth. > > I don't know if this is true about apnic, ripe and the others. This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From rdobbins at arbor.net Sun Jun 17 22:56:41 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 18 Jun 2012 03:56:41 +0000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <20120615145717.EEE73B15@m0005296.ppops.net> <0A3A7F18-3DED-4785-B882-D75584B07174@sonn.com> Message-ID: On Jun 18, 2012, at 10:50 AM, Jonathon Exley wrote: > APNIC has a web based whois form that is pretty easy to drive. Yes, but data-entry tools which are viewed as secondary to the task at hand - i.e., address allocations - and which require interactive human participation to perform duplicative input don't tend to scale very well. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From marka at isc.org Sun Jun 17 23:23:02 2012 From: marka at isc.org (Mark Andrews) Date: Mon, 18 Jun 2012 14:23:02 +1000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: Your message of "Mon, 18 Jun 2012 03:56:41 GMT." References: <20120615145717.EEE73B15@m0005296.ppops.net> <0A3A7F18-3DED-4785-B882-D75584B07174@sonn.com> Message-ID: <20120618042303.0A7FB21B2D13@drugs.dv.isc.org> In message , "Dobbins, Roland" writes: > > On Jun 18, 2012, at 10:50 AM, Jonathon Exley wrote: > > > APNIC has a web based whois form that is pretty easy to drive.=20 > > Yes, but data-entry tools which are viewed as secondary to the task at hand= > - i.e., address allocations - and which require interactive human particip= > ation to perform duplicative input don't tend to scale very well. APNIC has B2B over email. It should be possible to totally automate updating APNIC. http://www.apnic.net/apnic-info/whois_search/using-whois/updating-whois/objects -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rdobbins at arbor.net Sun Jun 17 23:34:54 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 18 Jun 2012 04:34:54 +0000 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120618042303.0A7FB21B2D13@drugs.dv.isc.org> References: <20120615145717.EEE73B15@m0005296.ppops.net> <0A3A7F18-3DED-4785-B882-D75584B07174@sonn.com> <20120618042303.0A7FB21B2D13@drugs.dv.isc.org> Message-ID: <9A286256-A04D-409B-86BB-C7BC86E9E3B3@arbor.net> On Jun 18, 2012, at 11:23 AM, Mark Andrews wrote: > APNIC has B2B over email. It should be possible to totally automate updating APNIC. That's a much better option than the Web form. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From arturo.servin at gmail.com Mon Jun 18 06:50:54 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 18 Jun 2012 08:50:54 -0300 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> Message-ID: On 17 Jun 2012, at 20:29, Owen DeLong wrote: > > Lather rinse repeat with a better choice of address... > > 2001:550:3ee3:f329:102a3:2aff:fe23:1f69 > > This is in the ARIN region... > > It's from within a particular ISP's /32. > > Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. > Have they delegated it to an end user? Again, if so, it's not in whois. > > Same for 2001:550:10:20:62a3:3eff:fe19:2909 > > I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong > in this particular case, but if they have been delegated and not registered in whois, that's > a real problem when it comes time to get a search warrant if speed is of the essence. > > Owen > Not being in the whois is not an indicator that the ISP (to whom the address block has been delegated) does not know about which customer has an IP (v4 or v6, doesn't matter). I have seen tons of ISPs that do not publish delegations in the whois but have a huge excel worksheets where they record every suballocation. You just need a warrant to see that info. Ergo, the FBI, interpol or you name it should not have problem to get them. /as From owen at delong.com Mon Jun 18 07:48:48 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Jun 2012 05:48:48 -0700 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> Message-ID: <11B526C7-5B3D-42EC-8D01-584F1B11199D@delong.com> On Jun 18, 2012, at 4:50 AM, Arturo Servin wrote: > > On 17 Jun 2012, at 20:29, Owen DeLong wrote: > >> >> Lather rinse repeat with a better choice of address... >> >> 2001:550:3ee3:f329:102a3:2aff:fe23:1f69 >> >> This is in the ARIN region... >> >> It's from within a particular ISP's /32. >> >> Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. >> Have they delegated it to an end user? Again, if so, it's not in whois. >> >> Same for 2001:550:10:20:62a3:3eff:fe19:2909 >> >> I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong >> in this particular case, but if they have been delegated and not registered in whois, that's >> a real problem when it comes time to get a search warrant if speed is of the essence. >> >> Owen >> > > Not being in the whois is not an indicator that the ISP (to whom the address block has been delegated) does not know about which customer has an IP (v4 or v6, doesn't matter). I have seen tons of ISPs that do not publish delegations in the whois but have a huge excel worksheets where they record every suballocation. > > You just need a warrant to see that info. Ergo, the FBI, interpol or you name it should not have problem to get them. > > /as Right... However... 1. That's a violation of resource policy. 2. It's an extra step and multi-day delay in a situation where time may be of the essence. Further, we're not talking about the recording of every end-user assignment so much as the fact that in some cases, large delegations to down-stream ISPs are not recorded in whois. My understanding from talking to the FBI/DEA people is that they want to be able to serve the correct ISP on the first try rather than iterating through multiple layers of delegations. That does not seem an unreasonable expectation. Owen From lists at internetpolicyagency.com Mon Jun 18 07:52:19 2012 From: lists at internetpolicyagency.com (Roland Perry) Date: Mon, 18 Jun 2012 13:52:19 +0100 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <20120617095906.GA32028@vacation.karoshi.com.?> References: <20120616160738.EEE097C4@resin05.mta.everyone.net> <20120617095906.GA32028@vacation.karoshi.com.?> Message-ID: In article <20120617095906.GA32028 at vacation.karoshi.com.?>, bmanning at vacation.karoshi.com top-posts: Why not. Lots of aspects of the Internet are regulated. > Internet Regulator? > >/bill > > >On Sun, Jun 17, 2012 at 10:43:26AM +0100, Roland Perry wrote: >> In article <20120616160738.EEE097C4 at resin05.mta.everyone.net>, Scott >> Weeks writes >> >> >What is going to make folks change their behavior? >> >> If all else fails, perhaps a regulator fining the ISP $1000 for every >> allocation (I agree that whether it's IPv4 or IPv6 isn't relevant) where >> the WHOIS information is shown to be false or significantly out of date. >> >> They could send compliance teams in to check, just like the IRS does for >> the accounts. >> -- >> Roland Perry -- Roland Perry From arturo.servin at gmail.com Mon Jun 18 08:13:07 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 18 Jun 2012 10:13:07 -0300 Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: <11B526C7-5B3D-42EC-8D01-584F1B11199D@delong.com> References: <12097624.9572.1339775966224.JavaMail.root@benjamin.baylink.com> <98B4B07E-3EAE-4F29-BC51-22152FBE2AA7@gmail.com> <27626.1339953843@turing-police.cc.vt.edu> <4FDE19B0.80800@bogus.com> <11B526C7-5B3D-42EC-8D01-584F1B11199D@delong.com> Message-ID: <2C881C01-48B2-4536-BF31-88463CF652A6@gmail.com> On 18 Jun 2012, at 09:48, Owen DeLong wrote: > > On Jun 18, 2012, at 4:50 AM, Arturo Servin wrote: > >> >> On 17 Jun 2012, at 20:29, Owen DeLong wrote: >> >>> >>> Lather rinse repeat with a better choice of address... >>> >>> 2001:550:3ee3:f329:102a3:2aff:fe23:1f69 >>> >>> This is in the ARIN region... >>> >>> It's from within a particular ISP's /32. >>> >>> Has that ISP delegated some overlapping fraction to another ISP? If so, it's not in whois. >>> Have they delegated it to an end user? Again, if so, it's not in whois. >>> >>> Same for 2001:550:10:20:62a3:3eff:fe19:2909 >>> >>> I don't honestly know if either of those prefixes is allocated or not, so maybe nothing's wrong >>> in this particular case, but if they have been delegated and not registered in whois, that's >>> a real problem when it comes time to get a search warrant if speed is of the essence. >>> >>> Owen >>> >> >> Not being in the whois is not an indicator that the ISP (to whom the address block has been delegated) does not know about which customer has an IP (v4 or v6, doesn't matter). I have seen tons of ISPs that do not publish delegations in the whois but have a huge excel worksheets where they record every suballocation. >> >> You just need a warrant to see that info. Ergo, the FBI, interpol or you name it should not have problem to get them. >> >> /as > > Right... > > However... > > 1. That's a violation of resource policy. > 2. It's an extra step and multi-day delay in a situation where time may be of the essence. > > Further, we're not talking about the recording of every end-user assignment so much as the fact that in some cases, large delegations to down-stream ISPs are not recorded in whois. My understanding from talking to the FBI/DEA people is that they want to be able to serve the correct ISP on the first try rather than iterating through multiple layers of delegations. > > That does not seem an unreasonable expectation. > > Owen > Not at all an unreasonable expectation. And that's the way it should be IMO. My point is that v6 is not very different than IPv4 in that respect. /as From Jason_Livingood at cable.comcast.com Mon Jun 18 08:23:47 2012 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 18 Jun 2012 13:23:47 +0000 Subject: Our first inbound email via IPv6 (was spam!) In-Reply-To: <4FDE116A.9070003@jason.roysdon.net> Message-ID: On 6/17/12 1:18 PM, "Jason Roysdon" wrote: >Jason, > >Will all MX get AAAA RRs, or at least all of your MX priority levels >have at least one AAAA RR? Without a failure of mx2 & mx3, Sendmail and >well-behaving mail servers are never going to try mx1. Yes, in the relatively near future. - Jason From jra at baylink.com Mon Jun 18 12:25:52 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 18 Jun 2012 13:25:52 -0400 (EDT) Subject: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE! In-Reply-To: Message-ID: <30092240.9868.1340040352952.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Arturo Servin" > Again, if every ISP followed BCP 38 that would not happen (IPv6 and > IPv4). But they are not, and probably they won't. I disagree with Arturo's assertion that BCP38 would help the "people don't SWIP their subdelegations" problem, but that doesn't mean it wouldn't help on lots of other points. The vector sum of the responses I (didn't) get when I asked about this last Friday, though, was somewhere between crickets and giggles. Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From mohta at necom830.hpcl.titech.ac.jp Tue Jun 19 08:10:19 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 19 Jun 2012 22:10:19 +0900 Subject: IPv6 day and tunnels In-Reply-To: References: <4FCC11B2.2090405@ttec.com> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> <4FD72C3D.10709@necom830.hpcl.titech.ac.jp> <4FD7A7B5.1070306@necom830.hpcl.titech.ac.jp> <4FD7B093.3010808@necom830.hpcl.titech.ac.jp> Message-ID: <4FE07A3B.8080900@necom830.hpcl.titech.ac.jp> Templin, Fred L wrote: >> Not necessarily, as IPv4 can take care of itself and IPv6 >> is hopeless. > > IPv4 can take care of it how - with broken PMTUD or As you know, RFC1191 style PMTUD is broken both for IPv4 and IPv6. > with broken fragmentation/reassembly? Fragmentation is fine, especially with RFC4821 style PMTUD, even though RFC4821 tries to make people believe it is broken, because accidental ID match is negligibly rare even with IPv4. > And, you won't > get any argument from me that IPv6 has been stuck > for years for good reasons - but MTU failures can > soon be taken off the list. Now, it's time for you to return v6-ops to defend your draft from Joe Touch. Note that there is no point for IPv6 forbid fragmentation by intermediate routers. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 19 08:21:11 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 19 Jun 2012 22:21:11 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4766.1339604070@turing-police.cc.vt.edu> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> <4FD82977.20904@necom830.hpcl.titech.ac.jp> <4766.1339604070@turing-police.cc.vt.edu> Message-ID: <4FE07CC7.5040401@necom830.hpcl.titech.ac.jp> valdis.kletnieks at vt.edu wrote: > And you tell the rest of the world that customer A's SMTP port is on > 125, and B's is on 225, and Z's is up at 2097, how? How? In draft-ohta-e2e-nat-00.txt, I already wrote: A server port number different from well known ones may be specified through mechanisms to specify an address of the server, which is the case of URLs. However, port numbers for DNS and SMTP are, in general, implicitly assumed by DNS and are not changeable. When an ISP operate a NAT gateway, the ISP should, for fairness between customers, reserve some well know port numbers and assign small port numbers evenly to all the customers. Or, a NAT gateway may receive packets to certain ports and behave as an application gateway to end hosts, if request messages to the server contains information, such as domain names, which is the case with DNS, SMTP and HTTP, to demultiplex the request messages to end 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. > (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. > (Totally overlooking the debugging issues that arise when a customer tries > to run a combination of applications that in aggregate have 101 ports open..) The applications are broken, if they can't handle temporally error of EAGAIN to use the 101st port. Unlike legacy NAT, where no error can be returned for failed port allocation, end to end NAT can take care of the situation. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Jun 19 08:28:11 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 19 Jun 2012 22:28:11 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <3AFDBCF3-F34F-48EE-A714-ECF419EB3C9A@delong.com> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> <4FD82977.20904@necom830.hpcl.titech.ac.jp> <3AFDBCF3-F34F-48EE-A714-ECF419EB3C9A@delong.com> Message-ID: <4FE07E6B.2010900@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: > Showing that you don't actually understand what everyone else means when > they say "end-to-end". Where is your point only to demonstrate that you don't understand what"end to end" means? > No carrier is going to implement that for obvious reasons. > > Besides, that's not transparent end-to-end, that's predictably opaque > end-to-end. With no reasoning of you, I can simply say: WRONG >> UPnP provides information for clients to restore IP and TCP >> headers from local ones back to global ones, which is visible >> to applications. > But it doesn't work across multiple layers of NAT. It is trivially easy to make UPnP works across multiple layers of UPnP capable NAT. > Now, redraw the diagram for the real world scenario: > > host <-> UPnP NAT <-> Carrier NAT <-> Internet <-> Carrier NAT <-> UPnP NAT <-> host > > Tell me again how the application signaling from UPnP survives through all that and comes up with correct answers? It is trivially: host <-> home UPnP NAT <-> Carrier UPnP NAT <-> Internet <-> Carrier UPnP NAT <-> home UPnP NAT <-> host Masataka Ohta From alexandru.petrescu at gmail.com Tue Jun 19 10:44:50 2012 From: alexandru.petrescu at gmail.com (Alexandru Petrescu) Date: Tue, 19 Jun 2012 17:44:50 +0200 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> References: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> Message-ID: <4FE09E72.3060005@gmail.com> I think, the length of Interface ID be 64 is so mostly because IEEE works now with 64bit EUI identifiers (instead of older 48bit MAC addresses). I.e. compatibility between IEEE and IETF IPv6 would be the main reason for this Interface ID to be 64. And this is so, even though there are IEEE links for which the MAC address is even shorter than 64bit, like 802.15.4 short addresses being on 16bit. For those, an IPv6 prefix length of 112bit would even make sense. But it's not done, because same IEEE which says the 15.4 MAC address is 16bit says that its EUI is 64bit. (what 'default' fill that with is what gets into an IPv6 address as well). The good thing isthere is nothing in the RFC IPv6 Addressing Architecture that makes the Interface ID to be MUST 64bit. It just says 'n'. What there _is_, is that when using RFC stateless addess autoconfiguration (not DHCP) and on Ethernet and its keen (WiFi, Bluetooth, ZigBee, more; but not USB nor LTE for example) then one must use Interface ID of 64bit; and consequently network prefix length of 64bit no more. Alex Le 06/06/2012 16:58, Chuck Church a ?crit : > Does anyone know the reason /64 was proposed as the size for all L2 > domains? I've looked for this answer before, never found a good one. > I thought I read there are some L2 technologies that use a 64 bit > hardware address, might have been Bluetooth. Guaranteeing that ALL > possible hosts could live together in the same L2 domain seems like > overkill, even for this group. /80 would make more sense, it does > match up with Ethernet MACs. Not as easy to compute, for humans nor > processors that like things in 32 or 64 bit chunks however. Anyone > have a definite answer? > > Thanks, > > Chuck > > -----Original Message----- From: > Jean-Francois.TremblayING at videotron.com > [mailto:Jean-Francois.TremblayING at videotron.com] Sent: Wednesday, > June 06, 2012 10:36 AM To: anton at huge.geek.nz Cc: NANOG list Subject: > IPv6 /64 links (was Re: ipv6 book recommendations?) > > Anton Smith a ?crit sur 06/06/2012 09:53:02 AM > : > >> Potentially silly question but, as Bill points out a LAN always >> occupies a /64. >> >> Does this imply that we would have large L2 segments with a large >> number of hosts on them? What about the age old discussion about >> keeping broadcast segments small? > > The /64 only removes the limitation on the number of *addresses* on > the L2 domain. Limitations still apply for the amount of ARP and ND > noise. A maximum number of hosts is reached when that noise floor > represents a significant portion of the link bandwidth. If ARP/ND > proxying is used, the limiting factor may instead be the CPU on the > gateway. > > The ND noise generated is arguably higher than ARP because of DAD, > but I don't remember seeing actual numbers on this (anybody?). I've > seen links with up to 15k devices where ARP represented a > significant part of the link usage, but most weren't (yet) IPv6. > > /JF > > > > > > From alexandru.petrescu at gmail.com Tue Jun 19 10:48:08 2012 From: alexandru.petrescu at gmail.com (Alexandru Petrescu) Date: Tue, 19 Jun 2012 17:48:08 +0200 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> Message-ID: <4FE09F38.9070800@gmail.com> Le 07/06/2012 22:27, Ricky Beam a ?crit : > On Wed, 06 Jun 2012 10:58:05 -0400, Chuck Church > wrote: >> Does anyone know the reason /64 was proposed as the size for all L2 >> domains? > > There is one, and only one, reason for the ::/64 split: SLAAC. IPv6 > is a classless addressing system. You can make your LAN ::/117 if > you want to; SLAAC will not work there. SLAAC could work with ::/117 but not on Ethernet and its keen. There are many other links than Ethernet and IEEE. Nothing (no RFC) prohibits SLAAC with something longer than 64, provided a means to form an Interfac Identifier for that particular link is provided. I.e. a new document that specifies e.g. IPv6-over-LTE (replace LTE with something non-IEEE). Alex > > The reason the requirement is (currently) 64 is to accomodate EUI-64 > hardware addresses -- firewire, bluetooth, fibre channel, etc. > Originally, SLAAC was designed for ethernet and its 48bit hardware > address. (required LAN mask was ::/80.) The purpose wasn't to put > the whole internet into one LAN. It was to make address selection > "brainless", esp. for embeded systems with limited memory/cpu/etc... > they can form an address by simply appending their MAC to the > prefix, and be 99.99999% sure it won't be in use. (i.e. no DAD > required.) However, that was optimizing a problem that never existed > -- existing tiny systems of the day were never destined to have an > IPv6 stack, "modern" IPv6 hardware can select an address and perform > DAD efficiently in well under 1K. (which is noise vs. the size of the > rest of the IPv6 stack.) > > SLAAC has been a flawed idea from the first letter... if for no other > reason than it makes people think "64bit network + 64bit host" -- > and that is absolutely wrong. (one cannot make such assumptions about > networks they do not control. it's even worse when people design > hardware thinking that.) > > --Ricky > > > From Fred.L.Templin at boeing.com Tue Jun 19 11:35:39 2012 From: Fred.L.Templin at boeing.com (Templin, Fred L) Date: Tue, 19 Jun 2012 09:35:39 -0700 Subject: IPv6 day and tunnels In-Reply-To: <4FE07A3B.8080900@necom830.hpcl.titech.ac.jp> References: <4FCC11B2.2090405@ttec.com> <4FCE60FB.3040302@necom830.hpcl.titech.ac.jp> <4FCE7DB6.7050505@necom830.hpcl.titech.ac.jp> <4FCE8B00.8010001@necom830.hpcl.titech.ac.jp> <4FCEB598.8000902@necom830.hp! cl.titech.ac.jp> <4FCFFC41.9020208@necom830.hpcl.titech.ac.jp> <4FD72C3D.10709@necom830.hpcl.titech.ac.jp> <4FD7A7B5.1070306@necom830.hpcl.titech.ac.jp> <4FD7B093.3010808@necom830.hpcl.titech.ac.jp> <4FE07A3B.8080900@necom830.hpcl.titech.ac.jp> Message-ID: > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Tuesday, June 19, 2012 6:10 AM > To: Templin, Fred L > Cc: Owen DeLong; nanog at nanog.org > Subject: Re: IPv6 day and tunnels > > Templin, Fred L wrote: > > >> Not necessarily, as IPv4 can take care of itself and IPv6 > >> is hopeless. > > > > IPv4 can take care of it how - with broken PMTUD or > > As you know, RFC1191 style PMTUD is broken both for IPv4 > and IPv6. Unfortunately, there is evidence that this is the case. > > with broken fragmentation/reassembly? > > Fragmentation is fine, especially with RFC4821 style PMTUD, > even though RFC4821 tries to make people believe it is broken, > because accidental ID match is negligibly rare even with IPv4. The 16-bit IP ID, plus the 120sec MSL, limits the rate for fragmentable packets to 6.4Mbps for a 1500 MTU. Exceeding this rate leads to the possibility of fragment misassociations (RFC4963). This would not be a problem if there were some stronger integrity check than just the Internet checksum, but with the current system we don't have that. > > And, you won't > > get any argument from me that IPv6 has been stuck > > for years for good reasons - but MTU failures can > > soon be taken off the list. > > Now, it's time for you to return v6-ops to defend your > draft from Joe Touch. > > Note that there is no point for IPv6 forbid fragmentation > by intermediate routers. I wasn't there when the decision was made, but based on my findings I don't disagree. Fred fred.l.templin at boeing.com > Masataka Ohta From John_Brzozowski at Cable.Comcast.com Tue Jun 19 11:40:17 2012 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Tue, 19 Jun 2012 16:40:17 +0000 Subject: A's for www.xfinitytv.com In-Reply-To: References: Message-ID: Paul, Circling back here, you all set here? Should see the following over IPv6 and IPv4: xfinity.comcast.net xfinitytv.comcast.net John ========================================= John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski at cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net ========================================= On Jun 8, 2012, at 10:33 AM, Paul WALL wrote: > I'm not learning any AAAA records for Streampix (www.xfinitytv.com), only A's. > > The domains this site redirects to are available over a v6 transport, > but not the actual streaming. > > Anyone know what's going on? > > Thanks, > Paul Wall > From me at anuragbhatia.com Tue Jun 19 15:15:10 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 20 Jun 2012 01:45:10 +0530 Subject: NTT handing packets to Reliance (Flag Telecom) in California for BSNL block Message-ID: Hello everyone, I was trying to understand reason for high latency between my BSNL (AS9829) connection and a specific Germany based server on M-Online. I can see forward path is correct but reverse path is: traceroute to 117.200.57.47 (117.200.57.X), 30 hops max, 60 byte packets 1 gw.giga-dns.com (91.194.90.1) [AS51167] 0.929 ms 0.915 ms 1.151 ms 2 host-93-104-204-33.customer.m-online.net (93.104.204.33) [AS8767] 1.144 ms 1.370 ms 1.608 ms 3 xe-1-1-0.rt-decix-2.m-online.net (82.135.16.102) [AS8767] 8.334 ms 8.325 ms 8.559 ms 4 xe-1-1-0.rt-decix-2.m-online.net (82.135.16.102) [AS8767] 8.043 ms 213.198.72.237 (213.198.72.237) [AS2914] 8.289 ms xe-1-1-0.rt-decix-2.m-online.net (82.135.16.102) [AS8767] 8.023 ms 5 ae-2.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.217) [AS2914] 77.508 ms 213.198.72.237 (213.198.72.237) [AS2914] 7.773 ms 7.768 ms 6 ae-1.r23.amstnl02.nl.bb.gin.ntt.net (129.250.3.179) [AS2914] 15.726 ms xe-1-1-3.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.221) [AS2914] 9.195 ms ae-3.r22.londen03.uk.bb.gin.ntt.net (129.250.3.137) [AS2914] 43.581 ms 7 ae-1.r23.amstnl02.nl.bb.gin.ntt.net (129.250.3.179) [AS2914] 15.876 ms xe-1-1-3.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.221) [AS2914] 42.557 ms 42.534 ms 8 ae-7.r21.asbnva02.us.bb.gin.ntt.net (129.250.2.144) [AS2914] 108.990 ms 101.966 ms ae-0.r23.nycmny01.us.bb.gin.ntt.net (129.250.3.73) [AS2914] 90.236 ms 9 ae-2.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.55) [AS2914] 167.662 ms ae-1.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9) [AS2914] 131.915 ms ae-7.r21.asbnva02.us.bb.gin.ntt.net (129.250.2.144) [AS2914] 99.925 ms 10 ae-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.4.4) [AS2914] 131.452 ms ae-2.r04.lsanca03.us.bb.gin.ntt.net (129.250.5.70) [AS2914] 162.135 ms 171.360 ms 11 ae-2.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.55) [AS2914] 227.815 ms ae-2.r04.lsanca03.us.bb.gin.ntt.net (129.250.5.70) [AS2914] 160.347 ms ae-2.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.55) [AS2914] 167.755 ms 12 ae-2.r04.lsanca03.us.bb.gin.ntt.net (129.250.5.70) [AS2914] 166.245 ms 172.954 ms 162.521 ms 13 xe-0-1-0-10.r04.lsanca03.us.ce.gin.ntt.net (198.172.90.222) [AS2914] 183.765 ms 183.748 ms 185.719 ms 14 115.249.245.201 (115.249.245.201) [AS18101] 322.389 ms 80.77.1.58 (80.77.1.58) [AS15412] 316.879 ms 218.248.255.57 (218.248.255.57) [AS9829] 315.371 ms 15 218.248.255.57 (218.248.255.57) [AS9829] 311.356 ms 311.584 ms 115.249.245.201 (115.249.245.201) [AS18101] 333.586 ms 16 218.248.173.41 (218.248.173.41) [AS9829] 359.339 ms 353.042 ms 354.021 ms 17 218.248.173.41 (218.248.173.41) [AS9829] 348.914 ms 344.156 ms 342.131 ms 18 * 218.248.173.41 (218.248.173.41) [AS9829] 354.091 ms * 19 * * * 20 * * * I can see from Reliance's Looking glass that there direct path from EU to India on their network. I wonder why exactly NTT handling off packets to Reliance in California? The problem seems only for BSNL block - 117.200.48.0/20. If destination is not BSNL and say Reliance itself...say for Monster.co.inweb server which is in Reliance datacenter: *Query Results:* *Router: *Amsterdam - NL *Command:* traceroute 220.226.205.30 *Disclaimer: Traceroute is a useful tool for determining the route a packet takes, but it should not be used as an accurate measure of network performance. For more information please view the Traceroute Disclaimer .* traceroute to 220.226.205.30 (220.226.205.30), 30 hops max, 40 byte packets 1 as-0.r22.amstnl02.nl.bb.gin.ntt.net (129.250.2.118) 15.806 ms 0.746 ms 0.718 ms MPLS Label=499040 CoS=0 TTL=1 S=0 MPLS Label=304400 CoS=0 TTL=1 S=1 2 ae-5.r23.londen03.uk.bb.gin.ntt.net (129.250.5.197) 8.180 ms 7.740 ms 8.770 ms MPLS Label=304400 CoS=0 TTL=1 S=1 3 ae-2.r02.londen03.uk.bb.gin.ntt.net (129.250.5.41) 16.229 ms 15.829 ms 16.326 ms 4 flagtelecom-0.r02.londen03.uk.bb.gin.ntt.net (83.231.235.238) 15.059 ms 16.032 ms 7.014 ms 5 62.216.128.106 (62.216.128.106) 8.332 ms 62.216.128.122 (62.216.128.122) 32.306 ms ge-0-0-3.0.cjr02.ldn004.flagtel.com (62.216.128.138) 9.051 ms MPLS Label=412816 CoS=0 TTL=1 S=1 6 so-1-0-0.0.pjr02.ldn001.flagtel.com (85.95.25.9) 8.616 ms so-1-0-0.0.pjr01.ldn001.flagtel.com (85.95.25.13) 19.806 ms ge-0-1-0.0.pjr01.ldn001.flagtel.com (62.216.129.137) 8.059 ms MPLS Label=300480 CoS=0 TTL=1 S=1 7 so-4-0-0.0.pjr01.mmb004.flagtel.com (85.95.25.113) 280.327 ms so-1-0-0.0.pjr02.mmb004.flagtel.com (85.95.25.138) 281.659 ms so-3-1-0.0-pjr02.mmb004-flagtel.com (85.95.26.158) 282.889 ms 8 62.216.147.138 (62.216.147.138) 285.101 ms 695.643 ms 62.216.147.46 (62.216.147.46) 278.537 ms Pretty much direct. I wonder what exactly is different/wrong in case of BSNL block 117.200.48.0/20? Is BSNL selectively announcing it only from Reliance's California based router and not any other router in Europe? Can somehow one can test & confirm the above guess of selective announcement? (*Apologize if I missed some fundamental glitch error. I am new to it.*) Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter| Google+ From morrowc.lists at gmail.com Tue Jun 19 16:02:56 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 19 Jun 2012 17:02:56 -0400 Subject: NTT handing packets to Reliance (Flag Telecom) in California for BSNL block In-Reply-To: References: Message-ID: On Tue, Jun 19, 2012 at 4:15 PM, Anurag Bhatia wrote: > I wonder what exactly is different/wrong in case of BSNL block > 117.200.48.0/20? Is BSNL selectively announcing it only from Reliance's > California based router and not any other router in Europe? there's a fiber cut in that part of the world, and reliance is ... in the middle of it (smwe-4 I think?) maybe they decided that some of their customer traffic ought to take a less congested path? From me at anuragbhatia.com Tue Jun 19 16:53:22 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 20 Jun 2012 03:23:22 +0530 Subject: NTT handing packets to Reliance (Flag Telecom) in California for BSNL block In-Reply-To: References: Message-ID: Hello Christopher Thanks for pointing out SMW4 cut as reported here - http://www.renesys.com/blog/2012/06/smw4-break-on-south-asia.shtml As far as I see it is likely not linked to issue. I guess it is still some bad routing issue rather then impact of cable cut since I have seen similar issues in past (last few months). Thanks. On Wed, Jun 20, 2012 at 2:32 AM, Christopher Morrow wrote: > On Tue, Jun 19, 2012 at 4:15 PM, Anurag Bhatia > wrote: > > I wonder what exactly is different/wrong in case of BSNL block > > 117.200.48.0/20? Is BSNL selectively announcing it only from Reliance's > > California based router and not any other router in Europe? > > there's a fiber cut in that part of the world, and reliance is ... in > the middle of it (smwe-4 I think?) maybe they decided that some of > their customer traffic ought to take a less congested path? > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Linkedin | Twitter| Google+ From kauer at biplane.com.au Tue Jun 19 17:39:34 2012 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 20 Jun 2012 08:39:34 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE07E6B.2010900@necom830.hpcl.titech.ac.jp> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> <4FD82977.20904@necom830.hpcl.titech.ac.jp> <3AFDBCF3-F34F-48EE-A714-ECF419EB3C9A@delong.com> <4FE07E6B.2010900@necom830.hpcl.titech.ac.jp> Message-ID: <1340145574.2753.6.camel@karl> On Tue, 2012-06-19 at 22:28 +0900, Masataka Ohta wrote: > It is trivially: > > host <-> home UPnP NAT <-> Carrier UPnP NAT <-> Internet > <-> Carrier UPnP NAT <-> home UPnP NAT <-> host "Trivially"? I think this looks much nicer: host <-> Internet <-> host The way it used to be before NAT, and the way, with IPv6, it can be again. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From drew.weaver at thenap.com Tue Jun 19 17:42:33 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 19 Jun 2012 18:42:33 -0400 Subject: NTT handing packets to Reliance (Flag Telecom) in California for BSNL block In-Reply-To: References: Message-ID: I have also noticed that traffic sourced in NYC destined for Qatar across NTT seems to now go from NYC -> SJC -> SNG and ends up being about 180+ms longer than just going over the atlantic. I've seen this a few times (only with NTT routes). Thanks, -Drew -----Original Message----- From: Anurag Bhatia [mailto:me at anuragbhatia.com] Sent: Tuesday, June 19, 2012 4:15 PM To: NANOG Mailing List Subject: NTT handing packets to Reliance (Flag Telecom) in California for BSNL block Hello everyone, I was trying to understand reason for high latency between my BSNL (AS9829) connection and a specific Germany based server on M-Online. I can see forward path is correct but reverse path is: traceroute to 117.200.57.47 (117.200.57.X), 30 hops max, 60 byte packets 1 gw.giga-dns.com (91.194.90.1) [AS51167] 0.929 ms 0.915 ms 1.151 ms 2 host-93-104-204-33.customer.m-online.net (93.104.204.33) [AS8767] 1.144 ms 1.370 ms 1.608 ms 3 xe-1-1-0.rt-decix-2.m-online.net (82.135.16.102) [AS8767] 8.334 ms 8.325 ms 8.559 ms 4 xe-1-1-0.rt-decix-2.m-online.net (82.135.16.102) [AS8767] 8.043 ms 213.198.72.237 (213.198.72.237) [AS2914] 8.289 ms xe-1-1-0.rt-decix-2.m-online.net (82.135.16.102) [AS8767] 8.023 ms 5 ae-2.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.217) [AS2914] 77.508 ms 213.198.72.237 (213.198.72.237) [AS2914] 7.773 ms 7.768 ms 6 ae-1.r23.amstnl02.nl.bb.gin.ntt.net (129.250.3.179) [AS2914] 15.726 ms xe-1-1-3.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.221) [AS2914] 9.195 ms ae-3.r22.londen03.uk.bb.gin.ntt.net (129.250.3.137) [AS2914] 43.581 ms 7 ae-1.r23.amstnl02.nl.bb.gin.ntt.net (129.250.3.179) [AS2914] 15.876 ms xe-1-1-3.r20.frnkge04.de.bb.gin.ntt.net (129.250.5.221) [AS2914] 42.557 ms 42.534 ms 8 ae-7.r21.asbnva02.us.bb.gin.ntt.net (129.250.2.144) [AS2914] 108.990 ms 101.966 ms ae-0.r23.nycmny01.us.bb.gin.ntt.net (129.250.3.73) [AS2914] 90.236 ms 9 ae-2.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.55) [AS2914] 167.662 ms ae-1.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9) [AS2914] 131.915 ms ae-7.r21.asbnva02.us.bb.gin.ntt.net (129.250.2.144) [AS2914] 99.925 ms 10 ae-0.r20.asbnva02.us.bb.gin.ntt.net (129.250.4.4) [AS2914] 131.452 ms ae-2.r04.lsanca03.us.bb.gin.ntt.net (129.250.5.70) [AS2914] 162.135 ms 171.360 ms 11 ae-2.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.55) [AS2914] 227.815 ms ae-2.r04.lsanca03.us.bb.gin.ntt.net (129.250.5.70) [AS2914] 160.347 ms ae-2.r21.lsanca03.us.bb.gin.ntt.net (129.250.3.55) [AS2914] 167.755 ms 12 ae-2.r04.lsanca03.us.bb.gin.ntt.net (129.250.5.70) [AS2914] 166.245 ms 172.954 ms 162.521 ms 13 xe-0-1-0-10.r04.lsanca03.us.ce.gin.ntt.net (198.172.90.222) [AS2914] 183.765 ms 183.748 ms 185.719 ms 14 115.249.245.201 (115.249.245.201) [AS18101] 322.389 ms 80.77.1.58 (80.77.1.58) [AS15412] 316.879 ms 218.248.255.57 (218.248.255.57) [AS9829] 315.371 ms 15 218.248.255.57 (218.248.255.57) [AS9829] 311.356 ms 311.584 ms 115.249.245.201 (115.249.245.201) [AS18101] 333.586 ms 16 218.248.173.41 (218.248.173.41) [AS9829] 359.339 ms 353.042 ms 354.021 ms 17 218.248.173.41 (218.248.173.41) [AS9829] 348.914 ms 344.156 ms 342.131 ms 18 * 218.248.173.41 (218.248.173.41) [AS9829] 354.091 ms * 19 * * * 20 * * * I can see from Reliance's Looking glass that there direct path from EU to India on their network. I wonder why exactly NTT handling off packets to Reliance in California? The problem seems only for BSNL block - 117.200.48.0/20. If destination is not BSNL and say Reliance itself...say for Monster.co.inweb server which is in Reliance datacenter: *Query Results:* *Router: *Amsterdam - NL *Command:* traceroute 220.226.205.30 *Disclaimer: Traceroute is a useful tool for determining the route a packet takes, but it should not be used as an accurate measure of network performance. For more information please view the Traceroute Disclaimer .* traceroute to 220.226.205.30 (220.226.205.30), 30 hops max, 40 byte packets 1 as-0.r22.amstnl02.nl.bb.gin.ntt.net (129.250.2.118) 15.806 ms 0.746 ms 0.718 ms MPLS Label=499040 CoS=0 TTL=1 S=0 MPLS Label=304400 CoS=0 TTL=1 S=1 2 ae-5.r23.londen03.uk.bb.gin.ntt.net (129.250.5.197) 8.180 ms 7.740 ms 8.770 ms MPLS Label=304400 CoS=0 TTL=1 S=1 3 ae-2.r02.londen03.uk.bb.gin.ntt.net (129.250.5.41) 16.229 ms 15.829 ms 16.326 ms 4 flagtelecom-0.r02.londen03.uk.bb.gin.ntt.net (83.231.235.238) 15.059 ms 16.032 ms 7.014 ms 5 62.216.128.106 (62.216.128.106) 8.332 ms 62.216.128.122 (62.216.128.122) 32.306 ms ge-0-0-3.0.cjr02.ldn004.flagtel.com (62.216.128.138) 9.051 ms MPLS Label=412816 CoS=0 TTL=1 S=1 6 so-1-0-0.0.pjr02.ldn001.flagtel.com (85.95.25.9) 8.616 ms so-1-0-0.0.pjr01.ldn001.flagtel.com (85.95.25.13) 19.806 ms ge-0-1-0.0.pjr01.ldn001.flagtel.com (62.216.129.137) 8.059 ms MPLS Label=300480 CoS=0 TTL=1 S=1 7 so-4-0-0.0.pjr01.mmb004.flagtel.com (85.95.25.113) 280.327 ms so-1-0-0.0.pjr02.mmb004.flagtel.com (85.95.25.138) 281.659 ms so-3-1-0.0-pjr02.mmb004-flagtel.com (85.95.26.158) 282.889 ms 8 62.216.147.138 (62.216.147.138) 285.101 ms 695.643 ms 62.216.147.46 (62.216.147.46) 278.537 ms Pretty much direct. I wonder what exactly is different/wrong in case of BSNL block 117.200.48.0/20? Is BSNL selectively announcing it only from Reliance's California based router and not any other router in Europe? Can somehow one can test & confirm the above guess of selective announcement? (*Apologize if I missed some fundamental glitch error. I am new to it.*) Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter| Google+ From owen at delong.com Tue Jun 19 17:58:36 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Jun 2012 15:58:36 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE09E72.3060005@gmail.com> References: <000d01cd43f4$cdd5bb30$69813190$@gmail.com> <4FE09E72.3060005@gmail.com> Message-ID: <4B0986D8-95EB-437F-A4EC-62607C86BEC5@delong.com> On Jun 19, 2012, at 8:44 AM, Alexandru Petrescu wrote: > I think, the length of Interface ID be 64 is so mostly because IEEE > works now with 64bit EUI identifiers (instead of older 48bit MAC > addresses). I.e. compatibility between IEEE and IETF IPv6 would be the > main reason for this Interface ID to be 64. > > And this is so, even though there are IEEE links for which the MAC > address is even shorter than 64bit, like 802.15.4 short addresses being > on 16bit. For those, an IPv6 prefix length of 112bit would even make > sense. But it's not done, because same IEEE which says the 15.4 MAC > address is 16bit says that its EUI is 64bit. (what 'default' fill that > with is what gets into an IPv6 address as well). > It's easy to put a 16 bit value into a 64 bit bucket. It's very hard to put a 64 bit value into a 16 bit bucket. Just saying. > The good thing isthere is nothing in the RFC IPv6 Addressing > Architecture that makes the Interface ID to be MUST 64bit. It just says > 'n'. > > What there _is_, is that when using RFC stateless addess > autoconfiguration (not DHCP) and on Ethernet and its keen (WiFi, > Bluetooth, ZigBee, more; but not USB nor LTE for example) then one must > use Interface ID of 64bit; and consequently network prefix length of > 64bit no more. > Well, there's another issue... On such a network, how would you go about doing ND? How do you construct a solicited node multicast address for such a node if it has, say, a /108 prefix? Owen From jared at puck.nether.net Tue Jun 19 18:17:19 2012 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Jun 2012 19:17:19 -0400 Subject: NTT handing packets to Reliance (Flag Telecom) in California for BSNL block In-Reply-To: References: Message-ID: <20120619231719.GD10476@puck.nether.net> On Tue, Jun 19, 2012 at 06:42:33PM -0400, Drew Weaver wrote: > I have also noticed that traffic sourced in NYC destined for Qatar across NTT seems to now go from NYC -> SJC -> SNG and ends up being about 180+ms longer than just going over the atlantic. I've seen some people in the middle east/africa purchase services in Asia based on their business needs. In the case of NTT, this is likely the case as they are a decent sized player in Asia. > I've seen this a few times (only with NTT routes). See below for some further insight.... > Thanks, > -Drew > > -----Original Message----- > From: Anurag Bhatia [mailto:me at anuragbhatia.com] > Sent: Tuesday, June 19, 2012 4:15 PM > To: NANOG Mailing List > Subject: NTT handing packets to Reliance (Flag Telecom) in California for BSNL block > > Hello everyone, > > > I was trying to understand reason for high latency between my BSNL (AS9829) connection and a specific Germany based server on M-Online. > > > I can see forward path is correct but reverse path is: > > > traceroute to 117.200.57.47 (117.200.57.X), 30 hops max, 60 byte packets > ... > 13 xe-0-1-0-10.r04.lsanca03.us.ce.gin.ntt.net (198.172.90.222) [AS2914] > 183.765 ms 183.748 ms 185.719 ms .CE.GIN.NTT.NET is customer equipment. It appears they are preferring their customer route. > I can see from Reliance's Looking glass that there direct path from EU to India on their network. I wonder why exactly NTT handling off packets to Reliance in California? The problem seems only for BSNL block - 117.200.48.0/20. It is going to their customer. > If destination is not BSNL and say Reliance itself...say for Monster.co.inweb server which is in Reliance datacenter: > > > > *Query Results:* > *Router: *Amsterdam - NL > *Command:* traceroute 220.226.205.30 > > *Disclaimer: Traceroute is a useful tool for determining the route a packet takes, but it should not be used as an accurate measure of network performance. For more information please view the Traceroute Disclaimer > .* > > > traceroute to 220.226.205.30 (220.226.205.30), 30 hops max, 40 byte packets > 1 as-0.r22.amstnl02.nl.bb.gin.ntt.net (129.250.2.118) 15.806 ms > 0.746 ms 0.718 ms > MPLS Label=499040 CoS=0 TTL=1 S=0 > MPLS Label=304400 CoS=0 TTL=1 S=1 > 2 ae-5.r23.londen03.uk.bb.gin.ntt.net (129.250.5.197) 8.180 ms > 7.740 ms 8.770 ms > MPLS Label=304400 CoS=0 TTL=1 S=1 > 3 ae-2.r02.londen03.uk.bb.gin.ntt.net (129.250.5.41) 16.229 ms > 15.829 ms 16.326 ms > 4 flagtelecom-0.r02.londen03.uk.bb.gin.ntt.net (83.231.235.238) > 15.059 ms 16.032 ms 7.014 ms > 5 62.216.128.106 (62.216.128.106) 8.332 ms 62.216.128.122 > (62.216.128.122) 32.306 ms ge-0-0-3.0.cjr02.ldn004.flagtel.com > (62.216.128.138) 9.051 ms > MPLS Label=412816 CoS=0 TTL=1 S=1 > 6 so-1-0-0.0.pjr02.ldn001.flagtel.com (85.95.25.9) 8.616 ms so-1-0-0.0.pjr01.ldn001.flagtel.com (85.95.25.13) 19.806 ms ge-0-1-0.0.pjr01.ldn001.flagtel.com (62.216.129.137) 8.059 ms > MPLS Label=300480 CoS=0 TTL=1 S=1 > 7 so-4-0-0.0.pjr01.mmb004.flagtel.com (85.95.25.113) 280.327 ms so-1-0-0.0.pjr02.mmb004.flagtel.com (85.95.25.138) 281.659 ms so-3-1-0.0-pjr02.mmb004-flagtel.com (85.95.26.158) 282.889 ms > 8 62.216.147.138 (62.216.147.138) 285.101 ms 695.643 ms > 62.216.147.46 (62.216.147.46) 278.537 ms > > > > Pretty much direct. > > > I wonder what exactly is different/wrong in case of BSNL block 117.200.48.0/20? Is BSNL selectively announcing it only from Reliance's California based router and not any other router in Europe? > > Can somehow one can test & confirm the above guess of selective announcement? > > > > (*Apologize if I missed some fundamental glitch error. I am new to it.*) I've seen cases where the packet goes around the world based on the networks involved. You can usually tell due to increased latency or looking at ping -R output. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From randy at psg.com Tue Jun 19 18:27:34 2012 From: randy at psg.com (Randy Bush) Date: Wed, 20 Jun 2012 08:27:34 +0900 Subject: A's for www.xfinitytv.com In-Reply-To: References: Message-ID: > Circling back here, you all set here? Should see the following over IPv6 and IPv4: > xfinity.comcast.net > xfinitytv.comcast.net from tokyo rair.psg.com:/Users/randy> ping6 xfinity.comcast.net PING6(56=40+8+8 bytes) 2001:240:6a8::4034:839d:25d9:2418 --> 2001:240:bb8f:8000::d295:8725 16 bytes from 2001:240:bb8f:8000::d295:8725, icmp_seq=0 hlim=58 time=7.407 ms 16 bytes from 2001:240:bb8f:8000::d295:8725, icmp_seq=1 hlim=58 time=9.363 ms ^C --- a1075.dscg.akamai.net ping6 statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 7.407/8.385/9.363/0.978 ms rair.psg.com:/Users/randy> ping6 xfinitytv.comcast.net PING6(56=40+8+8 bytes) 2001:240:6a8::4034:839d:25d9:2418 --> 2001:240:bb8f:8000::d295:8735 16 bytes from 2001:240:bb8f:8000::d295:8735, icmp_seq=0 hlim=58 time=6.842 ms ^C --- a1784.dscg.akamai.net ping6 statistics --- 2 packets transmitted, 1 packets received, 50.0% packet loss round-trip min/avg/max/std-dev = 6.842/6.842/6.842/0.000 ms i did not check ipv4, it is just sooo last century :) randy From mohta at necom830.hpcl.titech.ac.jp Tue Jun 19 18:34:11 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 20 Jun 2012 08:34:11 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1340145574.2753.6.camel@karl> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> <4FD82977.20904@necom830.hpcl.titech.ac.jp> <3AFDBCF3-F34F-48EE-A714-ECF419EB3C9A@delong.com> <4FE07E6B.2010900@necom830.hpcl.titech.ac.jp> <1340145574.2753.6.camel@karl> Message-ID: <4FE10C73.8050900@necom830.hpcl.titech.ac.jp> Karl Auer wrote: >> host <-> home UPnP NAT <-> Carrier UPnP NAT <-> Internet >> <-> Carrier UPnP NAT <-> home UPnP NAT <-> host > > "Trivially"? I think this looks much nicer: > > host <-> Internet <-> host Yes, if only the Internet were uniform. However, compared to V6 incapable V6 capable host <-> Internet<-> home router <-> Internet <-> 6/4 tunnel V6 capable 6/4 tunnel V6 capable end point <-> Internet <-> end point <-> Internet <-> V6 incapable home router <-> Internet <-> host which can often be: V6 incapable V6 capable host <-> Internet<-> home router <-> Internet <-> 6/4 tunnel V6 *INCAPABLE* 6/4 tunnel V6 capable end point <-> Internet <-> end point <-> Internet <-> V6 incapable home router <-> Internet <-> host >> host <-> home UPnP NAT <-> Carrier UPnP NAT <-> Internet >> <-> Carrier UPnP NAT <-> home UPnP NAT <-> host is just trivial and uniform. > The way it used to be before NAT, and the way, with IPv6, it can be > again. With IPv6, see above. Masataka Ohta From marine64 at gmail.com Tue Jun 19 18:50:50 2012 From: marine64 at gmail.com (Brian Henson) Date: Tue, 19 Jun 2012 19:50:50 -0400 Subject: TW in ohio Message-ID: 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 From ryan.landry at gmail.com Tue Jun 19 19:07:38 2012 From: ryan.landry at gmail.com (ryanL) Date: Tue, 19 Jun 2012 17:07:38 -0700 Subject: solid v smart optics Message-ID: anyone have any opinions on the two subject vendors, with general regard to 10GE transceivers? SR multi-mode data center stuff for my application. appreciate on/off list replies! ryanL From rcarpen at network1.net Tue Jun 19 19:22:22 2012 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 19 Jun 2012 20:22:22 -0400 (EDT) Subject: TW in ohio In-Reply-To: Message-ID: <1252723055.151622.1340151742034.JavaMail.root@network1.net> Nope. I signed up for the beta a long time ago, and have never heard anything about IPv6 on the residential network. My company is one of the first (if not *the* first) direct connect commercial customers that got IPv6 connectivity in Ohio. I only see a few other ASNs that are directly connected to Time Warner locally via IPv6. I wonder if they are having some problems with their residential rollout. I signed up for their RoadRunner "Extreme" when it was first advertised more than a year ago. They happily installed the proper DOCSIS 3.0 modem, and I was up and running. When I called about my upload speed being too low, I found out after several weeks and talking to numerous people that they have not yet upgraded their head end from DOCSIS 1.1. They subsequently took down all of the billboards and banners that advertised the "Extreme" packages. I still pay the higher rate for mine, only because I get much faster download than their standard service. I am guessing that they will roll out IPv6 only after the DOCSIS 3.0 upgrade is complete. -Randy ----- Original Message ----- > 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 > > From valdis.kletnieks at vt.edu Tue Jun 19 21:22:02 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Tue, 19 Jun 2012 22:22:02 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: Your message of "Tue, 19 Jun 2012 22:21:11 +0900." <4FE07CC7.5040401@necom830.hpcl.titech.ac.jp> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> <4FD82977.20904@necom830.hpcl.titech.ac.jp> <4766.1339604070@turing-police.cc.vt.edu> <4FE07CC7.5040401@necom830.hpcl.titech.ac.jp> Message-ID: <52697.1340158922@turing-police.cc.vt.edu> On Tue, 19 Jun 2012 22:21:11 +0900, Masataka Ohta said: > Or, a NAT gateway may receive packets to certain ports and behave as > an application gateway to end hosts, if request messages to the > server contains information, such as domain names, which is the case > with DNS, SMTP and HTTP, to demultiplex the request messages to end For SMTP, you'll have already consumed the 3 packet handshake and the EHLO, MAIL FROM, and at least one RCPT TO before you know which end host to demultiplex to (and even then, you may not unless the end hosts are running a DNS that advertises MX's with the NAT'ed IP in them). At that point, you have little choice but to then start up a conversation with the end host and relay the EHLO/MAIL FROM/RCPT TO and hope to heck that the end host doesn't reply differently to you than you did to the other end (in particular, you had to respond to the EHLO with a list of extensions supported - if you said you supported an extension that the end system doesn't actually have, you get to do fixups on the fly as you continue the MITM). And some things, like ssh or anything that uses OpenSSL, you'll have a very hard time because you need to respond with the right certificate or key, which you don't have. > 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. > > (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? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From shawn.marck at blacklotus.net Tue Jun 19 23:28:01 2012 From: shawn.marck at blacklotus.net (Shawn Marck) Date: Tue, 19 Jun 2012 21:28:01 -0700 Subject: Time Warner / Road Runner Message-ID: Can someone from Road Runner HoldCo LLC ( AS7843 ) Please contact me offline? NOC Ticket #1718425 not getting any progress, packetloss to AS32421 affecting multiple mutual customers. Thank you, -- Shawn Marck shawn.marck at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 From davidpeahi at gmail.com Wed Jun 20 00:02:03 2012 From: davidpeahi at gmail.com (david peahi) Date: Tue, 19 Jun 2012 22:02:03 -0700 Subject: Cisco Smartnet for 6509E Line Cards Message-ID: 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 From paul4004 at gmail.com Wed Jun 20 00:28:40 2012 From: paul4004 at gmail.com (PC) Date: Tue, 19 Jun 2012 23:28:40 -0600 Subject: Cisco Smartnet for 6509E Line Cards In-Reply-To: References: Message-ID: 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 > From lmay at nframe.com Wed Jun 20 02:01:56 2012 From: lmay at nframe.com (Larry May) Date: Wed, 20 Jun 2012 03:01:56 -0400 Subject: Cisco Smartnet for 6509E Line Cards In-Reply-To: Message-ID: <053E179161004E4C91C8613916AA37B90551A4DA@nframemail01.nframe.local> 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:paul4004 at gmail.com] Sent: Wednesday, June 20, 2012 1:29 AM To: david peahi Cc: nanog at 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 > From saku at ytti.fi Wed Jun 20 02:35:22 2012 From: saku at ytti.fi (Saku Ytti) Date: Wed, 20 Jun 2012 10:35:22 +0300 Subject: solid v smart optics In-Reply-To: References: Message-ID: <20120620073522.GA30218@pob.ytti.fi> 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 From hank at efes.iucc.ac.il Wed Jun 20 03:04:54 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 20 Jun 2012 11:04:54 +0300 (IDT) Subject: SIXSS not working? Message-ID: I am seeing all IPv6 prefixes that are monitored by Sixxs as being down and unavailable. Anyone know why? Thanks, Hank From mohta at necom830.hpcl.titech.ac.jp Wed Jun 20 03:44:14 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 20 Jun 2012 17:44:14 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <52697.1340158922@turing-police.cc.vt.edu> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> <4FD82977.20904@necom830.hpcl.titech.ac.jp> <4766.1339604070@turing-police.cc.vt.edu> <4FE07CC7.5040401@necom830.hpcl.titech.ac.jp> <52697.1340158922@turing-police.cc.vt.edu> Message-ID: <4FE18D5E.1050407@necom830.hpcl.titech.ac.jp> valdis.kletnieks at 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 From jeroen at unfix.org Wed Jun 20 04:05:12 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 20 Jun 2012 02:05:12 -0700 Subject: SIXSS not working? In-Reply-To: References: Message-ID: <4FE19248.4090608@unfix.org> 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 info at 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 info at sixxs.net as quite clearly stated on the contact page and apparently needs repeating on the NANOG list... Greets, Jeroen From hank at efes.iucc.ac.il Wed Jun 20 04:14:54 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 20 Jun 2012 12:14:54 +0300 (IDT) Subject: SIXSS not working? In-Reply-To: <4FE19248.4090608@unfix.org> References: <4FE19248.4090608@unfix.org> Message-ID: 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 info at 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 info at sixxs.net as quite clearly stated on the contact > page and apparently needs repeating on the NANOG list... > > Greets, > Jeroen > From hank at efes.iucc.ac.il Wed Jun 20 06:00:46 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 20 Jun 2012 14:00:46 +0300 (IDT) Subject: SIXSS not working? In-Reply-To: References: <4FE19248.4090608@unfix.org> Message-ID: 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 info at 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 info at sixxs.net as quite clearly stated on the contact >> page and apparently needs repeating on the NANOG list... >> >> Greets, >> Jeroen >> > > From Curtis.Starnes at granburyisd.org Wed Jun 20 07:26:41 2012 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Wed, 20 Jun 2012 07:26:41 -0500 Subject: Cisco Smartnet for 6509E Line Cards In-Reply-To: References: Message-ID: 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:davidpeahi at gmail.com] Sent: Wednesday, June 20, 2012 12:02 AM To: nanog at 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 From marine64 at gmail.com Wed Jun 20 08:55:18 2012 From: marine64 at gmail.com (Brian Henson) Date: Wed, 20 Jun 2012 09:55:18 -0400 Subject: TW in ohio In-Reply-To: <7d0415720120ae0bf5e78775c764ef8f.squirrel@mail.completeweb.net> References: <7d0415720120ae0bf5e78775c764ef8f.squirrel@mail.completeweb.net> Message-ID: 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 > > > > > From jeroen at unfix.org Wed Jun 20 10:34:01 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 20 Jun 2012 08:34:01 -0700 Subject: SIXSS not working? In-Reply-To: References: <4FE19248.4090608@unfix.org> Message-ID: <4FE1ED69.505@unfix.org> 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 info at 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 From copraphage at gmail.com Wed Jun 20 11:00:04 2012 From: copraphage at gmail.com (Chris McDonald) Date: Wed, 20 Jun 2012 12:00:04 -0400 Subject: Saleslurkers - onnet check in greenville nc Message-ID: Anyone have it? 638 Chapman Rd., Greenville, NC 28590 Thanks Chris -- Sent from my mobile device From davehart at gmail.com Wed Jun 20 13:00:10 2012 From: davehart at gmail.com (Dave Hart) Date: Wed, 20 Jun 2012 18:00:10 +0000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE18D5E.1050407@necom830.hpcl.titech.ac.jp> References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> <4FD82977.20904@necom830.hpcl.titech.ac.jp> <4766.1339604070@turing-police.cc.vt.edu> <4FE07CC7.5040401@necom830.hpcl.titech.ac.jp> <52697.1340158922@turing-police.cc.vt.edu> <4FE18D5E.1050407@necom830.hpcl.titech.ac.jp> Message-ID: 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 From davidpeahi at gmail.com Wed Jun 20 13:16:52 2012 From: davidpeahi at gmail.com (david peahi) Date: Wed, 20 Jun 2012 11:16:52 -0700 Subject: Cisco Smartnet for 6509E Line Cards In-Reply-To: References: Message-ID: 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.Starnes at 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:davidpeahi at gmail.com] > Sent: Wednesday, June 20, 2012 12:02 AM > To: nanog at 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 > From nanog at armoredpackets.com Wed Jun 20 14:30:58 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Wed, 20 Jun 2012 15:30:58 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> Message-ID: <4FE224F2.5020002@armoredpackets.com> 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: 00000de2528855f02cf9ed04c217a15c61b35657 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 may not feel comfortable about checking a password against a website and trusting that website doesn't store your password. http://www.armoredpackets.com/hashcheck_a_small_piece_of_mind I also hope that my explanation about how trust is the real issue, and that ultimately you can't trust any site nor any method. That by making simple, yet effective, changes in how you create and use passwords will protect you long enough to safely change the passwords/pass-phrases for all your sites. Back to leeching knowledge :-) Keep up the great conversations! - Robert Miller (arch3angel) On 6/13/12 3:54 PM, Grant Ridder wrote: > Hi Everyone, > > I thought that i would share an IEEE article about LinkenIn and eHarmony. > > http://spectrum.ieee.org/riskfactor/telecom/security/linkedin-and-eharmony-hacked-8-million-passwords-taken/?utm_source=computerwise&utm_medium=email&utm_campaign=061312 > > > -Grant > > On Wed, Jun 13, 2012 at 1:05 PM, Phil Pishioneri wrote: > >> On 6/8/12 7:22 PM, Luke S. Crawford wrote: >> >>> I haven't found any way that is as simple and as portable as using >>> ssh that works in a web browser. >>> >> The Enigform Firefox Add-on (plus mod_openpgp on Apache httpd) seems >> similar: >> >> http://wordpress.org/extend/**plugins/wp-enigform-**authentication/ >> >> Enigform is a Firefox Add-On which uses OpenPGP to digitally sign >>> outgoing HTTP requests and Securely login to remote web sites, as long >>> as the remote web server is Enigform-compliant. >>> >> -Phil >> >> From bicknell at ufp.org Wed Jun 20 14:43:44 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Jun 2012 12:43:44 -0700 Subject: LinkedIn password database compromised In-Reply-To: <4FE224F2.5020002@armoredpackets.com> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> Message-ID: <20120620194344.GA16763@ussenterprise.ufp.org> 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 - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From leo.vegoda at icann.org Wed Jun 20 16:19:15 2012 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 20 Jun 2012 14:19:15 -0700 Subject: LinkedIn password database compromised In-Reply-To: <20120620194344.GA16763@ussenterprise.ufp.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5488 bytes Desc: not available URL: From pederindi at gmail.com Wed Jun 20 16:26:52 2012 From: pederindi at gmail.com (Pedro) Date: Wed, 20 Jun 2012 23:26:52 +0200 Subject: LinkedIn password database compromised In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> Message-ID: >> 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 From nanog at armoredpackets.com Wed Jun 20 16:30:39 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Wed, 20 Jun 2012 17:30:39 -0400 Subject: LinkedIn password database compromised In-Reply-To: <20120620194344.GA16763@ussenterprise.ufp.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> Message-ID: <4FE240FF.2030008@armoredpackets.com> 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. > From bicknell at ufp.org Wed Jun 20 16:39:14 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Jun 2012 14:39:14 -0700 Subject: LinkedIn password database compromised In-Reply-To: <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> Message-ID: <20120620213914.GA20633@ussenterprise.ufp.org> 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 - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From elmi at 4ever.de Wed Jun 20 16:44:05 2012 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 20 Jun 2012 23:44:05 +0200 Subject: LinkedIn password database compromised In-Reply-To: <20120620213914.GA20633@ussenterprise.ufp.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> Message-ID: <20120620214405.GT15236@h.detebe.org> (Fight of the Leos...) bicknell at 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... From matthew at matthew.at Wed Jun 20 16:54:10 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 20 Jun 2012 14:54:10 -0700 Subject: LinkedIn password database compromised In-Reply-To: <20120620213914.GA20633@ussenterprise.ufp.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> Message-ID: <4FE24682.9040408@matthew.at> 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 From aaron at heyaaron.com Wed Jun 20 17:05:17 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 20 Jun 2012 15:05:17 -0700 Subject: LinkedIn password database compromised In-Reply-To: <20120620214405.GT15236@h.detebe.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> <20120620214405.GT15236@h.detebe.org> Message-ID: On Wed, Jun 20, 2012 at 2:44 PM, Elmar K. Bins wrote: > (Fight of the Leos...) > > bicknell at 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 From jared at puck.nether.net Wed Jun 20 17:06:40 2012 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 20 Jun 2012 18:06:40 -0400 Subject: LinkedIn password database compromised In-Reply-To: <4FE24682.9040408@matthew.at> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> <4FE24682.9040408@matthew.at> Message-ID: <8E49183D-B16C-49EB-A33D-B64577CF434D@puck.nether.net> 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 From bicknell at ufp.org Wed Jun 20 17:28:02 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Jun 2012 15:28:02 -0700 Subject: LinkedIn password database compromised In-Reply-To: <4FE24682.9040408@matthew.at> References: <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> <20120620214405.GT15236@h.detebe.org> Message-ID: <20120620222802.GA22002@ussenterprise.ufp.org> 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 "bicknell at foo.com" and submit it. If I want another a quick trip to the menu creates "superman at 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 - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Wed Jun 20 17:37:50 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 20 Jun 2012 18:37:50 -0400 Subject: LinkedIn password database compromised In-Reply-To: Your message of "Wed, 20 Jun 2012 14:39:14 -0700." <20120620213914.GA20633@ussenterprise.ufp.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> Message-ID: <68207.1340231870@turing-police.cc.vt.edu> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bicknell at ufp.org Wed Jun 20 17:52:23 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Jun 2012 15:52:23 -0700 Subject: LinkedIn password database compromised In-Reply-To: <68207.1340231870@turing-police.cc.vt.edu> References: <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> <68207.1340231870@turing-police.cc.vt.edu> Message-ID: <20120620225223.GA22892@ussenterprise.ufp.org> In a message written on Wed, Jun 20, 2012 at 06:37:50PM -0400, valdis.kletnieks at 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 - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Wed Jun 20 18:00:07 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 21 Jun 2012 08:00:07 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <1339017457.2754.8.camel@karl> <1339106986.2754.37.camel@karl> <4FD6FAD3.1040809@necom830.hpcl.titech.ac.jp> <1339493145.15324.229.camel@karl> <4FD70F1D.2040008@necom830.hpcl.titech.ac.jp> <02ef01cd48b7$f80d03f0$e8270bd0$@tndh.net> <4FD7AB5C.5000806@necom830.hpcl.titech.ac.jp> <034c01cd48ea$711c0020$53540060$@tndh.net> <4FD7CFB3.70009@necom830.hpcl.titech.ac.jp> <4FD815C7.2040108@necom830.hpcl.titech.ac.jp> <4FD82977.20904@necom830.hpcl.titech.ac.jp> <4766.1339604070@turing-police.cc.vt.edu> <4FE07CC7.5040401@necom830.hpcl.titech.ac.jp> <52697.1340158922@turing-police.cc.vt.edu> <4FE18D5E.1050407@necom830.hpcl.titech.ac.jp> Message-ID: <4FE255F7.3010307@necom830.hpcl.titech.ac.jp> 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 From randy at psg.com Wed Jun 20 18:02:58 2012 From: randy at psg.com (Randy Bush) Date: Thu, 21 Jun 2012 08:02:58 +0900 Subject: LinkedIn password database compromised In-Reply-To: <20120620194344.GA16763@ussenterprise.ufp.org> <20120620213914.GA20633@ussenterprise.ufp.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> Message-ID: 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 From jra at baylink.com Wed Jun 20 18:05:22 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Jun 2012 19:05:22 -0400 (EDT) Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: Message-ID: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> ----- 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 jra at 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 From bicknell at ufp.org Wed Jun 20 18:12:34 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Jun 2012 16:12:34 -0700 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> Message-ID: <20120620231234.GA23251@ussenterprise.ufp.org> 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 bicknell at foo.com (or superman at foo.com) was your login, do some math, and sign a response with your private key that says: "Hi, I'm bicknell at 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 - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From kyle.creyts at gmail.com Wed Jun 20 18:25:45 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Wed, 20 Jun 2012 19:25:45 -0400 Subject: SIXSS not working? In-Reply-To: <4FE1ED69.505@unfix.org> References: <4FE19248.4090608@unfix.org> <4FE1ED69.505@unfix.org> Message-ID: 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 info at 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 From jra at baylink.com Wed Jun 20 18:26:45 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Jun 2012 19:26:45 -0400 (EDT) Subject: How to fix authentication (was LinkedIn) In-Reply-To: <20120620194344.GA16763@ussenterprise.ufp.org> Message-ID: <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> ----- 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 jra at 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 From kyle.creyts at gmail.com Wed Jun 20 18:31:40 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Wed, 20 Jun 2012 19:31:40 -0400 Subject: How to fix authentication (was LinkedIn) In-Reply-To: <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> Message-ID: 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 ? ? ? ? ? ? ? ? ? ? ? jra at 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 From randy at psg.com Wed Jun 20 18:33:47 2012 From: randy at psg.com (Randy Bush) Date: Thu, 21 Jun 2012 08:33:47 +0900 Subject: LinkedIn password database compromised In-Reply-To: <20120620231234.GA23251@ussenterprise.ufp.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <20120620231234.GA23251@ussenterprise.ufp.org> Message-ID: > 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 From drew.weaver at thenap.com Wed Jun 20 18:36:00 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 20 Jun 2012 19:36:00 -0400 Subject: How to fix authentication (was LinkedIn) In-Reply-To: <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> Message-ID: 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:jra at 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 jra at 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 From valdis.kletnieks at vt.edu Wed Jun 20 18:46:16 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 20 Jun 2012 19:46:16 -0400 Subject: How to fix authentication (was LinkedIn) In-Reply-To: Your message of "Wed, 20 Jun 2012 19:31:40 -0400." References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> Message-ID: <73906.1340235976@turing-police.cc.vt.edu> 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... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From kyle.creyts at gmail.com Wed Jun 20 18:52:54 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Wed, 20 Jun 2012 19:52:54 -0400 Subject: How to fix authentication (was LinkedIn) In-Reply-To: <73906.1340235976@turing-police.cc.vt.edu> References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> <73906.1340235976@turing-police.cc.vt.edu> Message-ID: 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 From jra at baylink.com Wed Jun 20 18:59:09 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Jun 2012 19:59:09 -0400 (EDT) Subject: AAA design document pointers In-Reply-To: <16360948.10276.1340236470252.JavaMail.root@benjamin.baylink.com> Message-ID: <22191830.10278.1340236749519.JavaMail.root@benjamin.baylink.com> 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 jra at 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 From davehart at gmail.com Wed Jun 20 21:47:24 2012 From: davehart at gmail.com (Dave Hart) Date: Thu, 21 Jun 2012 02:47:24 +0000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> Message-ID: 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 From aaron at heyaaron.com Wed Jun 20 22:16:22 2012 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 20 Jun 2012 20:16:22 -0700 Subject: How to fix authentication (was LinkedIn) In-Reply-To: <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> Message-ID: 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 From mmcbride7 at gmail.com Thu Jun 21 01:00:15 2012 From: mmcbride7 at gmail.com (Mike McBride) Date: Wed, 20 Jun 2012 23:00:15 -0700 Subject: PIM survey for operators In-Reply-To: References: Message-ID: 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.eubanks at 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? From hank at efes.iucc.ac.il Thu Jun 21 01:23:38 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 21 Jun 2012 09:23:38 +0300 Subject: SIXSS not working? In-Reply-To: References: <4FE1ED69.505@unfix.org> <4FE19248.4090608@unfix.org> <4FE1ED69.505@unfix.org> Message-ID: <5.1.1.6.2.20120621092306.00f8fea8@efes.iucc.ac.il> 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 info at 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 From jeroen at unfix.org Thu Jun 21 01:38:51 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 20 Jun 2012 23:38:51 -0700 Subject: SIXSS not working? In-Reply-To: <5.1.1.6.2.20120621092306.00f8fea8@efes.iucc.ac.il> References: <4FE1ED69.505@unfix.org> <4FE19248.4090608@unfix.org> <4FE1ED69.505@unfix.org> <5.1.1.6.2.20120621092306.00f8fea8@efes.iucc.ac.il> Message-ID: <4FE2C17B.6050005@unfix.org> 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 ;) From randy at psg.com Thu Jun 21 01:47:29 2012 From: randy at psg.com (Randy Bush) Date: Thu, 21 Jun 2012 15:47:29 +0900 Subject: SIXSS not working? In-Reply-To: <4FE2C17B.6050005@unfix.org> References: <4FE1ED69.505@unfix.org> <4FE19248.4090608@unfix.org> <5.1.1.6.2.20120621092306.00f8fea8@efes.iucc.ac.il> <4FE2C17B.6050005@unfix.org> Message-ID: > still wondering why this is on NANOG maybe ipv6 is becoming relevant to operations? randy From kauer at biplane.com.au Thu Jun 21 03:12:13 2012 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 21 Jun 2012 18:12:13 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> Message-ID: <1340266333.2753.284.camel@karl> On Wed, 2012-06-20 at 19:05 -0400, Jay Ashworth wrote: > 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. Speaking for myself, I'm one of the "if I want to allow direct outside connection to my interior machines I should be able to" crowd. And also one of the "if I and someone else want to connect our hosts directly we should be able to" crowd. That is, I don't want the architecture of the Internet to be crippled by NAT everywhere. If you want to NAT *your* network, go for it. As a local stalwart is wont to say, "I encourage my competitors to do that" ;-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From randy at psg.com Thu Jun 21 04:28:25 2012 From: randy at psg.com (Randy Bush) Date: Thu, 21 Jun 2012 18:28:25 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1340266333.2753.284.camel@karl> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> Message-ID: > On Wed, 2012-06-20 at 19:05 -0400, Jay Ashworth wrote: > That is, I don't want the architecture of the Internet to be crippled > by NAT everywhere. If you want to NAT *your* network, go for it. in this case, an air gap might be encouraged randy From oscar.vives at gmail.com Thu Jun 21 05:59:38 2012 From: oscar.vives at gmail.com (Tei) Date: Thu, 21 Jun 2012 12:59:38 +0200 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <20120620231234.GA23251@ussenterprise.ufp.org> Message-ID: Anonymity on the Internet is a feature, because a lot of the world netcitizens come from countries where saying this or that is a crime, and can get you in trouble. Any asymetric cryptography solution that remove anonymity is a bad thing. Making censorship easier on the internet is making it worse. What could do some good, is to discredit some bad practices, and propose alternate better practices. This is hard, and part of it is because some people good practices is other people good practices. We can't start this yet, because we don't agree on these good practices. Theres something weird with passwords length, on most websites you are allowed to type a 80 or 120 characters long name. But if you try that with your password, you find a problem. Somehow VARCHAR(120) is unfeasible for passwords, but ok for first_name,second_name. Is even more weird wen people are storing hashs. The length of a md5 don't change if I choose very long passwords, so why are people limiting password length? Other weird limitations that "must go", is the idea that you can't use "special characters". The expresion "special characters" is a red flag itself. Most passwords sould allow UTF-8, and allow anything that UTF-8 allow. Forcing people to mix uppercase and lowercase.. I understand where this come from. It enhance the password strength. A what price? Making passwords a random mix of letter and numbers make then hard to remember and make life miserable for everyone. Practices to make passwords stronger may be pushing people to write password down, or reuse passwords. -- ?in del ?ensaje. From mohta at necom830.hpcl.titech.ac.jp Thu Jun 21 07:04:45 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 21 Jun 2012 21:04:45 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1340266333.2753.284.camel@karl> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> Message-ID: <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> Karl Auer wrote: > Speaking for myself, I'm one of the "if I want to allow direct outside > connection to my interior machines I should be able to" crowd. While "direct" and "interior" are not compatible that you actually mean some indirections... Anyway, what if, your ISP assigns a globally unique IPv4 address to your home router (a NAT box) which is UPnP capable? That's what the largest retail ISP in Japan is doing. Masataka Ohta From a.harrowell at gmail.com Thu Jun 21 07:23:50 2012 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 21 Jun 2012 13:23:50 +0100 Subject: How to fix authentication (was LinkedIn) In-Reply-To: References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> Message-ID: <201206211324.12502.alexander.harrowell@stlpartners.com> On Thursday 21 Jun 2012 04:16:22 Aaron C. de Bruyn wrote: > 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 As far as apps go, loads of them use OAuth and have a browser step in their setup. So this adds precisely one step to the smartphone sync/activation process - downloading the key pair from your PC (or if you don't have a PC, generating one). that covers vendor A and most vendor G devices. "what about the feature phones?" - not an issue, no apps to speak of, noOp(). "what about [person we want to be superior to who is always female for some reason]?" - well, they all seem to have iPhones now, so *somebody's* obviously handholding them through the activation procedure. obviously vendor A would be tempted to "sync this to iCloud"...but anyway, I repeat the call for a W3C password manager API. SSH would be better, but a lot of the intents, actions etc are the same. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From rsk at gsp.org Thu Jun 21 07:56:06 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 21 Jun 2012 08:56:06 -0400 Subject: LinkedIn password database compromised In-Reply-To: <20120620194344.GA16763@ussenterprise.ufp.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> Message-ID: <20120621125606.GA3760@gsp.org> On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote: (on the use of public/private keys) > 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. It's a nice thought, but it won't work. There are two large-scale security problems which prevent it from working: 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term, but any estimate of this population under 100M should be laughed out of the room. Plausible estimates are now in the 200M to 300M range. Any private key present on any of those is accessible to The Bad Guys whenever they can trouble themselves to grab it. (Just as they're already, quite obviously, grabbing passwords en masse.) 2. Pre-compromised-at-the-factory smartphones and similar. There's no reason why these can't be preloaded with spyware similar to CarrierIQ and directed to upload all newly-created private keys to a central collection point. This can be done, therefore it will be done, and when some security researcher discovers it, the usual excuses and justifications will be made by the designated spokesliars for the companies involved... which will of course keep right on doing it, albeit perhaps with more subterfuge. Problem #1 has been extant for ten years and no (meaningful) progress whatsoever has been made on solving it. Problem #2 is newer, but I'm willing to bet that it will also last at least a decade and that it will get worse, since there are substantial economic incentives to make it so. ---rsk From kauer at biplane.com.au Thu Jun 21 08:11:32 2012 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 21 Jun 2012 23:11:32 +1000 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> Message-ID: <1340284292.2753.305.camel@karl> On Thu, 2012-06-21 at 21:04 +0900, Masataka Ohta wrote: > Karl Auer wrote: > > Speaking for myself, I'm one of the "if I want to allow direct > > outside connection to my interior machines I should be able to" > > crowd. > > While "direct" and "interior" are not compatible that you actually > mean some indirections... I am a native English speaker, and I actually meant exactly what I actually wrote. I have found "direct" and "interior" to be completely compatible. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From dot at dotat.at Thu Jun 21 08:18:11 2012 From: dot at dotat.at (Tony Finch) Date: Thu, 21 Jun 2012 14:18:11 +0100 Subject: LinkedIn password database compromised In-Reply-To: References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <20120620231234.GA23251@ussenterprise.ufp.org> Message-ID: Tei wrote: > Anonymity on the Internet is a feature, because a lot of the world > netcitizens come from countries where saying this or that is a crime, > and can get you in trouble. Note that you need to make a distinction between pseudonymity and anonymity. In most online situations anonymity is not useful, because you want a service to be able to identify you as the same person when you go away and come back later. You want the service to attach a pseudonym to you, and you want to be in control of whether this pseudonym is linked to your identities at other services or in the real world. Whether you authenticate your pseudonym with a password or a cryptographic key is immaterial, provided the key store supports unlinked identities - i.e. it must not require you to use the same key for everything. A good key store makes it easier to decouple your identities at different services than remembering N different username + password pairs. Tony. -- f.anthony.n.finch http://dotat.at/ North Portland, Plymouth: Cyclonic, becoming westerly 5 to 7, occasionally gale 8. Rough. Rain or showers. Good, occasionally poor. From owen at delong.com Thu Jun 21 08:47:29 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Jun 2012 06:47:29 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> Message-ID: <1F878FF8-36C2-4CED-A6B5-6C0D65A9077C@delong.com> On Jun 21, 2012, at 5:04 AM, Masataka Ohta wrote: > Karl Auer wrote: > >> Speaking for myself, I'm one of the "if I want to allow direct outside >> connection to my interior machines I should be able to" crowd. > > While "direct" and "interior" are not compatible that you actually > mean some indirections... > > Anyway, what if, your ISP assigns a globally unique IPv4 address > to your home router (a NAT box) which is UPnP capable? > > That's what the largest retail ISP in Japan is doing. > > Masataka Ohta Does not scale. Not enough IPv4 addresses to do that for 6.8 billion people on the planet. What if my ISP just routes my /48? Seems to work quite well, actually. Owen From nanog at armoredpackets.com Thu Jun 21 09:43:44 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Thu, 21 Jun 2012 10:43:44 -0400 Subject: LinkedIn password database compromised In-Reply-To: <20120620222802.GA22002@ussenterprise.ufp.org> References: <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> <20120620214405.GT15236@h.detebe.org> <20120620222802.GA22002@ussenterprise.ufp.org> Message-ID: <4FE33320.8030408@armoredpackets.com> I have two concerns with this thought, while at the same time intrigued by it. How will this prevent man in the middle attacks, either at the users location, the server location, or even on the compromised server itself where the attacker is just gathering data. This is the same concerns we face now. Second is regarding the example just made with "bicknell at foo.com" and superman at foo.com. Does this not require the end user to have virtually endless number of email addresses if this method would be implemented across all authenticated websites, compounded by numerous devices (iPads, Smartphones, personal laptop, work laptop, etc..) Again I think this conversation is on the right track, but ultimately a form of two factor authentication method such as pub/priv, Wikid, etc.. is needed. On 6/20/12 6:28 PM, Leo Bicknell wrote: > 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 "bicknell at foo.com" and submit it. If > I want another a quick trip to the menu creates "superman at 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. > From oscar.vives at gmail.com Thu Jun 21 09:50:16 2012 From: oscar.vives at gmail.com (Tei) Date: Thu, 21 Jun 2012 16:50:16 +0200 Subject: LinkedIn password database compromised In-Reply-To: <4FE33320.8030408@armoredpackets.com> References: <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> <20120620214405.GT15236@h.detebe.org> <20120620222802.GA22002@ussenterprise.ufp.org> <4FE33320.8030408@armoredpackets.com> Message-ID: If anyone have a really good idea how to fix this mess, It will be a good idea to contact with Jeff Atwood (of codehorror.com and stackoverflow.com fame). He and other people is working on a new internet approach to discussions. Think forums 2.0. If this new pet rock succeed, could change how the world use, eerrh... forums. We could hit two problems with the same rock. -- -- ?in del ?ensaje. From bicknell at ufp.org Thu Jun 21 10:05:37 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 21 Jun 2012 08:05:37 -0700 Subject: LinkedIn password database compromised In-Reply-To: <4FE33320.8030408@armoredpackets.com> References: <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> <20120620214405.GT15236@h.detebe.org> <20120620222802.GA22002@ussenterprise.ufp.org> <4FE33320.8030408@armoredpackets.com> Message-ID: <20120621150537.GA49685@ussenterprise.ufp.org> I want to start by saing, there are lots of different security problems with accessing a "cloud service". Several folks have already brought up issues like compromised user machines or actually verifing identity. One of the problems in this space I think is that people keep looking for a silver bullet that magically solves all the problems. It doesn't exist. We need a series of technologies that work with each other. In a message written on Thu, Jun 21, 2012 at 10:43:44AM -0400, AP NANOG wrote: > How will this prevent man in the middle attacks, either at the users > location, the server location, or even on the compromised server itself > where the attacker is just gathering data. This is the same concerns we > face now. There is a sign up problem. You could sign up with a MTM web site, which then signs you up with the real web site. There are a number of solutions, you can try and prevent the MTM attack with something like DNSSEC, and/or verify the identity of the web site with something like X.509 certificates verified by a trusted party. The first relationship could exchange public keys in both directions, making the attack a sign-up attack only, once the relationship is established its public key in both directions and if done right impervious to a MTM attack. Note that plenty of corporations "hijack" HTTPS today, so MTM attacks are very real and work should be done in this space. > Second is regarding the example just made with "bicknell at foo.com" and > superman at foo.com. Does this not require the end user to have virtually > endless number of email addresses if this method would be implemented > across all authenticated websites, compounded by numerous devices > (iPads, Smartphones, personal laptop, work laptop, etc..) Not at all. Web sites can make the same restrictions they make today. Many may accept my "bicknell at ufp.org" key and let me us that as my login. A site like gmail or hotmail may force me to use something like bicknell at gmail.com, because it actually is an e-mail, but it could also give me the option of using an identifier of my choice. While I think use of e-mails is good for confirmation purposes, a semi-anonymous web site that requires no verification could allow a signup with "bob" or other unqualified identifier. It's just another name space. The browser is going to cache a mapping from web site, or domain, to identifier, quite similar to what it does today... Today: www.facebook.com, login: bob, password: secret Tomorrow: www.facebook.com, key: bob, key-public: ..., key-private: ... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From nanog at armoredpackets.com Thu Jun 21 10:32:58 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Thu, 21 Jun 2012 11:32:58 -0400 Subject: LinkedIn password database compromised In-Reply-To: <20120621150537.GA49685@ussenterprise.ufp.org> References: <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <41F6C547EA49EC46B4EE1EB2BC2F34184B11F80D76@EXVPMBX100-1.exc.icann.org> <20120620213914.GA20633@ussenterprise.ufp.org> <20120620214405.GT15236@h.detebe.org> <20120620222802.GA22002@ussenterprise.ufp.org> <4FE33320.8030408@armoredpackets.com> <20120621150537.GA49685@ussenterprise.ufp.org> Message-ID: <4FE33EAA.8060904@armoredpackets.com> While I am not disagreeing with your statements, nor do I believe they will work. What I am doing is playing devils advocate. I am hoping to stir all of our gray matter for ideas, maybe something said here may end up being the fix. However, which thread do we want to continue this conversation in? "LinkedIn password database compromised" or "How to fix authentication (was LinkedIn)" :-) - Robert Miller (arch3angel) On 6/21/12 11:05 AM, Leo Bicknell wrote: > I want to start by saing, there are lots of different security problems > with accessing a "cloud service". Several folks have already brought up > issues like compromised user machines or actually verifing identity. > > One of the problems in this space I think is that people keep looking > for a silver bullet that magically solves all the problems. It doesn't > exist. We need a series of technologies that work with each other. > > In a message written on Thu, Jun 21, 2012 at 10:43:44AM -0400, AP NANOG wrote: >> How will this prevent man in the middle attacks, either at the users >> location, the server location, or even on the compromised server itself >> where the attacker is just gathering data. This is the same concerns we >> face now. > There is a sign up problem. You could sign up with a MTM web site, > which then signs you up with the real web site. > > There are a number of solutions, you can try and prevent the MTM attack > with something like DNSSEC, and/or verify the identity of the web site with > something like X.509 certificates verified by a trusted party. The > first relationship could exchange public keys in both directions, making > the attack a sign-up attack only, once the relationship is established > its public key in both directions and if done right impervious to a MTM > attack. > > Note that plenty of corporations "hijack" HTTPS today, so MTM attacks > are very real and work should be done in this space. > >> Second is regarding the example just made with "bicknell at foo.com" and >> superman at foo.com. Does this not require the end user to have virtually >> endless number of email addresses if this method would be implemented >> across all authenticated websites, compounded by numerous devices >> (iPads, Smartphones, personal laptop, work laptop, etc..) > Not at all. Web sites can make the same restrictions they make > today. Many may accept my "bicknell at ufp.org" key and let me us > that as my login. A site like gmail or hotmail may force me to use > something like bicknell at gmail.com, because it actually is an e-mail, > but it could also give me the option of using an identifier of my > choice. > > While I think use of e-mails is good for confirmation purposes, a > semi-anonymous web site that requires no verification could allow > a signup with "bob" or other unqualified identifier. > > It's just another name space. The browser is going to cache a mapping > from web site, or domain, to identifier, quite similar to what it does > today... > > Today: > www.facebook.com, login: bob, password: secret > > Tomorrow: > www.facebook.com, key: bob, key-public: ..., key-private: ... > > From nanog at armoredpackets.com Thu Jun 21 11:15:52 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Thu, 21 Jun 2012 12:15:52 -0400 Subject: How to fix authentication (was LinkedIn) In-Reply-To: <201206211324.12502.alexander.harrowell@stlpartners.com> References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> <201206211324.12502.alexander.harrowell@stlpartners.com> Message-ID: <4FE348B8.4070109@armoredpackets.com> I still believe that the final solution should be some sort of two factor, something you know (i.e. a passphrase) and something you have (i.e. key / token / something which has been verified). Up till recently RSA was a good platform, but was not very effective for smartphone use. If there is no two factor methodology, which changes, being deployed then man in the middle will still work. So will compromising systems and even compromised servers. What if, and I am brainstorming here, what if there was a hardware device which plugged in via USB. It was programed (i.e verified) in person, such as a key signing party. The serial number of the hardware device was all that is stored in the "verified" database with say a generic email created at that time with the domain of the verifying group. For example, your serial number is 12345, so the email would be generated as 12345 at foo.com. This device is hardware encrypted, and stores your password (priv key) in a one way encryption. Then when you go to a website they can ask if you are verified by foo.com. The users selects yes, then the website pulls the public key at that time. Then asks you for your pin, password, pass-phrase, whatever, and at that time the users clicks a pretty eye candy button in the browser which looks for the USB device with the serial number from the database. Once found it then starts a secure tunnel such as VPN (can be anything just using it as a methodology), and no data is transmitted until the tunnel and DNSSEC has been established. Once established you can surf the site as normal. All these connections and tunnels being setup by the browser using two factor authentication. What you know being the public key with verification from foo.com, which was also verified in person with the foo.com email. What you have which is the hardware token, again serial number verified and encrypted. Combined to give you access and the browser does most the work. Couple things I see as issues off the bat are: Cost of USB device Security controls over manufacturing In person verification, will require many locations and volunteers - Still involves the Human Factor of error or misuse Education of the users who are techie Browser security Browser plugin & functionality Change time limit and process (i.e. must be regenerated after x months) Complete Revocation of the token and notification to all websites using foo.com verification Again I am just throwing an idea out there to see what others think, maybe pieces of everyone's idea may result in an effective solution :-) Along the lines of iCloud, or any cloud based service. I am by no means a fan of cloud services in any shape or form. The risks are WAY to great to out weigh the benefits. If someone has a good argument for "secure" cloud services I am open to hearing those, but that's an entirely different email thread :-) - Robert Miller (arch3angel) On 6/21/12 8:23 AM, Alexander Harrowell wrote: > On Thursday 21 Jun 2012 04:16:22 Aaron C. de Bruyn wrote: >> 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 > > As far as apps go, loads of them use OAuth and have a browser step in > their setup. > > > So this adds precisely one step to the smartphone sync/activation > process - downloading the key pair from your PC (or if you don't have a > PC, generating one). > > > that covers vendor A and most vendor G devices. "what about the feature > phones?" - not an issue, no apps to speak of, noOp(). "what about > [person we want to be superior to who is always female for some > reason]?" - well, they all seem to have iPhones now, so *somebody's* > obviously handholding them through the activation procedure. > > > obviously vendor A would be tempted to "sync this to iCloud"...but > anyway, I repeat the call for a W3C password manager API. SSH would be > better, but a lot of the intents, actions etc are the same. From davehart at gmail.com Thu Jun 21 11:17:41 2012 From: davehart at gmail.com (Dave Hart) Date: Thu, 21 Jun 2012 16:17:41 +0000 Subject: LinkedIn password database compromised In-Reply-To: <20120621125606.GA3760@gsp.org> References: <4FD004F0.4060606@deaddrop.org> <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <20120621125606.GA3760@gsp.org> Message-ID: On Thu, Jun 21, 2012 at 12:56 PM, Rich Kulawiec wrote: > On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote: > > (on the use of public/private keys) > >> 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. > > It's a nice thought, but it won't work. ? There are two large-scale > security problems which prevent it from working: > > 1. Fully-compromised/hijacked/botted/zombied systems. ?Pick your term, > but any estimate of this population under 100M should be laughed out > of the room. ?Plausible estimates are now in the 200M to 300M range. > Any private key present on any of those is accessible to The Bad Guys > whenever they can trouble themselves to grab it. ?(Just as they're > already, quite obviously, grabbing passwords en masse.) > > 2. Pre-compromised-at-the-factory smartphones and similar. ?There's > no reason why these can't be preloaded with spyware similar to CarrierIQ > and directed to upload all newly-created private keys to a central > collection point. ?This can be done, therefore it will be done, and when > some security researcher discovers it, the usual excuses and justifications > will be made by the designated spokesliars for the companies involved... > which will of course keep right on doing it, albeit perhaps with more > subterfuge. > > Problem #1 has been extant for ten years and no (meaningful) progress > whatsoever has been made on solving it. > > Problem #2 is newer, but I'm willing to bet that it will also last > at least a decade and that it will get worse, since there are > substantial economic incentives to make it so. In both cases, the evildoers may only gain access to a passphrase-protected private key. That doesn't help if the private key is generated on a compromised system, but it helps if the system is compromised after the private keys are generated, or if the private key is generated elsewhere and loaded onto the compromised system. And it doesn't help if the passphrase is easily guessed. Cheers, Dave Hart From ben at bjencks.net Thu Jun 21 13:11:24 2012 From: ben at bjencks.net (Ben Jencks) Date: Thu, 21 Jun 2012 14:11:24 -0400 Subject: How to fix authentication (was LinkedIn) In-Reply-To: <4FE348B8.4070109@armoredpackets.com> References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> <201206211324.12502.alexander.harrowell@stlpartners.com> <4FE348B8.4070109@armoredpackets.com> Message-ID: <3977CF28-0FA6-4EEF-8D38-C446D3E3FA93@bjencks.net> On Jun 21, 2012, at 12:15 PM, AP NANOG wrote: > What if, and I am brainstorming here, what if there was a hardware device which plugged in via USB. It was programed (i.e verified) in person, such as a key signing party. The serial number of the hardware device was all that is stored in the "verified" database with say a generic email created at that time with the domain of the verifying group. For example, your serial number is 12345, so the email would be generated as 12345 at foo.com. This device is hardware encrypted, and stores your password (priv key) in a one way encryption. Then when you go to a website they can ask if you are verified by foo.com. The users selects yes, then the website pulls the public key at that time. Then asks you for your pin, password, pass-phrase, whatever, and at that time the users clicks a pretty eye candy button in the browser which looks for the USB device with the serial number from the database. Once found it then starts a secure tunnel such as VPN (can be anything just using it as a methodology), and no data is transmitted until the tunnel and DNSSEC has been established. Once established you can surf the site as normal. All these connections and tunnels being setup by the browser using two factor authentication. What you know being the public key with verification from foo.com, which was also verified in person with the foo.com email. What you have which is the hardware token, again serial number verified and encrypted. Combined to give you access and the browser does most the work. That's basically the Yubikey. It uses a shared key, but since you're relying on a trusted third party anyway it's fine if they keep the key. When a Yubikey is manufactured the factory default key is stored in Yubico's public auth service database along with the serial number. Anyone on the internet can then ask the service "was this OTP in fact generated by serial number X?" If you don't trust Yubico's service you can program your own key into it and run your own verification service. The mechanics are different but I think the trust model is the same -- users get USB tokens identified only by serial number, and a third party service vouches that a signature/OTP was generated by a particular serial number. -Ben From jra at baylink.com Thu Jun 21 15:41:27 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 21 Jun 2012 16:41:27 -0400 (EDT) Subject: LinkedIn password database compromised In-Reply-To: Message-ID: <5960872.10358.1340311287262.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Tei" > If anyone have a really good idea how to fix this mess, It will be a > good idea to contact with Jeff Atwood (of codehorror.com and > stackoverflow.com fame). He and other people is working on a new > internet approach to discussions. Think forums 2.0. If this new pet > rock succeed, could change how the world use, eerrh... forums. We > could hit two problems with the same rock. Those who do not understand Usenet are condemned to reinvent it. Poorly. -- after henry at utzoo Cheers, -- jra -- Jay R. Ashworth Baylink jra at 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 From rsk at gsp.org Thu Jun 21 16:44:49 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 21 Jun 2012 17:44:49 -0400 Subject: LinkedIn password database compromised In-Reply-To: References: <20120608232215.GB20888@luke.xen.prgmr.com> <4FD8D670.8010800@psu.edu> <4FE224F2.5020002@armoredpackets.com> <20120620194344.GA16763@ussenterprise.ufp.org> <20120620231234.GA23251@ussenterprise.ufp.org> Message-ID: <20120621214449.GA23513@gsp.org> On Thu, Jun 21, 2012 at 08:33:47AM +0900, Randy Bush wrote: > would be interested to hear smb on this. +1. I've been reading and thinking about: http://www.ietf.org/id/draft-bellovin-hpw-01.txt for quite some time, and I recommend that others interested in this topic do the same. ---rsk From mohta at necom830.hpcl.titech.ac.jp Thu Jun 21 18:40:02 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 22 Jun 2012 08:40:02 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <1340284292.2753.305.camel@karl> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> Message-ID: <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: > Does not scale. Not enough IPv4 addresses to do that for 6.8 > billion people on the planet. It is the first step to have the RSIP style transparent Internet. The second step is to use port numbers for routing within ISPs. But, it is not necessary today. > What if my ISP just routes my /48? Seems to work quite well, > actually. Unlike IPv4 with natural boundary of /24, routing table explosion of IPv6 is a serious scalability problem. Masataka Ohta From owen at delong.com Thu Jun 21 19:28:20 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Jun 2012 17:28:20 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> Message-ID: <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> On Jun 21, 2012, at 4:40 PM, Masataka Ohta wrote: > Owen DeLong wrote: > >> Does not scale. Not enough IPv4 addresses to do that for 6.8 >> billion people on the planet. > > It is the first step to have the RSIP style transparent Internet. > > The second step is to use port numbers for routing within ISPs. > But, it is not necessary today. > Still doesn't scale. 40 bits isn't enough to uniquely identify a conversation end-point. If you use port numbers for routing, you don't have enough port numbers for conversation IDs. >> What if my ISP just routes my /48? Seems to work quite well, >> actually. > > Unlike IPv4 with natural boundary of /24, routing table > explosion of IPv6 is a serious scalability problem. > Solvable. IPv6 has enough bits that we can use map/encap or other various forms of herarchical overlay ASN-based routing to resolve those issues over time. Owen From valdis.kletnieks at vt.edu Thu Jun 21 19:36:48 2012 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 21 Jun 2012 20:36:48 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: Your message of "Fri, 22 Jun 2012 08:40:02 +0900." <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> Message-ID: <18112.1340325408@turing-police.cc.vt.edu> On Fri, 22 Jun 2012 08:40:02 +0900, Masataka Ohta said: > Owen DeLong wrote: > > What if my ISP just routes my /48? Seems to work quite well, > > actually. > > Unlike IPv4 with natural boundary of /24, routing table > explosion of IPv6 is a serious scalability problem. Do you have any *realistic* and *actual* reason to suspect that the IPv6 routing table will "explode" any further than the IPv4 has already? Hint - Owen's /48 will just get aggregated and announced just like the cable companies *already* aggregate all those /20s of customer /32s. Unless Owen multihomes - at which point he's a new entry in the v6 routing tables - but *also* almost certainly a new entry in the v4 routing table. Routing table size depends on the number of AS's, not the amount of address space the routes cover. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From owen at delong.com Thu Jun 21 19:45:21 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Jun 2012 17:45:21 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <18112.1340325408@turing-police.cc.vt.edu> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <18112.1340325408@turing-police.cc.vt.edu> Message-ID: On Jun 21, 2012, at 5:36 PM, valdis.kletnieks at vt.edu wrote: > On Fri, 22 Jun 2012 08:40:02 +0900, Masataka Ohta said: >> Owen DeLong wrote: > >>> What if my ISP just routes my /48? Seems to work quite well, >>> actually. >> >> Unlike IPv4 with natural boundary of /24, routing table >> explosion of IPv6 is a serious scalability problem. > > Do you have any *realistic* and *actual* reason to suspect that the IPv6 > routing table will "explode" any further than the IPv4 has already? Hint - > Owen's /48 will just get aggregated and announced just like the cable companies > *already* aggregate all those /20s of customer /32s. Unless Owen multihomes - at > which point he's a new entry in the v6 routing tables - but *also* almost > certainly a new entry in the v4 routing table. Routing table size depends on > the number of AS's, not the amount of address space the routes cover. > > Um, unlikely. My /48 is an ARIN direct assignment: 2620:0:930::/48 It's not really aggregable with their other customers. I do multihome and I am one entry in the v6 routing tables. However, I'm actually two entries in the v4 routing table. 192.159.10.0/24 and 192.124.40.0/23. Owen From mohta at necom830.hpcl.titech.ac.jp Thu Jun 21 21:29:28 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 22 Jun 2012 11:29:28 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> Message-ID: <4FE3D888.204@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: >> It is the first step to have the RSIP style transparent Internet. >> >> The second step is to use port numbers for routing within ISPs. >> But, it is not necessary today. >> > Still doesn't scale. 40 bits isn't enough to uniquely identify a > conversation end-point. It's 48 bit. > If you use port numbers for routing, > you don't have enough port numbers for conversation IDs. That you use IPv4 addresses for routing does not make it unusable for identifications. Moreover, it is easy to have a transport protocol with 32bit or 48bit port numbers with the end to end fashion only by modifying end part of the Internet. >> Unlike IPv4 with natural boundary of /24, routing table >> explosion of IPv6 is a serious scalability problem. > Solvable. It was solvable. > IPv6 has enough bits that we can use map/encap or > other various forms of herarchical overlay ASN-based routing > to resolve those issues over time. The reality is that situation has been worsening over time. As RFC2374 was obsoleted long ago, it is now impossible to restore it. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Thu Jun 21 21:35:15 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 22 Jun 2012 11:35:15 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <18112.1340325408@turing-police.cc.vt.edu> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <18112.1340325408@turing-police.cc.vt.edu> Message-ID: <4FE3D9E3.3030201@necom830.hpcl.titech.ac.jp> valdis.kletnieks at vt.edu wrote: >> Unlike IPv4 with natural boundary of /24, routing table >> explosion of IPv6 is a serious scalability problem. > > Do you have any *realistic* and *actual* reason to suspect that the IPv6 > routing table will "explode" any further than the IPv4 has already? That's not the point. The problem is that SRAMs scale well but CAMs do not. Masataka Ohta From randy at psg.com Thu Jun 21 21:48:47 2012 From: randy at psg.com (Randy Bush) Date: Thu, 21 Jun 2012 16:48:47 -1000 Subject: How to fix authentication (was LinkedIn) In-Reply-To: <3977CF28-0FA6-4EEF-8D38-C446D3E3FA93@bjencks.net> References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> <201206211324.12502.alexander.harrowell@stlpartners.com> <4FE348B8.4070109@armoredpackets.com> <3977CF28-0FA6-4EEF-8D38-C446D3E3FA93@bjencks.net> Message-ID: > That's basically the Yubikey. It uses a shared key, but since you're > relying on a trusted third party anyway there are no trustable third parties randy From morrowc.lists at gmail.com Thu Jun 21 21:53:18 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Jun 2012 22:53:18 -0400 Subject: How to fix authentication (was LinkedIn) In-Reply-To: References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> <201206211324.12502.alexander.harrowell@stlpartners.com> <4FE348B8.4070109@armoredpackets.com> <3977CF28-0FA6-4EEF-8D38-C446D3E3FA93@bjencks.net> Message-ID: On Thu, Jun 21, 2012 at 10:48 PM, Randy Bush wrote: >> That's basically the Yubikey. It uses a shared key, but since you're >> relying on a trusted third party anyway > > there are no trustable third parties note that yubico has models of auth that include: 1) using a third party 2) making your own party 3) HOTP on token 4) NFC they are a good company, trying to do the right thing(s)... They also don't necessarily want you to be stuck in the 'get your answer from another' -chris From ganbold at gmail.com Fri Jun 22 00:51:15 2012 From: ganbold at gmail.com (Ganbold Tsagaankhuu) Date: Fri, 22 Jun 2012 13:51:15 +0800 Subject: Automatic attack alert to ISPs Message-ID: Hi, Is there any well known free services or scripts that sends automatic attack alerts based on some logs to corresponding ISPs (based on src address)? I have seen dshield.org and mynetwatchman, but I don't know yet how good they are. If somebody has recommendations in this regard please let me know. thanks in advance, Ganbold From ops.lists at gmail.com Fri Jun 22 01:28:10 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 22 Jun 2012 11:58:10 +0530 Subject: Automatic attack alert to ISPs In-Reply-To: References: Message-ID: There are ISP feedback loops You might also try signing up at http://atlas.arbor.net - see if you can get a sensor deployed in your network. http://atlas.arbor.net/faq/#sensor On Fri, Jun 22, 2012 at 11:21 AM, Ganbold Tsagaankhuu wrote: > > Is there any well known free services or scripts that sends automatic > attack alerts based on some logs to corresponding ISPs (based on src > address)? > I have seen dshield.org and mynetwatchman, but I don't know yet how > good they are. > If somebody has recommendations in this regard please let me know. -- Suresh Ramasubramanian (ops.lists at gmail.com) From xiangy08 at csnet1.cs.tsinghua.edu.cn Fri Jun 22 01:46:28 2012 From: xiangy08 at csnet1.cs.tsinghua.edu.cn (Yang Xiang) Date: Fri, 22 Jun 2012 14:46:28 +0800 Subject: Automatic attack alert to ISPs In-Reply-To: References: Message-ID: Argus can alert prefix hijacking, in realtime. http://tli.tl/argus Hope to be useful to you. BR. ? 2012?6?22?????Ganbold Tsagaankhuu ??? > Hi, > > Is there any well known free services or scripts that sends automatic > attack alerts based on some logs to corresponding ISPs (based on src > address)? > I have seen dshield.org and mynetwatchman, but I don't know yet how > good they are. > If somebody has recommendations in this regard please let me know. > > thanks in advance, > > Ganbold > > -- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn From righa.shake at gmail.com Fri Jun 22 02:39:48 2012 From: righa.shake at gmail.com (Righa Shake) Date: Fri, 22 Jun 2012 10:39:48 +0300 Subject: Contact from Global Crossing Kindly contact me off list Message-ID: Hi, Kindly would someone from Global Crossing contact me offlist. Regards, Righa Shake From bgreene at senki.org Fri Jun 22 03:44:00 2012 From: bgreene at senki.org (Barry Greene) Date: Fri, 22 Jun 2012 16:44:00 +0800 Subject: Automatic attack alert to ISPs In-Reply-To: References: Message-ID: <63D3A448-B67F-45DC-A4D7-EC5E02EB727A@senki.org> Shadowserver.org has a public benefit notification service. Sent from my iPad On Jun 22, 2012, at 2:46 PM, Yang Xiang wrote: > Argus can alert prefix hijacking, in realtime. > http://tli.tl/argus > Hope to be useful to you. > > BR. > > ? 2012?6?22?????Ganbold Tsagaankhuu ??? > >> Hi, >> >> Is there any well known free services or scripts that sends automatic >> attack alerts based on some logs to corresponding ISPs (based on src >> address)? >> I have seen dshield.org and mynetwatchman, but I don't know yet how >> good they are. >> If somebody has recommendations in this regard please let me know. >> >> thanks in advance, >> >> Ganbold >> >> > > -- > _________________________________________ > Yang Xiang. Ph.D candidate. Tsinghua University > Argus: argus.csnet1.cs.tsinghua.edu.cn From bonomi at mail.r-bonomi.com Fri Jun 22 06:43:27 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 22 Jun 2012 06:43:27 -0500 (CDT) Subject: LinkedIn password database compromised In-Reply-To: <20120621125606.GA3760@gsp.org> Message-ID: <201206221143.q5MBhR0o041383@mail.r-bonomi.com> Rich Kulawiec wrote: > > On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote: > > (on the use of public/private keys) > > > 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. > > It's a nice thought, but it won't work. There are two large-scale > security problems which prevent it from working: > > 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term, > but any estimate of this population under 100M should be laughed out > of the room. Plausible estimates are now in the 200M to 300M range. > Any private key present on any of those is accessible to The Bad Guys > whenever they can trouble themselves to grab it. (Just as they're > already, quite obviously, grabbing passwords en masse.) The proverbial 'so what' applies? IF the end-user system is compromised, it *doesn't*matter* what kind of security is used, THAT USER is compromised. However, there is a _MASSIVE_ difference with respect to a 'server-side' compromise. One break-in, on *one* machine, can expose tens of millions, (if not hundreds of millions) of user credentials. > > 2. Pre-compromised-at-the-factory smartphones and similar. There's > no reason why these can't be preloaded with spyware similar to CarrierIQ > and directed to upload all newly-created private keys to a central > collection point. > > Problem #1 has been extant for ten years and no (meaningful) progress > whatsoever has been made on solving it. 'male bovine excrement' applies to this strawman argument. Leo made no claim of describing a FUSSP (final ultimate solution to stolen passwords). What he did describe was a methodology that could be fairly easily implemented in the real world, =and= which effectively eliminates the risk of _server-side_ compromise of a master 'password-equivalent' list. Leo's proposal _does_ effectively address the risk of server-side compromise. If implemented, it would effectively eliminate "more than half" of the From mohta at necom830.hpcl.titech.ac.jp Fri Jun 22 07:46:35 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 22 Jun 2012 21:46:35 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <09D57D42-2EF5-4330-9679-BBA57D0E1BFA@delong.com> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> <4FE3D888.204@necom830.hpcl.titech.ac.jp> <09D57D42-2EF5-4330-9679-BBA57D0E1BFA@delong.com> Message-ID: <4FE4692B.50101@necom830.hpcl.titech.ac.jp> Owen DeLong wrote privately to me, but as I think I need public responses, I'm Ccing to nanog fairly quoting part of his response: >> Moreover, it is easy to have a transport protocol with >> 32bit or 48bit port numbers with the end to end fashion >> only by modifying end part of the Internet. > The center part of the internet is the easiest part of > modification for IPv6 and is probably somewhere near 99% > complete at this point. That is a fairy tale once believed by so many infants who thought dual stack were enough. They still believed the fairy tale even when they designed automated tunneling. But, as most of them have grown up a little not to believe fairly tales, they are trying other possibilities. However, so far, they are not so successful. Masataka Ohta PS Rest of his response is omitted, because I think it is not worth quoting. From nanog at armoredpackets.com Fri Jun 22 09:24:15 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Fri, 22 Jun 2012 10:24:15 -0400 Subject: How to fix authentication (was LinkedIn) In-Reply-To: References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> <201206211324.12502.alexander.harrowell@stlpartners.com> <4FE348B8.4070109@armoredpackets.com> <3977CF28-0FA6-4EEF-8D38-C446D3E3FA93@bjencks.net> Message-ID: <4FE4800F.1020207@armoredpackets.com> I used the example I did based on YubiKey, I own one and use it on a regular basis. The real issue I am trying to make is the fact that even in the scenario I placed forward it still requires trust. Trust of a person or trust of a company. This reminds me of a quote: Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein By no means am I saying any of us, or the majority of the world is stupid or uneducated. However, the inherent nature behind trust is just that, relying on some sort of other party is the weak link here. It only takes a single person who has a bad day, or just wants to slack off for that day, to create a vulnerability in any password, key, encryption, or authentication process hundreds if not thousands of people work so hard to solve. While I used YubiKey as my original example, and use it on a regular basis, it still has its downfalls. It cannot be used with Active Sync, so ultimately you can not use it for your Active Directory log in because of a small thing called Exchange. There have been other areas were YubiKey has failed but not by it's design, but by the design of the application itself. How can any of our solutions over come the human factor? -- - Robert Miller (arch3angel) On 6/21/12 10:53 PM, Christopher Morrow wrote: > On Thu, Jun 21, 2012 at 10:48 PM, Randy Bush wrote: >>> That's basically the Yubikey. It uses a shared key, but since you're >>> relying on a trusted third party anyway >> there are no trustable third parties > note that yubico has models of auth that include: > 1) using a third party > 2) making your own party > 3) HOTP on token > 4) NFC > > they are a good company, trying to do the right thing(s)... They also > don't necessarily want you to be stuck in the 'get your answer from > another' > > -chris From bicknell at ufp.org Fri Jun 22 09:25:29 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 Jun 2012 07:25:29 -0700 Subject: How to fix authentication (was LinkedIn) In-Reply-To: References: <3977CF28-0FA6-4EEF-8D38-C446D3E3FA93@bjencks.net> <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> <201206211324.12502.alexander.harrowell@stlpartners.com> <4FE348B8.4070109@armoredpackets.com> <3977CF28-0FA6-4EEF-8D38-C446D3E3FA93@bjencks.net> Message-ID: <20120622142529.GA96023@ussenterprise.ufp.org> In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush wrote: > there are no trustable third parties With a lot of transactions the second party isn't trustable, and sometimes the first party isn't as well. :) In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher Morrow wrote: > note that yubico has models of auth that include: > 1) using a third party > 2) making your own party > 3) HOTP on token > 4) NFC > > they are a good company, trying to do the right thing(s)... They also > don't necessarily want you to be stuck in the 'get your answer from > another' Requirements of hardware or a third party are fine for the corporate world, or sites that make enough money or have enough risk to invest in security, like a bank. Requiring hardware for a site like Facebook or Twitter is right out. Does not scale, can't ship to the guy in Pakistan or McMurdo who wants to sign up. Trusting a third party becomes too expensive, and too big of a business risk. There are levels of security here. I don't expect Facebook to take the same security steps as my bank to move my money around. One size does not fit all. Making it so a hacker can't get 10 million login credentials at once is a quantum leap forward even if doing so doesn't improve security in any other way. The perfect is the enemy of the good. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From nanog at armoredpackets.com Fri Jun 22 09:26:06 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Fri, 22 Jun 2012 10:26:06 -0400 Subject: Automatic attack alert to ISPs In-Reply-To: <63D3A448-B67F-45DC-A4D7-EC5E02EB727A@senki.org> References: <63D3A448-B67F-45DC-A4D7-EC5E02EB727A@senki.org> Message-ID: <4FE4807E.4080906@armoredpackets.com> +1 - Took the letters right out from under my fingers :-) -- - Robert Miller (arch3angel) On 6/22/12 4:44 AM, Barry Greene wrote: > Shadowserver.org has a public benefit notification service. > > Sent from my iPad > > On Jun 22, 2012, at 2:46 PM, Yang Xiang wrote: > >> Argus can alert prefix hijacking, in realtime. >> http://tli.tl/argus >> Hope to be useful to you. >> >> BR. >> >> ? 2012?6?22?????Ganbold Tsagaankhuu ??? >> >>> Hi, >>> >>> Is there any well known free services or scripts that sends automatic >>> attack alerts based on some logs to corresponding ISPs (based on src >>> address)? >>> I have seen dshield.org and mynetwatchman, but I don't know yet how >>> good they are. >>> If somebody has recommendations in this regard please let me know. >>> >>> thanks in advance, >>> >>> Ganbold >>> >>> >> -- >> _________________________________________ >> Yang Xiang. Ph.D candidate. Tsinghua University >> Argus: argus.csnet1.cs.tsinghua.edu.cn From nanog at armoredpackets.com Fri Jun 22 09:29:01 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Fri, 22 Jun 2012 10:29:01 -0400 Subject: LinkedIn password database compromised In-Reply-To: <201206221143.q5MBhR0o041383@mail.r-bonomi.com> References: <201206221143.q5MBhR0o041383@mail.r-bonomi.com> Message-ID: <4FE4812D.4040800@armoredpackets.com> Still playing devils advocate here, but does this still not resolve the human factor of "Implementation"? -- - Robert Miller (arch3angel) On 6/22/12 7:43 AM, Robert Bonomi wrote: > Rich Kulawiec wrote: >> On Wed, Jun 20, 2012 at 12:43:44PM -0700, Leo Bicknell wrote: >> >> (on the use of public/private keys) >> >>> 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. >> It's a nice thought, but it won't work. There are two large-scale >> security problems which prevent it from working: >> >> 1. Fully-compromised/hijacked/botted/zombied systems. Pick your term, >> but any estimate of this population under 100M should be laughed out >> of the room. Plausible estimates are now in the 200M to 300M range. >> Any private key present on any of those is accessible to The Bad Guys >> whenever they can trouble themselves to grab it. (Just as they're >> already, quite obviously, grabbing passwords en masse.) > The proverbial 'so what' applies? > > IF the end-user system is compromised, it *doesn't*matter* what kind of > security is used, THAT USER is compromised. > > However, there is a _MASSIVE_ difference with respect to a 'server-side' > compromise. One break-in, on *one* machine, can expose tens of millions, > (if not hundreds of millions) of user credentials. > >> 2. Pre-compromised-at-the-factory smartphones and similar. There's >> no reason why these can't be preloaded with spyware similar to CarrierIQ >> and directed to upload all newly-created private keys to a central >> collection point. >> >> Problem #1 has been extant for ten years and no (meaningful) progress >> whatsoever has been made on solving it. > 'male bovine excrement' applies to this strawman argument. > > Leo made no claim of describing a FUSSP (final ultimate solution to stolen > passwords). What he did describe was a methodology that could be fairly > easily implemented in the real world, =and= which effectively eliminates > the risk of _server-side_ compromise of a master 'password-equivalent' list. > > Leo's proposal _does_ effectively address the risk of server-side compromise. > If implemented, it would effectively eliminate "more than half" of the From trejrco at gmail.com Fri Jun 22 09:38:38 2012 From: trejrco at gmail.com (TJ) Date: Fri, 22 Jun 2012 10:38:38 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE4692B.50101@necom830.hpcl.titech.ac.jp> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> <4FE3D888.204@necom830.hpcl.titech.ac.jp> <09D57D42-2EF5-4330-9679-BBA57D0E1BFA@delong.com> <4FE4692B.50101@necom830.hpcl.titech.ac.jp> Message-ID: On Fri, Jun 22, 2012 at 8:46 AM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > > The center part of the internet is the easiest part of > > modification for IPv6 and is probably somewhere near 99% > > complete at this point. > > That is a fairy tale once believed by so many infants who > thought dual stack were enough. > Just injecting a real-world comment/observation here: I am sitting at home, on my natively IPv6 connected, Comcast-provided residential service. My phone is sitting next to me, connected to VZW's IPv6-capable LTE network. When I go to one of my client sites, they get IPv6 through a HE.net tunnel. Another client site uses AT&T and/or CenturyLink for IPv6 connectivity. *... the list goes on ...* In all cases, IPv6 is alive and well for me. More importantly (even though the last-mile is not ubiquitously IPv6-enabled in all service regions) those five providers have backbones that are 100% up and running, native IPv6 all over the place. So what is the fairy tale?? Am I saying we are all done, and that IPv6 is fully deployed? Of course not, lots of work to do in the enterprise and last-mile areas ... but progress has been noticeable and is accelerating. /TJ From cscora at apnic.net Fri Jun 22 13:48:33 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Jun 2012 04:48:33 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201206221848.q5MImXE9026182@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Jun, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 414975 Prefixes after maximum aggregation: 175345 Deaggregation factor: 2.37 Unique aggregates announced to Internet: 202288 Total ASes present in the Internet Routing Table: 41358 Prefixes per ASN: 10.03 Origin-only ASes present in the Internet Routing Table: 33312 Origin ASes announcing only one prefix: 15660 Transit ASes present in the Internet Routing Table: 5532 Transit-only ASes present in the Internet Routing Table: 141 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 28 Max AS path prepend of ASN ( 36992) 22 Prefixes from unregistered ASNs in the Routing Table: 392 Unregistered ASNs in the Routing Table: 123 Number of 32-bit ASNs allocated by the RIRs: 2879 Number of 32-bit ASNs visible in the Routing Table: 2514 Prefixes from 32-bit ASNs in the Routing Table: 6440 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 260 Number of addresses announced to Internet: 2568129068 Equivalent to 153 /8s, 18 /16s and 138 /24s Percentage of available address space announced: 69.3 Percentage of allocated address space announced: 69.4 Percentage of available address space allocated: 99.9 Percentage of address space in use by end-sites: 93.0 Total number of prefixes smaller than registry allocations: 144378 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 101060 Total APNIC prefixes after maximum aggregation: 32679 APNIC Deaggregation factor: 3.09 Prefixes being announced from the APNIC address blocks: 101493 Unique aggregates announced from the APNIC address blocks: 41912 APNIC Region origin ASes present in the Internet Routing Table: 4708 APNIC Prefixes per ASN: 21.56 APNIC Region origin ASes announcing only one prefix: 1240 APNIC Region transit ASes present in the Internet Routing Table: 743 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 238 Number of APNIC addresses announced to Internet: 703274368 Equivalent to 41 /8s, 235 /16s and 29 /24s Percentage of available APNIC address space announced: 82.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 152044 Total ARIN prefixes after maximum aggregation: 77265 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 152987 Unique aggregates announced from the ARIN address blocks: 68132 ARIN Region origin ASes present in the Internet Routing Table: 15172 ARIN Prefixes per ASN: 10.08 ARIN Region origin ASes announcing only one prefix: 5752 ARIN Region transit ASes present in the Internet Routing Table: 1601 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 16 Number of ARIN addresses announced to Internet: 1080985216 Equivalent to 64 /8s, 110 /16s and 134 /24s Percentage of available ARIN address space announced: 57.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 103551 Total RIPE prefixes after maximum aggregation: 54846 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 105587 Unique aggregates announced from the RIPE address blocks: 66781 RIPE Region origin ASes present in the Internet Routing Table: 16640 RIPE Prefixes per ASN: 6.35 RIPE Region origin ASes announcing only one prefix: 8070 RIPE Region transit ASes present in the Internet Routing Table: 2666 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 28 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1654 Number of RIPE addresses announced to Internet: 631874948 Equivalent to 37 /8s, 169 /16s and 165 /24s Percentage of available RIPE address space announced: 91.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 42327 Total LACNIC prefixes after maximum aggregation: 8320 LACNIC Deaggregation factor: 5.09 Prefixes being announced from the LACNIC address blocks: 44845 Unique aggregates announced from the LACNIC address blocks: 21926 LACNIC Region origin ASes present in the Internet Routing Table: 1600 LACNIC Prefixes per ASN: 28.03 LACNIC Region origin ASes announcing only one prefix: 431 LACNIC Region transit ASes present in the Internet Routing Table: 308 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 600 Number of LACNIC addresses announced to Internet: 111077288 Equivalent to 6 /8s, 158 /16s and 231 /24s Percentage of available LACNIC address space announced: 66.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9352 Total AfriNIC prefixes after maximum aggregation: 2173 AfriNIC Deaggregation factor: 4.30 Prefixes being announced from the AfriNIC address blocks: 9803 Unique aggregates announced from the AfriNIC address blocks: 3304 AfriNIC Region origin ASes present in the Internet Routing Table: 548 AfriNIC Prefixes per ASN: 17.89 AfriNIC Region origin ASes announcing only one prefix: 167 AfriNIC Region transit ASes present in the Internet Routing Table: 125 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 40527872 Equivalent to 2 /8s, 106 /16s and 104 /24s Percentage of available AfriNIC address space announced: 40.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2704 11117 1196 Korea Telecom (KIX) 17974 1945 533 80 PT TELEKOMUNIKASI INDONESIA 7545 1689 301 87 TPG Internet Pty Ltd 4755 1594 385 154 TATA Communications formerly 9829 1300 1085 28 BSNL National Internet Backbo 9583 1173 89 511 Sify Limited 4808 1107 2054 313 CNCGROUP IP network: China169 7552 1100 1062 11 Vietel Corporation 24560 1034 385 165 Bharti Airtel Ltd., Telemedia 9498 966 291 63 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3401 3791 190 bellsouth.net, inc. 7029 3238 986 157 Windstream Communications Inc 18566 2091 382 181 Covad Communications 1785 1925 681 132 PaeTec Communications, Inc. 22773 1650 2911 121 Cox Communications, Inc. 20115 1645 1570 613 Charter Communications 4323 1571 1043 385 Time Warner Telecom 30036 1439 269 763 Mediacom Communications Corp 7018 1225 10013 823 AT&T WorldNet Services 11492 1189 216 356 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1690 544 16 Corbina telecom 2118 1255 97 14 EUnet/RELCOM Autonomous Syste 12479 757 721 93 Uni2 Autonomous System 34984 710 188 173 BILISIM TELEKOM 31148 686 37 9 FreeNet ISP 6830 685 2234 437 UPC Distribution Services 20940 664 215 520 Akamai Technologies European 8551 577 364 61 Bezeq International 3320 490 8442 403 Deutsche Telekom AG 13188 476 100 10 Educational Network Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1967 342 205 TVCABLE BOGOTA 28573 1942 1211 54 NET Servicos de Comunicao S.A 6503 1530 418 65 AVANTEL, S.A. 8151 1491 3068 336 UniNet S.A. de C.V. 7303 1440 901 195 Telecom Argentina Stet-France 26615 903 728 33 Tim Brasil S.A. 27947 705 73 93 Telconet S.A 11172 646 91 74 Servicios Alestra S.A de C.V 3816 586 247 89 Empresa Nacional de Telecomun 22047 583 326 15 VTR PUNTO NET S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1275 958 13 TEDATA 24863 860 274 35 LINKdotNET AS number 6713 499 649 18 Itissalat Al-MAGHRIB 24835 321 80 8 RAYA Telecom - Egypt 3741 262 905 223 The Internet Solution 33776 209 12 21 Starcomms Nigeria Limited 12258 197 28 62 Vodacom Internet Company 16637 172 664 87 MTN Network Solutions 29975 167 571 19 Vodacom 29571 157 15 16 Ci Telecom Autonomous system Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3401 3791 190 bellsouth.net, inc. 7029 3238 986 157 Windstream Communications Inc 4766 2704 11117 1196 Korea Telecom (KIX) 18566 2091 382 181 Covad Communications 10620 1967 342 205 TVCABLE BOGOTA 17974 1945 533 80 PT TELEKOMUNIKASI INDONESIA 28573 1942 1211 54 NET Servicos de Comunicao S.A 1785 1925 681 132 PaeTec Communications, Inc. 8402 1690 544 16 Corbina telecom 7545 1689 301 87 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3238 3081 Windstream Communications Inc 18566 2091 1910 Covad Communications 28573 1942 1888 NET Servicos de Comunicao S.A 17974 1945 1865 PT TELEKOMUNIKASI INDONESIA 1785 1925 1793 PaeTec Communications, Inc. 10620 1967 1762 TVCABLE BOGOTA 8402 1690 1674 Corbina telecom 7545 1689 1602 TPG Internet Pty Ltd 22773 1650 1529 Cox Communications, Inc. 4766 2704 1508 Korea Telecom (KIX) Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 32873 UNALLOCATED 12.46.100.0/23 10912 InterNAP Network Ser 32873 UNALLOCATED 12.46.102.0/24 10912 InterNAP Network Ser 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.192.0.0/22 45464 Room 201, TGU Bldg 14.192.4.0/22 45464 Room 201, TGU Bldg 14.192.8.0/22 45464 Room 201, TGU Bldg 14.192.12.0/22 45464 Room 201, TGU Bldg 14.192.16.0/22 45464 Room 201, TGU Bldg 14.192.20.0/22 45464 Room 201, TGU Bldg 14.192.24.0/22 45464 Room 201, TGU Bldg 14.192.28.0/22 45464 Room 201, TGU Bldg 27.112.114.0/24 23884 Proimage Engineering and Comm 46.96.0.0/22 31733 Link Telecom PJSC Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:13 /10:28 /11:83 /12:236 /13:462 /14:832 /15:1508 /16:12291 /17:6333 /18:10725 /19:20814 /20:29569 /21:31283 /22:40922 /23:38788 /24:217227 /25:1238 /26:1460 /27:866 /28:171 /29:66 /30:18 /31:0 /32:23 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2636 3238 Windstream Communications Inc 18566 2040 2091 Covad Communications 6389 1874 3401 bellsouth.net, inc. 8402 1389 1690 Corbina telecom 30036 1378 1439 Mediacom Communications Corp 11492 1152 1189 Cable One 22773 1082 1650 Cox Communications, Inc. 6503 1061 1530 AVANTEL, S.A. 8452 1040 1275 TEDATA 1785 1036 1925 PaeTec Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:563 2:712 3:1 4:13 5:62 6:3 8:429 12:2014 13:1 14:630 15:12 16:3 17:5 20:24 23:185 24:1784 27:1311 31:984 32:56 33:2 34:2 36:9 37:582 38:814 39:1 40:127 41:3147 42:139 44:3 46:1448 47:2 49:415 50:559 52:13 54:12 55:7 56:1 57:34 58:976 59:504 60:259 61:1227 62:997 63:2040 64:4251 65:2254 66:4460 67:2022 68:1155 69:3194 70:982 71:503 72:1829 74:2601 75:477 76:330 77:951 78:968 79:493 80:1216 81:943 82:653 83:526 84:498 85:1191 86:420 87:936 88:331 89:1721 90:298 91:4956 92:573 93:1402 94:1595 95:1230 96:371 97:316 98:893 99:38 100:17 101:251 103:1200 106:103 107:186 108:340 109:1411 110:785 111:925 112:419 113:623 114:642 115:822 116:949 117:730 118:899 119:1233 120:348 121:694 122:1673 123:1097 124:1400 125:1255 128:560 129:198 130:254 131:633 132:289 133:22 134:244 135:61 136:215 137:239 138:334 139:185 140:491 141:253 142:437 143:372 144:516 145:76 146:510 147:292 148:775 149:314 150:163 151:182 152:473 153:175 154:17 155:420 156:225 157:381 158:190 159:619 160:342 161:269 162:352 163:192 164:643 165:413 166:587 167:475 168:912 169:127 170:885 171:137 172:5 173:1779 174:615 175:436 176:545 177:842 178:1517 180:1264 181:97 182:1020 183:232 184:517 185:1 186:2375 187:1133 188:1349 189:1852 190:5635 192:6005 193:5539 194:4542 195:3430 196:1220 197:161 198:3666 199:4796 200:5897 201:1967 202:8667 203:8580 204:4337 205:2542 206:2805 207:2798 208:4042 209:3608 210:2786 211:1552 212:2032 213:1925 214:874 215:83 216:5102 217:1566 218:555 219:312 220:1241 221:574 222:315 223:354 End of report From stig at venaas.com Fri Jun 22 15:21:41 2012 From: stig at venaas.com (Stig Venaas) Date: Fri, 22 Jun 2012 13:21:41 -0700 Subject: [MBONED] PIM survey for operators Message-ID: <4FE4D3D5.2000900@venaas.com> 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.eubanks at 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? _______________________________________________ MBONED mailing list MBONED at ietf.org https://www.ietf.org/mailman/listinfo/mboned From cidr-report at potaroo.net Fri Jun 22 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Jun 2012 22:00:00 GMT Subject: BGP Update Report Message-ID: <201206222200.q5MM00Tu046983@wattle.apnic.net> BGP Update Report Interval: 14-Jun-12 -to- 21-Jun-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8452 113559 4.4% 62.4 -- TE-AS TE-AS 2 - AS9829 50283 2.0% 38.7 -- BSNL-NIB National Internet Backbone 3 - AS8402 45797 1.8% 23.5 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS13188 41623 1.6% 79.3 -- BANKINFORM-AS TOV "Bank-Inform" 5 - AS19361 32335 1.3% 951.0 -- Atrium Telecomunicacoes Ltda 6 - AS12479 28842 1.1% 38.1 -- UNI2-AS France Telecom Espana SA 7 - AS24560 27934 1.1% 26.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - AS7303 25098 1.0% 17.4 -- Telecom Argentina S.A. 9 - AS17813 25074 1.0% 188.5 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 10 - AS5800 21992 0.9% 83.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 11 - AS13118 20121 0.8% 419.2 -- ASN-YARTELECOM OJSC Rostelecom 12 - AS28057 18560 0.7% 1546.7 -- Contecol 13 - AS26615 16782 0.7% 18.4 -- Tim Celular S.A. 14 - AS17621 16250 0.6% 106.9 -- CNCGROUP-SH China Unicom Shanghai network 15 - AS28573 16052 0.6% 8.1 -- NET Servicos de Comunicao S.A. 16 - AS7552 14335 0.6% 12.1 -- VIETEL-AS-AP Vietel Corporation 17 - AS7029 14153 0.6% 4.1 -- WINDSTREAM - Windstream Communications Inc 18 - AS16814 12125 0.5% 17.9 -- NSS S.A. 19 - AS17974 11505 0.5% 5.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS25620 10104 0.4% 53.7 -- COTAS LTDA. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS45264 4799 0.2% 2399.5 -- BAJAJALLIANZLIFE-AS-AP Bajaj Allianz Life Insurance Company Ltd 2 - AS28057 18560 0.7% 1546.7 -- Contecol 3 - AS45286 1387 0.1% 1387.0 -- EDIINDONESIA-AS-ID PT EDI INDONESIA 4 - AS29421 1371 0.1% 1371.0 -- DCI-AS Digital Communications Incorporated Ltd. 5 - AS30944 1258 0.1% 1258.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD" 6 - AS29126 972 0.0% 972.0 -- DATIQ-AS Datiq B.V. 7 - AS19361 32335 1.3% 951.0 -- Atrium Telecomunicacoes Ltda 8 - AS40848 911 0.0% 911.0 -- FMFCU - Franklin Mint FCU 9 - AS55665 824 0.0% 824.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 10 - AS3 635 0.0% 1139.0 -- UNIXSTORM-AS Unix Storm - Michal Gottlieb 11 - AS3 555 0.0% 1322.0 -- UNIXSTORM-AS Unix Storm - Michal Gottlieb 12 - AS11652 2517 0.1% 503.4 -- TFCL-2 - TERRA FIRMA COMMUNICATIONS, LLC 13 - AS57201 459 0.0% 459.0 -- EDF-AS Estonian Defence Forces 14 - AS13118 20121 0.8% 419.2 -- ASN-YARTELECOM OJSC Rostelecom 15 - AS38857 814 0.0% 407.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 16 - AS19406 4428 0.2% 402.5 -- TWRS-MA - Towerstream I, Inc. 17 - AS43230 346 0.0% 346.0 -- OMNIPORT-AS OMNIPORT SRL 18 - AS16064 330 0.0% 330.0 -- INFOPAC-AS Joint-Stock Company INFOPAC 19 - AS51624 322 0.0% 322.0 -- ITC21VEK-AS ITC XXI Century Ltd. 20 - AS28666 4398 0.2% 314.1 -- HOSTLOCATION LTDA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 19886 0.7% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 220.196.26.0/24 15945 0.6% AS17621 -- CNCGROUP-SH China Unicom Shanghai network 3 - 41.43.147.0/24 11685 0.4% AS8452 -- TE-AS TE-AS 4 - 122.161.0.0/16 10614 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - 62.36.252.0/22 7930 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 6 - 182.64.0.0/16 7567 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 62.36.249.0/24 6595 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 8 - 202.56.215.0/24 6459 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 9 - 62.36.241.0/24 6172 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 59.177.48.0/20 6054 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 11 - 62.36.210.0/24 6021 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 12 - 194.63.9.0/24 5263 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 202.159.192.0/19 4837 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 14 - 202.90.40.0/24 4797 0.2% AS45264 -- BAJAJALLIANZLIFE-AS-AP Bajaj Allianz Life Insurance Company Ltd 15 - 69.38.178.0/24 4408 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 16 - 59.177.64.0/18 3362 0.1% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 17 - 59.177.144.0/20 3097 0.1% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 18 - 115.170.128.0/17 2206 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange 19 - 215.65.61.0/24 1889 0.1% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - 190.9.120.0/24 1720 0.1% AS11581 -- TRANSTEL S.A. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 22 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Jun 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201206222200.q5MM00qw046969@wattle.apnic.net> This report has been generated at Fri Jun 22 21:12:58 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 15-06-12 416421 242407 16-06-12 416435 242366 17-06-12 416800 242573 18-06-12 417057 242604 19-06-12 416751 242539 20-06-12 416653 242280 21-06-12 417133 242084 22-06-12 417401 241620 AS Summary 41477 Number of ASes in routing system 17307 Number of ASes announcing only one prefix 3401 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113213920 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 22Jun12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 417722 241644 176078 42.2% All ASes AS6389 3401 193 3208 94.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3279 1651 1628 49.6% WINDSTREAM - Windstream Communications Inc AS22773 1652 137 1515 91.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2720 1294 1426 52.4% KIXS-AS-KR Korea Telecom AS18566 2091 706 1385 66.2% COVAD - Covad Communications Co. AS28573 1954 581 1373 70.3% NET Servicos de Comunicao S.A. AS2118 1255 14 1241 98.9% RELCOM-AS OOO "NPO Relcom" AS7545 1704 503 1201 70.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS4323 1571 386 1185 75.4% TWTC - tw telecom holdings, inc. AS10620 1967 794 1173 59.6% Telmex Colombia S.A. AS1785 1925 815 1110 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1594 540 1054 66.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7303 1440 462 978 67.9% Telecom Argentina S.A. AS7552 1100 217 883 80.3% VIETEL-AS-AP Vietel Corporation AS26615 902 33 869 96.3% Tim Celular S.A. AS17974 1945 1088 857 44.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS8151 1490 672 818 54.9% Uninet S.A. de C.V. AS18101 947 160 787 83.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1107 346 761 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9394 892 162 730 81.8% CRNET CHINA RAILWAY Internet(CRNET) AS13977 839 123 716 85.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS3356 1113 467 646 58.0% LEVEL3 Level 3 Communications AS855 690 57 633 91.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17676 691 74 617 89.3% GIGAINFRA Softbank BB Corp. AS30036 1439 835 604 42.0% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS4780 841 246 595 70.7% SEEDNET Digital United Inc. AS19262 998 405 593 59.4% VZGNI-TRANSIT - Verizon Online LLC AS22561 1016 424 592 58.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS9808 593 22 571 96.3% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS8452 1275 716 559 43.8% TE-AS TE-AS Total 44431 14123 30308 68.2% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 46.96.0.0/22 AS31733 46.96.4.0/22 AS31733 46.96.8.0/22 AS31733 46.96.12.0/22 AS31733 46.96.16.0/22 AS31733 46.96.20.0/22 AS31733 46.96.24.0/22 AS31733 46.96.28.0/22 AS31733 46.96.32.0/22 AS31733 46.96.36.0/22 AS31733 46.96.40.0/22 AS31733 46.96.44.0/22 AS31733 46.96.48.0/22 AS31733 46.96.52.0/22 AS31733 46.96.56.0/22 AS31733 46.96.60.0/22 AS31733 46.96.64.0/22 AS31733 46.96.68.0/22 AS31733 46.96.72.0/22 AS31733 46.96.76.0/22 AS31733 46.96.80.0/22 AS31733 46.96.84.0/22 AS31733 46.96.88.0/22 AS31733 46.96.92.0/22 AS31733 46.96.96.0/22 AS31733 46.96.100.0/22 AS31733 46.96.104.0/22 AS31733 46.96.108.0/22 AS31733 46.96.112.0/22 AS31733 46.96.116.0/22 AS31733 46.96.120.0/22 AS31733 46.96.124.0/22 AS31733 46.96.128.0/22 AS31733 46.96.132.0/22 AS31733 46.96.136.0/22 AS31733 46.96.140.0/22 AS31733 46.96.144.0/22 AS31733 46.96.148.0/22 AS31733 46.96.152.0/22 AS31733 46.96.156.0/22 AS31733 46.96.160.0/22 AS31733 46.96.164.0/22 AS31733 46.96.168.0/22 AS31733 46.96.172.0/22 AS31733 46.96.176.0/22 AS31733 46.96.180.0/22 AS31733 46.96.184.0/22 AS31733 46.96.188.0/22 AS31733 46.96.192.0/22 AS31733 46.96.196.0/22 AS31733 46.96.200.0/22 AS31733 46.96.204.0/22 AS31733 46.96.208.0/22 AS31733 46.96.212.0/22 AS31733 46.96.216.0/22 AS31733 46.96.220.0/22 AS31733 46.96.224.0/22 AS31733 46.96.228.0/22 AS31733 46.96.232.0/22 AS31733 46.96.236.0/22 AS31733 46.96.240.0/22 AS31733 46.96.244.0/22 AS31733 46.96.248.0/22 AS31733 46.96.252.0/22 AS31733 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 83.223.224.0/22 AS31733 83.223.228.0/22 AS31733 83.223.232.0/22 AS31733 83.223.236.0/22 AS31733 83.223.240.0/22 AS31733 83.223.244.0/22 AS31733 83.223.248.0/22 AS31733 83.223.252.0/22 AS31733 94.250.128.0/22 AS31733 94.250.132.0/22 AS31733 94.250.136.0/22 AS31733 94.250.140.0/22 AS31733 94.250.144.0/22 AS31733 94.250.148.0/22 AS31733 94.250.152.0/22 AS31733 94.250.156.0/22 AS31733 94.250.160.0/22 AS31733 94.250.164.0/22 AS31733 94.250.168.0/22 AS31733 94.250.172.0/22 AS31733 94.250.176.0/22 AS31733 94.250.180.0/22 AS31733 94.250.184.0/22 AS31733 94.250.188.0/22 AS31733 94.250.192.0/22 AS31733 94.250.196.0/22 AS31733 94.250.200.0/22 AS31733 94.250.204.0/22 AS31733 94.250.208.0/22 AS31733 94.250.212.0/22 AS31733 94.250.216.0/22 AS31733 94.250.220.0/22 AS31733 94.250.224.0/22 AS31733 94.250.228.0/22 AS31733 94.250.232.0/22 AS31733 94.250.236.0/22 AS31733 94.250.240.0/22 AS31733 94.250.244.0/22 AS31733 94.250.248.0/22 AS31733 94.250.252.0/22 AS31733 98.159.96.0/20 AS46975 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.136.17.0/24 AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.14.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.15.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 172.223.60.0/22 AS6910 DIALTELECOMRO Dial Telecom S.R.L. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/21 AS14754 Telgua 200.106.128.0/20 AS3257 TINET-BACKBONE Tinet SpA 200.115.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.202.0/24 AS8513 SKYVISION SkyVision Global Networks Ltd 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mohta at necom830.hpcl.titech.ac.jp Fri Jun 22 18:29:11 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 23 Jun 2012 08:29:11 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> <4FE3D888.204@necom830.hpcl.titech.ac.jp> <09D57D42-2EF5-4330-9679-BBA57D0E1BFA@delong.com> <4FE4692B.50101@necom830.hpcl.titech.ac.jp> Message-ID: <4FE4FFC7.9070006@necom830.hpcl.titech.ac.jp> TJ wrote: >>> The center part of the internet is the easiest part of >>> modification for IPv6 and is probably somewhere near 99% >>> complete at this point. > Am I saying we are all done, and that IPv6 is fully deployed? Of course > not, lots of work to do in the enterprise and last-mile areas ... but > progress has been noticeable and is accelerating. Owen tried to deny my point that: : Moreover, it is easy to have a transport protocol with : 32bit or 48bit port numbers with the end to end fashion : only by modifying end part of the Internet. As "the enterprise and last-mile areas" do not need to be modified to accommodate a new transport protocol, they belong to the center part. Even though it may be easy to make end systems and local LANs v6 capable, rest, the center part, of the Internet keep causing problems. Masataka Ohta From owen at delong.com Fri Jun 22 20:08:37 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 22 Jun 2012 18:08:37 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE4FFC7.9070006@necom830.hpcl.titech.ac.jp> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> <4FE3D888.204@necom830.hpcl.titech.ac.jp> <09D57D42-2EF5-4330-9679-BBA57D0E1BFA@delong.com> <4FE4692B.50101@necom830.hpcl.titech.ac.jp> <4FE4FFC7.9070006@necom830.hpcl.titech.ac.jp> Message-ID: > > Even though it may be easy to make end systems and local > LANs v6 capable, rest, the center part, of the Internet > keep causing problems. > > Masataka Ohta Those problems are getting solved more and more every day. The rate of IPv6 deployment is rapidly accelerating at this point. QED, your statement does not stand up to current events. Owen From mohta at necom830.hpcl.titech.ac.jp Fri Jun 22 20:15:27 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 23 Jun 2012 10:15:27 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> <4FE3D888.204@necom830.hpcl.titech.ac.jp> <09D57D42-2EF5-4330-9679-BBA57D0E1BFA@delong.com> <4FE4692B.50101@necom830.hpcl.titech.ac.jp> <4FE4FFC7.9070006@necom830.hpcl.titech.ac.jp> Message-ID: <4FE518AF.2090703@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: >> Even though it may be easy to make end systems and local >> LANs v6 capable, rest, the center part, of the Internet >> keep causing problems. > Those problems are getting solved more and more every day. > > The rate of IPv6 deployment is rapidly accelerating at this point. Remember that you wrote: >>> The center part of the internet is the easiest part of >>> modification for IPv6 and is probably somewhere near 99% >>> complete at this point. What do you mean something 99% complete is rapidly accelerating? Is it a theory for time traveling? Masataka Ohta From owen at delong.com Fri Jun 22 20:24:12 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 22 Jun 2012 18:24:12 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE518AF.2090703@necom830.hpcl.titech.ac.jp> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> <4FE3D888.204@necom830.hpcl.titech.ac.jp> <09D57D42-2EF5-4330-9679-BBA57D0E1BFA@delong.com> <4FE4692B.50101@necom830.hpcl.titech.ac.jp> <4FE4FFC7.9070006@necom830.hpcl.titech.ac.jp> <4FE518AF.2090703@necom830.hpcl.titech.ac.jp> Message-ID: <48C66FE1-27BD-45DC-BC5F-548334816073@delong.com> On Jun 22, 2012, at 6:15 PM, Masataka Ohta wrote: > Owen DeLong wrote: > >>> Even though it may be easy to make end systems and local >>> LANs v6 capable, rest, the center part, of the Internet >>> keep causing problems. > >> Those problems are getting solved more and more every day. >> >> The rate of IPv6 deployment is rapidly accelerating at this point. > > Remember that you wrote: > >>>> The center part of the internet is the easiest part of >>>> modification for IPv6 and is probably somewhere near 99% >>>> complete at this point. > > What do you mean something 99% complete is rapidly accelerating? > > Is it a theory for time traveling? You redefined center. My definition of center when I claimed 99% was the major backbones and core routers. That is the CENTER of the internet. Different definition of center (yours) where the center includes everything except the edge-most hosts, different metrics for completion and challenges. Owen From trejrco at gmail.com Fri Jun 22 20:35:22 2012 From: trejrco at gmail.com (TJ) Date: Fri, 22 Jun 2012 21:35:22 -0400 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE518AF.2090703@necom830.hpcl.titech.ac.jp> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> <4FE3D888.204@necom830.hpcl.titech.ac.jp> <09D57D42-2EF5-4330-9679-BBA57D0E1BFA@delong.com> <4FE4692B.50101@necom830.hpcl.titech.ac.jp> <4FE4FFC7.9070006@necom830.hpcl.titech.ac.jp> <4FE518AF.2090703@necom830.hpcl.titech.ac.jp> Message-ID: > >>> The center part of the internet is the easiest part of > >>> modification for IPv6 and is probably somewhere near 99% > >>> complete at this point. > > What do you mean something 99% complete is rapidly accelerating? > > Is it a theory for time traveling? Rate of deployment is more inclusive than just the 'center', that would be my guess. Are we really taking this already nearly-pointless conversation to an all new low and arguing semantics? Clearly some of us disagree with each other, perhaps we just hold our tongues (& fingers) and let the real world decide?? /TJ From astrodog at gmx.com Fri Jun 22 21:01:50 2012 From: astrodog at gmx.com (Astrodog) Date: Fri, 22 Jun 2012 21:01:50 -0500 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> <4FE3D888.204@necom830.hpcl.titech.ac.jp> <09D57D42-2EF5-4330-9679-BBA57D0E1BFA@delong.com> <4FE4692B.50101@necom830.hpcl.titech.ac.jp> <4FE4FFC7.9070006@necom830.hpcl.titech.ac.jp> <4FE518AF.2090703@necom830.hpcl.titech.ac.jp> Message-ID: <4FE5238E.6040308@gmx.com> On 06/22/2012 08:35 PM, TJ wrote: >>>>> The center part of the internet is the easiest part of >>>>> modification for IPv6 and is probably somewhere near 99% >>>>> complete at this point. >> What do you mean something 99% complete is rapidly accelerating? >> >> Is it a theory for time traveling? > Rate of deployment is more inclusive than just the 'center', that would be > my guess. > > Are we really taking this already nearly-pointless conversation to an all > new low and arguing semantics? > > Clearly some of us disagree with each other, perhaps we just hold our > tongues (& fingers) and let the real world decide?? > > /TJ There might be good money in a PPV "cagematch"-style event. From mohta at necom830.hpcl.titech.ac.jp Fri Jun 22 21:20:40 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 23 Jun 2012 11:20:40 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <74E64BA7-9E18-4F2B-9661-3250093CC5E1@delong.com> <4FE3D888.204@necom830.hpcl.titech.ac.jp> <09D57D42-2EF5-4330-9679-BBA57D0E1BFA@delong.com> <4FE4692B.50101@necom830.hpcl.titech.ac.jp> <4FE4FFC7.9070006@necom830.hpcl.titech.ac.jp> <4FE518AF.2090703@necom830.hpcl.titech.ac.jp> Message-ID: <4FE527F8.5090805@necom830.hpcl.titech.ac.jp> (2012/06/23 10:35), TJ wrote: > Rate of deployment is more inclusive than just the 'center', that would be > my guess. But, the context, as you can see, is this: :> Even though it may be easy to make end systems and local :> LANs v6 capable, rest, the center part, of the Internet :> keep causing problems. :> :> Masataka Ohta : : Those problems are getting solved more and more every day. that the problems are caused by the center part. Masataka Ohta From streiner at cluebyfour.org Fri Jun 22 23:49:03 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 23 Jun 2012 00:49:03 -0400 (EDT) Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> Message-ID: On Fri, 22 Jun 2012, Masataka Ohta wrote: > Unlike IPv4 with natural boundary of /24, routing table > explosion of IPv6 is a serious scalability problem. I really don't see where you're getting that from. The biggest consumers of IPv4 space in the US tended to get initial IPv6 blocks from ARIN that were large enough to accommodate their needs for some time. One large v6 prefix in the global routing table is more efficient in terms of the impact on the global routing table than the patchwork of IPv4 blocks those same providers needed to get over time to accommodate growth. Those 'green-field' deployments of IPv6, coupled with the sparse allocation model that the RIRs seem to be using will do a lot to keep v6 routing table growth in check. I see periodic upticks in the growth of the global v6 routing table (a little over 9k prefixes at the moment - the v4 global view is about 415k prefixes right now), which I would reasonably attribute an upswing in networks getting initial assignments. If anything, I see more of a chance for the v4 routing table to grow more out of control, as v4 blocks get chopped up into smaller and smaller pieces in an ultimately vain effort to squeeze a little more mileage out of IPv4. jms From garret at picchioni.org Sat Jun 23 11:38:12 2012 From: garret at picchioni.org (Garret Picchioni) Date: Sat, 23 Jun 2012 12:38:12 -0400 Subject: Cogent DNS Contact Message-ID: Hi All, If anyone has a contact at Cogent, who might be able to solve a reverse DNS issue, could they contact me offline? Thanks! Garret From lists at mtin.net Sat Jun 23 11:42:13 2012 From: lists at mtin.net (Justin Wilson) Date: Sat, 23 Jun 2012 12:42:13 -0400 Subject: Cogent DNS Contact In-Reply-To: Message-ID: I have always had excellent response if you open up a ticket with their helpdesk. Cogent helpdesk has solved some rather complex issues so I would try there first. Justin -- Justin Wilson Aol & Yahoo IM: j2sw http://www.mtin.net/blog ? xISP News http://www.twitter.com/j2sw ? Follow me on Twitter -----Original Message----- From: Garret Picchioni Date: Saturday, June 23, 2012 12:38 PM To: Subject: Cogent DNS Contact >Hi All, >If anyone has a contact at Cogent, who might be able to solve a reverse >DNS issue, could they contact me offline? > >Thanks! >Garret From tdurack at gmail.com Sat Jun 23 17:38:56 2012 From: tdurack at gmail.com (Tim Durack) Date: Sat, 23 Jun 2012 18:38:56 -0400 Subject: NYC to DEU packet loss In-Reply-To: References: Message-ID: As suspected, this ended up being an XO/DTAG peering issue. Took a long time to get sorted out, but thanks to any and all who assisted! Tim:> On Fri, May 4, 2012 at 12:01 PM, Tim Durack wrote: > Trying to troubleshoot packet loss from NYC to DEU. Traceroute shows: > > tdurack at 2ua82715mg:~$ traceroute -I 194.25.250.73 > traceroute to 194.25.250.73 (194.25.250.73), 30 hops max, 60 byte packets > -- Tim:> From kmedcalf at dessus.com Sat Jun 23 19:52:10 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 23 Jun 2012 18:52:10 -0600 Subject: LinkedIn password database compromised In-Reply-To: <20120620213914.GA20633@ussenterprise.ufp.org> Message-ID: <2bce6257d310384a9e0cd3b5bf71e3f3@mail.dessus.com> Leo, This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user. Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage. If it does not use self-generated unsigned keys, it will never fly. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > -----Original Message----- > From: Leo Bicknell [mailto:bicknell at ufp.org] > Sent: Wednesday, 20 June, 2012 15:39 > To: nanog at nanog.org > Subject: 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 - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From kmedcalf at dessus.com Sat Jun 23 20:14:31 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 23 Jun 2012 19:14:31 -0600 Subject: LinkedIn password database compromised In-Reply-To: <20120621125606.GA3760@gsp.org> Message-ID: <8e36f7431646a04c831b2e1b6e02c6a5@mail.dessus.com> > 2. Pre-compromised-at-the-factory smartphones and similar. There's > no reason why these can't be preloaded with spyware similar to CarrierIQ > and directed to upload all newly-created private keys to a central > collection point. This can be done, therefore it will be done, and when > some security researcher discovers it, the usual excuses and justifications > will be made by the designated spokesliars for the companies involved... > which will of course keep right on doing it, albeit perhaps with more > subterfuge. > Problem #2 is newer, but I'm willing to bet that it will also last > at least a decade and that it will get worse, since there are > substantial economic incentives to make it so. This doesn't only apply to "SmartPhones". The most widely used Operating System (by this I mean Windows) has been issued pre-compromised and has "intentionally implanted compromise via Vendor Update" for many years. It is only unethical when a non-American does it. The excuses and justifications are no different. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From mike at mtcc.com Sat Jun 23 21:09:32 2012 From: mike at mtcc.com (Michael Thomas) Date: Sat, 23 Jun 2012 19:09:32 -0700 Subject: LinkedIn password database compromised In-Reply-To: <2bce6257d310384a9e0cd3b5bf71e3f3@mail.dessus.com> References: <2bce6257d310384a9e0cd3b5bf71e3f3@mail.dessus.com> Message-ID: <4FE676DC.9000108@mtcc.com> On 06/23/2012 05:52 PM, Keith Medcalf wrote: > Leo, > > This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). What is their leverage to extort? A web site just needs to make the client and server end agree on a scheme, and they control both ends. They can't force me to use their scheme any more than they can force me to not use Basic and use their scheme instead. Keep in mind that asymmetric keys do not imply certification, and asymmetric keys are cheap and plentiful -- as in a modest amount of CPU time these days. Mike > You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user. > > Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage. > > If it does not use self-generated unsigned keys, it will never fly. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > >> -----Original Message----- >> From: Leo Bicknell [mailto:bicknell at ufp.org] >> Sent: Wednesday, 20 June, 2012 15:39 >> To: nanog at nanog.org >> Subject: 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 - bicknell at ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ > > From kyle.creyts at gmail.com Sun Jun 24 00:02:25 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Sat, 23 Jun 2012 22:02:25 -0700 Subject: How to fix authentication (was LinkedIn) In-Reply-To: <20120622142529.GA96023@ussenterprise.ufp.org> References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> <201206211324.12502.alexander.harrowell@stlpartners.com> <4FE348B8.4070109@armoredpackets.com> <3977CF28-0FA6-4EEF-8D38-C446D3E3FA93@bjencks.net> <20120622142529.GA96023@ussenterprise.ufp.org> Message-ID: I would suggest that multiple models be pursued (since each appears to have a champion) and that the market/drafting process will resolve the issue of which is better (which is okay by me: widespread adoption of any of the proposed models would advance the state of the norm; progress beats the snot out of stagnation in my book) My earlier replies were reprehensible. This is not a thread that should just be laughed off. Real progress may be occurring here, and at the least, good knowledge and discussion is accumulating in a way which may serve as a resource for the curious or concerned. On Jun 22, 2012 7:25 AM, "Leo Bicknell" wrote: > In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush > wrote: > > there are no trustable third parties > > With a lot of transactions the second party isn't trustable, and > sometimes the first party isn't as well. :) > > In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher > Morrow wrote: > > note that yubico has models of auth that include: > > 1) using a third party > > 2) making your own party > > 3) HOTP on token > > 4) NFC > > > > they are a good company, trying to do the right thing(s)... They also > > don't necessarily want you to be stuck in the 'get your answer from > > another' > > Requirements of hardware or a third party are fine for the corporate > world, or sites that make enough money or have enough risk to invest > in security, like a bank. > > Requiring hardware for a site like Facebook or Twitter is right > out. Does not scale, can't ship to the guy in Pakistan or McMurdo > who wants to sign up. Trusting a third party becomes too expensive, > and too big of a business risk. > > There are levels of security here. I don't expect Facebook to take > the same security steps as my bank to move my money around. One > size does not fit all. Making it so a hacker can't get 10 million > login credentials at once is a quantum leap forward even if doing > so doesn't improve security in any other way. > > The perfect is the enemy of the good. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > From james at smithwaysecurity.com Sun Jun 24 22:41:26 2012 From: james at smithwaysecurity.com (James Smith) Date: Mon, 25 Jun 2012 00:41:26 -0300 Subject: EULAs Message-ID: <4FE7DDE6.7070606@smithwaysecurity.com> Hello, I was wondering if some one could contact me with regards to ISP's who share data to private companies if stated in their EULAs . -- Sincerely; James Smith CEO, Security Analyst From mohta at necom830.hpcl.titech.ac.jp Mon Jun 25 02:06:50 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 25 Jun 2012 16:06:50 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> Message-ID: <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> Justin M. Streiner wrote: > I see periodic upticks in the growth of the global v6 routing table (a > little over 9k prefixes at the moment - the v4 global view is about 415k > prefixes right now), which I would reasonably attribute an upswing in > networks getting initial assignments. As I already wrote: : That's not the point. The problem is that SRAMs scale well but : CAMs do not. it is a lot more difficult to quickly look up 1M routes with /48 than 2M routes with /24. > If anything, I see more of a > chance for the v4 routing table to grow more out of control, as v4 > blocks get chopped up into smaller and smaller pieces in an ultimately > vain effort to squeeze a little more mileage out of IPv4. The routing table grows mostly because of multihoming, regardless of whether it is v4 or v6. The only solution is, IMO, to let multihomed sites have multiple prefixes inherited from their upper ISPs, still keeping the sites' ability to control loads between incoming multiple links. Masataka Ohta From tim at pelican.org Mon Jun 25 04:00:16 2012 From: tim at pelican.org (Tim Franklin) Date: Mon, 25 Jun 2012 10:00:16 +0100 (BST) Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE4FFC7.9070006@necom830.hpcl.titech.ac.jp> Message-ID: > Even though it may be easy to make end systems and local > LANs v6 capable, rest, the center part, of the Internet > keep causing problems. Really? My impression is that it's very much the edge that's hard - CE routers, and in particular cheap, nasty, residential DSL and cable CE routers. Lots of existing kit out there that can't do v6, and the business case for a fork-lift upgrade just doesn't stack up. It's a cost issue, though, not a technology one - it's perfectly possible to deliver v6 over these technologies. Tunnelling, while not ideal, is certainly a workable stop-gap, and I'm *very* happy to have real, globally uniquely addressed end-to-end Internet in my house again as a result. Systems can be a problem too - both in convincing IS people to change things, in getting the budget for changes, and in finding all the dark places hidden in the organisation where v4 assumptions are made. But in the Internet core? I don't see any huge obstacles at $ISP_DAYJOB, with any of the people I know in the industry, or with the ISPs I do business with. For co-lo, VPS, leased lines, real Ethernet tails, v6 connectivity is being delivered and working fine today. Regards, Tim. From tim at pelican.org Mon Jun 25 04:04:29 2012 From: tim at pelican.org (Tim Franklin) Date: Mon, 25 Jun 2012 10:04:29 +0100 (BST) Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> Message-ID: > The only solution is, IMO, to let multihomed sites have > multiple prefixes inherited from their upper ISPs, still > keeping the sites' ability to control loads between incoming > multiple links. And for the basement multi-homers, RA / SLAAC makes this much easier to do with v6. The larger-scale / more mission-critical multi-homers are going to consume an AS and some BGP space whether you like it or not - at least with v6 there's a really good chance that they'll only *ever* need to announce a single-prefix. (Ignore "traffic engineering" pollution, but that doesn't get better or worse). Regards, Tim. From nanog at armoredpackets.com Mon Jun 25 08:30:02 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Mon, 25 Jun 2012 09:30:02 -0400 Subject: How to fix authentication (was LinkedIn) In-Reply-To: References: <20120620194344.GA16763@ussenterprise.ufp.org> <32087489.10264.1340234805345.JavaMail.root@benjamin.baylink.com> <201206211324.12502.alexander.harrowell@stlpartners.com> <4FE348B8.4070109@armoredpackets.com> <3977CF28-0FA6-4EEF-8D38-C446D3E3FA93@bjencks.net> <20120622142529.GA96023@ussenterprise.ufp.org> Message-ID: <4FE867DA.8050400@armoredpackets.com> Kyle, I may be mistaken here, but I don't believe anyone is truly laughing the matter off. There may have been some remarks about second or third parties, but the fact does remain these are the areas which current concerns still lay. -- Robert Miller (arch3angel) On 6/24/12 1:02 AM, Kyle Creyts wrote: > I would suggest that multiple models be pursued (since each appears to have > a champion) and that the market/drafting process will resolve the issue of > which is better (which is okay by me: widespread adoption of any of the > proposed models would advance the state of the norm; progress beats the > snot out of stagnation in my book) > > My earlier replies were reprehensible. This is not a thread that should > just be laughed off. Real progress may be occurring here, and at the least, > good knowledge and discussion is accumulating in a way which may serve as a > resource for the curious or concerned. > On Jun 22, 2012 7:25 AM, "Leo Bicknell" wrote: > >> In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush >> wrote: >>> there are no trustable third parties >> With a lot of transactions the second party isn't trustable, and >> sometimes the first party isn't as well. :) >> >> In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher >> Morrow wrote: >>> note that yubico has models of auth that include: >>> 1) using a third party >>> 2) making your own party >>> 3) HOTP on token >>> 4) NFC >>> >>> they are a good company, trying to do the right thing(s)... They also >>> don't necessarily want you to be stuck in the 'get your answer from >>> another' >> Requirements of hardware or a third party are fine for the corporate >> world, or sites that make enough money or have enough risk to invest >> in security, like a bank. >> >> Requiring hardware for a site like Facebook or Twitter is right >> out. Does not scale, can't ship to the guy in Pakistan or McMurdo >> who wants to sign up. Trusting a third party becomes too expensive, >> and too big of a business risk. >> >> There are levels of security here. I don't expect Facebook to take >> the same security steps as my bank to move my money around. One >> size does not fit all. Making it so a hacker can't get 10 million >> login credentials at once is a quantum leap forward even if doing >> so doesn't improve security in any other way. >> >> The perfect is the enemy of the good. >> >> -- >> Leo Bicknell - bicknell at ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ >> From mohta at necom830.hpcl.titech.ac.jp Mon Jun 25 09:09:22 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 25 Jun 2012 23:09:22 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: Message-ID: <4FE87112.3010307@necom830.hpcl.titech.ac.jp> (2012/06/25 18:00), Tim Franklin wrote: >> Even though it may be easy to make end systems and local >> LANs v6 capable, rest, the center part, of the Internet >> keep causing problems. > > Really? My impression is that it's very much the edge > that's hard - CE routers, and in particular cheap, nasty, > residential DSL and cable CE routers. Are you saying they are "end systems and local LANs"? Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Mon Jun 25 09:19:28 2012 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 25 Jun 2012 23:19:28 +0900 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: References: Message-ID: <4FE87370.7040305@necom830.hpcl.titech.ac.jp> Tim Franklin wrote: > at least with v6 there's a really good chance that they'll > only *ever* need to announce a single-prefix. That's exactly why routing table is exploding today, at least with v4. Masataka Ohta From owen at delong.com Mon Jun 25 09:54:32 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Jun 2012 07:54:32 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> Message-ID: On Jun 25, 2012, at 12:06 AM, Masataka Ohta wrote: > Justin M. Streiner wrote: > >> I see periodic upticks in the growth of the global v6 routing table (a >> little over 9k prefixes at the moment - the v4 global view is about 415k >> prefixes right now), which I would reasonably attribute an upswing in >> networks getting initial assignments. > > As I already wrote: > > : That's not the point. The problem is that SRAMs scale well but > : CAMs do not. > > it is a lot more difficult to quickly look up 1M routes > with /48 than 2M routes with /24. > It is incrementally more difficult, but not a lot at this point. Further, 2M routes in IPv4 at the current prefix:ASN ratios would only map to about 100,000 routes in IPv6. (IPv6 prefix:AS ratio is currently about 3:1 while IPv4 is around 14:1, so if all 35,000 active AS were advertising 3 IPv6 routes, we would be at about 100,000. Most of the growth in the IPv4 routing table represents increases in the prefix:ASN ratio whereas most of the growth in the IPv6 routing table represents additional ASNs coming online with IPv6.) >> If anything, I see more of a >> chance for the v4 routing table to grow more out of control, as v4 >> blocks get chopped up into smaller and smaller pieces in an ultimately >> vain effort to squeeze a little more mileage out of IPv4. > > The routing table grows mostly because of multihoming, > regardless of whether it is v4 or v6. > Assertion proved false by actual data. The majority of the growth in the IPv4 routing table is actually due to disaggregation and slow start. A smaller proportion is due to traffic engineering and multihoming. (See Geoff Huston's various presentations and white papers on this). > The only solution is, IMO, to let multihomed sites have > multiple prefixes inherited from their upper ISPs, still > keeping the sites' ability to control loads between incoming > multiple links. This is not a solution. This is an administrative nightmare for the multihomed sites which has very poor failure survival characteristics. 1. Established flows do not survive a failover. 2. Every end host has to have knowledge of reachability which is not readily available in order to make a proper source address selection. The solution, in fact, is to move IDR to being locator based while intra-domain routing is done on prefix. This would allow the global table to only contain locator information and not care about prefixes. Currently, in order to do that, we unfortunately have to wrap the entire datagram up inside another datagram. If we were to create a version of the IPv6 header that had a field for destination ASN, we could do this without encapsulation. Unfortunately, encapsulation brings all the MTU baggage of tunneling. More unfortunately, changing the header comes with the need to touch the IP stack on every end host. Neither is an attractive option. It would have been better if IETF had actually solved this instead of punting on it when developing IPv6. Owen From owen at delong.com Mon Jun 25 09:57:36 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Jun 2012 07:57:36 -0700 Subject: IPv6 /64 links (was Re: ipv6 book recommendations?) In-Reply-To: <4FE87112.3010307@necom830.hpcl.titech.ac.jp> References: <4FE87112.3010307@necom830.hpcl.titech.ac.jp> Message-ID: <27AE553A-3058-4F17-A52B-EEF03E4EB52A@delong.com> On Jun 25, 2012, at 7:09 AM, Masataka Ohta wrote: > (2012/06/25 18:00), Tim Franklin wrote: >>> Even though it may be easy to make end systems and local >>> LANs v6 capable, rest, the center part, of the Internet >>> keep causing problems. >> >> Really? My impression is that it's very much the edge >> that's hard - CE routers, and in particular cheap, nasty, >> residential DSL and cable CE routers. > > Are you saying they are "end systems and local LANs"? > > Masataka Ohta Yes... Most people think of everything off the ISP network as "Edge". So from the CPE outward, is the Edge to most people's thinking. Your definition of center vs. edge is misplaced compared to everyone else. This is what created the confusion between us when I first said 99% of the center was already IPv6 -- If you don't count CPE outwards as part of the center, then that is a valid statement. If you count the CPE, etc. as center and only count the very end host as edge, then, my other statement (that IPv6 deployment in this area is accelerating) is true. Owen From dotis at mail-abuse.org Mon Jun 25 12:09:11 2012 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 25 Jun 2012 10:09:11 -0700 Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> Message-ID: <4FE89B37.4030905@mail-abuse.org> On 6/25/12 7:54 AM, Owen DeLong wrote: > It would have been better if IETF had actually solved this instead > of punting on it when developing IPv6. Dear Owen, The IETF offered a HA solution that operates at the transport level. It solves jumbo frame error detection rate issues, head of queue blocking, instant fail-over, better supports high data rates with lower overhead, offers multi-homing transparently across multiple providers, offers fast setup and anti-packet source spoofing. The transport is SCTP, used by every cellular tower and for media distribution. This transport's improved error detection is now supported in hardware by current network adapters and processors. Conversely, TCP suffers from high undetected stuck bit errors, head of queue blocking, complex multi-homing, slow setup, high process overhead and is prone to source spoofing. It seems OS vendors rather than the IETF hampered progress in this area. Why band-aid on a solved problem? Regards, Douglas Otis From morrowc.lists at gmail.com Mon Jun 25 12:17:24 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 25 Jun 2012 13:17:24 -0400 Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: <4FE89B37.4030905@mail-abuse.org> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> <4FE89B37.4030905@mail-abuse.org> Message-ID: On Mon, Jun 25, 2012 at 1:09 PM, Douglas Otis wrote: > On 6/25/12 7:54 AM, Owen DeLong wrote: >> It would have been better if IETF had actually solved this instead >> of punting on it when developing IPv6. > > Dear Owen, > > The IETF offered a HA solution that operates at the transport level. ?It > solves jumbo frame error detection rate issues, head of queue > blocking, instant fail-over, better supports high data rates with > lower overhead, offers multi-homing transparently across > multiple providers, offers fast setup and anti-packet source spoofing. > The transport is SCTP, used by every cellular tower and for > media distribution. > > This transport's improved error detection is now supported in hardware > by current network adapters and processors. ?Conversely, TCP suffers > from high undetected stuck bit errors, head of queue blocking, complex > multi-homing, slow setup, high process overhead and is prone to source > spoofing. ?It seems OS vendors rather than the IETF hampered progress in > this area. ?Why band-aid on a solved problem? can I use sctp to do the facebooks? From dotis at mail-abuse.org Mon Jun 25 12:58:08 2012 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 25 Jun 2012 10:58:08 -0700 Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> <4FE89B37.4030905@mail-abuse.org> Message-ID: <4FE8A6B0.6010408@mail-abuse.org> On 6/25/12 10:17 AM, Christopher Morrow wrote: > On Mon, Jun 25, 2012 at 1:09 PM, Douglas Otis > wrote: >> On 6/25/12 7:54 AM, Owen DeLong wrote: >>> It would have been better if IETF had actually solved this >>> instead of punting on it when developing IPv6. >> >> Dear Owen, >> >> The IETF offered a HA solution that operates at the transport >> level. It solves jumbo frame error detection rate issues, head >> of queue blocking, instant fail-over, better supports high data >> rates with lower overhead, offers multi-homing transparently >> across multiple providers, offers fast setup and anti-packet >> source spoofing. The transport is SCTP, used by every cellular >> tower and for media distribution. >> >> This transport's improved error detection is now supported in >> hardware by current network adapters and processors. Conversely, >> TCP suffers from high undetected stuck bit errors, head of queue >> blocking, complex multi-homing, slow setup, high process overhead >> and is prone to source spoofing. It seems OS vendors rather than >> the IETF hampered progress in this area. Why band-aid on a >> solved problem? > > can I use sctp to do the facebooks? Dear Christopher, Not now, but you could. SCTP permits faster page loads and more efficient use of bandwidth. OS vendors could embrace SCTP to achieve safer and faster networks also better able to scale. Instead, vendors are hacking HTTP to provide experimental protocols like SPDY which requires extensions like: http://tools.ietf.org/search/draft-agl-tls-nextprotoneg-00 The Internet should use more than port 80 and port 443. Is extending entrenched TCP cruft really taking the Internet to a better and safer place? Regards, Douglas Otis From morrowc.lists at gmail.com Mon Jun 25 13:26:14 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 25 Jun 2012 14:26:14 -0400 Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: <4FE8A6B0.6010408@mail-abuse.org> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> <4FE89B37.4030905@mail-abuse.org> <4FE8A6B0.6010408@mail-abuse.org> Message-ID: On Mon, Jun 25, 2012 at 1:58 PM, Douglas Otis wrote: > The Internet should use more than port 80 and port 443. ?Is extending > entrenched TCP cruft really taking the Internet to a better and safer > place? isn't the 'internet should use more than 80/443' really: "Some compelling use case should be found for more than 2 ports" ? Or perhaps more clearly: "What application is written that is getting wide appeal and uses more than 80/443?" (aside from edonkey which Arbor always shows as a huge user of bandwidth) -chris (btw, it would be nice to use more ports, if there are applications and users of said applications that want to do that...) From spaceradio123 at yahoo.com Mon Jun 25 14:18:50 2012 From: spaceradio123 at yahoo.com (Gregg) Date: Mon, 25 Jun 2012 13:18:50 -0600 Subject: NANOG Digest, Vol 53, Issue 105 In-Reply-To: References: Message-ID: <5A057B36-4152-4243-BCFC-9EDA97A9D2D5@yahoo.com> It really is possible to have a secure society that does not require identification and authentication at every turn and for every move. We the people will have to demand such freedom in order that it come to pass, however, because it is at odds with what money and power want. And where those go, sex follows. So, you could say, we have ourselves in a bit of a bind at the moment. Gregg Squires Consultant Unimatics, Inc NV Sent from my mobile fruit device. On Jun 25, 2012, at 7:30 AM, nanog-request at nanog.org wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. RE: LinkedIn password database compromised (Keith Medcalf) > 2. RE: LinkedIn password database compromised (Keith Medcalf) > 3. Re: LinkedIn password database compromised (Michael Thomas) > 4. Re: How to fix authentication (was LinkedIn) (Kyle Creyts) > 5. EULAs (James Smith) > 6. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > (Masataka Ohta) > 7. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > (Tim Franklin) > 8. Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > (Tim Franklin) > 9. Re: How to fix authentication (was LinkedIn) (AP NANOG) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 23 Jun 2012 18:52:10 -0600 > From: "Keith Medcalf" > To: "Leo Bicknell" > Cc: "nanog at nanog.org" > Subject: RE: LinkedIn password database compromised > Message-ID: <2bce6257d310384a9e0cd3b5bf71e3f3 at mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > Leo, > > This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user. > > Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage. > > If it does not use self-generated unsigned keys, it will never fly. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > >> -----Original Message----- >> From: Leo Bicknell [mailto:bicknell at ufp.org] >> Sent: Wednesday, 20 June, 2012 15:39 >> To: nanog at nanog.org >> Subject: 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 - bicknell at ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ > > > > > > > ------------------------------ > > Message: 2 > Date: Sat, 23 Jun 2012 19:14:31 -0600 > From: "Keith Medcalf" > To: "Rich Kulawiec" > Cc: "nanog at nanog.org" > Subject: RE: LinkedIn password database compromised > Message-ID: <8e36f7431646a04c831b2e1b6e02c6a5 at mail.dessus.com> > Content-Type: text/plain; charset="us-ascii" > > >> 2. Pre-compromised-at-the-factory smartphones and similar. There's >> no reason why these can't be preloaded with spyware similar to CarrierIQ >> and directed to upload all newly-created private keys to a central >> collection point. This can be done, therefore it will be done, and when >> some security researcher discovers it, the usual excuses and justifications >> will be made by the designated spokesliars for the companies involved... >> which will of course keep right on doing it, albeit perhaps with more >> subterfuge. > >> Problem #2 is newer, but I'm willing to bet that it will also last >> at least a decade and that it will get worse, since there are >> substantial economic incentives to make it so. > > This doesn't only apply to "SmartPhones". The most widely used Operating System (by this I mean Windows) has been issued pre-compromised and has "intentionally implanted compromise via Vendor Update" for many years. It is only unethical when a non-American does it. The excuses and justifications are no different. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > > > > > > ------------------------------ > > Message: 3 > Date: Sat, 23 Jun 2012 19:09:32 -0700 > From: Michael Thomas > To: Keith Medcalf > Cc: "nanog at nanog.org" > Subject: Re: LinkedIn password database compromised > Message-ID: <4FE676DC.9000108 at mtcc.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 06/23/2012 05:52 PM, Keith Medcalf wrote: >> Leo, >> >> This will never work. The "vested profiteers" will all get together and make it a condition that in order to use this method the user has to have "purchased" a "verified" key from them. Every site will use different profiteers (probably whoever gives them the biggest kickback). > > What is their leverage to extort? A web site just needs to make the > client and server end agree on a scheme, and they control both ends. > They can't force me to use their scheme any more than they can force > me to not use Basic and use their scheme instead. Keep in mind that > asymmetric keys do not imply certification, and asymmetric keys are > cheap and plentiful -- as in a modest amount of CPU time these days. > > Mike > >> You will end up paying thousands of dollars a year (as a user) to buy multiple keys from the profiteers, and provide them all sorts of private information in the process. They will then also insist that web sites using this method provide "tracking" information on key usage back to the profiteers. The profiteers will then sell all this information to whomever they want, for whatever purpose, so long as it results in a profit. Some of this will get kicked back to participating web sites. Then there will be "affiliate programs" where any web site can "sign up" with the profiteers to "silently" do key exchanges without the users consent so that more tracking information can be collected, for which the participating affiliate web site will get a kickback. Browser vendors will "assist" by making the whole process transparent. Contracts in restraint of trade will be enforced by the profiteers to prevent any browser from using the "method" unless it is completely invisible to the user. >> >> Then (in the US) the fascist government will step in and require "registration" of issued keys along with the verified real-world identity linkage. >> >> If it does not use self-generated unsigned keys, it will never fly. >> >> --- >> () ascii ribbon campaign against html e-mail >> /\ www.asciiribbon.org >> >> >>> -----Original Message----- >>> From: Leo Bicknell [mailto:bicknell at ufp.org] >>> Sent: Wednesday, 20 June, 2012 15:39 >>> To: nanog at nanog.org >>> Subject: 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 - bicknell at ufp.org - CCIE 3440 >>> PGP keys at http://www.ufp.org/~bicknell/ >> >> > > > > > > > ------------------------------ > > Message: 4 > Date: Sat, 23 Jun 2012 22:02:25 -0700 > From: Kyle Creyts > To: nanog at nanog.org > Subject: Re: How to fix authentication (was LinkedIn) > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > I would suggest that multiple models be pursued (since each appears to have > a champion) and that the market/drafting process will resolve the issue of > which is better (which is okay by me: widespread adoption of any of the > proposed models would advance the state of the norm; progress beats the > snot out of stagnation in my book) > > My earlier replies were reprehensible. This is not a thread that should > just be laughed off. Real progress may be occurring here, and at the least, > good knowledge and discussion is accumulating in a way which may serve as a > resource for the curious or concerned. > On Jun 22, 2012 7:25 AM, "Leo Bicknell" wrote: > >> In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush >> wrote: >>> there are no trustable third parties >> >> With a lot of transactions the second party isn't trustable, and >> sometimes the first party isn't as well. :) >> >> In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher >> Morrow wrote: >>> note that yubico has models of auth that include: >>> 1) using a third party >>> 2) making your own party >>> 3) HOTP on token >>> 4) NFC >>> >>> they are a good company, trying to do the right thing(s)... They also >>> don't necessarily want you to be stuck in the 'get your answer from >>> another' >> >> Requirements of hardware or a third party are fine for the corporate >> world, or sites that make enough money or have enough risk to invest >> in security, like a bank. >> >> Requiring hardware for a site like Facebook or Twitter is right >> out. Does not scale, can't ship to the guy in Pakistan or McMurdo >> who wants to sign up. Trusting a third party becomes too expensive, >> and too big of a business risk. >> >> There are levels of security here. I don't expect Facebook to take >> the same security steps as my bank to move my money around. One >> size does not fit all. Making it so a hacker can't get 10 million >> login credentials at once is a quantum leap forward even if doing >> so doesn't improve security in any other way. >> >> The perfect is the enemy of the good. >> >> -- >> Leo Bicknell - bicknell at ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ >> > > > ------------------------------ > > Message: 5 > Date: Mon, 25 Jun 2012 00:41:26 -0300 > From: James Smith > To: "nanog at nanog.org" > Subject: EULAs > Message-ID: <4FE7DDE6.7070606 at smithwaysecurity.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, > > I was wondering if some one could contact me with regards to ISP's who > share data to private companies if stated in their EULAs . > > -- > Sincerely; > > > James Smith > CEO, Security Analyst > > > > ------------------------------ > > Message: 6 > Date: Mon, 25 Jun 2012 16:06:50 +0900 > From: Masataka Ohta > To: nanog at nanog.org > Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > Message-ID: <4FE80E0A.5020906 at necom830.hpcl.titech.ac.jp> > Content-Type: text/plain; charset=ISO-2022-JP > > Justin M. Streiner wrote: > >> I see periodic upticks in the growth of the global v6 routing table (a >> little over 9k prefixes at the moment - the v4 global view is about 415k >> prefixes right now), which I would reasonably attribute an upswing in >> networks getting initial assignments. > > As I already wrote: > > : That's not the point. The problem is that SRAMs scale well but > : CAMs do not. > > it is a lot more difficult to quickly look up 1M routes > with /48 than 2M routes with /24. > >> If anything, I see more of a >> chance for the v4 routing table to grow more out of control, as v4 >> blocks get chopped up into smaller and smaller pieces in an ultimately >> vain effort to squeeze a little more mileage out of IPv4. > > The routing table grows mostly because of multihoming, > regardless of whether it is v4 or v6. > > The only solution is, IMO, to let multihomed sites have > multiple prefixes inherited from their upper ISPs, still > keeping the sites' ability to control loads between incoming > multiple links. > > Masataka Ohta > > > > ------------------------------ > > Message: 7 > Date: Mon, 25 Jun 2012 10:00:16 +0100 (BST) > From: Tim Franklin > To: nanog at nanog.org > Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > Message-ID: > Content-Type: text/plain; charset=utf-8 > >> Even though it may be easy to make end systems and local >> LANs v6 capable, rest, the center part, of the Internet >> keep causing problems. > > Really? My impression is that it's very much the edge that's hard - CE routers, and in particular cheap, nasty, residential DSL and cable CE routers. Lots of existing kit out there that can't do v6, and the business case for a fork-lift upgrade just doesn't stack up. It's a cost issue, though, not a technology one - it's perfectly possible to deliver v6 over these technologies. Tunnelling, while not ideal, is certainly a workable stop-gap, and I'm *very* happy to have real, globally uniquely addressed end-to-end Internet in my house again as a result. > > Systems can be a problem too - both in convincing IS people to change things, in getting the budget for changes, and in finding all the dark places hidden in the organisation where v4 assumptions are made. > > But in the Internet core? I don't see any huge obstacles at $ISP_DAYJOB, with any of the people I know in the industry, or with the ISPs I do business with. For co-lo, VPS, leased lines, real Ethernet tails, v6 connectivity is being delivered and working fine today. > > Regards, > Tim. > > > > ------------------------------ > > Message: 8 > Date: Mon, 25 Jun 2012 10:04:29 +0100 (BST) > From: Tim Franklin > To: nanog at nanog.org > Subject: Re: IPv6 /64 links (was Re: ipv6 book recommendations?) > Message-ID: > Content-Type: text/plain; charset=utf-8 > >> The only solution is, IMO, to let multihomed sites have >> multiple prefixes inherited from their upper ISPs, still >> keeping the sites' ability to control loads between incoming >> multiple links. > > And for the basement multi-homers, RA / SLAAC makes this much easier to do with v6. The larger-scale / more mission-critical multi-homers are going to consume an AS and some BGP space whether you like it or not - at least with v6 there's a really good chance that they'll only *ever* need to announce a single-prefix. (Ignore "traffic engineering" pollution, but that doesn't get better or worse). > > Regards, > Tim. > > > > ------------------------------ > > Message: 9 > Date: Mon, 25 Jun 2012 09:30:02 -0400 > From: AP NANOG > To: nanog at nanog.org > Subject: Re: How to fix authentication (was LinkedIn) > Message-ID: <4FE867DA.8050400 at armoredpackets.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Kyle, > > I may be mistaken here, but I don't believe anyone is truly laughing the > matter off. > > There may have been some remarks about second or third parties, but the > fact does remain these are the areas which current concerns still lay. > > -- > > Robert Miller > (arch3angel) > > On 6/24/12 1:02 AM, Kyle Creyts wrote: >> I would suggest that multiple models be pursued (since each appears to have >> a champion) and that the market/drafting process will resolve the issue of >> which is better (which is okay by me: widespread adoption of any of the >> proposed models would advance the state of the norm; progress beats the >> snot out of stagnation in my book) >> >> My earlier replies were reprehensible. This is not a thread that should >> just be laughed off. Real progress may be occurring here, and at the least, >> good knowledge and discussion is accumulating in a way which may serve as a >> resource for the curious or concerned. >> On Jun 22, 2012 7:25 AM, "Leo Bicknell" wrote: >> >>> In a message written on Thu, Jun 21, 2012 at 04:48:47PM -1000, Randy Bush >>> wrote: >>>> there are no trustable third parties >>> With a lot of transactions the second party isn't trustable, and >>> sometimes the first party isn't as well. :) >>> >>> In a message written on Thu, Jun 21, 2012 at 10:53:18PM -0400, Christopher >>> Morrow wrote: >>>> note that yubico has models of auth that include: >>>> 1) using a third party >>>> 2) making your own party >>>> 3) HOTP on token >>>> 4) NFC >>>> >>>> they are a good company, trying to do the right thing(s)... They also >>>> don't necessarily want you to be stuck in the 'get your answer from >>>> another' >>> Requirements of hardware or a third party are fine for the corporate >>> world, or sites that make enough money or have enough risk to invest >>> in security, like a bank. >>> >>> Requiring hardware for a site like Facebook or Twitter is right >>> out. Does not scale, can't ship to the guy in Pakistan or McMurdo >>> who wants to sign up. Trusting a third party becomes too expensive, >>> and too big of a business risk. >>> >>> There are levels of security here. I don't expect Facebook to take >>> the same security steps as my bank to move my money around. One >>> size does not fit all. Making it so a hacker can't get 10 million >>> login credentials at once is a quantum leap forward even if doing >>> so doesn't improve security in any other way. >>> >>> The perfect is the enemy of the good. >>> >>> -- >>> Leo Bicknell - bicknell at ufp.org - CCIE 3440 >>> PGP keys at http://www.ufp.org/~bicknell/ >>> > > > > End of NANOG Digest, Vol 53, Issue 105 > ************************************** From bill at herrin.us Mon Jun 25 14:20:22 2012 From: bill at herrin.us (William Herrin) Date: Mon, 25 Jun 2012 15:20:22 -0400 Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: <4FE89B37.4030905@mail-abuse.org> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> <4FE89B37.4030905@mail-abuse.org> Message-ID: On Mon, Jun 25, 2012 at 1:09 PM, Douglas Otis wrote: > On 6/25/12 7:54 AM, Owen DeLong wrote: >> It would have been better if IETF had actually solved this instead >> of punting on it when developing IPv6. > > The IETF offered a HA solution that operates at the transport level. > The transport is SCTP Hi Douglas, SCTP proposes a solution to multihoming by multi-addressing each server. Each address represents one of the leaf node's paths to the Internet and if one fails an SCTP session can switch to the other. Correct? How does SCTP address the most immediate problem with multiaddressed TCP servers: the client doesn't rapidly find a currently working address from the set initially offered by A and AAAA DNS records. Is there anything in the SCTP protocol for this? Or does it handle it exactly the way TCP does (nothing at all in the API; app-controlled timeout and round robin)? Is the SCTP API drop-in compatible with TCP where a client can change a parameter in a socket() call and expect it to try SCTP and promptly fall back to TCP if no connection establishes? On the server side, does it work like the IPv6 API where one socket accepts both protocols? Or do the apps have to be redesigned to handle both SCTP and TCP? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From almarzuki2001 at hotmail.com Mon Jun 25 17:12:45 2012 From: almarzuki2001 at hotmail.com (Hadi Salem) Date: Tue, 26 Jun 2012 01:12:45 +0300 Subject: inquire Message-ID: Hi, I have inquire regard how to setup pop for terminating voice to telecom carries around the global. May scenario is, Telecom companies will connect to us thru VoIP. And we would like to terminate these voice calls to telecom carrier around the global... At best price. How can I accomplish this? I have read many article to host my equipment?s in co-location provider, where all carries well meet there. Like meet-me-room I?m confused here, is all carriers will be hosting there equipment?s in ixp? Or data center? What equipment?s do I need is Multiplexer and media gateway and Softswitch and patch panel? I need to make 30000 calls do I need 1000xE1 lines from the Multiplexer? What in my mind this picture Softswitch will connect media gateway. Media gateway will connect Multiplexer at DS3. Multiplexer will produce E1line to patch panel and from patch panel will connect cross connect to others telecom carrier Is this right?? Do I have to host my equipment?s at each ixp ? or data center where meet-me-room available Thanks and regards Mike From dotis at mail-abuse.org Mon Jun 25 18:06:15 2012 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 25 Jun 2012 16:06:15 -0700 Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> <4FE89B37.4030905@mail-abuse.org> Message-ID: <4FE8EEE7.8000702@mail-abuse.org> On 6/25/12 12:20 PM, William Herrin wrote: > On Mon, Jun 25, 2012 at 1:09 PM, Douglas Otis > wrote: >> On 6/25/12 7:54 AM, Owen DeLong wrote: >>> It would have been better if IETF had actually solved this >>> instead of punting on it when developing IPv6. >> >> The IETF offered a HA solution that operates at the transport >> level. The transport is SCTP > > Hi Douglas, > > SCTP proposes a solution to multihoming by multi-addressing each > server. Each address represents one of the leaf node's paths to > the Internet and if one fails an SCTP session can switch to the > other. Correct? Dear William, Yes. An SCTP association periodically checks alternate path functionality. > How does SCTP address the most immediate problem with > multiaddressed TCP servers: the client doesn't rapidly find a > currently working address from the set initially offered by A and > AAAA DNS records. Is there anything in the SCTP protocol for this? > Or does it handle it exactly the way TCP does (nothing at all in > the API; app-controlled timeout and round robin)? This is addressed by deprecating use of TCP, since SCTP offers a super-set of the socket API. It can also dramatically expand the number of virtual associations supported in a manner similar to that of UDP while still mitigating source spoofing. > Is the SCTP API drop-in compatible with TCP where a client can > change a parameter in a socket() call and expect it to try SCTP and > promptly fall back to TCP if no connection establishes? On the > server side, does it work like the IPv6 API where one socket > accepts both protocols? Or do the apps have to be redesigned to > handle both SCTP and TCP? The SCTP socket API is defined by: http://tools.ietf.org/html/rfc6458 As the world adopts IPv6, NAT issues become a bad memory of insecure middle boxes replaced by transports that can be as robust as necessary. IMHO, TCP is the impediment preventing simplistic (hardware based) high speed interfaces able to avoid buffer bloat. Regards, Douglas Otis From bill at herrin.us Mon Jun 25 19:03:13 2012 From: bill at herrin.us (William Herrin) Date: Mon, 25 Jun 2012 20:03:13 -0400 Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: <4FE8EEE7.8000702@mail-abuse.org> References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> <4FE89B37.4030905@mail-abuse.org> <4FE8EEE7.8000702@mail-abuse.org> Message-ID: On Mon, Jun 25, 2012 at 7:06 PM, Douglas Otis wrote: > On 6/25/12 12:20 PM, William Herrin wrote: >> How does SCTP address the most immediate problem with >> multiaddressed TCP servers: the client doesn't rapidly find a >> currently working address from the set initially offered by A and >> AAAA DNS records. Is there anything in the SCTP protocol for this? >> Or does it handle it exactly the way TCP does (nothing at all in >> the API; app-controlled timeout and round robin)? > > This is addressed by deprecating use of TCP, since SCTP offers a > super-set of the socket API. ?It can also dramatically expand the > number of virtual associations supported in a manner similar to that > of UDP while still mitigating source spoofing. Hi Douglas, Your answer was not responsive to my question. I'll rephrase. The most immediate problem with multiaddressed TCP servers is that clients have no way to pass the list of IPv4 and IPv6 addresses received from DNS to the layer 4 protocol as a whole. Instead, the application must try each in sequence. This results in connect delays (2 minutes by default) for each address which is not currently reachable as the application attempts a TCP connection to each in sequence, trying the next after a time out. This delay is often unacceptable. Does SCTP operate on a list of IPv4 and IPv6 addresses received from the application when it asks for a connect, parallelizing its attempt to reach a live address? Or a DNS name which it resolves to find those addresses? Or does it accept only one address at a time for the initial connect, just like TCP? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From DHyde at hosting.com Mon Jun 25 20:24:55 2012 From: DHyde at hosting.com (Darrell Hyde) Date: Mon, 25 Jun 2012 21:24:55 -0400 Subject: Feedback on Entrasys Switching Message-ID: <1AA11A6BC714D944985F3BC7FF7AB35F64A569846F@MBX03.corp.safesecureweb.com> Was hoping that anyone with experience with the Entrasys K or S series switches would be willing to offer any feedback on the platform, organization, support, software, etc. Interested in fairly vanilla L2 and L3 functionality and performance at high 1 and 10G interface density. Considering an evaluation and would value some informed argument for or against. Happy to take replies offline. Will be glad to summarize for anyone interested. Thanks! - Darrell From bill at herrin.us Mon Jun 25 20:37:54 2012 From: bill at herrin.us (William Herrin) Date: Mon, 25 Jun 2012 21:37:54 -0400 Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> <4FE89B37.4030905@mail-abuse.org> <4FE8EEE7.8000702@mail-abuse.org> Message-ID: On Mon, Jun 25, 2012 at 8:03 PM, William Herrin wrote: > Does SCTP operate on a list of IPv4 and IPv6 addresses received from > the application when it asks for a connect, parallelizing its attempt > to reach a live address? Or a DNS name which it resolves to find those > addresses? Or does it accept only one address at a time for the > initial connect, just like TCP? Hi Douglas, Another gentleman clarified for me privately: sctp_connectx() is listed as a new function in the 12/2011 standard. It accepts and uses multiple addresses during the initial connect. Good progress since the last time I looked at SCTP. I assume the SCTP API does not gracefully fall back to TCP for stream-oriented connections and UDP for datagram oriented connections, yes? So if an app author wants to use this in the real world as it exists in 2012, he'll have to juggle timeouts in order to try TCP if SCTP doesn't promptly establish. And he'll have to juggle the two APIs anywhere he does something more complex than send() and recv(). Yes? Also, has there been improvement to the situation where an endpoint loses all of its IP addresses and wants to re-establish? Something like a notification to the app requesting a fresh list of addresses? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cb.list6 at gmail.com Mon Jun 25 21:22:33 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 25 Jun 2012 19:22:33 -0700 Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> <4FE89B37.4030905@mail-abuse.org> <4FE8EEE7.8000702@mail-abuse.org> Message-ID: On Jun 25, 2012 6:38 PM, "William Herrin" wrote: > > On Mon, Jun 25, 2012 at 8:03 PM, William Herrin wrote: > > Does SCTP operate on a list of IPv4 and IPv6 addresses received from > > the application when it asks for a connect, parallelizing its attempt > > to reach a live address? Or a DNS name which it resolves to find those > > addresses? Or does it accept only one address at a time for the > > initial connect, just like TCP? > > Hi Douglas, > > Another gentleman clarified for me privately: sctp_connectx() is > listed as a new function in the 12/2011 standard. It accepts and uses > multiple addresses during the initial connect. > > Good progress since the last time I looked at SCTP. > > I assume the SCTP API does not gracefully fall back to TCP for > stream-oriented connections and UDP for datagram oriented connections, > yes? So if an app author wants to use this in the real world as it > exists in 2012, he'll have to juggle timeouts in order to try TCP if > SCTP doesn't promptly establish. And he'll have to juggle the two APIs > anywhere he does something more complex than send() and recv(). Yes? > There is some scope for this type of work.... This draft is expired, i imagine it may come back soonish http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 now that the ipv6 variant has shipped SCTP is coming along, and it has a lot of promise. CB > Also, has there been improvement to the situation where an endpoint > loses all of its IP addresses and wants to re-establish? Something > like a notification to the app requesting a fresh list of addresses? > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From swmike at swm.pp.se Tue Jun 26 00:33:12 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 26 Jun 2012 07:33:12 +0200 (CEST) Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> <4FE89B37.4030905@mail-abuse.org> <4FE8EEE7.8000702@mail-abuse.org> Message-ID: On Mon, 25 Jun 2012, Cameron Byrne wrote: > SCTP is coming along, and it has a lot of promise. Doesn't SCTP "suffer" from the same problem as SHIM6 was said to be suffering from, ie that now all of a sudden end systems control where packets go and there is going to be a bunch of people on this list complaining that they no longer can do "traffic engineering"? I don't mind. I wish more would use SCTP so it would get wider use. I also wish would have used SCTP instead of trying to invent that part again (the transport part of it at least). -- Mikael Abrahamsson email: swmike at swm.pp.se From graham at apolix.co.za Tue Jun 26 00:45:27 2012 From: graham at apolix.co.za (Graham Beneke) Date: Tue, 26 Jun 2012 07:45:27 +0200 Subject: Collecting flows at an IXP Message-ID: <4FE94C77.9040006@apolix.co.za> Hi All I'm busy doing some digging to find a solution for collecting layer-2 flows data on a medium sized IXP. All we have at the moment is some MRTG graphs and we're trying to get a better view into IPv4 vs IPv6, src and dst MACs, packet sizes and also perhaps port & protocol trends. I found Richard A. Steenbergen's NANOG 39 presentation and not much since then. Is it still correct that Cisco does not support sFlow? Are you able to get the same kind of useful data using Netflow v9? Which FOSS flow collectors do an decent/adequate job at crunching about 10Gbps worth of flows and presenting it in a useful way? Thanks -- Graham Beneke From graham at apolix.co.za Tue Jun 26 01:06:23 2012 From: graham at apolix.co.za (Graham Beneke) Date: Tue, 26 Jun 2012 08:06:23 +0200 Subject: Collecting flows at an IXP In-Reply-To: <4FE94C77.9040006@apolix.co.za> References: <4FE94C77.9040006@apolix.co.za> Message-ID: <4FE9515F.2050804@apolix.co.za> On 26/06/2012 07:45, Graham Beneke wrote: > Which FOSS flow collectors do an decent/adequate job at crunching about > 10Gbps worth of flows and presenting it in a useful way? Just to clarify - there are 3 switch fabrics involved here. One from vendor C, one from vendor J and a third new fabric from an unchosen vendor. So ideally something that can accept the flows from various vendors. I'm also hoping for some insight on flows support and caveats with the various vendors and platforms since the this third vendor still must be chosen and it would be handy to quantify the flows support of the proposed platform. -- Graham Beneke From nick at foobar.org Tue Jun 26 04:32:12 2012 From: nick at foobar.org (Nick Hilliard) Date: Tue, 26 Jun 2012 10:32:12 +0100 Subject: Collecting flows at an IXP In-Reply-To: <4FE9515F.2050804@apolix.co.za> References: <4FE94C77.9040006@apolix.co.za> <4FE9515F.2050804@apolix.co.za> Message-ID: <4FE9819C.6010701@foobar.org> On 26/06/2012 07:06, Graham Beneke wrote: > Just to clarify - there are 3 switch fabrics involved here. One from vendor > C, one from vendor J and a third new fabric from an unchosen vendor. > > So ideally something that can accept the flows from various vendors. > > I'm also hoping for some insight on flows support and caveats with the > various vendors and platforms since the this third vendor still must be > chosen and it would be handy to quantify the flows support of the proposed > platform. Graham, INEX has open-sourced its IXP provisioning system (github.com/inex), and part of that, is an sflow stats munging system which we use to present member to member data flows, split out by ipv4 / ipv6 traffic, pps and bits/sec. It would be easy enough to put in more graphing options. We haven't released the sflow stuff yet, but it's certainly there and in production, and shoudn't be too much trouble to get into git. Your difficulty is going to be that you're mixing and matching two different systems with completely different characteristics. sflow is easy because you can multiply the sample rate by the packet size (and possibly by an offset constant) and get a statistically representative sample of what's happening on the switch. But netflow is much more messy to handle. Mixing them together will be a lot of fun. Further to this, if you're using Cisco PFC3 based system (sup720 / rsp720 / etc), then this isn't going to work because Cisco WS-X67xx cards don't export mac addresses in netflow data. This is a hardware limitation; nothing you can do about it. This breaks point to point traffic analysis. Nick From hhoffman at ip-solutions.net Tue Jun 26 08:38:50 2012 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 26 Jun 2012 09:38:50 -0400 Subject: Collecting flows at an IXP In-Reply-To: <4FE94C77.9040006@apolix.co.za> References: <4FE94C77.9040006@apolix.co.za> Message-ID: <4FE9BB6A.8010305@ip-solutions.net> Hi Graham, Have you had a look at Argus? http://www.qosient.com/argus/ It works well for us and they have very active support community to boot! Cheers, Harry On 06/26/2012 01:45 AM, Graham Beneke wrote: > Hi All > > I'm busy doing some digging to find a solution for collecting layer-2 > flows data on a medium sized IXP. All we have at the moment is some MRTG > graphs and we're trying to get a better view into IPv4 vs IPv6, src and > dst MACs, packet sizes and also perhaps port & protocol trends. > > I found Richard A. Steenbergen's NANOG 39 presentation and not much > since then. > > Is it still correct that Cisco does not support sFlow? > > Are you able to get the same kind of useful data using Netflow v9? > > Which FOSS flow collectors do an decent/adequate job at crunching about > 10Gbps worth of flows and presenting it in a useful way? > > Thanks From peterehiwe at gmail.com Tue Jun 26 08:48:18 2012 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Tue, 26 Jun 2012 14:48:18 +0100 Subject: Net::Perl::SSH for MRLG Message-ID: Hello All , Has anyone successfully implemented Net::perl::ssh with mrlg . If yes please unicast me. The Perl module works fine but mrlg dosent seem to be able to connect to the routers using that module . . From nick at foobar.org Tue Jun 26 09:39:54 2012 From: nick at foobar.org (Nick Hilliard) Date: Tue, 26 Jun 2012 15:39:54 +0100 Subject: Net::Perl::SSH for MRLG In-Reply-To: References: Message-ID: <4FE9C9BA.2030305@foobar.org> On 26/06/2012 14:48, Peter Ehiwe wrote: > Has anyone successfully implemented Net::perl::ssh with mrlg . If yes > please unicast me. > > The Perl module works fine but mrlg dosent seem to be able to connect to > the routers using that module . I take it you're referring to Net::SSH::Perl? If so, why not stab your brains out with a rusty fork? It's a lot more fun. CPAN installation of this module generally doesn't work, which means either explicit package dependency installation or else some system like freebsd, where the default package installation works fine. Last time I counted, it pulled in forty-something dependencies on a clean perl installation. Haven't tried it with mrlg, but have got it to work with one of the other LG packages. Each time there's an upgrade, it takes patience to diagnose and fix the various problems. Nick From garrett at skjelstad.org Tue Jun 26 10:17:10 2012 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Tue, 26 Jun 2012 08:17:10 -0700 Subject: Net::Perl::SSH for MRLG In-Reply-To: References: Message-ID: Net::Appliance::Session has successfully worked for me. On Tue, Jun 26, 2012 at 6:48 AM, Peter Ehiwe wrote: > Hello All , > > Has anyone successfully implemented Net::perl::ssh with mrlg . If yes > please unicast me. > > The Perl module works fine but mrlg dosent seem to be able to connect to > the routers using that module . > > . > From khomyakov.andrey at gmail.com Tue Jun 26 11:14:31 2012 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Tue, 26 Jun 2012 12:14:31 -0400 Subject: Cisco ASR router performance specs Message-ID: Hi all, Could you point me into the right direction, please, on where one would find different performance ratings for Cisco routers other than talking to my SE (who is on PTO right now). My understanding is that Cisco does not publish this info. How do folks research that kind of stuff? For example, right now I want to find out how many DMVPN tunnels a given model of an ASR will support and what kind of throughput I can count on with that enabled. Thanks in advance for answers --Andrey From kenny.sallee at gmail.com Tue Jun 26 12:05:07 2012 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Tue, 26 Jun 2012 10:05:07 -0700 Subject: Cisco ASR router performance specs In-Reply-To: References: Message-ID: Here's what I always refer too http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf It's close. I don't think the testing incorporates a lot of services in use on the routers, however. For max interfaces, read up on this: http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_tech_note09186a0080094322.shtml I can tell you we have a couple ASR's pushing around 100Mbps running VRF, BGP, bunch of ACL's and prefix lists and they are pretty much idle. Traffic pattern is mostly SIP and RTP traffic (lots of small packets) On Tue, Jun 26, 2012 at 9:14 AM, Andrey Khomyakov wrote: > Hi all, > Could you point me into the right direction, please, on where one would > find different performance ratings for Cisco routers other than talking to > my SE (who is on PTO right now). > My understanding is that Cisco does not publish this info. How do folks > research that kind of stuff? > For example, right now I want to find out how many DMVPN tunnels a given > model of an ASR will support and what kind of throughput I can count on > with that enabled. > > Thanks in advance for answers > > --Andrey From randy at psg.com Tue Jun 26 12:30:30 2012 From: randy at psg.com (Randy Bush) Date: Tue, 26 Jun 2012 07:30:30 -1000 Subject: strat-1 gps Message-ID: my old TymServe 2100-GPS seems to have died. would appreciate reccos for a replacement. it is in a stand-alone environment so i can avoid roof access issues. antenna already in place. thanks. randy From smeuse at mara.org Tue Jun 26 12:54:37 2012 From: smeuse at mara.org (Steve Meuse) Date: Tue, 26 Jun 2012 13:54:37 -0400 Subject: strat-1 gps In-Reply-To: References: Message-ID: FreeBSD, Trimble Thunderbolt and a TAPR FatPPS? -Steve On Tue, Jun 26, 2012 at 1:30 PM, Randy Bush wrote: > my old TymServe 2100-GPS seems to have died. would appreciate reccos > for a replacement. it is in a stand-alone environment so i can avoid > roof access issues. antenna already in place. thanks. > > randy > > From jtk at cymru.com Tue Jun 26 13:15:38 2012 From: jtk at cymru.com (John Kristoff) Date: Tue, 26 Jun 2012 13:15:38 -0500 Subject: strat-1 gps In-Reply-To: References: Message-ID: <20120626131538.1764d4eb@localhost> On Tue, 26 Jun 2012 07:30:30 -1000 Randy Bush wrote: > my old TymServe 2100-GPS seems to have died. would appreciate reccos > for a replacement. it is in a stand-alone environment so i can avoid > roof access issues. antenna already in place. thanks. I've only used their CDMA-based time server, which is handy here in the States when line-of-sight access is difficult, but EndRun Technologies makes something you might want to consider: Just be aware that you may want to harden the system a bit based on what I saw from the last shipping defaults. A template for the CDMA version is here, but I suspect the GPS version would be hardened in a similar fashion: John From msa at latt.net Tue Jun 26 13:15:49 2012 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 26 Jun 2012 14:15:49 -0400 Subject: strat-1 gps In-Reply-To: References: Message-ID: <20120626181549.GI26323@puck.nether.net> On Tue, Jun 26, 2012 at 01:54:37PM -0400, Steve Meuse wrote: > FreeBSD, Trimble Thunderbolt and a TAPR FatPPS? Thing with the Thunderbolts is not all revisions of the firmware seem to play nice with ntpd. And yes, the PPS is quite narrow and would have to be conditioned as well. I think I'd start somewhere else unless you also needed the frequency reference. Good news is, the 2100-GPS used a 5-12VDC antenna with no downconversion, so it should work with just about anything. Randy, what's your budget for this? ($$$$ and space) Does it have to be 1U, or is a 1U GPS receiver and 1U time server acceptable? --msa From randy at psg.com Tue Jun 26 13:29:56 2012 From: randy at psg.com (Randy Bush) Date: Tue, 26 Jun 2012 08:29:56 -1000 Subject: strat-1 gps In-Reply-To: <20120626131538.1764d4eb@localhost> References: <20120626131538.1764d4eb@localhost> Message-ID: > http://endruntechnologies.com/time-server.htm at over $4k, not sensible randy From trelane at trelane.net Tue Jun 26 14:03:35 2012 From: trelane at trelane.net (Andrew D Kirch) Date: Tue, 26 Jun 2012 15:03:35 -0400 Subject: strat-1 gps In-Reply-To: References: <20120626131538.1764d4eb@localhost> Message-ID: <4FEA0787.1080406@trelane.net> Randy, Ublox LEA-7T's are either out, or will be out shortly in the Evaluation Kit product. Stick your antenna on that, and it provides a very solid 1PPS to NTPd. Should be less than $300 shipped. Andrew From deric.kwok2000 at gmail.com Tue Jun 26 14:51:03 2012 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Tue, 26 Jun 2012 15:51:03 -0400 Subject: please helpconfederation and ibgp question Message-ID: Hi all I would like to ask questions aboutconfederation and ibgp We know confederation from nanog achieve 101,102 and setup lab. bgp and ibgp can work properly but not sure we are doing right. We have quesions 1/ for the annoucing networks, do we have to announce it in border routers? eg: border routers. 66.59.128.0/22 but all ibgp routers are already announcing networks individually in ibgp Routers eg: Router A: 66.59.128.0/24, Router B: 66.59.129.0/24, Router C: 66.59.130.0/24, Router D: 66.59.131.128/25 In our labs, it can work. but we would like to know the setting is correct. or any announcing overlapping when announcing in broder Router and all individual ibgp routers 2/ But if it is not right to announce /22 in broder routers, let Router A,B,C, D announce it in 4 separate networks. ls it ok too? in the lab, the bgp can work too. but i read the bgp doc that it prefers us to announce it in /22 instead of 4 seperate one? 3/ in the border routers, we take out some ip from network 66.59.131.0/24 (eg: 66.59.131.0/28, 66.59.131.16/28) to interconnected to Router A, B, C and D We don't know which one is good for use in bgp configuration redistributed connected or network 66.59.131.0/28 network 66.59.131.16/28 If using network command "network 66.59.131.0/28, network 66.59.131.0/28" to let communicate between ibgp, there might have overlapping too as we already announcing 66.59.128.0/22. in the border router, there might have network 66.59.128.0/22 network 66.59.131.0/28 network 66.59.131.16/28 ls the command "redistributed connect" better? but this is border Router. We concern it will effect the upstream using redistributed connect Please help Thank you so much From malayter at gmail.com Tue Jun 26 15:05:10 2012 From: malayter at gmail.com (Ryan Malayter) Date: Tue, 26 Jun 2012 15:05:10 -0500 Subject: strat-1 gps Message-ID: +1 on the freesd-or-linux. with say a Garmin GPS-18x or whatever timing puck. Have an intern or junior tech tackle it as a learning exercise. The time geeks on comp.protocols.time.ntp seem to favor low-power Soekris hardware (http://soekris.com/) for stratum-1s. You need RS232 serial to get decent PPS; USB introduces tons of jitter. If you have to have something pre-integrated and soon, I'd look at Meinberg: http://www.meinberg.de/english/products/index.htm#network_sync -- RPM From sylvie at newnog.org Tue Jun 26 15:30:25 2012 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Tue, 26 Jun 2012 16:30:25 -0400 Subject: [NANOG-announce] Board Member Replacement Announcement - Dan Golding Message-ID: NANOG * How is the selection made? The Board will review the candidacies and appoint. Decision will be final and announced on June 22 to nanog-announce at nanog.org. There is more than the replacement position. Bear in mind that the election process will be initiated in early August when we will have 3 vacant boardpositions to fill. Check http://www.nanog.org/governance/elections/ late July and we will communicate the elections process via nanog-announce at nanog.org. We trust this answers your questions about the replacement and thank you for your consideration and interest for NANOG. * -- Sylvie LaPerriere NANOG Chair - www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From virendra.rode at gmail.com Tue Jun 26 15:31:41 2012 From: virendra.rode at gmail.com (virendra rode) Date: Tue, 26 Jun 2012 13:31:41 -0700 Subject: Collecting flows at an IXP In-Reply-To: <4FE94C77.9040006@apolix.co.za> References: <4FE94C77.9040006@apolix.co.za> Message-ID: <4FEA1C2D.5090905@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 06/25/2012 10:45 PM, Graham Beneke wrote: > Hi All > > I'm busy doing some digging to find a solution for collecting > layer-2 flows data on a medium sized IXP. All we have at the moment > is some MRTG graphs and we're trying to get a better view into IPv4 > vs IPv6, src and dst MACs, packet sizes and also perhaps port & > protocol trends. > > I found Richard A. Steenbergen's NANOG 39 presentation and not > much since then. > > Is it still correct that Cisco does not support sFlow? > > Are you able to get the same kind of useful data using Netflow v9? > > Which FOSS flow collectors do an decent/adequate job at crunching > about 10Gbps worth of flows and presenting it in a useful way? > > Thanks - ------------------- Another option to consider would be nfsen/nfdump..running nicely as a plugin under cacti so we get a central view. regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk/qHC0ACgkQ3HuimOHfh+FioQD/Qs7/fje8hziGEym2Wh0sIDWI 16p7ZC+6cJnUUGHzPJsA/jzn0/iCwDCFO8UKSjkXuEpwysRo8U/WeZpTKcbzvhHN =k2E2 -----END PGP SIGNATURE----- From rs at seastrom.com Tue Jun 26 15:33:35 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 26 Jun 2012 16:33:35 -0400 Subject: strat-1 gps In-Reply-To: (Ryan Malayter's message of "Tue, 26 Jun 2012 15:05:10 -0500") References: Message-ID: <867gutizj4.fsf@seastrom.com> Word around the campfire is that the 18x is jittery compared to the 18. Maybe it only matters if you are super-anal. Majdi, do you have any current info on this? -r Ryan Malayter writes: > +1 on the freesd-or-linux. with say a Garmin GPS-18x or whatever > timing puck. Have an intern or junior tech tackle it as a learning > exercise. The time geeks on comp.protocols.time.ntp seem to favor > low-power Soekris hardware (http://soekris.com/) for stratum-1s. You > need RS232 serial to get decent PPS; USB introduces tons of jitter. > > If you have to have something pre-integrated and soon, I'd look at Meinberg: > http://www.meinberg.de/english/products/index.htm#network_sync > > -- > RPM From hmurray at megapathdsl.net Tue Jun 26 15:33:41 2012 From: hmurray at megapathdsl.net (Hal Murray) Date: Tue, 26 Jun 2012 13:33:41 -0700 Subject: NTP/THunderbolt (was Re: strat-1 gps) Message-ID: <20120626203341.8194080003B@ip-64-139-1-69.sjc.megapath.net> > Thing with the Thunderbolts is not all revisions of the firmware seem to > play nice with ntpd. Would anybody with more info please contact me off-list. We should be able to fix that, or at least document it. -- These are my opinions. I hate spam. From sylvie at newnog.org Tue Jun 26 15:41:39 2012 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Tue, 26 Jun 2012 16:41:39 -0400 Subject: [NANOG-announce] Appointment of Dan Golding as Board Member Message-ID: NANOG Colleagues, The Board has met last Friday June 22 and appointed Dan Golding as the replacement board member until the next election. He will join our next Board on July 6. We would like to thank everyone who submitted their candidacy for this interim. Your desire to serve is encouraging. We had previously announced that we would communicate this appointment on June 22. The delay is due to our desire to communicate personally with all that were not selected first. We trust you understand. Welcome Dan! Sincerely, -- Sylvie LaPerriere NANOG Chair - www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From saku at ytti.fi Tue Jun 26 15:54:33 2012 From: saku at ytti.fi (Saku Ytti) Date: Tue, 26 Jun 2012 23:54:33 +0300 Subject: strat-1 gps In-Reply-To: References: Message-ID: <20120626205433.GB23021@pob.ytti.fi> On (2012-06-26 15:05 -0500), Ryan Malayter wrote: > If you have to have something pre-integrated and soon, I'd look at Meinberg: > http://www.meinberg.de/english/products/index.htm#network_sync We have several Meinbergs, quality hardware definitely. But I really wish they'd have hardware timestamping. And 1GE instead of 100M would also reduce jitter further. Right now I'm seeing offset of about 65us from our meinbergss over routed network of several hops and delay to meinbergs ranging from 0.5ms to 8.4ms I wonder if symmetricom does NTP timestamping in HW, or only PTP? -- ++ytti From msa at latt.net Tue Jun 26 16:11:41 2012 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 26 Jun 2012 17:11:41 -0400 Subject: strat-1 gps In-Reply-To: <867gutizj4.fsf@seastrom.com> References: <867gutizj4.fsf@seastrom.com> Message-ID: <20120626211141.GK26323@puck.nether.net> On Tue, Jun 26, 2012 at 04:33:35PM -0400, Robert E. Seastrom wrote: > Word around the campfire is that the 18x is jittery compared to the 18. The 18x is much worse than the 18LVC. Thankfully I still have 2 18LVCs... but that said, given the hockey puck design, and that Randy already has an antenna, I wouldn't recommend this approach anyway. It's really only suitable next to a window, or in a short, wooden structure. Also, we've got a leap second pending, and at least the 18LVCs...do not appear to handle those gracefully. Mine freaked out pretty badly in 2008 and had to be reset and reconfigured. I've also seen them lose their configuration (which has to be reset using a Garmin utility.) For this reason I can't recommend running them unattended. Does anyone have any experience with the Veracity VTN-TN? I don't, but it looks somewhat interesting. --msa From gem at rellim.com Tue Jun 26 16:20:44 2012 From: gem at rellim.com (Gary E. Miller) Date: Tue, 26 Jun 2012 14:20:44 -0700 Subject: strat-1 gps In-Reply-To: <20120626211141.GK26323@puck.nether.net> References: <867gutizj4.fsf@seastrom.com> <20120626211141.GK26323@puck.nether.net> Message-ID: <20120626142044.530447da.gem@rellim.com> Yo Majdi! > Does anyone have any experience with the Veracity VTN-TN? > I don't, but it looks somewhat interesting. No, but I highly recommend the BU-353. Chrony reports jitter of about 700 nano Sec while in my basement. So no need for an external antenna in many cases. Not tried the new BU-353-S4, but got on on order. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From davehart at gmail.com Tue Jun 26 16:34:31 2012 From: davehart at gmail.com (Dave Hart) Date: Tue, 26 Jun 2012 21:34:31 +0000 Subject: strat-1 gps In-Reply-To: <20120626211141.GK26323@puck.nether.net> References: <867gutizj4.fsf@seastrom.com> <20120626211141.GK26323@puck.nether.net> Message-ID: On Tue, Jun 26, 2012 at 9:11 PM, Majdi S. Abbas wrote: > On Tue, Jun 26, 2012 at 04:33:35PM -0400, Robert E. Seastrom wrote: >> Word around the campfire is that the 18x is jittery compared to the 18. > > ? ? ? ?The 18x is much worse than the 18LVC. ?Thankfully I still have > 2 18LVCs... but that said, given the hockey puck design, and that Randy > already has an antenna, I wouldn't recommend this approach anyway. ?It's > really only suitable next to a window, or in a short, wooden structure. I agree the Garmin GPS 18x LVC solution is only appropriate near a window, or in a short wooden structure. David J. Taylor's experience was the older GPS 18 LVC had a substantially less sensitive receiver, so that his needed to be mounted outside, while his 18x LVC works inside. The area where 18x LVC underperforms the 18 LVC is the jitter of the timing of its NMEA output relative to the leading edge of the PPS. Configured correctly, this should matter very little, and only transiently at startup where ntpd first uses the NMEA end-of-line timestamp (possibly fudged to bring it closer to the top of second) to "number the seconds" before engaging the PPS. I don't recommend attempting to use any NMEA source without PPS. With it, I don't understand why Majdi finds the 18x LVC much worse. The 18x is a number of years old at this point. Newer GPS receivers (such as the Sure GPS evaluation kits at around $30) are likely to be much more sensitive. I've heard reports of them working in basements and in office buildings 20 or more feet from a window. > ? ? ? ?Also, we've got a leap second pending, and at least the > 18LVCs...do not appear to handle those gracefully. ?Mine freaked out > pretty badly in 2008 and had to be reset and reconfigured. ?I've also > seen them lose their configuration (which has to be reset using a Garmin > utility.) ?For this reason I can't recommend running them unattended. There was a bug in early firmware versions of the GPS 18x LVC that could result in the device wedging until you either left it unpowered long enough to drain its battery/capacitor and thereby clear its configuration, or cracked it open to achieve the same, or (as many did) exchanged it with Garmin for a replacement. I believe that bug was first fixed in the 3.20 or 3.30 release, but one of those made the NMEA timing even worse, sometimes causing NMEA sentences to continue past the next top-of-second that could have fit easily in one second if not so delayed. The NMEA timing was improved in the 3.70 firmware, which I recommend all GPS 18x LVC + ntpd users upgrade to, particularly those using 3.20 or earlier. The change history included with the 3.70 firmware doesn't completely align with my recollection. There's no mention of fixing the bricking bug I mentioned. The closest likely mention is of a 3.60 fix: Version 3.50 to 3.60 1. Fixed factory firmware flash capabilities. It does confirm the NMEA timing fix for 3.70, on the other hand. Cheers, Dave Hart From eric.rosenberry at iovation.com Tue Jun 26 16:44:44 2012 From: eric.rosenberry at iovation.com (Eric Rosenberry) Date: Tue, 26 Jun 2012 14:44:44 -0700 Subject: Whois data compromised? Message-ID: Not sure where this data got injected into the system (or who knows, perhaps it's a DNS injection attack or something), but this certainly is not right. :-( Erics-MacBook-Pro-2:~ erosenbe$ whois -h whois.internic.net facebook.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. FACEBOOK.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM FACEBOOK.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM FACEBOOK.COM.LOVED.BY.WWW.SHQIPHOST.COM FACEBOOK.COM.KNOWS.THAT.THE.BEST.WEB.HOSTING.IS.NASHHOST.NET FACEBOOK.COM.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM FACEBOOK.COM To single out one record, look it up with "xxx", where xxx is one of the of the records displayed above. If the records are the same, look them up with "=xxx" to receive a full display for each record. >>> Last update of whois database: Tue, 26 Jun 2012 21:42:13 UTC <<< NOTICE: The expiration date displayed in this record is the date the registrar's sponsorship of the domain name registration in the registry is currently set to expire. This date does not necessarily reflect the expiration date of the domain name registrant's agreement with the sponsoring registrar. Users may consult the sponsoring registrar's Whois database to view the registrar's reported date of expiration for this registration. TERMS OF USE: You are not authorized to access or query our Whois database through the use of electronic processes that are high-volume and automated except as reasonably necessary to register domain names or modify existing registrations; the Data in VeriSign Global Registry Services' ("VeriSign") Whois database is provided by VeriSign for information purposes only, and to assist persons in obtaining information about or related to a domain name registration record. VeriSign does not guarantee its accuracy. By submitting a Whois query, you agree to abide by the following terms of use: You agree that you may use this Data only for lawful purposes and that under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or (2) enable high volume, automated, electronic processes that apply to VeriSign (or its computer systems). The compilation, repackaging, dissemination or other use of this Data is expressly prohibited without the prior written consent of VeriSign. You agree not to use electronic processes that are automated and high-volume to access or query the Whois database except as reasonably necessary to register domain names or modify existing registrations. VeriSign reserves the right to restrict your access to the Whois database in its sole discretion to ensure operational stability. VeriSign may restrict or terminate your access to the Whois database for failure to abide by these terms of use. VeriSign reserves the right to modify these terms at any time. The Registry database contains ONLY .COM, .NET, .EDU domains and Registrars. Erics-MacBook-Pro-2:~ erosenbe$ -- *Eric Rosenberry* Sr. Infrastructure Architect // Chief Bit Plumber Direct: 503.943.6763 Mobile: 503.348.3625 // XMPP: eric.rosenberry at iovation.com *www.iovation.com* From regnauld at nsrc.org Tue Jun 26 16:53:40 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 26 Jun 2012 14:53:40 -0700 Subject: Whois data compromised? In-Reply-To: References: Message-ID: <20120626215340.GH97080@macbook.bluepipe.net> Eric Rosenberry (eric.rosenberry) writes: > Not sure where this data got injected into the system (or who knows, > perhaps it's a DNS injection attack or something), but this certainly is > not right. :-( > http://slacksite.com/humour/whois.html From marka at isc.org Tue Jun 26 16:53:25 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 27 Jun 2012 07:53:25 +1000 Subject: Whois data compromised? In-Reply-To: Your message of "Tue, 26 Jun 2012 14:44:44 MST." References: Message-ID: <20120626215325.3FE1F21F9570@drugs.dv.isc.org> In message , Eric Rosenberry writes: > Not sure where this data got injected into the system (or who knows, > perhaps it's a DNS injection attack or something), but this certainly is > not right. :-( It's perfectly NORMAL. Just the owners of SWINGINGCOMMUNITY.COM, BEYONDWHOIS.COM, SHQIPHOST.COM, NASHHOST.NET and UNIMUNDI.COM playing games. It would just be nice if "single out" actually worked. :-) Mark % whois -h whois.internic.net =facebook.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Server Name: FACEBOOK.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM IP Address: 69.41.185.229 Registrar: TUCOWS.COM CO. Whois Server: whois.tucows.com Referral URL: http://domainhelp.opensrs.net Server Name: FACEBOOK.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM IP Address: 203.36.226.2 Registrar: INSTRA CORPORATION PTY, LTD. Whois Server: whois.instra.net Referral URL: http://www.instra.com Server Name: FACEBOOK.COM.LOVED.BY.WWW.SHQIPHOST.COM IP Address: 46.4.210.254 Registrar: ONLINENIC, INC. Whois Server: whois.onlinenic.com Referral URL: http://www.OnlineNIC.com Server Name: FACEBOOK.COM.KNOWS.THAT.THE.BEST.WEB.HOSTING.IS.NASHHOST.NET IP Address: 78.47.16.44 Registrar: HETZNER ONLINE AG Whois Server: whois.your-server.de Referral URL: http://www.hetzner.de Server Name: FACEBOOK.COM.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM IP Address: 209.126.190.70 Registrar: DIRECTI INTERNET SOLUTIONS PVT. LTD. D/B/A PUBLICDOMAINREGISTRY.COM Whois Server: whois.PublicDomainRegistry.com Referral URL: http://www.PublicDomainRegistry.com Domain Name: FACEBOOK.COM Registrar: MARKMONITOR INC. Whois Server: whois.markmonitor.com Referral URL: http://www.markmonitor.com Name Server: NS3.FACEBOOK.COM Name Server: NS4.FACEBOOK.COM Name Server: NS5.FACEBOOK.COM Status: clientDeleteProhibited Status: clientTransferProhibited Status: clientUpdateProhibited Status: serverDeleteProhibited Status: serverTransferProhibited Status: serverUpdateProhibited Updated Date: 25-apr-2012 Creation Date: 29-mar-1997 >>> Last update of whois database: Tue, 26 Jun 2012 21:48:03 UTC <<< [notice snipped] % > Erics-MacBook-Pro-2:~ erosenbe$ whois -h whois.internic.net facebook.com > > Whois Server Version 2.0 > > Domain names in the .com and .net domains can now be registered > with many different competing registrars. Go to http://www.internic.net > for detailed information. > > FACEBOOK.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM > FACEBOOK.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM > FACEBOOK.COM.LOVED.BY.WWW.SHQIPHOST.COM > FACEBOOK.COM.KNOWS.THAT.THE.BEST.WEB.HOSTING.IS.NASHHOST.NET > FACEBOOK.COM.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM > FACEBOOK.COM > > To single out one record, look it up with "xxx", where xxx is one of the > of the records displayed above. If the records are the same, look them up > with "=xxx" to receive a full display for each record. > > >>> Last update of whois database: Tue, 26 Jun 2012 21:42:13 UTC <<< > > NOTICE: The expiration date displayed in this record is the date the > registrar's sponsorship of the domain name registration in the registry is > currently set to expire. This date does not necessarily reflect the > expiration > date of the domain name registrant's agreement with the sponsoring > registrar. Users may consult the sponsoring registrar's Whois database to > view the registrar's reported date of expiration for this registration. > > TERMS OF USE: You are not authorized to access or query our Whois > database through the use of electronic processes that are high-volume and > automated except as reasonably necessary to register domain names or > modify existing registrations; the Data in VeriSign Global Registry > Services' ("VeriSign") Whois database is provided by VeriSign for > information purposes only, and to assist persons in obtaining information > about or related to a domain name registration record. VeriSign does not > guarantee its accuracy. By submitting a Whois query, you agree to abide > by the following terms of use: You agree that you may use this Data only > for lawful purposes and that under no circumstances will you use this Data > to: (1) allow, enable, or otherwise support the transmission of mass > unsolicited, commercial advertising or solicitations via e-mail, telephone, > or facsimile; or (2) enable high volume, automated, electronic processes > that apply to VeriSign (or its computer systems). The compilation, > repackaging, dissemination or other use of this Data is expressly > prohibited without the prior written consent of VeriSign. You agree not to > use electronic processes that are automated and high-volume to access or > query the Whois database except as reasonably necessary to register > domain names or modify existing registrations. VeriSign reserves the right > to restrict your access to the Whois database in its sole discretion to > ensure > operational stability. VeriSign may restrict or terminate your access to > the > Whois database for failure to abide by these terms of use. VeriSign > reserves the right to modify these terms at any time. > > The Registry database contains ONLY .COM, .NET, .EDU domains and > Registrars. > Erics-MacBook-Pro-2:~ erosenbe$ > > > -- > *Eric Rosenberry* > Sr. Infrastructure Architect // Chief Bit Plumber > > Direct: 503.943.6763 > Mobile: 503.348.3625 // XMPP: eric.rosenberry at iovation.com > *www.iovation.com* -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From eric.rosenberry at iovation.com Tue Jun 26 16:57:08 2012 From: eric.rosenberry at iovation.com (Eric Rosenberry) Date: Tue, 26 Jun 2012 14:57:08 -0700 Subject: Whois data compromised? In-Reply-To: <20120626215340.GH97080@macbook.bluepipe.net> References: <20120626215340.GH97080@macbook.bluepipe.net> Message-ID: lol, nice. I should have actually read the output before posting. That's funny. Disregard... -Eric On Tue, Jun 26, 2012 at 2:53 PM, Phil Regnauld wrote: > Eric Rosenberry (eric.rosenberry) writes: > > Not sure where this data got injected into the system (or who knows, > > perhaps it's a DNS injection attack or something), but this certainly is > > not right. :-( > > > > http://slacksite.com/humour/whois.html > -- *Eric Rosenberry* Sr. Infrastructure Architect // Chief Bit Plumber Direct: 503.943.6763 Mobile: 503.348.3625 // XMPP: eric.rosenberry at iovation.com *www.iovation.com* From egon at egon.cc Tue Jun 26 17:07:46 2012 From: egon at egon.cc (James Downs) Date: Tue, 26 Jun 2012 15:07:46 -0700 Subject: Whois data compromised? In-Reply-To: References: Message-ID: <195B94D6-E59B-4414-8908-E25030BBD20D@egon.cc> On Jun 26, 2012, at 2:44 PM, Eric Rosenberry wrote: > Not sure where this data got injected into the system (or who knows, > perhaps it's a DNS injection attack or something), but this certainly is It's an old trick, been around forever. You just register some random A record with a registrar. Same thing happens for google.com, microsoft.com, probably every big company. Cheers, -j From randy_94108 at yahoo.com Tue Jun 26 18:54:27 2012 From: randy_94108 at yahoo.com (Randy) Date: Tue, 26 Jun 2012 16:54:27 -0700 (PDT) Subject: please helpconfederation and ibgp question In-Reply-To: Message-ID: <1340754867.59104.YahooMailClassic@web181113.mail.ne1.yahoo.com> --- On Tue, 6/26/12, Deric Kwok wrote: > From: Deric Kwok > Subject: please helpconfederation and ibgp question > To: "nanog list" > Date: Tuesday, June 26, 2012, 12:51 PM > Hi all > > I would like to ask questions aboutconfederation and ibgp > > We know confederation from nanog achieve 101,102 and setup > lab. > bgp and ibgp can work properly? but not sure we are > doing right. > > We have quesions > > 1/? for the annoucing networks, do we have to announce > it in border routers? > eg: border routers.? 66.59.128.0/22 > but all ibgp routers are already announcing networks > individually in > ibgp Routers > eg: Router A: 66.59.128.0/24, Router B: 66.59.129.0/24, > Router C: > 66.59.130.0/24, Router D: 66.59.131.128/25 > > In our labs, it can work. but we would like to know the > setting is > correct. or any announcing overlapping when announcing in > broder > Router and all individual ibgp routers > > 2/ But if it is not right to announce /22 in broder routers, > let > Router A,B,C, D announce it in 4 separate networks.? ls > it ok too? > in the lab, the bgp can work too. but i read the bgp doc > that it > prefers us to announce it in /22 instead of 4 seperate one? > > 3/ in the border routers, we take out some ip from network > 66.59.131.0/24 (eg: 66.59.131.0/28, 66.59.131.16/28) to > interconnected > to Router A, B, C and D > We don't know which one is good for use in bgp > configuration > > redistributed connected > or > network 66.59.131.0/28 > network 66.59.131.16/28 > > If using network command "network 66.59.131.0/28, network > 66.59.131.0/28" to let communicate between ibgp, there might > have > overlapping too as we already announcing? > 66.59.128.0/22. in the > border router, there might have > > network 66.59.128.0/22 > network 66.59.131.0/28 > network 66.59.131.16/28 > > ls the command "redistributed connect" better? but this is > border > Router.? We concern it will effect the upstream using > redistributed > connect > > Please help > > Thank you so much > Deric- I don't mean to sound rude but I think it is time you asked $Employer for routing/switching/best-practices training. It will help you understand what you do and why you do it. The labs, and NANOG presentations are a good start. ./Randy From mysidia at gmail.com Tue Jun 26 19:43:31 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 26 Jun 2012 19:43:31 -0500 Subject: Whois data compromised? In-Reply-To: <20120626215325.3FE1F21F9570@drugs.dv.isc.org> References: <20120626215325.3FE1F21F9570@drugs.dv.isc.org> Message-ID: On 6/26/12, Mark Andrews wrote: [snip] > It's perfectly NORMAL. Just the owners of SWINGINGCOMMUNITY.COM, > BEYONDWHOIS.COM, SHQIPHOST.COM, NASHHOST.NET and UNIMUNDI.COM playing > games. It's "expected" behavior of the WHOIS implementation, the "games" involving creating WHOIS lookup ambiguity are not very amusing. Using .. as the name of a nameserver with the registry should be considered abuse. I would like to see the registry refuse future registrations of . as a nameserver, for 3-letter TLD names. In addition, no new global TLD names should be created. > It would just be nice if "single out" actually worked. :-) > Mark -- -JH From paul at paulgraydon.co.uk Tue Jun 26 19:47:07 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 26 Jun 2012 14:47:07 -1000 Subject: Whois data compromised? In-Reply-To: <20120626215325.3FE1F21F9570@drugs.dv.isc.org> References: <20120626215325.3FE1F21F9570@drugs.dv.isc.org> Message-ID: <4FEA580B.3080808@paulgraydon.co.uk> On 06/26/2012 11:53 AM, Mark Andrews wrote: > In message > , Eric Rosenberry writes: >> Not sure where this data got injected into the system (or who knows, >> perhaps it's a DNS injection attack or something), but this certainly is >> not right. :-( > It's perfectly NORMAL. Just the owners of SWINGINGCOMMUNITY.COM, > BEYONDWHOIS.COM, SHQIPHOST.COM, NASHHOST.NET and UNIMUNDI.COM playing > games. > > Probably a stupid question, but what do they gain by doing such? Paul From jlewis at lewis.org Tue Jun 26 19:56:39 2012 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 26 Jun 2012 20:56:39 -0400 (EDT) Subject: Whois data compromised? In-Reply-To: <4FEA580B.3080808@paulgraydon.co.uk> References: <20120626215325.3FE1F21F9570@drugs.dv.isc.org> <4FEA580B.3080808@paulgraydon.co.uk> Message-ID: On Tue, 26 Jun 2012, Paul Graydon wrote: > On 06/26/2012 11:53 AM, Mark Andrews wrote: >> In message >> >> , Eric Rosenberry writes: >>> Not sure where this data got injected into the system (or who knows, >>> perhaps it's a DNS injection attack or something), but this certainly is >>> not right. :-( >> It's perfectly NORMAL. Just the owners of SWINGINGCOMMUNITY.COM, >> BEYONDWHOIS.COM, SHQIPHOST.COM, NASHHOST.NET and UNIMUNDI.COM playing >> games. >> >> > Probably a stupid question, but what do they gain by doing such? Vanity. Poking fun at the domains in question. People have been doing it at least 10 years, probably longer. http://attrition.org/news/content/00-01-26.001.html That's a page about it from 2000. So, obviously, it has been going on more than 10 years. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From dotis at mail-abuse.org Tue Jun 26 20:15:31 2012 From: dotis at mail-abuse.org (Douglas Otis) Date: Tue, 26 Jun 2012 18:15:31 -0700 Subject: IPv6 Multi-homing (was IPv6 /64 links) In-Reply-To: References: <6304710.10262.1340233522086.JavaMail.root@benjamin.baylink.com> <1340266333.2753.284.camel@karl> <4FE30DDD.3030103@necom830.hpcl.titech.ac.jp> <1340284292.2753.305.camel@karl> <4FE3B0D2.7080705@necom830.hpcl.titech.ac.jp> <4FE80E0A.5020906@necom830.hpcl.titech.ac.jp> <4FE89B37.4030905@mail-abuse.org> <4FE8EEE7.8000702@mail-abuse.org> Message-ID: <4FEA5EB3.3070900@mail-abuse.org> On 6/25/12 10:33 PM, Mikael Abrahamsson wrote: > On Mon, 25 Jun 2012, Cameron Byrne wrote: > >> SCTP is coming along, and it has a lot of promise. > > Doesn't SCTP "suffer" from the same problem as SHIM6 was said to be > suffering from, ie that now all of a sudden end systems control where > packets go and there is going to be a bunch of people on this list > complaining that they no longer can do "traffic engineering"? Dear Mikael, SCTP permits multiple provider support of specific hosts where instant fail-over is needed. When DNS returns multiple IP addresses, an application calls sctp_connectx() with this list combined into an association endpoint belonging to a single host. This eliminates a need for PI addresses and related router table growth when high availability service becomes popular. Rather than having multi-homing implemented at the router, SCTP fail-over does not require 20 second delays nor will fail-over cause a sizable shift in traffic that might introduce other instabilities. Although not all details related to multi-homing remain hidden, SCTP offers several significant advantages related to performance and reliability. SCTP can isolate applications over fewer ports. Unlike TCP, SCTP can combine thousands of independent streams into a single association and port. SCTP offers faster setup and can eliminate head-of-queue blocking and the associated buffering involved. SCTP also compensates for reduced Ethernet error detection rates when Jumbo frames are used. Providers able to control multiple routers will likely prefer router based methods. A router approach will not always offer a superior solution nor will it limit router table growth, but traffic engineering should remain feasible when SCTP is used instead. > I don't mind. I wish more would use SCTP so it would get wider use. I > also wish would have used SCTP instead of trying > to invent that part again (the transport part of it at least). Perhaps MIT could have implemented SCTP over UDP as a starting point. An adoption impediment has been desktop OS vendors. This may change once SCTP's advantages become increasingly apparent with the rise of data rates and desires for greater resiliency and security. Regards, Douglas Otis From ecables at gmail.com Tue Jun 26 21:37:36 2012 From: ecables at gmail.com (Eric Cables) Date: Tue, 26 Jun 2012 19:37:36 -0700 Subject: DDI (DNS+DHCP+IPAM) Solutions Message-ID: I'm looking to consolidate DNS/DHCP/IPAM into a single tool. Today I use IPPlan for IPAM, and have been reasonably happy with it over the last 5+ years, but I'd like to leverage the benefits of integrating DNS and DHCP for real-time information, along with a more supportable solution for my staff. It seems that InfoBlox and BlueCat are the top players, but maybe I'm being fooled by the hype. Can anyone respond with their experience with DDI in an Enterprise environment? Have the tools been useful/reliable? What is the pricing model?Replies can be on, or off, list. -- Eric Cables From nikm at cyberflunk.com Tue Jun 26 22:50:37 2012 From: nikm at cyberflunk.com (Nikos Mouat) Date: Tue, 26 Jun 2012 20:50:37 -0700 (PDT) Subject: strat-1 gps In-Reply-To: <20120626131538.1764d4eb@localhost> References: <20120626131538.1764d4eb@localhost> Message-ID: I would definitely second this - I have one of these from ages ago and it runs great, and the CDMA sourced data means just throwing an antenna at the top of the cabinet in the datacenter vs running antenna cabling onto the roof for a GPS antenna. I believe I got mine on the secondary market for a fraction of the cost you mentioned Randy. I did have an issue in 2004 with a Verizon base station having a leap second setting off or something like that, but after reporting it to EndRun they contacted Verizon and had them update it and I don't think I've touched it since. Nikos On Tue, 26 Jun 2012, John Kristoff wrote: > On Tue, 26 Jun 2012 07:30:30 -1000 > Randy Bush wrote: > >> my old TymServe 2100-GPS seems to have died. would appreciate reccos >> for a replacement. it is in a stand-alone environment so i can avoid >> roof access issues. antenna already in place. thanks. > > I've only used their CDMA-based time server, which is handy here in the > States when line-of-sight access is difficult, but EndRun Technologies > makes something you might want to consider: > > > > Just be aware that you may want to harden the system a bit based on > what I saw from the last shipping defaults. A template for the CDMA > version is here, but I suspect the GPS version would be hardened in a > similar fashion: > > > > John > > > From Matthew.Black at csulb.edu Tue Jun 26 22:53:17 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 03:53:17 +0000 Subject: DNS poisoning at Google? Message-ID: Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com. We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. We believe the DNS servers used by Google's crawler have been poisoned. Can anyone shed some light on this? matthew black information technology services california state university, long beach www.csulb.edu From sethm at rollernet.us Tue Jun 26 22:58:13 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 26 Jun 2012 20:58:13 -0700 Subject: strat-1 gps In-Reply-To: References: <867gutizj4.fsf@seastrom.com> <20120626211141.GK26323@puck.nether.net> Message-ID: <4FEA84D5.1070809@rollernet.us> On 6/26/12 2:34 PM, Dave Hart wrote: > On Tue, Jun 26, 2012 at 9:11 PM, Majdi S. Abbas wrote: >> On Tue, Jun 26, 2012 at 04:33:35PM -0400, Robert E. Seastrom wrote: >>> Word around the campfire is that the 18x is jittery compared to the 18. >> >> The 18x is much worse than the 18LVC. Thankfully I still have >> 2 18LVCs... but that said, given the hockey puck design, and that Randy >> already has an antenna, I wouldn't recommend this approach anyway. It's >> really only suitable next to a window, or in a short, wooden structure. > > I agree the Garmin GPS 18x LVC solution is only appropriate near a > window, or in a short wooden structure. David J. Taylor's experience > was the older GPS 18 LVC had a substantially less sensitive receiver, > so that his needed to be mounted outside, while his 18x LVC works > inside. > > The area where 18x LVC underperforms the 18 LVC is the jitter of the > timing of its NMEA output relative to the leading edge of the PPS. > Configured correctly, this should matter very little, and only > transiently at startup where ntpd first uses the NMEA end-of-line > timestamp (possibly fudged to bring it closer to the top of second) to > "number the seconds" before engaging the PPS. I don't recommend > attempting to use any NMEA source without PPS. With it, I don't > understand why Majdi finds the 18x LVC much worse. > Does anyone use or prefer the 5Hz version of the 18x LVC? ~Seth From sadiq at asininetech.com Tue Jun 26 23:04:58 2012 From: sadiq at asininetech.com (Sadiq Saif) Date: Wed, 27 Jun 2012 00:04:58 -0400 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: Accidentally sent that to Matthew only, mind sharing the domain name? On Tue, Jun 26, 2012 at 11:53 PM, Matthew Black wrote: > Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com. > > We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. > > We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. > > We believe the DNS servers used by Google's crawler have been poisoned. > > Can anyone shed some light on this? > > matthew black > information technology services > california state university, long beach > www.csulb.edu > -- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From lstewart at superb.net Tue Jun 26 23:07:16 2012 From: lstewart at superb.net (Landon Stewart) Date: Tue, 26 Jun 2012 21:07:16 -0700 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected. On 26 June 2012 20:53, Matthew Black wrote: > Google Safe Browsing and Firefox have marked our website as containing > malware. They claim our home page returns no results, but redirects users > to another compromised website couchtarts.com. > > We have thoroughly examined our root .htaccess and httpd.conf files and > are not redirecting to the problem target site. No recent changes either. > > We ran some NSLOOKUPs against various public DNS servers and > intermittently get results that are NOT our servers. > > We believe the DNS servers used by Google's crawler have been poisoned. > > Can anyone shed some light on this? > > matthew black > information technology services > california state university, long beach > www.csulb.edu > > -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From sakamura at gmail.com Tue Jun 26 23:07:26 2012 From: sakamura at gmail.com (Ishmael Rufus) Date: Tue, 26 Jun 2012 23:07:26 -0500 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: I'm glad I'm not the only one that miss this one: http://www.csulb.edu It is in his signature and email address as well ;) On Tue, Jun 26, 2012 at 11:04 PM, Sadiq Saif wrote: > Accidentally sent that to Matthew only, > > mind sharing the domain name? > > On Tue, Jun 26, 2012 at 11:53 PM, Matthew Black > wrote: > > Google Safe Browsing and Firefox have marked our website as containing > malware. They claim our home page returns no results, but redirects users > to another compromised website couchtarts.com. > > > > We have thoroughly examined our root .htaccess and httpd.conf files and > are not redirecting to the problem target site. No recent changes either. > > > > We ran some NSLOOKUPs against various public DNS servers and > intermittently get results that are NOT our servers. > > > > We believe the DNS servers used by Google's crawler have been poisoned. > > > > Can anyone shed some light on this? > > > > matthew black > > information technology services > > california state university, long beach > > www.csulb.edu > > > > > > -- > Sadiq S > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org > > From sakamura at gmail.com Tue Jun 26 23:12:07 2012 From: sakamura at gmail.com (Ishmael Rufus) Date: Tue, 26 Jun 2012 23:12:07 -0500 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: I am also getting the same issue when accessing his website. On Tue, Jun 26, 2012 at 11:07 PM, Landon Stewart wrote: > Is it possible that some malicious software is listening and injecting a > redirect on the wire? We've seen this before with a Windows machine being > infected. > > On 26 June 2012 20:53, Matthew Black wrote: > > > Google Safe Browsing and Firefox have marked our website as containing > > malware. They claim our home page returns no results, but redirects users > > to another compromised website couchtarts.com. > > > > We have thoroughly examined our root .htaccess and httpd.conf files and > > are not redirecting to the problem target site. No recent changes either. > > > > We ran some NSLOOKUPs against various public DNS servers and > > intermittently get results that are NOT our servers. > > > > We believe the DNS servers used by Google's crawler have been poisoned. > > > > Can anyone shed some light on this? > > > > matthew black > > information technology services > > california state university, long beach > > www.csulb.edu > > > > > > > -- > Landon Stewart > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 > Web hosting and more "Ahead of the Rest": http://www.superbhosting.net > From mjwise at kapu.net Tue Jun 26 23:14:14 2012 From: mjwise at kapu.net (Michael J Wise) Date: Tue, 26 Jun 2012 21:14:14 -0700 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: On Jun 26, 2012, at 9:07 PM, Ishmael Rufus wrote: > I'm glad I'm not the only one that miss this one: > > http://www.csulb.edu > > It is in his signature and email address as well ;) The queries do seem to be taking a number of seconds, though, as opposed to being nearly instant when I reference the DNS servers of record directly. The results I get at home (via SpeakEasy) all appear correct, though. > On Tue, Jun 26, 2012 at 11:04 PM, Sadiq Saif wrote: > >> Accidentally sent that to Matthew only, >> >> mind sharing the domain name? >> >> On Tue, Jun 26, 2012 at 11:53 PM, Matthew Black >> wrote: >>> Google Safe Browsing and Firefox have marked our website as containing >> malware. They claim our home page returns no results, but redirects users >> to another compromised website couchtarts.com. >>> >>> We have thoroughly examined our root .htaccess and httpd.conf files and >> are not redirecting to the problem target site. No recent changes either. >>> >>> We ran some NSLOOKUPs against various public DNS servers and >> intermittently get results that are NOT our servers. >>> >>> We believe the DNS servers used by Google's crawler have been poisoned. >>> >>> Can anyone shed some light on this? >>> >>> matthew black >>> information technology services >>> california state university, long beach >>> www.csulb.edu >>> >> >> >> >> -- >> Sadiq S >> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org >> >> Aloha, Michael. -- "Please have your Internet License and Usenet Registration handy..." From dhubbard at dino.hostasaurus.com Tue Jun 26 23:14:17 2012 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 27 Jun 2012 00:14:17 -0400 Subject: DNS poisoning at Google? Message-ID: Typically if google were pulling your site sometimes from the wrong IP, their safe browsing page should indicate it being on another AS number in addition to the correct one 2152: http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http ://www.csulb.edu For example, the couchtarts site they claim yours is redirecting to: http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http ://www.couchtarts.com That site's DNS is screwed up and some requests are sent to a different IP at a different host, so Google picked up both AS numbers. Could one of your domain's subdomains be what is actually infected? You seem to have a bunch of them, maybe google is penalizing the whole domain over a subdomain? Not sure if they do that or not. If your sites are running off of an application like wordpress, etc., you may not get the same page that google gets and the application may have been hacked. Here's a wget command you can use to make requests to your site pretending to be google: wget -c \ --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \ --output-document=googlebot.html 'http://www.csulb.edu' nanog will probably line wrap that user agent line making it not correct so you'll have to put it back together correctly. It will save the output to a file named googlebot.html you can look at to see if anything weird ends up being served. David > -----Original Message----- > From: Matthew Black [mailto:Matthew.Black at csulb.edu] > Sent: Tuesday, June 26, 2012 11:53 PM > To: nanog at nanog.org > Subject: DNS poisoning at Google? > > Google Safe Browsing and Firefox have marked our website as > containing malware. They claim our home page returns no > results, but redirects users to another compromised website > couchtarts.com. > > We have thoroughly examined our root .htaccess and httpd.conf > files and are not redirecting to the problem target site. No > recent changes either. > > We ran some NSLOOKUPs against various public DNS servers and > intermittently get results that are NOT our servers. > > We believe the DNS servers used by Google's crawler have been > poisoned. > > Can anyone shed some light on this? > > matthew black > information technology services > california state university, long beach > www.csulb.edu > > > From sadiq at asininetech.com Tue Jun 26 23:15:43 2012 From: sadiq at asininetech.com (Sadiq Saif) Date: Wed, 27 Jun 2012 00:15:43 -0400 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: DNS seems to check out from here. Tested against Google DNS, OpenDNS and Linode's DNS servers. According to Google: "Malicious software is hosted on 1 domain(s), including couchtarts.com/." Normally, I would say this happens due to malicious ads loaded but this does not seem to be a site that will contain ads. :) On Wed, Jun 27, 2012 at 12:12 AM, Ishmael Rufus wrote: > I am also getting the same issue when accessing his website. > > On Tue, Jun 26, 2012 at 11:07 PM, Landon Stewart wrote: > >> Is it possible that some malicious software is listening and injecting a >> redirect on the wire? ?We've seen this before with a Windows machine being >> infected. >> >> On 26 June 2012 20:53, Matthew Black wrote: >> >> > Google Safe Browsing and Firefox have marked our website as containing >> > malware. They claim our home page returns no results, but redirects users >> > to another compromised website couchtarts.com. >> > >> > We have thoroughly examined our root .htaccess and httpd.conf files and >> > are not redirecting to the problem target site. No recent changes either. >> > >> > We ran some NSLOOKUPs against various public DNS servers and >> > intermittently get results that are NOT our servers. >> > >> > We believe the DNS servers used by Google's crawler have been poisoned. >> > >> > Can anyone shed some light on this? >> > >> > matthew black >> > information technology services >> > california state university, long beach >> > www.csulb.edu >> > >> > >> >> >> -- >> Landon Stewart >> Sr. Administrator >> Systems Engineering >> Superb Internet Corp - 888-354-6128 x 4199 >> Web hosting and more "Ahead of the Rest": http://www.superbhosting.net >> -- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From toasty at dragondata.com Tue Jun 26 23:21:21 2012 From: toasty at dragondata.com (Kevin Day) Date: Tue, 26 Jun 2012 23:21:21 -0500 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: On Jun 26, 2012, at 10:53 PM, Matthew Black wrote: > Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com. > > We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. > > We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. > > We believe the DNS servers used by Google's crawler have been poisoned. > > Can anyone shed some light on this? Not sure if it's related, but yesterday one of my clients (a top 500 alexa site) suddenly had most search results (when googling for things like the site's name) suddenly change to some other shady looking domain that's just sending 302 redirects to the real site. All the same search results are there, but they're now sending everyone to the wrong domain that's just redirecting to the correct place. No idea how Google thought this is correct and I'm totally failing at getting anyone's attention at Google to look into this. This coincided with this message from @google on twitter yesterday: Heads up: we're pushing a new Panda data refresh that noticeably affects only ~1% of queries worldwide. http://twitter.com/google/status/217366321879453696 But i'm not sure that's related either. -- Kevin From Matthew.Black at csulb.edu Tue Jun 26 23:24:26 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 04:24:26 +0000 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: Running Apache on three Solaris webservers behind a load balancer. No MS Windows! Not sure how malicious software could get between our load balancer and Unix servers. Thanks for the tip! matthew black information technology services california state university, long beach From: Landon Stewart [mailto:lstewart at superb.net] Sent: Tuesday, June 26, 2012 9:07 PM To: Matthew Black Cc: nanog at nanog.org Subject: Re: DNS poisoning at Google? Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected. On 26 June 2012 20:53, Matthew Black > wrote: Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com. We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. We believe the DNS servers used by Google's crawler have been poisoned. Can anyone shed some light on this? matthew black information technology services california state university, long beach www.csulb.edu -- Landon Stewart > Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From regnauld at nsrc.org Tue Jun 26 23:24:58 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 26 Jun 2012 21:24:58 -0700 Subject: DDI (DNS+DHCP+IPAM) Solutions In-Reply-To: References: Message-ID: On 26/06/2012, at 19.37, Eric Cables wrote: > Can anyone respond with their experience with DDI in an Enterprise > environment? Have the tools been useful/reliable? What is the pricing > model?Replies can be on, or off, list Have you looked at netdot (netdot.uoregon.edu) ? Cheers, Phil From Matthew.Black at csulb.edu Tue Jun 26 23:28:52 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 04:28:52 +0000 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: Running Apache on three Solaris servers behind a load balancer. I forgot how to lookup our AS number to see if it matches couchtarts. matthew black information technology services california state university, long beach -----Original Message----- From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] Sent: Tuesday, June 26, 2012 9:14 PM To: nanog at nanog.org Subject: RE: DNS poisoning at Google? Typically if google were pulling your site sometimes from the wrong IP, their safe browsing page should indicate it being on another AS number in addition to the correct one 2152: http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http ://www.csulb.edu For example, the couchtarts site they claim yours is redirecting to: http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http ://www.couchtarts.com That site's DNS is screwed up and some requests are sent to a different IP at a different host, so Google picked up both AS numbers. Could one of your domain's subdomains be what is actually infected? You seem to have a bunch of them, maybe google is penalizing the whole domain over a subdomain? Not sure if they do that or not. If your sites are running off of an application like wordpress, etc., you may not get the same page that google gets and the application may have been hacked. Here's a wget command you can use to make requests to your site pretending to be google: wget -c \ --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \ --output-document=googlebot.html 'http://www.csulb.edu' nanog will probably line wrap that user agent line making it not correct so you'll have to put it back together correctly. It will save the output to a file named googlebot.html you can look at to see if anything weird ends up being served. David > -----Original Message----- > From: Matthew Black [mailto:Matthew.Black at csulb.edu] > Sent: Tuesday, June 26, 2012 11:53 PM > To: nanog at nanog.org > Subject: DNS poisoning at Google? > > Google Safe Browsing and Firefox have marked our website as containing > malware. They claim our home page returns no results, but redirects > users to another compromised website couchtarts.com. > > We have thoroughly examined our root .htaccess and httpd.conf files > and are not redirecting to the problem target site. No recent changes > either. > > We ran some NSLOOKUPs against various public DNS servers and > intermittently get results that are NOT our servers. > > We believe the DNS servers used by Google's crawler have been > poisoned. > > Can anyone shed some light on this? > > matthew black > information technology services > california state university, long beach > www.csulb.edu > > > From sadiq at asininetech.com Tue Jun 26 23:33:24 2012 From: sadiq at asininetech.com (Sadiq Saif) Date: Wed, 27 Jun 2012 00:33:24 -0400 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: couchtarts.com seems to be hosted on a IP belonging to AS32244 (Liquid Web). On Wed, Jun 27, 2012 at 12:28 AM, Matthew Black wrote: > Running Apache on three Solaris servers behind a load balancer. > > I forgot how to lookup our AS number to see if it matches couchtarts. > > matthew black > information technology services > california state university, long beach > > > -----Original Message----- > From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] > Sent: Tuesday, June 26, 2012 9:14 PM > To: nanog at nanog.org > Subject: RE: DNS poisoning at Google? > > Typically if google were pulling your site sometimes from the wrong IP, their safe browsing page should indicate it being on another AS number in addition to the correct one 2152: > > http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http > ://www.csulb.edu > > For example, the couchtarts site they claim yours is redirecting to: > > http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http > ://www.couchtarts.com > > That site's DNS is screwed up and some requests are sent to a different IP at a different host, so Google picked up both AS numbers. > > Could one of your domain's subdomains be what is actually infected? ?You seem to have a bunch of them, maybe google is penalizing the whole domain over a subdomain? ?Not sure if they do that or not. > > If your sites are running off of an application like wordpress, etc., you may not get the same page that google gets and the application may have been hacked. > Here's a wget command you can use to make requests to your site pretending to be google: > > wget -c \ > --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; > +http://www.google.com/bot.html)" \ > --output-document=googlebot.html 'http://www.csulb.edu' > > nanog will probably line wrap that user agent line making it not correct so you'll have to put it back together correctly. ?It will save the output to a file named googlebot.html you can look at to see if anything weird ends up being served. > > David > > >> -----Original Message----- >> From: Matthew Black [mailto:Matthew.Black at csulb.edu] >> Sent: Tuesday, June 26, 2012 11:53 PM >> To: nanog at nanog.org >> Subject: DNS poisoning at Google? >> >> Google Safe Browsing and Firefox have marked our website as containing >> malware. They claim our home page returns no results, but redirects >> users to another compromised website couchtarts.com. >> >> We have thoroughly examined our root .htaccess and httpd.conf files >> and are not redirecting to the problem target site. No recent changes >> either. >> >> We ran some NSLOOKUPs against various public DNS servers and >> intermittently get results that are NOT our servers. >> >> We believe the DNS servers used by Google's crawler have been >> poisoned. >> >> Can anyone shed some light on this? >> >> matthew black >> information technology services >> california state university, long beach >> www.csulb.edu >> >> >> > > > > -- Sadiq S O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From sakamura at gmail.com Tue Jun 26 23:33:45 2012 From: sakamura at gmail.com (Ishmael Rufus) Date: Tue, 26 Jun 2012 23:33:45 -0500 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: Have you tried using Google Webmaster tools? On Tue, Jun 26, 2012 at 11:28 PM, Matthew Black wrote: > Running Apache on three Solaris servers behind a load balancer. > > I forgot how to lookup our AS number to see if it matches couchtarts. > > matthew black > information technology services > california state university, long beach > > > -----Original Message----- > From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] > Sent: Tuesday, June 26, 2012 9:14 PM > To: nanog at nanog.org > Subject: RE: DNS poisoning at Google? > > Typically if google were pulling your site sometimes from the wrong IP, > their safe browsing page should indicate it being on another AS number in > addition to the correct one 2152: > > http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http > ://www.csulb.edu > > For example, the couchtarts site they claim yours is redirecting to: > > http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http > ://www.couchtarts.com > > That site's DNS is screwed up and some requests are sent to a different IP > at a different host, so Google picked up both AS numbers. > > Could one of your domain's subdomains be what is actually infected? You > seem to have a bunch of them, maybe google is penalizing the whole domain > over a subdomain? Not sure if they do that or not. > > If your sites are running off of an application like wordpress, etc., you > may not get the same page that google gets and the application may have > been hacked. > Here's a wget command you can use to make requests to your site pretending > to be google: > > wget -c \ > --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; > +http://www.google.com/bot.html)" \ > --output-document=googlebot.html 'http://www.csulb.edu' > > nanog will probably line wrap that user agent line making it not correct > so you'll have to put it back together correctly. It will save the output > to a file named googlebot.html you can look at to see if anything weird > ends up being served. > > David > > > > -----Original Message----- > > From: Matthew Black [mailto:Matthew.Black at csulb.edu] > > Sent: Tuesday, June 26, 2012 11:53 PM > > To: nanog at nanog.org > > Subject: DNS poisoning at Google? > > > > Google Safe Browsing and Firefox have marked our website as containing > > malware. They claim our home page returns no results, but redirects > > users to another compromised website couchtarts.com. > > > > We have thoroughly examined our root .htaccess and httpd.conf files > > and are not redirecting to the problem target site. No recent changes > > either. > > > > We ran some NSLOOKUPs against various public DNS servers and > > intermittently get results that are NOT our servers. > > > > We believe the DNS servers used by Google's crawler have been > > poisoned. > > > > Can anyone shed some light on this? > > > > matthew black > > information technology services > > california state university, long beach > > www.csulb.edu > > > > > > > > > > > From Matthew.Black at csulb.edu Tue Jun 26 23:35:45 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 04:35:45 +0000 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: Yes, we?ve used the Google Webmaster Tools a lot today. Submitted multiple requests and they keep insisting that our site issues a redirect. Unable to duplicate the problem here. matthew black information technology services california state university, long beach From: Ishmael Rufus [mailto:sakamura at gmail.com] Sent: Tuesday, June 26, 2012 9:34 PM To: Matthew Black Cc: David Hubbard; nanog at nanog.org Subject: Re: DNS poisoning at Google? Have you tried using Google Webmaster tools? On Tue, Jun 26, 2012 at 11:28 PM, Matthew Black > wrote: Running Apache on three Solaris servers behind a load balancer. I forgot how to lookup our AS number to see if it matches couchtarts. matthew black information technology services california state university, long beach -----Original Message----- From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] Sent: Tuesday, June 26, 2012 9:14 PM To: nanog at nanog.org Subject: RE: DNS poisoning at Google? Typically if google were pulling your site sometimes from the wrong IP, their safe browsing page should indicate it being on another AS number in addition to the correct one 2152: http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http ://www.csulb.edu For example, the couchtarts site they claim yours is redirecting to: http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http ://www.couchtarts.com That site's DNS is screwed up and some requests are sent to a different IP at a different host, so Google picked up both AS numbers. Could one of your domain's subdomains be what is actually infected? You seem to have a bunch of them, maybe google is penalizing the whole domain over a subdomain? Not sure if they do that or not. If your sites are running off of an application like wordpress, etc., you may not get the same page that google gets and the application may have been hacked. Here's a wget command you can use to make requests to your site pretending to be google: wget -c \ --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \ --output-document=googlebot.html 'http://www.csulb.edu' nanog will probably line wrap that user agent line making it not correct so you'll have to put it back together correctly. It will save the output to a file named googlebot.html you can look at to see if anything weird ends up being served. David > -----Original Message----- > From: Matthew Black [mailto:Matthew.Black at csulb.edu] > Sent: Tuesday, June 26, 2012 11:53 PM > To: nanog at nanog.org > Subject: DNS poisoning at Google? > > Google Safe Browsing and Firefox have marked our website as containing > malware. They claim our home page returns no results, but redirects > users to another compromised website couchtarts.com. > > We have thoroughly examined our root .htaccess and httpd.conf files > and are not redirecting to the problem target site. No recent changes > either. > > We ran some NSLOOKUPs against various public DNS servers and > intermittently get results that are NOT our servers. > > We believe the DNS servers used by Google's crawler have been > poisoned. > > Can anyone shed some light on this? > > matthew black > information technology services > california state university, long beach > www.csulb.edu > > > From sakamura at gmail.com Tue Jun 26 23:44:54 2012 From: sakamura at gmail.com (Ishmael Rufus) Date: Tue, 26 Jun 2012 23:44:54 -0500 Subject: [MailServer Notification]Web Reputation Notification In-Reply-To: <7A3886824BCD43A3B4902A519DB6F501@PVT.COM> References: <7A3886824BCD43A3B4902A519DB6F501@PVT.COM> Message-ID: Access the site via domain name: SaferBrowsing message Access the site via IP: works fine. Interesting... On Tue, Jun 26, 2012 at 11:36 PM, Administrator wrote: > www.couchtarts.com has been detected as > suspicious URLs,and Tag and deliver has been > taken on 6/26/2012 10:36:04 PM. > Message details: > Server: MAIL > Sender: Matthew.Black at csulb.edu; > Recipient: sakamura at gmail.com;nanog at nanog.org; > Subject: Suspicious URL: RE: DNS poisoning at Google? > From sakamura at gmail.com Tue Jun 26 23:51:17 2012 From: sakamura at gmail.com (Ishmael Rufus) Date: Tue, 26 Jun 2012 23:51:17 -0500 Subject: [MailServer Notification]Web Reputation Notification In-Reply-To: References: <7A3886824BCD43A3B4902A519DB6F501@PVT.COM> Message-ID: Looks like it is fixed. slowbro.jpg On Tue, Jun 26, 2012 at 11:44 PM, Ishmael Rufus wrote: > Access the site via domain name: SaferBrowsing message > Access the site via IP: works fine. > > Interesting... > > > On Tue, Jun 26, 2012 at 11:36 PM, Administrator < > administrator at do.not.reply> wrote: > >> www.couchtarts.com has been detected as >> suspicious URLs,and Tag and deliver has been >> taken on 6/26/2012 10:36:04 PM. >> Message details: >> Server: MAIL >> Sender: Matthew.Black at csulb.edu; >> Recipient: sakamura at gmail.com;nanog at nanog.org; >> Subject: Suspicious URL: RE: DNS poisoning at Google? >> > > From sakamura at gmail.com Tue Jun 26 23:55:01 2012 From: sakamura at gmail.com (Ishmael Rufus) Date: Tue, 26 Jun 2012 23:55:01 -0500 Subject: [MailServer Notification]Web Reputation Notification In-Reply-To: References: <7A3886824BCD43A3B4902A519DB6F501@PVT.COM> Message-ID: IIRC Google safe browsing should be using its own DNS. Nevertheless, my experience with Google's DNS is that it takes at least 2 hours before DNS records would update. If anyone knows more feel free to shed any light on Google's DNS and Google SafeBrowsing. On Tue, Jun 26, 2012 at 11:51 PM, Matthew Black wrote: > Yes, isn?t it! What DNS server does Google Safe Browsing use?**** > > ** ** > > matthew black**** > > information technology services**** > > california state university, long beach**** > > ** ** > > ** ** > > ** ** > > *From:* Ishmael Rufus [mailto:sakamura at gmail.com] > *Sent:* Tuesday, June 26, 2012 9:45 PM > *To:* Matthew Black > *Cc:* nanog at nanog.org > *Subject:* Re: [MailServer Notification]Web Reputation Notification**** > > ** ** > > Access the site via domain name: SaferBrowsing message**** > > Access the site via IP: works fine.**** > > ** ** > > Interesting...**** > > On Tue, Jun 26, 2012 at 11:36 PM, Administrator < > administrator at do.not.reply> wrote:**** > > www.couchtarts.com has been detected as > suspicious URLs,and Tag and deliver has been > taken on 6/26/2012 10:36:04 PM. > Message details: > Server: MAIL > Sender: Matthew.Black at csulb.edu; > Recipient: sakamura at gmail.com;nanog at nanog.org; > Subject: Suspicious URL: RE: DNS poisoning at Google?**** > > ** ** > From mjwise at kapu.net Tue Jun 26 23:56:11 2012 From: mjwise at kapu.net (Michael J Wise) Date: Tue, 26 Jun 2012 21:56:11 -0700 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: <3C6EA8A8-B806-4B7E-9B82-68C528DFB2C1@kapu.net> On Jun 26, 2012, at 9:35 PM, Matthew Black wrote: > Yes, we?ve used the Google Webmaster Tools a lot today. Submitted multiple requests and they keep insisting that our site issues a redirect. Unable to duplicate the problem here. ? have you consulted the logs? If the redirect is there, it ? 1) might not be from the home page, and 2) could be in ? user content? awk '{if ($9 ~ /304/) { print $0 }}' access_log. ? or some such. Granted, might be a storm of " " -> index.html redirects, but they should be grep -v 'able in short order. You might also look for the rDNS of the Google spider to see exactly where it is looking, and what it sees. Aloha, Michael. -- "Please have your Internet License and Usenet Registration handy..." From jeremy at hq.newdream.net Tue Jun 26 23:59:00 2012 From: jeremy at hq.newdream.net (Jeremy Hanmer) Date: Tue, 26 Jun 2012 21:59:00 -0700 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: <7C8D73E5-9043-4D9A-A541-612138163763@hq.newdream.net> It's not DNS. If you're sure there's no htaccess files in place, check your content (even that stored in a database) for anything that might be altering data based on referrer. This simple test shows what I mean: Airy:~ user$ curl -e 'http://google.com' csulb.edu 301 Moved Permanently

Moved Permanently

The document has moved here.

Running curl without the -e argument gives the proper site contents. On Jun 26, 2012, at 9:35 PM, Matthew Black wrote: > Yes, we?ve used the Google Webmaster Tools a lot today. Submitted multiple requests and they keep insisting that our site issues a redirect. Unable to duplicate the problem here. > > matthew black > information technology services > california state university, long beach > > From: Ishmael Rufus [mailto:sakamura at gmail.com] > Sent: Tuesday, June 26, 2012 9:34 PM > To: Matthew Black > Cc: David Hubbard; nanog at nanog.org > Subject: Re: DNS poisoning at Google? > > Have you tried using Google Webmaster tools? > On Tue, Jun 26, 2012 at 11:28 PM, Matthew Black > wrote: > Running Apache on three Solaris servers behind a load balancer. > > I forgot how to lookup our AS number to see if it matches couchtarts. > > matthew black > information technology services > california state university, long beach > > -----Original Message----- > From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] > Sent: Tuesday, June 26, 2012 9:14 PM > To: nanog at nanog.org > Subject: RE: DNS poisoning at Google? > > Typically if google were pulling your site sometimes from the wrong IP, their safe browsing page should indicate it being on another AS number in addition to the correct one 2152: > > http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http > ://www.csulb.edu > > For example, the couchtarts site they claim yours is redirecting to: > > http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=http > ://www.couchtarts.com > > That site's DNS is screwed up and some requests are sent to a different IP at a different host, so Google picked up both AS numbers. > > Could one of your domain's subdomains be what is actually infected? You seem to have a bunch of them, maybe google is penalizing the whole domain over a subdomain? Not sure if they do that or not. > > If your sites are running off of an application like wordpress, etc., you may not get the same page that google gets and the application may have been hacked. > Here's a wget command you can use to make requests to your site pretending to be google: > > wget -c \ > --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; > +http://www.google.com/bot.html)" \ > --output-document=googlebot.html 'http://www.csulb.edu' > > nanog will probably line wrap that user agent line making it not correct so you'll have to put it back together correctly. It will save the output to a file named googlebot.html you can look at to see if anything weird ends up being served. > > David > > >> -----Original Message----- >> From: Matthew Black [mailto:Matthew.Black at csulb.edu] >> Sent: Tuesday, June 26, 2012 11:53 PM >> To: nanog at nanog.org >> Subject: DNS poisoning at Google? >> >> Google Safe Browsing and Firefox have marked our website as containing >> malware. They claim our home page returns no results, but redirects >> users to another compromised website couchtarts.com. >> >> We have thoroughly examined our root .htaccess and httpd.conf files >> and are not redirecting to the problem target site. No recent changes >> either. >> >> We ran some NSLOOKUPs against various public DNS servers and >> intermittently get results that are NOT our servers. >> >> We believe the DNS servers used by Google's crawler have been >> poisoned. >> >> Can anyone shed some light on this? >> >> matthew black >> information technology services >> california state university, long beach >> www.csulb.edu >> >> >> > > > > From Matthew.Black at csulb.edu Wed Jun 27 00:02:49 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 05:02:49 +0000 Subject: DNS poisoning at Google? In-Reply-To: <3C6EA8A8-B806-4B7E-9B82-68C528DFB2C1@kapu.net> References: <3C6EA8A8-B806-4B7E-9B82-68C528DFB2C1@kapu.net> Message-ID: Q:have you consulted the logs? Seriously? Our servers have multiple log files due to multiple virtual hosts. Our primary domain log file on just one server has over 600,000 records x 3 servers. Probably over 100,000 304 redirects in our logs. couchtarts.com does not appear in our log files. matthew black information technology services california state university, long beach -----Original Message----- From: Michael J Wise [mailto:mjwise at kapu.net] Sent: Tuesday, June 26, 2012 9:56 PM To: Matthew Black Cc: nanog at nanog.org Subject: Re: DNS poisoning at Google? On Jun 26, 2012, at 9:35 PM, Matthew Black wrote: > Yes, we've used the Google Webmaster Tools a lot today. Submitted multiple requests and they keep insisting that our site issues a redirect. Unable to duplicate the problem here. ... have you consulted the logs? If the redirect is there, it ... 1) might not be from the home page, and 2) could be in ... user content? awk '{if ($9 ~ /304/) { print $0 }}' access_log. ... or some such. Granted, might be a storm of " " -> index.html redirects, but they should be grep -v 'able in short order. You might also look for the rDNS of the Google spider to see exactly where it is looking, and what it sees. Aloha, Michael. -- "Please have your Internet License and Usenet Registration handy..." From Matthew.Black at csulb.edu Wed Jun 27 00:05:01 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 05:05:01 +0000 Subject: DNS poisoning at Google? In-Reply-To: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: Google Webtools reports a problem with our HOMEPAGE "/". That page is not redirecting anywhere. They also report problems with some 48 other primary sites, none of which redirect to the offending couchtarts. matthew black information technology services california state university, long beach -----Original Message----- From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com] Sent: Tuesday, June 26, 2012 9:58 PM To: Matthew Black Cc: nanog at nanog.org Subject: Re: DNS poisoning at Google? It's not DNS. If you're sure there's no htaccess files in place, check your content (even that stored in a database) for anything that might be altering data based on referrer. This simple test shows what I mean: Airy:~ user$ curl -e 'http://google.com' csulb.edu 301 Moved Permanently

Moved Permanently

The document has moved here.

Running curl without the -e argument gives the proper site contents. On Jun 26, 2012, at 9:24 PM, Matthew Black wrote: > Running Apache on three Solaris webservers behind a load balancer. No MS Windows! > > Not sure how malicious software could get between our load balancer and Unix servers. Thanks for the tip! > > matthew black > information technology services > california state university, long beach > > > > From: Landon Stewart [mailto:lstewart at superb.net] > Sent: Tuesday, June 26, 2012 9:07 PM > To: Matthew Black > Cc: nanog at nanog.org > Subject: Re: DNS poisoning at Google? > > Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected. > On 26 June 2012 20:53, Matthew Black > wrote: > Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com. > > We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. > > We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. > > We believe the DNS servers used by Google's crawler have been poisoned. > > Can anyone shed some light on this? > > matthew black > information technology services > california state university, long beach > www.csulb.edu > > > > -- > Landon Stewart > > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead > of the Rest": > http://www.superbhosting.net > From nanog at techmonkeys.org Wed Jun 27 00:12:31 2012 From: nanog at techmonkeys.org (Jeff Fisher) Date: Tue, 26 Jun 2012 23:12:31 -0600 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: <4FEA963F.7010500@techmonkeys.org> On 06/26/2012 11:05 PM, Matthew Black wrote: > Google Webtools reports a problem with our HOMEPAGE "/". That page is not redirecting anywhere. > They also report problems with some 48 other primary sites, none of which redirect to the offending couchtarts. Except it is redirecting as shown by Jeremy: [guppy at mrlaptop ~]$ curl -e 'http://google.com' csulb.edu 301 Moved Permanently

Moved Permanently

The document has moved here.

That looks like a redirect to me. Jeff From Matthew.Black at csulb.edu Wed Jun 27 00:13:45 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 05:13:45 +0000 Subject: DNS poisoning at Google? In-Reply-To: <7C8D73E5-9043-4D9A-A541-612138163763@hq.newdream.net> References: <7C8D73E5-9043-4D9A-A541-612138163763@hq.newdream.net> Message-ID: I'm not familiar with curl and don't understand what I type and what are results. Are you suggesting that when google refers to our website, we pick that up and redirect to couchtarts? matthew black information technology services california state university, long beach -----Original Message----- From: Jeremy Hanmer [mailto:jeremy at hq.newdream.net] Sent: Tuesday, June 26, 2012 9:59 PM To: Matthew Black Cc: nanog at nanog.org Subject: Re: DNS poisoning at Google? It's not DNS. If you're sure there's no htaccess files in place, check your content (even that stored in a database) for anything that might be altering data based on referrer. This simple test shows what I mean: Airy:~ user$ curl -e 'http://google.com' csulb.edu 301 Moved Permanently

Moved Permanently

The document has moved here.

Running curl without the -e argument gives the proper site contents. On Jun 26, 2012, at 9:35 PM, Matthew Black wrote: > Yes, we've used the Google Webmaster Tools a lot today. Submitted multiple requests and they keep insisting that our site issues a redirect. Unable to duplicate the problem here. > > matthew black > information technology services > california state university, long beach > > From: Ishmael Rufus [mailto:sakamura at gmail.com] > Sent: Tuesday, June 26, 2012 9:34 PM > To: Matthew Black > Cc: David Hubbard; nanog at nanog.org > Subject: Re: DNS poisoning at Google? > > Have you tried using Google Webmaster tools? > On Tue, Jun 26, 2012 at 11:28 PM, Matthew Black > wrote: > Running Apache on three Solaris servers behind a load balancer. > > I forgot how to lookup our AS number to see if it matches couchtarts. > > matthew black > information technology services > california state university, long beach > > -----Original Message----- > From: David Hubbard > [mailto:dhubbard at dino.hostasaurus.com .com>] > Sent: Tuesday, June 26, 2012 9:14 PM > To: nanog at nanog.org > Subject: RE: DNS poisoning at Google? > > Typically if google were pulling your site sometimes from the wrong IP, their safe browsing page should indicate it being on another AS number in addition to the correct one 2152: > > http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=ht > tp ://www.csulb.edu > > For example, the couchtarts site they claim yours is redirecting to: > > http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=ht > tp ://www.couchtarts.com > > That site's DNS is screwed up and some requests are sent to a different IP at a different host, so Google picked up both AS numbers. > > Could one of your domain's subdomains be what is actually infected? You seem to have a bunch of them, maybe google is penalizing the whole domain over a subdomain? Not sure if they do that or not. > > If your sites are running off of an application like wordpress, etc., you may not get the same page that google gets and the application may have been hacked. > Here's a wget command you can use to make requests to your site pretending to be google: > > wget -c \ > --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; > +http://www.google.com/bot.html)" \ > --output-document=googlebot.html 'http://www.csulb.edu' > > nanog will probably line wrap that user agent line making it not correct so you'll have to put it back together correctly. It will save the output to a file named googlebot.html you can look at to see if anything weird ends up being served. > > David > > >> -----Original Message----- >> From: Matthew Black >> [mailto:Matthew.Black at csulb.edu] >> Sent: Tuesday, June 26, 2012 11:53 PM >> To: nanog at nanog.org >> Subject: DNS poisoning at Google? >> >> Google Safe Browsing and Firefox have marked our website as >> containing malware. They claim our home page returns no results, but >> redirects users to another compromised website couchtarts.com. >> >> We have thoroughly examined our root .htaccess and httpd.conf files >> and are not redirecting to the problem target site. No recent changes >> either. >> >> We ran some NSLOOKUPs against various public DNS servers and >> intermittently get results that are NOT our servers. >> >> We believe the DNS servers used by Google's crawler have been >> poisoned. >> >> Can anyone shed some light on this? >> >> matthew black >> information technology services >> california state university, long beach >> www.csulb.edu >> >> >> > > > > From dhubbard at dino.hostasaurus.com Wed Jun 27 00:13:34 2012 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 27 Jun 2012 01:13:34 -0400 Subject: DNS poisoning at Google? Message-ID: Well as Jeremy pointed out, your site is issuing redirects, he gave you the command to show it: curl -e 'http://google.com' csulb.edu So if you're sure your server(s) haven't been hacked, your application appears to have been hacked. It only issues the redirect if the visitor comes in from a google search. > -----Original Message----- > From: Matthew Black [mailto:Matthew.Black at csulb.edu] > Sent: Wednesday, June 27, 2012 1:03 AM > To: Michael J Wise > Cc: nanog at nanog.org > Subject: RE: DNS poisoning at Google? > > Q:have you consulted the logs? > > Seriously? Our servers have multiple log files due to > multiple virtual hosts. Our primary domain log file on just > one server has over 600,000 records x 3 servers. > > Probably over 100,000 304 redirects in our logs. > > couchtarts.com does not appear in our log files. > > > matthew black > information technology services > california state university, long beach > > -----Original Message----- > From: Michael J Wise [mailto:mjwise at kapu.net] > Sent: Tuesday, June 26, 2012 9:56 PM > To: Matthew Black > Cc: nanog at nanog.org > Subject: Re: DNS poisoning at Google? > > > On Jun 26, 2012, at 9:35 PM, Matthew Black wrote: > > > Yes, we've used the Google Webmaster Tools a lot today. > Submitted multiple requests and they keep insisting that our > site issues a redirect. Unable to duplicate the problem here. > > ... have you consulted the logs? > If the redirect is there, it ... 1) might not be from the > home page, and 2) could be in ... user content? > > awk '{if ($9 ~ /304/) { print $0 }}' access_log. > ... or some such. > Granted, might be a storm of " " -> index.html redirects, but > they should be grep -v 'able in short order. > You might also look for the rDNS of the Google spider to see > exactly where it is looking, and what it sees. > > Aloha, > Michael. > -- > "Please have your Internet License > and Usenet Registration handy..." > > > > > > From sakamura at gmail.com Wed Jun 27 00:13:58 2012 From: sakamura at gmail.com (Ishmael Rufus) Date: Wed, 27 Jun 2012 00:13:58 -0500 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: Invoking the referrer on your site recommends a redirect to couchtarts. I agree with Jeremy and Jeff check your htaccess files, conf files and anything that calls RewriteCond or Rewrite On Wed, Jun 27, 2012 at 12:05 AM, Matthew Black wrote: > Google Webtools reports a problem with our HOMEPAGE "/". That page is not > redirecting anywhere. > They also report problems with some 48 other primary sites, none of which > redirect to the offending couchtarts. > > matthew black > information technology services > california state university, long beach > > > > > > -----Original Message----- > From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com] > Sent: Tuesday, June 26, 2012 9:58 PM > To: Matthew Black > Cc: nanog at nanog.org > Subject: Re: DNS poisoning at Google? > > It's not DNS. If you're sure there's no htaccess files in place, check > your content (even that stored in a database) for anything that might be > altering data based on referrer. This simple test shows what I mean: > > Airy:~ user$ curl -e 'http://google.com' csulb.edu "-//IETF//DTD HTML 2.0//EN"> > 301 Moved Permanently > >

Moved Permanently

>

The document has moved here.

> > > Running curl without the -e argument gives the proper site contents. > > On Jun 26, 2012, at 9:24 PM, Matthew Black > wrote: > > > Running Apache on three Solaris webservers behind a load balancer. No MS > Windows! > > > > Not sure how malicious software could get between our load balancer and > Unix servers. Thanks for the tip! > > > > matthew black > > information technology services > > california state university, long beach > > > > > > > > From: Landon Stewart [mailto:lstewart at superb.net] > > Sent: Tuesday, June 26, 2012 9:07 PM > > To: Matthew Black > > Cc: nanog at nanog.org > > Subject: Re: DNS poisoning at Google? > > > > Is it possible that some malicious software is listening and injecting a > redirect on the wire? We've seen this before with a Windows machine being > infected. > > On 26 June 2012 20:53, Matthew Black Matthew.Black at csulb.edu>> wrote: > > Google Safe Browsing and Firefox have marked our website as containing > malware. They claim our home page returns no results, but redirects users > to another compromised website couchtarts.com. > > > > We have thoroughly examined our root .htaccess and httpd.conf files and > are not redirecting to the problem target site. No recent changes either. > > > > We ran some NSLOOKUPs against various public DNS servers and > intermittently get results that are NOT our servers. > > > > We believe the DNS servers used by Google's crawler have been poisoned. > > > > Can anyone shed some light on this? > > > > matthew black > > information technology services > > california state university, long beach > > www.csulb.edu > > > > > > > > -- > > Landon Stewart > > > Sr. Administrator > > Systems Engineering > > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead > > of the Rest": > > http://www.superbhosting.net > > > > > > > From morrowc.lists at gmail.com Wed Jun 27 00:16:54 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 27 Jun 2012 01:16:54 -0400 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: for example, from the commandline with telnet: morrowc at teensy:~$ telnet www.csulb.edu 80 Trying 134.139.1.60... Connected to gaggle.its.csulb.edu. Escape character is '^]'. GET / HTTP/1.0 Host: www.csulb.edu Referer: http://www.google.com/ HTTP/1.1 301 Moved Permanently Date: Wed, 27 Jun 2012 05:04:04 GMT Server: Apache/2.0.63 Location: http://www.couchtarts.com/media.php Content-Length: 243 Connection: close Content-Type: text/html; charset=iso-8859-1 301 Moved Permanently

Moved Permanently

The document has moved here.

Connection closed by foreign host. oops :( fail. On Wed, Jun 27, 2012 at 1:13 AM, Ishmael Rufus wrote: > Invoking the referrer on your site recommends a redirect to couchtarts. I > agree with Jeremy and Jeff check your htaccess files, conf files and > anything that ?calls RewriteCond or Rewrite > > On Wed, Jun 27, 2012 at 12:05 AM, Matthew Black wrote: > >> Google Webtools reports a problem with our HOMEPAGE "/". That page is not >> redirecting anywhere. >> They also report problems with some 48 other primary sites, none of which >> redirect to the offending couchtarts. >> >> matthew black >> information technology services >> california state university, long beach >> >> >> >> >> >> -----Original Message----- >> From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com] >> Sent: Tuesday, June 26, 2012 9:58 PM >> To: Matthew Black >> Cc: nanog at nanog.org >> Subject: Re: DNS poisoning at Google? >> >> It's not DNS. ?If you're sure there's no htaccess files in place, check >> your content (even that stored in a database) for anything that might be >> altering data based on referrer. ?This simple test shows what I mean: >> >> Airy:~ user$ curl -e 'http://google.com' csulb.edu > "-//IETF//DTD HTML 2.0//EN"> >> 301 Moved Permanently >> >>

Moved Permanently

>>

The document has moved here.

>> >> >> Running curl without the -e argument gives the proper site contents. >> >> On Jun 26, 2012, at 9:24 PM, Matthew Black >> wrote: >> >> > Running Apache on three Solaris webservers behind a load balancer. No MS >> Windows! >> > >> > Not sure how malicious software could get between our load balancer and >> Unix servers. Thanks for the tip! >> > >> > matthew black >> > information technology services >> > california state university, long beach >> > >> > >> > >> > From: Landon Stewart [mailto:lstewart at superb.net] >> > Sent: Tuesday, June 26, 2012 9:07 PM >> > To: Matthew Black >> > Cc: nanog at nanog.org >> > Subject: Re: DNS poisoning at Google? >> > >> > Is it possible that some malicious software is listening and injecting a >> redirect on the wire? ?We've seen this before with a Windows machine being >> infected. >> > On 26 June 2012 20:53, Matthew Black > Matthew.Black at csulb.edu>> wrote: >> > Google Safe Browsing and Firefox have marked our website as containing >> malware. They claim our home page returns no results, but redirects users >> to another compromised website couchtarts.com. >> > >> > We have thoroughly examined our root .htaccess and httpd.conf files and >> are not redirecting to the problem target site. No recent changes either. >> > >> > We ran some NSLOOKUPs against various public DNS servers and >> intermittently get results that are NOT our servers. >> > >> > We believe the DNS servers used by Google's crawler have been poisoned. >> > >> > Can anyone shed some light on this? >> > >> > matthew black >> > information technology services >> > california state university, long beach >> > www.csulb.edu >> > >> > >> > >> > -- >> > Landon Stewart > >> > Sr. Administrator >> > Systems Engineering >> > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead >> > of the Rest": >> > http://www.superbhosting.net >> > >> >> >> >> >> From dmiller at tiggee.com Wed Jun 27 00:18:38 2012 From: dmiller at tiggee.com (David Miller) Date: Wed, 27 Jun 2012 01:18:38 -0400 Subject: DNS poisoning at Google? In-Reply-To: References: <7C8D73E5-9043-4D9A-A541-612138163763@hq.newdream.net> Message-ID: <4FEA97AE.9000103@tiggee.com> On 6/27/2012 1:13 AM, Matthew Black wrote: > I'm not familiar with curl and don't understand what I type and what are results. Are you suggesting that when google refers to our website, we pick that up and redirect to couchtarts? > > matthew black > information technology services > california state university, long beach Referer is an HTTP header that can be included in requests to your web server - http://en.wikipedia.org/wiki/HTTP_referer "man curl" -e, --referer (HTTP) Sends the "Referer Page" information to the HTTP server. This can also be set with the -H, --header flag of course. When used with -L, --location you can append ";auto" to the --referer URL to make curl automatically set the previous URL when it follows a Location: header. The ";auto" string can be used alone, even if you don't set an initial --referer. $ curl -v -e 'http://google.com' csulb.edu * About to connect() to csulb.edu port 80 (#0) * Trying 134.139.1.60... * connected * Connected to csulb.edu (134.139.1.60) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.24.0 (x86_64-pc-linux-gnu) libcurl/7.24.0 OpenSSL/1.0.0g zlib/1.2.5 > Host: csulb.edu > Accept: */* > Referer: http://google.com > < HTTP/1.1 301 Moved Permanently < Date: Wed, 27 Jun 2012 05:11:39 GMT < Server: Apache/2.0.63 < Location: http://www.couchtarts.com/media.php < Content-Length: 243 < Connection: close < Content-Type: text/html; charset=iso-8859-1 < 301 Moved Permanently

Moved Permanently

The document has moved here.

* Closing connection #0 -DMM > > > > > -----Original Message----- > From: Jeremy Hanmer [mailto:jeremy at hq.newdream.net] > Sent: Tuesday, June 26, 2012 9:59 PM > To: Matthew Black > Cc: nanog at nanog.org > Subject: Re: DNS poisoning at Google? > > It's not DNS. If you're sure there's no htaccess files in place, check your content (even that stored in a database) for anything that might be altering data based on referrer. This simple test shows what I mean: > > Airy:~ user$ curl -e 'http://google.com' csulb.edu > 301 Moved Permanently > >

Moved Permanently

>

The document has moved here.

> > > Running curl without the -e argument gives the proper site contents. > > On Jun 26, 2012, at 9:35 PM, Matthew Black wrote: > >> Yes, we've used the Google Webmaster Tools a lot today. Submitted multiple requests and they keep insisting that our site issues a redirect. Unable to duplicate the problem here. >> >> matthew black >> information technology services >> california state university, long beach >> >> From: Ishmael Rufus [mailto:sakamura at gmail.com] >> Sent: Tuesday, June 26, 2012 9:34 PM >> To: Matthew Black >> Cc: David Hubbard; nanog at nanog.org >> Subject: Re: DNS poisoning at Google? >> >> Have you tried using Google Webmaster tools? >> On Tue, Jun 26, 2012 at 11:28 PM, Matthew Black > wrote: >> Running Apache on three Solaris servers behind a load balancer. >> >> I forgot how to lookup our AS number to see if it matches couchtarts. >> >> matthew black >> information technology services >> california state university, long beach >> >> -----Original Message----- >> From: David Hubbard >> [mailto:dhubbard at dino.hostasaurus.com> .com>] >> Sent: Tuesday, June 26, 2012 9:14 PM >> To: nanog at nanog.org >> Subject: RE: DNS poisoning at Google? >> >> Typically if google were pulling your site sometimes from the wrong IP, their safe browsing page should indicate it being on another AS number in addition to the correct one 2152: >> >> http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=ht >> tp ://www.csulb.edu >> >> For example, the couchtarts site they claim yours is redirecting to: >> >> http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=ht >> tp ://www.couchtarts.com >> >> That site's DNS is screwed up and some requests are sent to a different IP at a different host, so Google picked up both AS numbers. >> >> Could one of your domain's subdomains be what is actually infected? You seem to have a bunch of them, maybe google is penalizing the whole domain over a subdomain? Not sure if they do that or not. >> >> If your sites are running off of an application like wordpress, etc., you may not get the same page that google gets and the application may have been hacked. >> Here's a wget command you can use to make requests to your site pretending to be google: >> >> wget -c \ >> --user-agent="Mozilla/5.0 (compatible; Googlebot/2.1; >> +http://www.google.com/bot.html)" \ >> --output-document=googlebot.html 'http://www.csulb.edu' >> >> nanog will probably line wrap that user agent line making it not correct so you'll have to put it back together correctly. It will save the output to a file named googlebot.html you can look at to see if anything weird ends up being served. >> >> David >> >> >>> -----Original Message----- >>> From: Matthew Black >>> [mailto:Matthew.Black at csulb.edu] >>> Sent: Tuesday, June 26, 2012 11:53 PM >>> To: nanog at nanog.org >>> Subject: DNS poisoning at Google? >>> >>> Google Safe Browsing and Firefox have marked our website as >>> containing malware. They claim our home page returns no results, but >>> redirects users to another compromised website couchtarts.com. >>> >>> We have thoroughly examined our root .htaccess and httpd.conf files >>> and are not redirecting to the problem target site. No recent changes >>> either. >>> >>> We ran some NSLOOKUPs against various public DNS servers and >>> intermittently get results that are NOT our servers. >>> >>> We believe the DNS servers used by Google's crawler have been >>> poisoned. >>> >>> Can anyone shed some light on this? >>> >>> matthew black >>> information technology services >>> california state university, long beach >>> www.csulb.edu >>> >>> >>> >> >> >> > > > From cgriffin at ufl.edu Wed Jun 27 00:20:46 2012 From: cgriffin at ufl.edu (Chris Griffin) Date: Wed, 27 Jun 2012 01:20:46 -0400 Subject: DNS poisoning at Google? In-Reply-To: References: Message-ID: <978D398C-6633-437C-B6DA-DA09968723A7@ufl.edu> Also shows a redirect if you use bing.com or yahoo.com (and probably others) but not, for instance, blah.com... Tnx Chris On Jun 27, 2012, at 1:13 AM, David Hubbard wrote: > Well as Jeremy pointed out, your site is issuing > redirects, he gave you the command to show it: > > curl -e 'http://google.com' csulb.edu > > So if you're sure your server(s) haven't been hacked, > your application appears to have been hacked. It only > issues the redirect if the visitor comes in from a > google search. > > > > >> -----Original Message----- >> From: Matthew Black [mailto:Matthew.Black at csulb.edu] >> Sent: Wednesday, June 27, 2012 1:03 AM >> To: Michael J Wise >> Cc: nanog at nanog.org >> Subject: RE: DNS poisoning at Google? >> >> Q:have you consulted the logs? >> >> Seriously? Our servers have multiple log files due to >> multiple virtual hosts. Our primary domain log file on just >> one server has over 600,000 records x 3 servers. >> >> Probably over 100,000 304 redirects in our logs. >> >> couchtarts.com does not appear in our log files. >> >> >> matthew black >> information technology services >> california state university, long beach >> >> -----Original Message----- >> From: Michael J Wise [mailto:mjwise at kapu.net] >> Sent: Tuesday, June 26, 2012 9:56 PM >> To: Matthew Black >> Cc: nanog at nanog.org >> Subject: Re: DNS poisoning at Google? >> >> >> On Jun 26, 2012, at 9:35 PM, Matthew Black wrote: >> >>> Yes, we've used the Google Webmaster Tools a lot today. >> Submitted multiple requests and they keep insisting that our >> site issues a redirect. Unable to duplicate the problem here. >> >> ... have you consulted the logs? >> If the redirect is there, it ... 1) might not be from the >> home page, and 2) could be in ... user content? >> >> awk '{if ($9 ~ /304/) { print $0 }}' access_log. >> ... or some such. >> Granted, might be a storm of " " -> index.html redirects, but >> they should be grep -v 'able in short order. >> You might also look for the rDNS of the Google spider to see >> exactly where it is looking, and what it sees. >> >> Aloha, >> Michael. >> -- >> "Please have your Internet License >> and Usenet Registration handy..." >> >> >> >> >> >> > --- Chris Griffin cgriffin at ufl.edu Sr. Network Engineer - CCNP Phone: (352) 273-1051 CNS - Network Services Fax: (352) 392-9440 University of Florida/FLR Gainesville, FL 32611 From Matthew.Black at csulb.edu Wed Jun 27 00:26:27 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 05:26:27 +0000 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: Thank you for that helpful instruction! curl doesn't work because our webserver is firewalled against outbound traffic. The telnet to port 80 showed me the problem. I also didn't understand when output was placed at the end of the command line, instead of starting on the next line...that looked like something I was supposed to type. matthew black information technology services california state university, long beac -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, June 26, 2012 10:17 PM To: Ishmael Rufus Cc: Matthew Black; nanog at nanog.org; Jeremy Hanmer Subject: Re: DNS poisoning at Google? for example, from the commandline with telnet: morrowc at teensy:~$ telnet www.csulb.edu 80 Trying 134.139.1.60... Connected to gaggle.its.csulb.edu. Escape character is '^]'. GET / HTTP/1.0 Host: www.csulb.edu Referer: http://www.google.com/ HTTP/1.1 301 Moved Permanently Date: Wed, 27 Jun 2012 05:04:04 GMT Server: Apache/2.0.63 Location: http://www.couchtarts.com/media.php Content-Length: 243 Connection: close Content-Type: text/html; charset=iso-8859-1 301 Moved Permanently

Moved Permanently

The document has moved here.

Connection closed by foreign host. oops :( fail. On Wed, Jun 27, 2012 at 1:13 AM, Ishmael Rufus wrote: > Invoking the referrer on your site recommends a redirect to > couchtarts. I agree with Jeremy and Jeff check your htaccess files, > conf files and anything that ?calls RewriteCond or Rewrite > > On Wed, Jun 27, 2012 at 12:05 AM, Matthew Black wrote: > >> Google Webtools reports a problem with our HOMEPAGE "/". That page is >> not redirecting anywhere. >> They also report problems with some 48 other primary sites, none of >> which redirect to the offending couchtarts. >> >> matthew black >> information technology services >> california state university, long beach >> >> >> >> >> >> -----Original Message----- >> From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com] >> Sent: Tuesday, June 26, 2012 9:58 PM >> To: Matthew Black >> Cc: nanog at nanog.org >> Subject: Re: DNS poisoning at Google? >> >> It's not DNS. ?If you're sure there's no htaccess files in place, >> check your content (even that stored in a database) for anything that >> might be altering data based on referrer. ?This simple test shows what I mean: >> >> Airy:~ user$ curl -e 'http://google.com' csulb.edu > PUBLIC "-//IETF//DTD HTML 2.0//EN"> >> 301 Moved Permanently >> >>

Moved Permanently

>>

The document has moved > href="http://www.couchtarts.com/media.php >> ">here.

>> >> >> Running curl without the -e argument gives the proper site contents. >> >> On Jun 26, 2012, at 9:24 PM, Matthew Black >> wrote: >> >> > Running Apache on three Solaris webservers behind a load balancer. >> > No MS >> Windows! >> > >> > Not sure how malicious software could get between our load balancer >> > and >> Unix servers. Thanks for the tip! >> > >> > matthew black >> > information technology services >> > california state university, long beach >> > >> > >> > >> > From: Landon Stewart [mailto:lstewart at superb.net] >> > Sent: Tuesday, June 26, 2012 9:07 PM >> > To: Matthew Black >> > Cc: nanog at nanog.org >> > Subject: Re: DNS poisoning at Google? >> > >> > Is it possible that some malicious software is listening and >> > injecting a >> redirect on the wire? ?We've seen this before with a Windows machine >> being infected. >> > On 26 June 2012 20:53, Matthew Black > Matthew.Black at csulb.edu>> wrote: >> > Google Safe Browsing and Firefox have marked our website as >> > containing >> malware. They claim our home page returns no results, but redirects >> users to another compromised website couchtarts.com. >> > >> > We have thoroughly examined our root .htaccess and httpd.conf files >> > and >> are not redirecting to the problem target site. No recent changes either. >> > >> > We ran some NSLOOKUPs against various public DNS servers and >> intermittently get results that are NOT our servers. >> > >> > We believe the DNS servers used by Google's crawler have been poisoned. >> > >> > Can anyone shed some light on this? >> > >> > matthew black >> > information technology services >> > california state university, long beach >> > www.csulb.edu >> > >> > >> > >> > -- >> > Landon Stewart > >> > Sr. Administrator >> > Systems Engineering >> > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more >> > "Ahead of the Rest": >> > http://www.superbhosting.net >> > >> >> >> >> >> From johnl at iecc.com Wed Jun 27 00:29:40 2012 From: johnl at iecc.com (John Levine) Date: 27 Jun 2012 05:29:40 -0000 Subject: DNS poisoning at Google? In-Reply-To: Message-ID: <20120627052940.75072.qmail@joyce.lan> In article you write: >I'm not familiar with curl and don't understand what I type and what are results. Are you suggesting that when >google refers to our website, we pick that up and redirect to couchtarts? curl is a command line www client that's worth knowing about. And I observe the same thing, using my own local DNS cache -- if I fetch the home page from csulb.edu or www.csulb.edu with Google as the referrer, it returns a page that redirects to couchtarts. Sorry, dude, you've been pwn3d. R's, John >Airy:~ user$ curl -e 'http://google.com' csulb.edu >301 Moved Permanently > >

Moved Permanently

>

The document has moved here.

> From morrowc.lists at gmail.com Wed Jun 27 00:32:12 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 27 Jun 2012 01:32:12 -0400 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: On Wed, Jun 27, 2012 at 1:26 AM, Matthew Black wrote: > Thank you for that helpful instruction! > > curl doesn't work because our webserver is firewalled against outbound traffic. The telnet to port 80 showed me the problem. I also didn't understand when output was placed at the end of the command line, instead of starting on the next line...that looked like something I was supposed to type. > sorry... often when I end up testing something like this I cut/paste from a buffer, so: telnet bloop 80 read-output... In the case of your server: GET / HTTP/1.0 Host: www.csulb.edu Referer: http://www.google.com/ all gets pasted once the 'telnet www.csulb.edu 80' connects... the output is the stuff that includes the 'redirect to couchtarts'. -chris > > matthew black > information technology services > california state university, long beac > > -----Original Message----- > From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow > Sent: Tuesday, June 26, 2012 10:17 PM > To: Ishmael Rufus > Cc: Matthew Black; nanog at nanog.org; Jeremy Hanmer > Subject: Re: DNS poisoning at Google? > > for example, from the commandline with telnet: > > morrowc at teensy:~$ telnet www.csulb.edu 80 Trying 134.139.1.60... > Connected to gaggle.its.csulb.edu. > Escape character is '^]'. > GET / HTTP/1.0 > Host: www.csulb.edu > Referer: http://www.google.com/ > > > > HTTP/1.1 301 Moved Permanently > Date: Wed, 27 Jun 2012 05:04:04 GMT > Server: Apache/2.0.63 > Location: http://www.couchtarts.com/media.php > Content-Length: 243 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > > 301 Moved Permanently > >

Moved Permanently

>

The document has moved href="http://www.couchtarts.com/media.php">here.

> > Connection closed by foreign host. > > > oops :( fail. > > On Wed, Jun 27, 2012 at 1:13 AM, Ishmael Rufus wrote: >> Invoking the referrer on your site recommends a redirect to >> couchtarts. I agree with Jeremy and Jeff check your htaccess files, >> conf files and anything that ?calls RewriteCond or Rewrite >> >> On Wed, Jun 27, 2012 at 12:05 AM, Matthew Black wrote: >> >>> Google Webtools reports a problem with our HOMEPAGE "/". That page is >>> not redirecting anywhere. >>> They also report problems with some 48 other primary sites, none of >>> which redirect to the offending couchtarts. >>> >>> matthew black >>> information technology services >>> california state university, long beach >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com] >>> Sent: Tuesday, June 26, 2012 9:58 PM >>> To: Matthew Black >>> Cc: nanog at nanog.org >>> Subject: Re: DNS poisoning at Google? >>> >>> It's not DNS. ?If you're sure there's no htaccess files in place, >>> check your content (even that stored in a database) for anything that >>> might be altering data based on referrer. ?This simple test shows what I mean: >>> >>> Airy:~ user$ curl -e 'http://google.com' csulb.edu >> PUBLIC "-//IETF//DTD HTML 2.0//EN"> >>> 301 Moved Permanently >>> >>>

Moved Permanently

>>>

The document has moved >> href="http://www.couchtarts.com/media.php >>> ">here.

>>> >>> >>> Running curl without the -e argument gives the proper site contents. >>> >>> On Jun 26, 2012, at 9:24 PM, Matthew Black >>> wrote: >>> >>> > Running Apache on three Solaris webservers behind a load balancer. >>> > No MS >>> Windows! >>> > >>> > Not sure how malicious software could get between our load balancer >>> > and >>> Unix servers. Thanks for the tip! >>> > >>> > matthew black >>> > information technology services >>> > california state university, long beach >>> > >>> > >>> > >>> > From: Landon Stewart [mailto:lstewart at superb.net] >>> > Sent: Tuesday, June 26, 2012 9:07 PM >>> > To: Matthew Black >>> > Cc: nanog at nanog.org >>> > Subject: Re: DNS poisoning at Google? >>> > >>> > Is it possible that some malicious software is listening and >>> > injecting a >>> redirect on the wire? ?We've seen this before with a Windows machine >>> being infected. >>> > On 26 June 2012 20:53, Matthew Black >> Matthew.Black at csulb.edu>> wrote: >>> > Google Safe Browsing and Firefox have marked our website as >>> > containing >>> malware. They claim our home page returns no results, but redirects >>> users to another compromised website couchtarts.com. >>> > >>> > We have thoroughly examined our root .htaccess and httpd.conf files >>> > and >>> are not redirecting to the problem target site. No recent changes either. >>> > >>> > We ran some NSLOOKUPs against various public DNS servers and >>> intermittently get results that are NOT our servers. >>> > >>> > We believe the DNS servers used by Google's crawler have been poisoned. >>> > >>> > Can anyone shed some light on this? >>> > >>> > matthew black >>> > information technology services >>> > california state university, long beach >>> > www.csulb.edu >>> > >>> > >>> > >>> > -- >>> > Landon Stewart > >>> > Sr. Administrator >>> > Systems Engineering >>> > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more >>> > "Ahead of the Rest": >>> > http://www.superbhosting.net >>> > >>> >>> >>> >>> >>> > > From Matthew.Black at csulb.edu Wed Jun 27 00:33:28 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 05:33:28 +0000 Subject: DNS poisoning at Google? In-Reply-To: <20120627052940.75072.qmail@joyce.lan> References: <20120627052940.75072.qmail@joyce.lan> Message-ID: Yes, thanks. I'll have to read up on that. My e-mail was showing extra stuff at the end of the sample command lines, which confused me: Airy:~ user$ curl -e 'http://google.com' csulb.edu ...................................................############################################################### Sigh, I just Outlook not to strip extra line breaks. matthew black information technology services california state university, long beach -----Original Message----- From: John Levine [mailto:johnl at iecc.com] Sent: Tuesday, June 26, 2012 10:30 PM To: nanog at nanog.org Cc: Matthew Black Subject: Re: DNS poisoning at Google? In article you write: >I'm not familiar with curl and don't understand what I type and what >are results. Are you suggesting that when google refers to our website, we pick that up and redirect to couchtarts? curl is a command line www client that's worth knowing about. And I observe the same thing, using my own local DNS cache -- if I fetch the home page from csulb.edu or www.csulb.edu with Google as the referrer, it returns a page that redirects to couchtarts. Sorry, dude, you've been pwn3d. R's, John >Airy:~ user$ curl -e 'http://google.com' csulb.edu PUBLIC "-//IETF//DTD HTML 2.0//EN"> >301 Moved Permanently > >

Moved Permanently

>

The document has moved href="http://www.couchtarts.com/media.php">here.

> From nicolas at ncartron.org Wed Jun 27 00:36:10 2012 From: nicolas at ncartron.org (Nicolas CARTRON) Date: Wed, 27 Jun 2012 07:36:10 +0200 Subject: DDI (DNS+DHCP+IPAM) Solutions In-Reply-To: References: Message-ID: Hi Eric, On Wed, Jun 27, 2012 at 4:37 AM, Eric Cables wrote: > [...] > Can anyone respond with their experience with DDI in an Enterprise > environment? Have the tools been useful/reliable? What is the pricing > model?Replies can be on, or off, list. Have you looked at EfficientIP (http://www.efficientip.com). Disclaimer: I'm working there. KInd regards, Nicolas. From lstewart at superb.net Wed Jun 27 00:36:55 2012 From: lstewart at superb.net (Landon Stewart) Date: Tue, 26 Jun 2012 22:36:55 -0700 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: There is definitely a 301 redirect. $ curl -I --referer http://www.google.com/ http://www.csulb.edu/ HTTP/1.1 301 Moved Permanently Date: Wed, 27 Jun 2012 05:36:31 GMT Server: Apache/2.0.63 Location: http://www.couchtarts.com/media.php Connection: close Content-Type: text/html; charset=iso-8859-1 On 26 June 2012 22:05, Matthew Black wrote: > Google Webtools reports a problem with our HOMEPAGE "/". That page is not > redirecting anywhere. > They also report problems with some 48 other primary sites, none of which > redirect to the offending couchtarts. > > matthew black > information technology services > california state university, long beach > > > > > > -----Original Message----- > From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com] > Sent: Tuesday, June 26, 2012 9:58 PM > To: Matthew Black > Cc: nanog at nanog.org > Subject: Re: DNS poisoning at Google? > > It's not DNS. If you're sure there's no htaccess files in place, check > your content (even that stored in a database) for anything that might be > altering data based on referrer. This simple test shows what I mean: > > Airy:~ user$ curl -e 'http://google.com' csulb.edu "-//IETF//DTD HTML 2.0//EN"> > 301 Moved Permanently > >

Moved Permanently

>

The document has moved here.

> > > Running curl without the -e argument gives the proper site contents. > > On Jun 26, 2012, at 9:24 PM, Matthew Black > wrote: > > > Running Apache on three Solaris webservers behind a load balancer. No MS > Windows! > > > > Not sure how malicious software could get between our load balancer and > Unix servers. Thanks for the tip! > > > > matthew black > > information technology services > > california state university, long beach > > > > > > > > From: Landon Stewart [mailto:lstewart at superb.net] > > Sent: Tuesday, June 26, 2012 9:07 PM > > To: Matthew Black > > Cc: nanog at nanog.org > > Subject: Re: DNS poisoning at Google? > > > > Is it possible that some malicious software is listening and injecting a > redirect on the wire? We've seen this before with a Windows machine being > infected. > > On 26 June 2012 20:53, Matthew Black Matthew.Black at csulb.edu>> wrote: > > Google Safe Browsing and Firefox have marked our website as containing > malware. They claim our home page returns no results, but redirects users > to another compromised website couchtarts.com. > > > > We have thoroughly examined our root .htaccess and httpd.conf files and > are not redirecting to the problem target site. No recent changes either. > > > > We ran some NSLOOKUPs against various public DNS servers and > intermittently get results that are NOT our servers. > > > > We believe the DNS servers used by Google's crawler have been poisoned. > > > > Can anyone shed some light on this? > > > > matthew black > > information technology services > > california state university, long beach > > www.csulb.edu > > > > > > > > -- > > Landon Stewart > > > Sr. Administrator > > Systems Engineering > > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead > > of the Rest": > > http://www.superbhosting.net > > > > > > > -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From Matthew.Black at csulb.edu Wed Jun 27 00:40:22 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 05:40:22 +0000 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: Thanks again to everyone who helped. I didn't know what to enter with curl, because Outlook clobbered the line breaks in Jeremy's original message. Also, curl failed on our primary webserver because of firewall and load balancer magic settings. The Telnet method worked better! Our team is now scouring for that hidden redirect to couchtarts. matthew black information technology services california state university, long beach From: Landon Stewart [mailto:lstewart at superb.net] Sent: Tuesday, June 26, 2012 10:37 PM To: Matthew Black Cc: Jeremy Hanmer; nanog at nanog.org Subject: Re: DNS poisoning at Google? There is definitely a 301 redirect. $ curl -I --referer http://www.google.com/ http://www.csulb.edu/ HTTP/1.1 301 Moved Permanently Date: Wed, 27 Jun 2012 05:36:31 GMT Server: Apache/2.0.63 Location: http://www.couchtarts.com/media.php Connection: close Content-Type: text/html; charset=iso-8859-1 On 26 June 2012 22:05, Matthew Black > wrote: Google Webtools reports a problem with our HOMEPAGE "/". That page is not redirecting anywhere. They also report problems with some 48 other primary sites, none of which redirect to the offending couchtarts. matthew black information technology services california state university, long beach -----Original Message----- From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com] Sent: Tuesday, June 26, 2012 9:58 PM To: Matthew Black Cc: nanog at nanog.org Subject: Re: DNS poisoning at Google? It's not DNS. If you're sure there's no htaccess files in place, check your content (even that stored in a database) for anything that might be altering data based on referrer. This simple test shows what I mean: Airy:~ user$ curl -e 'http://google.com' csulb.edu 301 Moved Permanently

Moved Permanently

The document has moved here.

Running curl without the -e argument gives the proper site contents. On Jun 26, 2012, at 9:24 PM, Matthew Black > wrote: > Running Apache on three Solaris webservers behind a load balancer. No MS Windows! > > Not sure how malicious software could get between our load balancer and Unix servers. Thanks for the tip! > > matthew black > information technology services > california state university, long beach > > > > From: Landon Stewart [mailto:lstewart at superb.net] > Sent: Tuesday, June 26, 2012 9:07 PM > To: Matthew Black > Cc: nanog at nanog.org > Subject: Re: DNS poisoning at Google? > > Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected. > On 26 June 2012 20:53, Matthew Black >> wrote: > Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com. > > We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. > > We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. > > We believe the DNS servers used by Google's crawler have been poisoned. > > Can anyone shed some light on this? > > matthew black > information technology services > california state university, long beach > www.csulb.edu > > > > -- > Landon Stewart >> > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead > of the Rest": > http://www.superbhosting.net > -- Landon Stewart > Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From shortdudey123 at gmail.com Wed Jun 27 00:52:32 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 27 Jun 2012 00:52:32 -0500 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: Matt, what happens you get on a subnet that can access the webservers directly and bypass the load balancer. Try curl then and see if its something w/ the webserver or load balancer. -Grant On Wed, Jun 27, 2012 at 12:40 AM, Matthew Black wrote: > Thanks again to everyone who helped. I didn't know what to enter with > curl, because Outlook clobbered the line breaks in Jeremy's original > message. > > Also, curl failed on our primary webserver because of firewall and load > balancer magic settings. The Telnet method worked better! > > Our team is now scouring for that hidden redirect to couchtarts. > > matthew black > information technology services > california state university, long beach > > > > From: Landon Stewart [mailto:lstewart at superb.net] > Sent: Tuesday, June 26, 2012 10:37 PM > To: Matthew Black > Cc: Jeremy Hanmer; nanog at nanog.org > Subject: Re: DNS poisoning at Google? > > There is definitely a 301 redirect. > > $ curl -I --referer http://www.google.com/ http://www.csulb.edu/ > HTTP/1.1 301 Moved Permanently > Date: Wed, 27 Jun 2012 05:36:31 GMT > Server: Apache/2.0.63 > Location: http://www.couchtarts.com/media.php > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > On 26 June 2012 22:05, Matthew Black Matthew.Black at csulb.edu>> wrote: > Google Webtools reports a problem with our HOMEPAGE "/". That page is not > redirecting anywhere. > They also report problems with some 48 other primary sites, none of which > redirect to the offending couchtarts. > > matthew black > information technology services > california state university, long beach > > > > > -----Original Message----- > From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com jeremy.hanmer at dreamhost.com>] > Sent: Tuesday, June 26, 2012 9:58 PM > To: Matthew Black > Cc: nanog at nanog.org > Subject: Re: DNS poisoning at Google? > It's not DNS. If you're sure there's no htaccess files in place, check > your content (even that stored in a database) for anything that might be > altering data based on referrer. This simple test shows what I mean: > > Airy:~ user$ curl -e 'http://google.com' csulb.edu > > 301 Moved Permanently > >

Moved Permanently

>

The document has moved here.

> > > Running curl without the -e argument gives the proper site contents. > On Jun 26, 2012, at 9:24 PM, Matthew Black > wrote: > > > Running Apache on three Solaris webservers behind a load balancer. No MS > Windows! > > > > Not sure how malicious software could get between our load balancer and > Unix servers. Thanks for the tip! > > > > matthew black > > information technology services > > california state university, long beach > > > > > > > > From: Landon Stewart [mailto:lstewart at superb.net lstewart at superb.net>] > > Sent: Tuesday, June 26, 2012 9:07 PM > > To: Matthew Black > > Cc: nanog at nanog.org > > Subject: Re: DNS poisoning at Google? > > > > Is it possible that some malicious software is listening and injecting a > redirect on the wire? We've seen this before with a Windows machine being > infected. > > On 26 June 2012 20:53, Matthew Black Matthew.Black at csulb.edu> Matthew.Black at csulb.edu>>> wrote: > > Google Safe Browsing and Firefox have marked our website as containing > malware. They claim our home page returns no results, but redirects users > to another compromised website couchtarts.com< > http://couchtarts.com>. > > > > We have thoroughly examined our root .htaccess and httpd.conf files and > are not redirecting to the problem target site. No recent changes either. > > > > We ran some NSLOOKUPs against various public DNS servers and > intermittently get results that are NOT our servers. > > > > We believe the DNS servers used by Google's crawler have been poisoned. > > > > Can anyone shed some light on this? > > > > matthew black > > information technology services > > california state university, long beach > > www.csulb.edu< > http://www.csulb.edu> > > > > > > > > -- > > Landon Stewart LStewart at Superb.Net>>> > > Sr. Administrator > > Systems Engineering > > Superb Internet Corp - 888-354-6128 x 4199 > Web hosting and more "Ahead > > of the Rest": > > http://www.superbhosting.net > > > > > > > > > -- > Landon Stewart > > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 > Web hosting and more "Ahead of the Rest": http://www.superbhosting.net< > http://www.superbhosting.net/> > > From jhellenthal at dataix.net Wed Jun 27 00:53:21 2012 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 27 Jun 2012 01:53:21 -0400 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: <20120627055321.GB27912@DataIX.net> On Tue, Jun 26, 2012 at 10:36:55PM -0700, Landon Stewart wrote: > There is definitely a 301 redirect. > > $ curl -I --referer http://www.google.com/ http://www.csulb.edu/ > HTTP/1.1 301 Moved Permanently > Date: Wed, 27 Jun 2012 05:36:31 GMT > Server: Apache/2.0.63 > Location: http://www.couchtarts.com/media.php > Connection: close > Content-Type: text/html; charset=iso-8859-1 > And if you visit http://www.couchtarts.com/media.php using the correct broser you end up back at http://google.com ... > On 26 June 2012 22:05, Matthew Black wrote: > > > Google Webtools reports a problem with our HOMEPAGE "/". That page is not > > redirecting anywhere. > > They also report problems with some 48 other primary sites, none of which > > redirect to the offending couchtarts. > > > > matthew black > > information technology services > > california state university, long beach > > > > > > > > > > > > -----Original Message----- > > From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com] > > Sent: Tuesday, June 26, 2012 9:58 PM > > To: Matthew Black > > Cc: nanog at nanog.org > > Subject: Re: DNS poisoning at Google? > > > > It's not DNS. If you're sure there's no htaccess files in place, check > > your content (even that stored in a database) for anything that might be > > altering data based on referrer. This simple test shows what I mean: > > > > Airy:~ user$ curl -e 'http://google.com' csulb.edu > "-//IETF//DTD HTML 2.0//EN"> > > 301 Moved Permanently > > > >

Moved Permanently

> >

The document has moved here.

> > > > > > Running curl without the -e argument gives the proper site contents. > > > > On Jun 26, 2012, at 9:24 PM, Matthew Black > > wrote: > > > > > Running Apache on three Solaris webservers behind a load balancer. No MS > > Windows! > > > > > > Not sure how malicious software could get between our load balancer and > > Unix servers. Thanks for the tip! > > > > > > matthew black > > > information technology services > > > california state university, long beach > > > > > > > > > > > > From: Landon Stewart [mailto:lstewart at superb.net] > > > Sent: Tuesday, June 26, 2012 9:07 PM > > > To: Matthew Black > > > Cc: nanog at nanog.org > > > Subject: Re: DNS poisoning at Google? > > > > > > Is it possible that some malicious software is listening and injecting a > > redirect on the wire? We've seen this before with a Windows machine being > > infected. > > > On 26 June 2012 20:53, Matthew Black > Matthew.Black at csulb.edu>> wrote: > > > Google Safe Browsing and Firefox have marked our website as containing > > malware. They claim our home page returns no results, but redirects users > > to another compromised website couchtarts.com. > > > > > > We have thoroughly examined our root .htaccess and httpd.conf files and > > are not redirecting to the problem target site. No recent changes either. > > > > > > We ran some NSLOOKUPs against various public DNS servers and > > intermittently get results that are NOT our servers. > > > > > > We believe the DNS servers used by Google's crawler have been poisoned. > > > > > > Can anyone shed some light on this? > > > > > > matthew black > > > information technology services > > > california state university, long beach > > > www.csulb.edu > > > > > > > > > > > > -- > > > Landon Stewart > > > > Sr. Administrator > > > Systems Engineering > > > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead > > > of the Rest": > > > http://www.superbhosting.net > > > > > > > > > > > > > > > > -- > Landon Stewart > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 > Web hosting and more "Ahead of the Rest": http://www.superbhosting.net -- - (2^(N-1)) From shortdudey123 at gmail.com Wed Jun 27 01:02:00 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 27 Jun 2012 01:02:00 -0500 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: It also redirects with facebook, youtube, and ebay but NOT amazon. -Grant On Wed, Jun 27, 2012 at 12:57 AM, Matthew Black wrote: > Our web lead was able to run curl. Thanks.**** > > ** ** > > matthew black**** > > information technology services**** > > california state university, long beach**** > > ** ** > > *From:* Grant Ridder [mailto:shortdudey123 at gmail.com] > *Sent:* Tuesday, June 26, 2012 10:53 PM > *To:* Matthew Black > *Cc:* Landon Stewart; nanog at nanog.org; Jeremy Hanmer > > *Subject:* Re: DNS poisoning at Google?**** > > ** ** > > Matt, what happens you get on a subnet that can access the webservers > directly and bypass the load balancer. Try curl then and see if its > something w/ the webserver or load balancer.**** > > ** ** > > -Grant**** > > On Wed, Jun 27, 2012 at 12:40 AM, Matthew Black > wrote:**** > > Thanks again to everyone who helped. I didn't know what to enter with > curl, because Outlook clobbered the line breaks in Jeremy's original > message. > > Also, curl failed on our primary webserver because of firewall and load > balancer magic settings. The Telnet method worked better! > > Our team is now scouring for that hidden redirect to couchtarts.**** > > > matthew black > information technology services > california state university, long beach > > > **** > > From: Landon Stewart [mailto:lstewart at superb.net]**** > > Sent: Tuesday, June 26, 2012 10:37 PM > To: Matthew Black > Cc: Jeremy Hanmer; nanog at nanog.org**** > > Subject: Re: DNS poisoning at Google?**** > > There is definitely a 301 redirect. > > $ curl -I --referer http://www.google.com/ http://www.csulb.edu/ > HTTP/1.1 301 Moved Permanently > Date: Wed, 27 Jun 2012 05:36:31 GMT > Server: Apache/2.0.63 > Location: http://www.couchtarts.com/media.php > Connection: close > Content-Type: text/html; charset=iso-8859-1**** > > On 26 June 2012 22:05, Matthew Black Matthew.Black at csulb.edu>> wrote: > Google Webtools reports a problem with our HOMEPAGE "/". That page is not > redirecting anywhere. > They also report problems with some 48 other primary sites, none of which > redirect to the offending couchtarts. > > matthew black > information technology services > california state university, long beach > > > > > -----Original Message-----**** > > From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com jeremy.hanmer at dreamhost.com>] > Sent: Tuesday, June 26, 2012 9:58 PM > To: Matthew Black**** > > Cc: nanog at nanog.org > Subject: Re: DNS poisoning at Google? > It's not DNS. If you're sure there's no htaccess files in place, check > your content (even that stored in a database) for anything that might be > altering data based on referrer. This simple test shows what I mean:**** > > Airy:~ user$ curl -e 'http://google.com' csulb.edu > **** > > 301 Moved Permanently > >

Moved Permanently

>

The document has moved here.

> > > Running curl without the -e argument gives the proper site contents.**** > > On Jun 26, 2012, at 9:24 PM, Matthew Black > wrote: > > > Running Apache on three Solaris webservers behind a load balancer. No MS > Windows! > > > > Not sure how malicious software could get between our load balancer and > Unix servers. Thanks for the tip! > > > > matthew black > > information technology services > > california state university, long beach > > > > > >**** > > > From: Landon Stewart [mailto:lstewart at superb.net lstewart at superb.net>]**** > > > Sent: Tuesday, June 26, 2012 9:07 PM > > To: Matthew Black**** > > > Cc: nanog at nanog.org**** > > > Subject: Re: DNS poisoning at Google? > > > > Is it possible that some malicious software is listening and injecting a > redirect on the wire? We've seen this before with a Windows machine being > infected.**** > > > On 26 June 2012 20:53, Matthew Black Matthew.Black at csulb.edu> Matthew.Black at csulb.edu>>> wrote: > > Google Safe Browsing and Firefox have marked our website as containing > malware. They claim our home page returns no results, but redirects users > to another compromised website couchtarts.com< > http://couchtarts.com>.**** > > > > > We have thoroughly examined our root .htaccess and httpd.conf files and > are not redirecting to the problem target site. No recent changes either. > > > > We ran some NSLOOKUPs against various public DNS servers and > intermittently get results that are NOT our servers. > > > > We believe the DNS servers used by Google's crawler have been poisoned. > > > > Can anyone shed some light on this? > > > > matthew black > > information technology services > > california state university, long beach**** > > > www.csulb.edu< > http://www.csulb.edu> > > > > > > > > -- > > Landon Stewart LStewart at Superb.Net>>> > > Sr. Administrator > > Systems Engineering > > Superb Internet Corp - 888-354-6128 x 4199 > Web hosting and more "Ahead**** > > > of the Rest": > > http://www.superbhosting.net > > > > > > > > > -- > Landon Stewart > > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 > Web hosting and more "Ahead of the Rest": http://www.superbhosting.net< > http://www.superbhosting.net/>**** > > ** ** > From mansaxel at besserwisser.org Wed Jun 27 01:45:59 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 27 Jun 2012 08:45:59 +0200 Subject: DDI (DNS+DHCP+IPAM) Solutions In-Reply-To: References: Message-ID: <20120627064559.GH16676@besserwisser.org> Subject: DDI (DNS+DHCP+IPAM) Solutions Date: Tue, Jun 26, 2012 at 07:37:36PM -0700 Quoting Eric Cables (ecables at gmail.com): > I'm looking to consolidate DNS/DHCP/IPAM into a single tool. Today I use > IPPlan for IPAM, and have been reasonably happy with it over the last 5+ > years, but I'd like to leverage the benefits of integrating DNS and DHCP > for real-time information, along with a more supportable solution for my > staff. It seems that InfoBlox and BlueCat are the top players, but maybe > I'm being fooled by the hype. > > Can anyone respond with their experience with DDI in an Enterprise > environment? Have the tools been useful/reliable? What is the pricing > model?Replies can be on, or off, list. We've been happy with InfoBlox. Big plusses are the AD integration and the do-everything-in-one-place solution. Not so happy about price, but it is hard to compete with free. InfoBlox is ISC daemons which means that you know what to expect. Most knobs in named.conf are available from the UI, although I sometimes have wished for QIP's freetext in named.conf feature. We run a non-HA pair of 1050 units as DHCP servers (using ISC-style fallover), and two HA pairs of 1050 as name servers and management node / backup management node. HA pairs is mostly overrated in name service, DNS being fault-tolerant as is, but the management interface is an exception where it is nice to have HA. To get economical scalability from relatively few hardware units we disable recursion and put OpenBSD servers with unbound as resolvers in front. The first entry in /etc/resolv.conf is anycasted from a number of such resolver hosts, using OpenOSPFd. I can not enough emphasize the goodness resulting from strict separation of resolvers and name servers. And anycasting means that I can gracefully remove a busy resolver from operation without anyone noticing since the next one will take over. The best part is that I got to PROVE to the Windows admins that Windows IS RFC-compliant wrt dynamic updates. Hilarious. Broke the bubble of Arthur C Clarke -compliant magic for many of them. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 If Robert Di Niro assassinates Walter Slezak, will Jodie Foster marry Bonzo?? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From Matthew.Black at csulb.edu Wed Jun 27 02:06:01 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 07:06:01 +0000 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: We found the aberrant .htaccess file and have removed it. What a mess! matthew black information technology services california state university, long beach From: Grant Ridder [mailto:shortdudey123 at gmail.com] Sent: Tuesday, June 26, 2012 11:02 PM To: Matthew Black; nanog at nanog.org Cc: Jeremy Hanmer Subject: Re: DNS poisoning at Google? It also redirects with facebook, youtube, and ebay but NOT amazon. -Grant On Wed, Jun 27, 2012 at 12:57 AM, Matthew Black > wrote: Our web lead was able to run curl. Thanks. matthew black information technology services california state university, long beach From: Grant Ridder [mailto:shortdudey123 at gmail.com] Sent: Tuesday, June 26, 2012 10:53 PM To: Matthew Black Cc: Landon Stewart; nanog at nanog.org; Jeremy Hanmer Subject: Re: DNS poisoning at Google? Matt, what happens you get on a subnet that can access the webservers directly and bypass the load balancer. Try curl then and see if its something w/ the webserver or load balancer. -Grant On Wed, Jun 27, 2012 at 12:40 AM, Matthew Black > wrote: Thanks again to everyone who helped. I didn't know what to enter with curl, because Outlook clobbered the line breaks in Jeremy's original message. Also, curl failed on our primary webserver because of firewall and load balancer magic settings. The Telnet method worked better! Our team is now scouring for that hidden redirect to couchtarts. matthew black information technology services california state university, long beach From: Landon Stewart [mailto:lstewart at superb.net] Sent: Tuesday, June 26, 2012 10:37 PM To: Matthew Black Cc: Jeremy Hanmer; nanog at nanog.org Subject: Re: DNS poisoning at Google? There is definitely a 301 redirect. $ curl -I --referer http://www.google.com/ http://www.csulb.edu/ HTTP/1.1 301 Moved Permanently Date: Wed, 27 Jun 2012 05:36:31 GMT Server: Apache/2.0.63 Location: http://www.couchtarts.com/media.php Connection: close Content-Type: text/html; charset=iso-8859-1 On 26 June 2012 22:05, Matthew Black >> wrote: Google Webtools reports a problem with our HOMEPAGE "/". That page is not redirecting anywhere. They also report problems with some 48 other primary sites, none of which redirect to the offending couchtarts. matthew black information technology services california state university, long beach -----Original Message----- From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com>] Sent: Tuesday, June 26, 2012 9:58 PM To: Matthew Black Cc: nanog at nanog.org> Subject: Re: DNS poisoning at Google? It's not DNS. If you're sure there's no htaccess files in place, check your content (even that stored in a database) for anything that might be altering data based on referrer. This simple test shows what I mean: Airy:~ user$ curl -e 'http://google.com' csulb.edu 301 Moved Permanently

Moved Permanently

The document has moved here.

Running curl without the -e argument gives the proper site contents. On Jun 26, 2012, at 9:24 PM, Matthew Black >> wrote: > Running Apache on three Solaris webservers behind a load balancer. No MS Windows! > > Not sure how malicious software could get between our load balancer and Unix servers. Thanks for the tip! > > matthew black > information technology services > california state university, long beach > > > > From: Landon Stewart [mailto:lstewart at superb.net>] > Sent: Tuesday, June 26, 2012 9:07 PM > To: Matthew Black > Cc: nanog at nanog.org> > Subject: Re: DNS poisoning at Google? > > Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected. > On 26 June 2012 20:53, Matthew Black >>>> wrote: > Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com. > > We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. > > We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. > > We believe the DNS servers used by Google's crawler have been poisoned. > > Can anyone shed some light on this? > > matthew black > information technology services > california state university, long beach > www.csulb.edu > > > > -- > Landon Stewart >>> > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead > of the Rest": > http://www.superbhosting.net > -- Landon Stewart >> Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From sparctacus at gmail.com Wed Jun 27 02:09:11 2012 From: sparctacus at gmail.com (Bryan Irvine) Date: Wed, 27 Jun 2012 00:09:11 -0700 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: The fun part will be figuring out how it got there. :) Sent from my iPhone On Jun 27, 2012, at 12:06 AM, Matthew Black wrote: > We found the aberrant .htaccess file and have removed it. What a mess! > > matthew black > information technology services > california state university, long beach > > From: Grant Ridder [mailto:shortdudey123 at gmail.com] > Sent: Tuesday, June 26, 2012 11:02 PM > To: Matthew Black; nanog at nanog.org > Cc: Jeremy Hanmer > Subject: Re: DNS poisoning at Google? > > It also redirects with facebook, youtube, and ebay but NOT amazon. > > -Grant > > On Wed, Jun 27, 2012 at 12:57 AM, Matthew Black > wrote: > Our web lead was able to run curl. Thanks. > > matthew black > information technology services > california state university, long beach > > From: Grant Ridder [mailto:shortdudey123 at gmail.com] > Sent: Tuesday, June 26, 2012 10:53 PM > To: Matthew Black > Cc: Landon Stewart; nanog at nanog.org; Jeremy Hanmer > > Subject: Re: DNS poisoning at Google? > > Matt, what happens you get on a subnet that can access the webservers directly and bypass the load balancer. Try curl then and see if its something w/ the webserver or load balancer. > > -Grant > On Wed, Jun 27, 2012 at 12:40 AM, Matthew Black > wrote: > Thanks again to everyone who helped. I didn't know what to enter with curl, because Outlook clobbered the line breaks in Jeremy's original message. > > Also, curl failed on our primary webserver because of firewall and load balancer magic settings. The Telnet method worked better! > > Our team is now scouring for that hidden redirect to couchtarts. > > matthew black > information technology services > california state university, long beach > > From: Landon Stewart [mailto:lstewart at superb.net] > Sent: Tuesday, June 26, 2012 10:37 PM > To: Matthew Black > Cc: Jeremy Hanmer; nanog at nanog.org > Subject: Re: DNS poisoning at Google? > There is definitely a 301 redirect. > > $ curl -I --referer http://www.google.com/ http://www.csulb.edu/ > HTTP/1.1 301 Moved Permanently > Date: Wed, 27 Jun 2012 05:36:31 GMT > Server: Apache/2.0.63 > Location: http://www.couchtarts.com/media.php > Connection: close > Content-Type: text/html; charset=iso-8859-1 > On 26 June 2012 22:05, Matthew Black >> wrote: > Google Webtools reports a problem with our HOMEPAGE "/". That page is not redirecting anywhere. > They also report problems with some 48 other primary sites, none of which redirect to the offending couchtarts. > > matthew black > information technology services > california state university, long beach > > > > > -----Original Message----- > From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com>] > Sent: Tuesday, June 26, 2012 9:58 PM > To: Matthew Black > Cc: nanog at nanog.org> > Subject: Re: DNS poisoning at Google? > It's not DNS. If you're sure there's no htaccess files in place, check your content (even that stored in a database) for anything that might be altering data based on referrer. This simple test shows what I mean: > Airy:~ user$ curl -e 'http://google.com' csulb.edu > 301 Moved Permanently > >

Moved Permanently

>

The document has moved here.

> > > Running curl without the -e argument gives the proper site contents. > On Jun 26, 2012, at 9:24 PM, Matthew Black >> wrote: > >> Running Apache on three Solaris webservers behind a load balancer. No MS Windows! >> >> Not sure how malicious software could get between our load balancer and Unix servers. Thanks for the tip! >> >> matthew black >> information technology services >> california state university, long beach >> >> >> >> From: Landon Stewart [mailto:lstewart at superb.net>] >> Sent: Tuesday, June 26, 2012 9:07 PM >> To: Matthew Black >> Cc: nanog at nanog.org> >> Subject: Re: DNS poisoning at Google? >> >> Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected. >> On 26 June 2012 20:53, Matthew Black >>>> wrote: >> Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com. >> >> We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. >> >> We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. >> >> We believe the DNS servers used by Google's crawler have been poisoned. >> >> Can anyone shed some light on this? >> >> matthew black >> information technology services >> california state university, long beach >> www.csulb.edu >> >> >> >> -- >> Landon Stewart >>> >> Sr. Administrator >> Systems Engineering >> Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead >> of the Rest": >> http://www.superbhosting.net >> > > > > > > > -- > Landon Stewart >> > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 > Web hosting and more "Ahead of the Rest": http://www.superbhosting.net > > From iam at st-andrews.ac.uk Wed Jun 27 02:11:50 2012 From: iam at st-andrews.ac.uk (Ian McDonald) Date: Wed, 27 Jun 2012 07:11:50 +0000 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> , Message-ID: Ahh, but how did it get there in the first place. Matthew, meet can of worms. I presume you have an opener. -- ian -----Original Message----- From: Matthew Black Sent: 27/06/2012, 08:07 To: Grant Ridder; nanog at nanog.org Cc: Jeremy Hanmer Subject: RE: DNS poisoning at Google? We found the aberrant .htaccess file and have removed it. What a mess! matthew black information technology services california state university, long beach From: Grant Ridder [mailto:shortdudey123 at gmail.com] Sent: Tuesday, June 26, 2012 11:02 PM To: Matthew Black; nanog at nanog.org Cc: Jeremy Hanmer Subject: Re: DNS poisoning at Google? It also redirects with facebook, youtube, and ebay but NOT amazon. -Grant On Wed, Jun 27, 2012 at 12:57 AM, Matthew Black > wrote: Our web lead was able to run curl. Thanks. matthew black information technology services california state university, long beach From: Grant Ridder [mailto:shortdudey123 at gmail.com] Sent: Tuesday, June 26, 2012 10:53 PM To: Matthew Black Cc: Landon Stewart; nanog at nanog.org; Jeremy Hanmer Subject: Re: DNS poisoning at Google? Matt, what happens you get on a subnet that can access the webservers directly and bypass the load balancer. Try curl then and see if its something w/ the webserver or load balancer. -Grant On Wed, Jun 27, 2012 at 12:40 AM, Matthew Black > wrote: Thanks again to everyone who helped. I didn't know what to enter with curl, because Outlook clobbered the line breaks in Jeremy's original message. Also, curl failed on our primary webserver because of firewall and load balancer magic settings. The Telnet method worked better! Our team is now scouring for that hidden redirect to couchtarts. matthew black information technology services california state university, long beach From: Landon Stewart [mailto:lstewart at superb.net] Sent: Tuesday, June 26, 2012 10:37 PM To: Matthew Black Cc: Jeremy Hanmer; nanog at nanog.org Subject: Re: DNS poisoning at Google? There is definitely a 301 redirect. $ curl -I --referer http://www.google.com/ http://www.csulb.edu/ HTTP/1.1 301 Moved Permanently Date: Wed, 27 Jun 2012 05:36:31 GMT Server: Apache/2.0.63 Location: http://www.couchtarts.com/media.php Connection: close Content-Type: text/html; charset=iso-8859-1 On 26 June 2012 22:05, Matthew Black >> wrote: Google Webtools reports a problem with our HOMEPAGE "/". That page is not redirecting anywhere. They also report problems with some 48 other primary sites, none of which redirect to the offending couchtarts. matthew black information technology services california state university, long beach -----Original Message----- From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com>] Sent: Tuesday, June 26, 2012 9:58 PM To: Matthew Black Cc: nanog at nanog.org> Subject: Re: DNS poisoning at Google? It's not DNS. If you're sure there's no htaccess files in place, check your content (even that stored in a database) for anything that might be altering data based on referrer. This simple test shows what I mean: Airy:~ user$ curl -e 'http://google.com' csulb.edu 301 Moved Permanently

Moved Permanently

The document has moved here.

Running curl without the -e argument gives the proper site contents. On Jun 26, 2012, at 9:24 PM, Matthew Black >> wrote: > Running Apache on three Solaris webservers behind a load balancer. No MS Windows! > > Not sure how malicious software could get between our load balancer and Unix servers. Thanks for the tip! > > matthew black > information technology services > california state university, long beach > > > > From: Landon Stewart [mailto:lstewart at superb.net>] > Sent: Tuesday, June 26, 2012 9:07 PM > To: Matthew Black > Cc: nanog at nanog.org> > Subject: Re: DNS poisoning at Google? > > Is it possible that some malicious software is listening and injecting a redirect on the wire? We've seen this before with a Windows machine being infected. > On 26 June 2012 20:53, Matthew Black >>>> wrote: > Google Safe Browsing and Firefox have marked our website as containing malware. They claim our home page returns no results, but redirects users to another compromised website couchtarts.com. > > We have thoroughly examined our root .htaccess and httpd.conf files and are not redirecting to the problem target site. No recent changes either. > > We ran some NSLOOKUPs against various public DNS servers and intermittently get results that are NOT our servers. > > We believe the DNS servers used by Google's crawler have been poisoned. > > Can anyone shed some light on this? > > matthew black > information technology services > california state university, long beach > www.csulb.edu > > > > -- > Landon Stewart >>> > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead > of the Rest": > http://www.superbhosting.net > -- Landon Stewart >> Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From sakamura at gmail.com Wed Jun 27 02:30:35 2012 From: sakamura at gmail.com (Ishmael Rufus) Date: Wed, 27 Jun 2012 02:30:35 -0500 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: I'll take files that shouldn't have level 7 permissions for $400 alex. On Wed, Jun 27, 2012 at 2:09 AM, Bryan Irvine wrote: > The fun part will be figuring out how it got there. :) > > Sent from my iPhone > > On Jun 27, 2012, at 12:06 AM, Matthew Black > wrote: > > > We found the aberrant .htaccess file and have removed it. What a mess! > > > > matthew black > > information technology services > > california state university, long beach > > > > From: Grant Ridder [mailto:shortdudey123 at gmail.com] > > Sent: Tuesday, June 26, 2012 11:02 PM > > To: Matthew Black; nanog at nanog.org > > Cc: Jeremy Hanmer > > Subject: Re: DNS poisoning at Google? > > > > It also redirects with facebook, youtube, and ebay but NOT amazon. > > > > -Grant > > > > On Wed, Jun 27, 2012 at 12:57 AM, Matthew Black > wrote: > > Our web lead was able to run curl. Thanks. > > > > matthew black > > information technology services > > california state university, long beach > > > > From: Grant Ridder [mailto:shortdudey123 at gmail.com shortdudey123 at gmail.com>] > > Sent: Tuesday, June 26, 2012 10:53 PM > > To: Matthew Black > > Cc: Landon Stewart; nanog at nanog.org; Jeremy > Hanmer > > > > Subject: Re: DNS poisoning at Google? > > > > Matt, what happens you get on a subnet that can access the webservers > directly and bypass the load balancer. Try curl then and see if its > something w/ the webserver or load balancer. > > > > -Grant > > On Wed, Jun 27, 2012 at 12:40 AM, Matthew Black > wrote: > > Thanks again to everyone who helped. I didn't know what to enter with > curl, because Outlook clobbered the line breaks in Jeremy's original > message. > > > > Also, curl failed on our primary webserver because of firewall and load > balancer magic settings. The Telnet method worked better! > > > > Our team is now scouring for that hidden redirect to couchtarts. > > > > matthew black > > information technology services > > california state university, long beach > > > > From: Landon Stewart [mailto:lstewart at superb.net lstewart at superb.net>] > > Sent: Tuesday, June 26, 2012 10:37 PM > > To: Matthew Black > > Cc: Jeremy Hanmer; nanog at nanog.org > > Subject: Re: DNS poisoning at Google? > > There is definitely a 301 redirect. > > > > $ curl -I --referer http://www.google.com/ http://www.csulb.edu/ > > HTTP/1.1 301 Moved Permanently > > Date: Wed, 27 Jun 2012 05:36:31 GMT > > Server: Apache/2.0.63 > > Location: http://www.couchtarts.com/media.php > > Connection: close > > Content-Type: text/html; charset=iso-8859-1 > > On 26 June 2012 22:05, Matthew Black Matthew.Black at csulb.edu> Matthew.Black at csulb.edu>>> wrote: > > Google Webtools reports a problem with our HOMEPAGE "/". That page is > not redirecting anywhere. > > They also report problems with some 48 other primary sites, none of > which redirect to the offending couchtarts. > > > > matthew black > > information technology services > > california state university, long beach > > > > > > > > > > -----Original Message----- > > From: Jeremy Hanmer [mailto:jeremy.hanmer at dreamhost.com jeremy.hanmer at dreamhost.com> jeremy.hanmer at dreamhost.com>>] > > Sent: Tuesday, June 26, 2012 9:58 PM > > To: Matthew Black > > Cc: nanog at nanog.org > > > Subject: Re: DNS poisoning at Google? > > It's not DNS. If you're sure there's no htaccess files in place, check > your content (even that stored in a database) for anything that might be > altering data based on referrer. This simple test shows what I mean: > > Airy:~ user$ curl -e 'http://google.com' csulb.edu< > http://csulb.edu> > > > 301 Moved Permanently > > > >

Moved Permanently

> >

The document has moved here.

> > > > > > Running curl without the -e argument gives the proper site contents. > > On Jun 26, 2012, at 9:24 PM, Matthew Black Matthew.Black at csulb.edu>>> wrote: > > > >> Running Apache on three Solaris webservers behind a load balancer. No > MS Windows! > >> > >> Not sure how malicious software could get between our load balancer and > Unix servers. Thanks for the tip! > >> > >> matthew black > >> information technology services > >> california state university, long beach > >> > >> > >> > >> From: Landon Stewart [mailto:lstewart at superb.net lstewart at superb.net> >>] > >> Sent: Tuesday, June 26, 2012 9:07 PM > >> To: Matthew Black > >> Cc: nanog at nanog.org > > >> Subject: Re: DNS poisoning at Google? > >> > >> Is it possible that some malicious software is listening and injecting > a redirect on the wire? We've seen this before with a Windows machine > being infected. > >> On 26 June 2012 20:53, Matthew Black Matthew.Black at csulb.edu> Matthew.Black at csulb.edu>> Matthew.Black at csulb.edu> Matthew.Black at csulb.edu>>>> wrote: > >> Google Safe Browsing and Firefox have marked our website as containing > malware. They claim our home page returns no results, but redirects users > to another compromised website couchtarts.com< > http://couchtarts.com>. > >> > >> We have thoroughly examined our root .htaccess and httpd.conf files and > are not redirecting to the problem target site. No recent changes either. > >> > >> We ran some NSLOOKUPs against various public DNS servers and > intermittently get results that are NOT our servers. > >> > >> We believe the DNS servers used by Google's crawler have been poisoned. > >> > >> Can anyone shed some light on this? > >> > >> matthew black > >> information technology services > >> california state university, long beach > >> www.csulb.edu< > http://www.csulb.edu> > >> > >> > >> > >> -- > >> Landon Stewart LStewart at Superb.Net> >>>> > >> Sr. Administrator > >> Systems Engineering > >> Superb Internet Corp - 888-354-6128 x 4199 > Web hosting and more "Ahead > >> of the Rest": > >> http://www.superbhosting.net > >> > > > > > > > > > > > > > > -- > > Landon Stewart LStewart at Superb.Net>>> > > Sr. Administrator > > Systems Engineering > > Superb Internet Corp - 888-354-6128 x 4199 > > Web hosting and more "Ahead of the Rest": http://www.superbhosting.net< > http://www.superbhosting.net/> > > > > > > From randy at psg.com Wed Jun 27 02:35:29 2012 From: randy at psg.com (Randy Bush) Date: Tue, 26 Jun 2012 21:35:29 -1000 Subject: strat-1 gps In-Reply-To: References: <20120626131538.1764d4eb@localhost> Message-ID: my experience with cdma was kinda funky and there already is a fancy gps antenna randy From mjwise at kapu.net Wed Jun 27 02:36:43 2012 From: mjwise at kapu.net (Michael J Wise) Date: Wed, 27 Jun 2012 00:36:43 -0700 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> Message-ID: <26707541-0B71-4291-980C-72C54E20B1D2@kapu.net> On Jun 27, 2012, at 12:06 AM, Matthew Black wrote: > We found the aberrant .htaccess file and have removed it. What a mess! Trusting you carefully noted the date/time stamp before removing it, as that's an important bit of forensics. Aloha, Michael. -- "Please have your Internet License and Usenet Registration handy..." From bmanning at vacation.karoshi.com Wed Jun 27 02:43:35 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 27 Jun 2012 07:43:35 +0000 Subject: strat-1 gps In-Reply-To: References: <20120626131538.1764d4eb@localhost> Message-ID: <20120627074335.GD7705@vacation.karoshi.com.> i've been using a earlier version of this: http://www.spectracomcorp.com/ProductsServices/TimingSynchronization/NetworkTimeServers/9483NetClockTimeServer/tabid/1439/Default.aspx On Tue, Jun 26, 2012 at 09:35:29PM -1000, Randy Bush wrote: > my experience with cdma was kinda funky > > and there already is a fancy gps antenna > > randy From bortzmeyer at nic.fr Wed Jun 27 02:50:51 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 27 Jun 2012 09:50:51 +0200 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: References: Message-ID: <20120627075051.GA11061@nic.fr> On Wed, Jun 27, 2012 at 03:53:17AM +0000, Matthew Black wrote a message of 18 lines which said: > We believe the DNS servers used by Google's crawler have been poisoned. [After reading the whole thread and discovering that Google was indeed right.] What made you think it can be a DNS cache poisoning (a very rare event, despite what the media say) when there are many much more realistic possibilities (specially for a Web site written in PHP)? What was the evidence pointing to a DNS problem? From drohan at gmail.com Wed Jun 27 03:07:56 2012 From: drohan at gmail.com (Daniel Rohan) Date: Wed, 27 Jun 2012 11:07:56 +0300 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: <20120627075051.GA11061@nic.fr> References: <20120627075051.GA11061@nic.fr> Message-ID: On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer wrote: What made you think it can be a DNS cache poisoning (a very rare > event, despite what the media say) when there are many much more > realistic possibilities (specially for a Web site written in > PHP)? > > What was the evidence pointing to a DNS problem? > It seems likely that he made a mistake in his analysis of the evidence. Something that could happen to anyone when operating outside of a comfort zone or having a bad day. Go easy. -DR From jethro.binks at strath.ac.uk Wed Jun 27 03:08:12 2012 From: jethro.binks at strath.ac.uk (Jethro R Binks) Date: Wed, 27 Jun 2012 09:08:12 +0100 (BST) Subject: DDI (DNS+DHCP+IPAM) Solutions In-Reply-To: References: Message-ID: On Tue, 26 Jun 2012, Eric Cables wrote: > I'm looking to consolidate DNS/DHCP/IPAM into a single tool. Today I > use IPPlan for IPAM, and have been reasonably happy with it over the > last 5+ years, but I'd like to leverage the benefits of integrating DNS > and DHCP for real-time information, along with a more supportable > solution for my staff. It seems that InfoBlox and BlueCat are the top > players, but maybe I'm being fooled by the hype. You might like to add EfficientIP to your list to investigate. (I haven't bought any yet). Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. From tshaw at oitc.com Wed Jun 27 06:50:19 2012 From: tshaw at oitc.com (TR Shaw) Date: Wed, 27 Jun 2012 07:50:19 -0400 Subject: DNS poisoning at Google? In-Reply-To: <26707541-0B71-4291-980C-72C54E20B1D2@kapu.net> References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> <26707541-0B71-4291-980C-72C54E20B1D2@kapu.net> Message-ID: <83A6778F-CFB7-4781-8B29-1CA6ECA8938B@oitc.com> On Jun 27, 2012, at 3:36 AM, Michael J Wise wrote: > > On Jun 27, 2012, at 12:06 AM, Matthew Black wrote: > >> We found the aberrant .htaccess file and have removed it. What a mess! > > > Trusting you carefully noted the date/time stamp before removing it, as that's an important bit of forensics. And done forget there is a trail on that file on your backups. Tom From fernando at gont.com.ar Wed Jun 27 06:29:34 2012 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 27 Jun 2012 13:29:34 +0200 Subject: New I-D on SLAAC DNS configuration problems (Fwd: New Version Notification for draft-gont-6man-slaac-dns-config-issues-00.txt) In-Reply-To: <20120615013626.31172.89725.idtracker@ietfa.amsl.com> References: <20120615013626.31172.89725.idtracker@ietfa.amsl.com> Message-ID: <4FEAEE9E.9060505@gont.com.ar> Folks, We have published a new Internet-Draft entitled "Current issues with DNS Configuration Options for SLAAC". This draft if meant to address the SLAAC DNS configuration issues raised by Pavel on the 6man mailing-list, and also discusses other potential issues. The I-D is available at: The I-D is aimed at 6man, so please considering weighing in the corresponding mailing-list (that of the 6man wg). Any comments will be highly appreciated (including off-list and posts to the nanog list). Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-6man-slaac-dns-config-issues-00.txt Date: Thu, 14 Jun 2012 18:36:26 -0700 From: internet-drafts at ietf.org To: fgont at si6networks.com CC: pavlix at pavlix.net A new version of I-D, draft-gont-6man-slaac-dns-config-issues-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-6man-slaac-dns-config-issues Revision: 00 Title: Current issues with DNS Configuration Options for SLAAC Creation date: 2012-06-15 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-gont-6man-slaac-dns-config-issues-00.txt Status: http://datatracker.ietf.org/doc/draft-gont-6man-slaac-dns-config-issues Htmlized: http://tools.ietf.org/html/draft-gont-6man-slaac-dns-config-issues-00 Abstract: RFC 6106 specifies two Neighbor Discovery options that can be included in Router Advertisement messages to convey information about DNS recursive servers and DNS Search Lists. Small lifetime values for the aforementioned options have been found to cause interoperability problems in those network scenarios in which these options are used to convey DNS-related information. This document analyzes the aforementioned problem, and formally updates RFC 6106 such that these issues are mitigated. The IETF Secretariat -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From dave at temk.in Wed Jun 27 07:59:04 2012 From: dave at temk.in (David Temkin) Date: Wed, 27 Jun 2012 08:59:04 -0400 Subject: NANOG 56 - Dallas, TX: Call For Presentations Message-ID: <4FEB0398.8070605@temk.in> NANOG Community, After a great NANOG in Vancouver, BC, the survey results are in from 55 and we are already assembling a world-class program for NANOG 56. The North American Network Operators' Group (NANOG) will hold its 56th meeting in Dallas, TX on October 21 - 23, 2012 and join with ARIN on October 24, 2012. Terremark, a Verzion company, will be our host for NANOG 56. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 56 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet. Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. NANOG 56 submissions are welcome at http://pc.nanog.org For further information on what the Program Committee is seeking, please see http://www.nanog.org/meetings/nanog56/callforpresentations.html When considering submitting a presentation, keep these important dates in mind: Presentation Abstracts and Draft Slides Due: 06-August-2012 Final Slides Due: 27-August-2012 Draft Program Published: 17-September-2012 Final Agenda Published: 1-October-2012 Please submit your materials to http://pc.nanog.org Looking forward to seeing everyone in Dallas! -Dave Temkin (Chair, NANOG Program Committee) From dave at temk.in Wed Jun 27 07:59:04 2012 From: dave at temk.in (David Temkin) Date: Wed, 27 Jun 2012 08:59:04 -0400 Subject: [NANOG-announce] NANOG 56 - Dallas, TX: Call For Presentations Message-ID: <4FEB0398.8070605@temk.in> NANOG Community, After a great NANOG in Vancouver, BC, the survey results are in from 55 and we are already assembling a world-class program for NANOG 56. The North American Network Operators' Group (NANOG) will hold its 56th meeting in Dallas, TX on October 21 - 23, 2012 and join with ARIN on October 24, 2012. Terremark, a Verzion company, will be our host for NANOG 56. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 56 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet. Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. NANOG 56 submissions are welcome at http://pc.nanog.org For further information on what the Program Committee is seeking, please see http://www.nanog.org/meetings/nanog56/callforpresentations.html When considering submitting a presentation, keep these important dates in mind: Presentation Abstracts and Draft Slides Due: 06-August-2012 Final Slides Due: 27-August-2012 Draft Program Published: 17-September-2012 Final Agenda Published: 1-October-2012 Please submit your materials to http://pc.nanog.org Looking forward to seeing everyone in Dallas! -Dave Temkin (Chair, NANOG Program Committee) -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From arturo.servin at gmail.com Wed Jun 27 08:14:12 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 27 Jun 2012 10:14:12 -0300 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: References: <20120627075051.GA11061@nic.fr> Message-ID: It was not DNS issue, but it was a clear case on how community-support helped. Some of us may even learn some new tricks. :) Regards, as Sent from mobile device. Excuse brevity and typos. On 27 Jun 2012, at 05:07, Daniel Rohan wrote: > On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer wrote: > > What made you think it can be a DNS cache poisoning (a very rare >> event, despite what the media say) when there are many much more >> realistic possibilities (specially for a Web site written in >> PHP)? >> >> What was the evidence pointing to a DNS problem? >> > > It seems likely that he made a mistake in his analysis of the evidence. > Something that could happen to anyone when operating outside of a comfort > zone or having a bad day. Go easy. > > -DR From jhellenthal at dataix.net Wed Jun 27 08:26:05 2012 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Wed, 27 Jun 2012 09:26:05 -0400 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: References: <20120627075051.GA11061@nic.fr> Message-ID: <20120627132604.GA74019@DataIX.net> What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded) On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote: > > It was not DNS issue, but it was a clear case on how community-support helped. > > Some of us may even learn some new tricks. :) > > Regards, > as > > Sent from mobile device. Excuse brevity and typos. > > > On 27 Jun 2012, at 05:07, Daniel Rohan wrote: > > > On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer wrote: > > > > What made you think it can be a DNS cache poisoning (a very rare > >> event, despite what the media say) when there are many much more > >> realistic possibilities (specially for a Web site written in > >> PHP)? > >> > >> What was the evidence pointing to a DNS problem? > >> > > > > It seems likely that he made a mistake in his analysis of the evidence. > > Something that could happen to anyone when operating outside of a comfort > > zone or having a bad day. Go easy. > > > > -DR > -- - (2^(N-1)) From ryan at u13.net Wed Jun 27 09:10:04 2012 From: ryan at u13.net (Ryan Rawdon) Date: Wed, 27 Jun 2012 10:10:04 -0400 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: <20120627132604.GA74019@DataIX.net> References: <20120627075051.GA11061@nic.fr> <20120627132604.GA74019@DataIX.net> Message-ID: <2BDC6728-6809-4525-A9E8-1D13357E30EE@u13.net> On Jun 27, 2012, at 9:26 AM, Jason Hellenthal wrote: > > What would be nice is the to see the contents of the htaccess file > (obviously with sensitive information excluded) I cleaned up compromises similar to this in a customer site fairly recently. In our case it was the same exact behavior but was php injected into their application, instead of .htaccess. I do not recall what the original compromise vector was, it was something in the customer's custom application which they resolved. It looked like the malware did a find and replace for > On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote: >> >>> >> > > -- > > - (2^(N-1)) > From ryan at u13.net Wed Jun 27 09:30:47 2012 From: ryan at u13.net (Ryan Rawdon) Date: Wed, 27 Jun 2012 10:30:47 -0400 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: <2BDC6728-6809-4525-A9E8-1D13357E30EE@u13.net> References: <20120627075051.GA11061@nic.fr> <20120627132604.GA74019@DataIX.net> <2BDC6728-6809-4525-A9E8-1D13357E30EE@u13.net> Message-ID: On Jun 27, 2012, at 10:10 AM, Ryan Rawdon wrote: > > > On Jun 27, 2012, at 9:26 AM, Jason Hellenthal wrote: > >> >> What would be nice is the to see the contents of the htaccess file >> (obviously with sensitive information excluded) > > > I cleaned up compromises similar to this in a customer site fairly recently. In our case it was the same exact behavior but was php injected into their application, instead of .htaccess. I do not recall what the original compromise vector was, it was something in the customer's custom application which they resolved. > > It looked like the malware did a find and replace for > http://r.u13.net/permatemp/forefront.png My message may have gotten caught as spam/malicious by filters. Not sure if it caught the base64 or plaintext so I snipped both. You can view my original message in the archives at http://mailman.nanog.org/pipermail/nanog/2012-June/049612.html > > > > (where brugge.osa.pl was the destination for the redirects in the compromise of this customer site) > > > >> >> On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote: >>> >>>> >>> >> >> -- >> >> - (2^(N-1)) >> > > From nanog at armoredpackets.com Wed Jun 27 10:05:07 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Wed, 27 Jun 2012 11:05:07 -0400 Subject: DNS poisoning at Google? In-Reply-To: <83A6778F-CFB7-4781-8B29-1CA6ECA8938B@oitc.com> References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> <26707541-0B71-4291-980C-72C54E20B1D2@kapu.net> <83A6778F-CFB7-4781-8B29-1CA6ECA8938B@oitc.com> Message-ID: <4FEB2123.2030003@armoredpackets.com> This may not help Matt now, but I just came across this today and believe it may help others who have to deal with incidents: http://cert.societegenerale.com/en/publications.html --> "IRM (Incident Response Methodologies)" If you changed the file contents before noting the created date, modified date, etc. then begin looking at your backups. This date will then help you track down the log entries and finally lead you to the root cause. Also, if possible, please post the culprit code that caused this, exif'ing the sensitive data of course :-) -- Thank you, Robert Miller http://www.armoredpackets.com Twitter: @arch3angel On 6/27/12 7:50 AM, TR Shaw wrote: > On Jun 27, 2012, at 3:36 AM, Michael J Wise wrote: > >> On Jun 27, 2012, at 12:06 AM, Matthew Black wrote: >> >>> We found the aberrant .htaccess file and have removed it. What a mess! >> >> Trusting you carefully noted the date/time stamp before removing it, as that's an important bit of forensics. > And done forget there is a trail on that file on your backups. > > Tom > > > From Matthew.Black at csulb.edu Wed Jun 27 11:48:45 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 16:48:45 +0000 Subject: DNS poisoning at Google? In-Reply-To: <26707541-0B71-4291-980C-72C54E20B1D2@kapu.net> References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> <26707541-0B71-4291-980C-72C54E20B1D2@kapu.net> Message-ID: Yes, we did that and also noted the username and IP address from where the FTP upload originated. matthew black information technology services california state university, long beach -----Original Message----- From: Michael J Wise [mailto:mjwise at kapu.net] Sent: Wednesday, June 27, 2012 12:37 AM To: nanog at nanog.org Subject: Re: DNS poisoning at Google? On Jun 27, 2012, at 12:06 AM, Matthew Black wrote: > We found the aberrant .htaccess file and have removed it. What a mess! Trusting you carefully noted the date/time stamp before removing it, as that's an important bit of forensics. Aloha, Michael. -- "Please have your Internet License and Usenet Registration handy..." From Matthew.Black at csulb.edu Wed Jun 27 11:51:53 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 16:51:53 +0000 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: <20120627132604.GA74019@DataIX.net> References: <20120627075051.GA11061@nic.fr> <20120627132604.GA74019@DataIX.net> Message-ID: Ask and ye shall receive: # more .htaccess (backup copy) #c3284d# RewriteEngine On RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|acoon|alexana|allesklar|allpages|allthesites|alltheuk|alltheweb|alt avista|america|amfibi|aol|apollo7|aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|bluewin|botw|brainysea rch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|clickz|clush|confex|cyber-content|daffodil|devaro|dmoz|d ogpile|ebay|ehow|eniro|entireweb|euroseek|exalead|excite|express|facebook|fastbot|filesearch|findelio|findhow|finditirel and|findloo|findwhat|finnalle|finnfirma|fireball|flemiro|flickr|freenet|friendsreunited|gasta|gigablast|gimpsy|globalsea rchdirectory|goo|google|goto|gulesider|hispavista|hotbot|hotfrog|icq|iesearch|ilse|infoseek|ireland-information|ixquick| jaan|jayde|jobrapido|kataweb|keyweb|kingdomseek|klammeraffe|km|kobala|kompass|kpnvandaag|kvasir|libero|limier|linkedin|l ive|liveinternet|lookle|lycos|mail|mamma|metabot|metacrawler|metaeureka|mojeek|msn|myspace|netscape|netzindex|nigma|nlse arch|nol9|oekoportal|openstat|orange|passagen|pocketflier|qp|qq|rambler|rtl|savio|schnellsuche|search|search-belgium|sea rchers|searchspot|sfr|sharelook|simplyhired|slider|sol|splut|spray|startpagina|startsiden|sucharchiv|suchbiene|suchbot|s uchknecht|suchmaschine|suchnase|sympatico|telfort|telia|teoma|terra|the-arena|thisisouryear|thunderstone|tiscali|t-onlin e|topseven|twitter|ukkey|uwe|verygoodsearch|vkontakte|voila|walhello|wanadoo|web|webalta|web-archiv|webcrawler|websuche| westaustraliaonline|wikipedia|wisenut|witch|wolong|ya|yahoo|yandex|yell|yippy|youtube|zoneru)\.(.*) RewriteRule ^(.*)$ http://www.couchtarts.com/media.php [R=301,L] #/c3284d# # # # matthew black information technology services california state university, long beach -----Original Message----- From: Jason Hellenthal [mailto:jhellenthal at dataix.net] Sent: Wednesday, June 27, 2012 6:26 AM To: Arturo Servin Cc: nanog at nanog.org Subject: Re: No DNS poisoning at Google (in case of trouble, blame the DNS) What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded) On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote: > > It was not DNS issue, but it was a clear case on how community-support helped. > > Some of us may even learn some new tricks. :) > > Regards, > as > > Sent from mobile device. Excuse brevity and typos. > > > On 27 Jun 2012, at 05:07, Daniel Rohan wrote: > > > On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer wrote: > > > > What made you think it can be a DNS cache poisoning (a very rare > >> event, despite what the media say) when there are many much more > >> realistic possibilities (specially for a Web site written in > >> PHP)? > >> > >> What was the evidence pointing to a DNS problem? > >> > > > > It seems likely that he made a mistake in his analysis of the evidence. > > Something that could happen to anyone when operating outside of a comfort > > zone or having a bad day. Go easy. > > > > -DR > -- - (2^(N-1)) From Matthew.Black at csulb.edu Wed Jun 27 11:56:31 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Wed, 27 Jun 2012 16:56:31 +0000 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: References: <20120627075051.GA11061@nic.fr> <20120627132604.GA74019@DataIX.net> Message-ID: By the way, FTP access originated from: 208.88.11.111 Sky Wire Communications SKYWIRE-SG (NET-208-88-8-0-1) 208.88.8.0 - 208.88.11.255 NetRange: 208.88.8.0 - 208.88.11.255 CIDR: 208.88.8.0/22 OriginAS: AS40603 NetName: SKYWIRE-SG NetHandle: NET-208-88-8-0-1 Parent: NET-208-0-0-0-0 NetType: Direct Allocation Comment: http://www.skywireusa.com RegDate: 2008-03-04 Updated: 2012-03-02 Ref: http://whois.arin.net/rest/net/NET-208-88-8-0-1 OrgName: Sky Wire Communications OrgId: DGSU Address: 946 W Sunset Blvd Ste L City: St George StateProv: UT PostalCode: 84770 Country: US RegDate: 2007-12-04 Updated: 2009-11-04 Ref: http://whois.arin.net/rest/org/DGSU Who We Are Skywire Communications is the Leading High Speed Internet Provider in Southern Utah. Offering Service in St George, Washington, Santa Clara, Ivins, Cedar City, and Enoch. It is the goal of SkyWire Communications to provide high speed internet access to 100 Percent of Southern Utah. We are located in St George, Utah. matthew black information technology services california state university, long beach -----Original Message----- From: Matthew Black [mailto:Matthew.Black at csulb.edu] Sent: Wednesday, June 27, 2012 9:52 AM To: 'Jason Hellenthal'; Arturo Servin Cc: nanog at nanog.org Subject: RE: No DNS poisoning at Google (in case of trouble, blame the DNS) Ask and ye shall receive: # more .htaccess (backup copy) #c3284d# RewriteEngine On RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|acoon|alexana|allesklar|allpages|allthesites|alltheuk|alltheweb|alt avista|america|amfibi|aol|apollo7|aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|bluewin|botw|brainysea rch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|clickz|clush|confex|cyber-content|daffodil|devaro|dmoz|d ogpile|ebay|ehow|eniro|entireweb|euroseek|exalead|excite|express|facebook|fastbot|filesearch|findelio|findhow|finditirel and|findloo|findwhat|finnalle|finnfirma|fireball|flemiro|flickr|freenet|friendsreunited|gasta|gigablast|gimpsy|globalsea rchdirectory|goo|google|goto|gulesider|hispavista|hotbot|hotfrog|icq|iesearch|ilse|infoseek|ireland-information|ixquick| jaan|jayde|jobrapido|kataweb|keyweb|kingdomseek|klammeraffe|km|kobala|kompass|kpnvandaag|kvasir|libero|limier|linkedin|l ive|liveinternet|lookle|lycos|mail|mamma|metabot|metacrawler|metaeureka|mojeek|msn|myspace|netscape|netzindex|nigma|nlse arch|nol9|oekoportal|openstat|orange|passagen|pocketflier|qp|qq|rambler|rtl|savio|schnellsuche|search|search-belgium|sea rchers|searchspot|sfr|sharelook|simplyhired|slider|sol|splut|spray|startpagina|startsiden|sucharchiv|suchbiene|suchbot|s uchknecht|suchmaschine|suchnase|sympatico|telfort|telia|teoma|terra|the-arena|thisisouryear|thunderstone|tiscali|t-onlin e|topseven|twitter|ukkey|uwe|verygoodsearch|vkontakte|voila|walhello|wanadoo|web|webalta|web-archiv|webcrawler|websuche| westaustraliaonline|wikipedia|wisenut|witch|wolong|ya|yahoo|yandex|yell|yippy|youtube|zoneru)\.(.*) RewriteRule ^(.*)$ http://www.couchtarts.com/media.php [R=301,L] #/c3284d# # # # matthew black information technology services california state university, long beach -----Original Message----- From: Jason Hellenthal [mailto:jhellenthal at dataix.net] Sent: Wednesday, June 27, 2012 6:26 AM To: Arturo Servin Cc: nanog at nanog.org Subject: Re: No DNS poisoning at Google (in case of trouble, blame the DNS) What would be nice is the to see the contents of the htaccess file (obviously with sensitive information excluded) On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote: > > It was not DNS issue, but it was a clear case on how community-support helped. > > Some of us may even learn some new tricks. :) > > Regards, > as > > Sent from mobile device. Excuse brevity and typos. > > > On 27 Jun 2012, at 05:07, Daniel Rohan wrote: > > > On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer wrote: > > > > What made you think it can be a DNS cache poisoning (a very rare > >> event, despite what the media say) when there are many much more > >> realistic possibilities (specially for a Web site written in > >> PHP)? > >> > >> What was the evidence pointing to a DNS problem? > >> > > > > It seems likely that he made a mistake in his analysis of the evidence. > > Something that could happen to anyone when operating outside of a comfort > > zone or having a bad day. Go easy. > > > > -DR > -- - (2^(N-1)) From mjkelly at gmail.com Wed Jun 27 12:18:33 2012 From: mjkelly at gmail.com (matt kelly) Date: Wed, 27 Jun 2012 13:18:33 -0400 Subject: Hotmail/live Message-ID: Can a hotmail/live.com postmaster contact me offlist please? Thanks From nanog at armoredpackets.com Wed Jun 27 12:26:36 2012 From: nanog at armoredpackets.com (AP NANOG) Date: Wed, 27 Jun 2012 13:26:36 -0400 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: References: <20120627075051.GA11061@nic.fr> <20120627132604.GA74019@DataIX.net> Message-ID: <4FEB424C.5010507@armoredpackets.com> On 6/27/12 12:51 PM, Matthew Black wrote: > Ask and ye shall receive: > > # more .htaccess (backup copy) > > #c3284d# > > RewriteEngine On > RewriteCond %{HTTP_REFERER} ^.*(abacho|abizdirectory|acoon|alexana|allesklar|allpages|allthesites|alltheuk|alltheweb|alt > avista|america|amfibi|aol|apollo7|aport|arcor|ask|atsearch|baidu|bellnet|bestireland|bhanvad|bing|bluewin|botw|brainysea > rch|bricabrac|browseireland|chapu|claymont|click4choice|clickey|clickz|clush|confex|cyber-content|daffodil|devaro|dmoz|d > ogpile|ebay|ehow|eniro|entireweb|euroseek|exalead|excite|express|facebook|fastbot|filesearch|findelio|findhow|finditirel > and|findloo|findwhat|finnalle|finnfirma|fireball|flemiro|flickr|freenet|friendsreunited|gasta|gigablast|gimpsy|globalsea > rchdirectory|goo|google|goto|gulesider|hispavista|hotbot|hotfrog|icq|iesearch|ilse|infoseek|ireland-information|ixquick| > jaan|jayde|jobrapido|kataweb|keyweb|kingdomseek|klammeraffe|km|kobala|kompass|kpnvandaag|kvasir|libero|limier|linkedin|l > ive|liveinternet|lookle|lycos|mail|mamma|metabot|metacrawler|metaeureka|mojeek|msn|myspace|netscape|netzindex|nigma|nlse > arch|nol9|oekoportal|openstat|orange|passagen|pocketflier|qp|qq|rambler|rtl|savio|schnellsuche|search|search-belgium|sea > rchers|searchspot|sfr|sharelook|simplyhired|slider|sol|splut|spray|startpagina|startsiden|sucharchiv|suchbiene|suchbot|s > uchknecht|suchmaschine|suchnase|sympatico|telfort|telia|teoma|terra|the-arena|thisisouryear|thunderstone|tiscali|t-onlin > e|topseven|twitter|ukkey|uwe|verygoodsearch|vkontakte|voila|walhello|wanadoo|web|webalta|web-archiv|webcrawler|websuche| > westaustraliaonline|wikipedia|wisenut|witch|wolong|ya|yahoo|yandex|yell|yippy|youtube|zoneru)\.(.*) > RewriteRule ^(.*)$ http://www.couchtarts.com/media.php [R=301,L] > > #/c3284d# > > # # # > > matthew black > information technology services > california state university, long beach > > > > -----Original Message----- > From: Jason Hellenthal [mailto:jhellenthal at dataix.net] > Sent: Wednesday, June 27, 2012 6:26 AM > To: Arturo Servin > Cc: nanog at nanog.org > Subject: Re: No DNS poisoning at Google (in case of trouble, blame the DNS) > > > What would be nice is the to see the contents of the htaccess file > (obviously with sensitive information excluded) > > On Wed, Jun 27, 2012 at 10:14:12AM -0300, Arturo Servin wrote: >> It was not DNS issue, but it was a clear case on how community-support helped. >> >> Some of us may even learn some new tricks. :) >> >> Regards, >> as >> >> Sent from mobile device. Excuse brevity and typos. >> >> >> On 27 Jun 2012, at 05:07, Daniel Rohan wrote: >> >>> On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer wrote: >>> >>> What made you think it can be a DNS cache poisoning (a very rare >>>> event, despite what the media say) when there are many much more >>>> realistic possibilities (specially for a Web site written in >>>> PHP)? >>>> >>>> What was the evidence pointing to a DNS problem? >>>> >>> It seems likely that he made a mistake in his analysis of the evidence. >>> Something that could happen to anyone when operating outside of a comfort >>> zone or having a bad day. Go easy. >>> >>> -DR G' did they miss anyone in that list of referers :-) Thanks for posting! -- Thank you, Robert Miller http://www.armoredpackets.com Twitter: @arch3angel From sparctacus at gmail.com Wed Jun 27 12:35:51 2012 From: sparctacus at gmail.com (Bryan Irvine) Date: Wed, 27 Jun 2012 10:35:51 -0700 Subject: DNS poisoning at Google? In-Reply-To: References: <00D9D692-17E6-408A-978B-F3E712D4CA9F@dreamhost.com> <26707541-0B71-4291-980C-72C54E20B1D2@kapu.net> Message-ID: On Wed, Jun 27, 2012 at 9:48 AM, Matthew Black wrote: > Yes, we did that and also noted the username and IP address from where the FTP upload originated. It came from an FTP upload? Why I outta ... ;-) From sylvie at newnog.org Wed Jun 27 17:33:57 2012 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Wed, 27 Jun 2012 18:33:57 -0400 Subject: [NANOG-announce] Announcing a Monday to Wednesday NANOG Program Starting at NANOG 57 (Feb 2013) Message-ID: Colleagues, At our NANOG 55 Community meeting Dave Temkin presented the PC proposal to move our Conference Program to a Monday-to-Wednesday format. Originating from the community, this proposal was developed and refined in the last year using the conference surveys. We surveyed you one last time at NANOG 55. The majority spoke in favour and the Board approved this change on June 22. I am pleased to announce that starting in February 2013, at NANOG 57 Orlando, the NANOG Conference program will : - start Monday morning with Tutorials; - have the Keynote kick off the Plenary after Monday's lunch; - add a standing Policy Track programmed by ARIN; - move the Peering Track to Wednesday afternoon. The net result will provide a Conference Program with 10% more content: +15 min of General Session and +90 min of Unique Track. On behalf of the Board, I would like to thank Nate Davis and John Curran (ARIN partners), Betty Burke (Executive Director), Dave Temkin (PC Chair), Greg Dendy (PC VIce-Chair) and each and every PC member (Nina, Jim, Tom, Ryan, Kevin, Igor, Greg H, Manish, Mohit, David, Dani, Tom, Michael, Tony) for the careful thought and consideration they afforded this proposal over the past 9 months. Have a great Summer and see you all next October for NANOG 56 in Dallas. Regards, Sylvie -- Sylvie LaPerriere NANOG Chair - www.nanog.org -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From hank at efes.iucc.ac.il Thu Jun 28 01:27:57 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 28 Jun 2012 09:27:57 +0300 (IDT) Subject: Looking for Geoff Message-ID: I am urgently trying to find Geoff but it appears he has left Telstra: : host pit-mail.telstra.net[203.50.40.14] said: 550 5.1.1 ... User unknown (in reply to RCPT TO command) Sorry for using the list but I don't know how else to find him. Please reply directly to me and not to the list. Thanks, Hank From jeroen at unfix.org Thu Jun 28 02:01:38 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 28 Jun 2012 03:01:38 -0400 Subject: Looking for Geoff In-Reply-To: References: Message-ID: <4FEC0152.7070306@unfix.org> On 2012-06-28 02:27, Hank Nussbacher wrote: > I am urgently trying to find Geoff but it appears he has left Telstra: > : host pit-mail.telstra.net[203.50.40.14] said: 550 5.1.1 > ... User unknown (in reply to RCPT TO command) > > Sorry for using the list but I don't know how else to find him. Please > reply directly to me and not to the list. He has been at APNIC for quite a large number of years already. Next to that there is always http://www.potaroo.net/ Google will tell the rest of the details. Greets, Jeroen From j at arpa.com Thu Jun 28 04:27:59 2012 From: j at arpa.com (jamie rishaw) Date: Thu, 28 Jun 2012 04:27:59 -0500 Subject: charter communications In-Reply-To: References: Message-ID: wow, the sh*t is really hitting the fan over there.. /this/ has got to be a record - I've never seen this before.. yikes. -snip- 20115 Origin IGP, localpref 100, external, atomic-aggregate ... Dampinfo: penalty 10766, flapped 99 times in 03:14:17, reuse in 00:03:03 ... (suppressed due to dampening) (history entry) -/snip- 99 flaps, 10K penalty.. ehhhhh. looks to be nationwide.. or multistate at the least. (Noc only confirms 'a few areas'). anyone w/411 on this? offlist replies well be kept off list.. -j From oscar.vives at gmail.com Thu Jun 28 06:05:30 2012 From: oscar.vives at gmail.com (Tei) Date: Thu, 28 Jun 2012 13:05:30 +0200 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: <20120627075051.GA11061@nic.fr> References: <20120627075051.GA11061@nic.fr> Message-ID: On 27 June 2012 09:50, Stephane Bortzmeyer wrote: >(specially for a Web site written in > PHP)? > We software makers have a problem, when a customer ask for a application, often theres a wen project that already do it ( for the most part is a round peg on a round hole). So a natural solution is to install this project and customize it to his needs (theme, perhaps some programming). The other option is to create a code from scratch (perhaps using a framework). If you create the code from scratch, it will be safe. A tree cant get a human virus, and a human can't get a tree virus. You are not unhackable, bad practices will byte you on the long term, but you don't see exploits made specifically for this custom made code daily. Too bad, the features the code allow will be few, limited to the budget to the project. Programming sucks, and generate code and bugs, and everybody suffer for it. This option suck. If you use these project that already do 99% of what the customer need, plus a 120% the customer not need (and perhaps don't want). The code quality will be normally be good, with **horrible** exceptions. But sooner or later, (weeks) there will be exploits for this codebase, to hack the site in horrible ways. If the customer don't pay maintenance and dont do the maintenance himself the code will turn comically outdated. Hacking the site will be easy for childrens age 5 and high. Maintenance suck. This option suck. All options suck. Your browser will call you a idiot if you try to browse with a outdated version. But web projects are not this rude on owners. So you have people browsing forums in Chrome 18, where the forums software is a version of 2004 ("heavily customized", but this will not save you). Then a cracker comes, uses a know exploit from 2008, and download 1.2 million unhashed passwords. Where 98% of these passwords are reused on facebook, twitter, linkedin and gmail. -- -- ?in del ?ensaje. From arturo.servin at gmail.com Thu Jun 28 07:48:08 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Thu, 28 Jun 2012 09:48:08 -0300 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: References: <20120627075051.GA11061@nic.fr> Message-ID: On 28 Jun 2012, at 08:05, Tei wrote: > On 27 June 2012 09:50, Stephane Bortzmeyer wrote: >> (specially for a Web site written in >> PHP)? >> > > We software makers have a problem, when a customer ask for a > application, often theres a wen project that already do it ( for the > most part is a round peg on a round hole). So a natural solution is to > install this project and customize it to his needs (theme, perhaps > some programming). The other option is to create a code from scratch > (perhaps using a framework). > > If you create the code from scratch, it will be safe. I would challenge this. This is not true unless you follow very strict rules to make your code safe, and even then, you are not completely safe. > A tree cant get > a human virus, and a human can't get a tree virus. You are not > unhackable, bad practices will byte you on the long term, but you > don't see exploits made specifically for this custom made code daily. Think about sql injection, they are not only to specific platforms but to general bad programming practices. =) Regards, as From oscar.vives at gmail.com Thu Jun 28 08:46:43 2012 From: oscar.vives at gmail.com (Tei) Date: Thu, 28 Jun 2012 15:46:43 +0200 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: References: <20120627075051.GA11061@nic.fr> Message-ID: On 28 June 2012 14:48, Arturo Servin wrote: ... > > ? ? ? ?Think about sql injection, they are not only to specific platforms but to general bad programming practices. If you are already a good programmer, writing code that is safe against sql inyections is trivial. So is not a real problem, and thats why I don't mention it. A real problem is one that you can't avoid by just walking one step to the left. But I support that you champion it, and I fully agree bad code is possible and some people do write it. We don't really disagree. -- -- ?in del ?ensaje. From ka at pacific.net Thu Jun 28 10:21:26 2012 From: ka at pacific.net (Ken A) Date: Thu, 28 Jun 2012 10:21:26 -0500 Subject: No DNS poisoning at Google (in case of trouble, blame the DNS) In-Reply-To: References: <20120627075051.GA11061@nic.fr> Message-ID: <4FEC7676.4060909@pacific.net> On 6/28/2012 6:05 AM, Tei wrote: > If you use these project that already do 99% of what the customer > need, plus a 120% the customer not need (and perhaps don't want). The > code quality will be normally be good, with **horrible** exceptions. > But sooner or later, (weeks) there will be exploits for this codebase, > to hack the site in horrible ways. If the customer don't pay > maintenance and dont do the maintenance himself the code will turn > comically outdated. Hacking the site will be easy for childrens age 5 > and high. Maintenance suck. This option suck. > > All options suck. That's why there are things like mod_security and other application level firewalls. After exploits have CVE numbers, so do the fixes to the firewalls. And, due to the cost of custom software, and ease of use of push button install Wordpress, this isn't likely to change soon. It would be nice if WP/Joomla/etc force auto-updated by default, at least for sec fixes.. Ken Pacific.Net From egermann at limanews.com Thu Jun 28 10:42:07 2012 From: egermann at limanews.com (Eric Germann) Date: Thu, 28 Jun 2012 08:42:07 -0700 Subject: Question about Martians on Vyatta Message-ID: <6244CA0E5130B349820CA2E8B24DC262537F1B40@VA3DIAXVSC31.RED001.local> All, I'm trying to understand why a Vyatta 6.4 collection of routers is carping about the following as martian routes: 113.107.174.14 27.73.1.159 94.248.215.60 95.26.105.161 They don't look like they fall in the traditional martian space. I also wondered if they were addresses without a reverse route, but they have reverse paths in our routing tables (full routes from AS 10796 and 11530). Any thoughts? EKG From nenolod at systeminplace.net Thu Jun 28 10:45:24 2012 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 28 Jun 2012 10:45:24 -0500 Subject: Question about Martians on Vyatta In-Reply-To: <6244CA0E5130B349820CA2E8B24DC262537F1B40@VA3DIAXVSC31.RED001.local> References: <6244CA0E5130B349820CA2E8B24DC262537F1B40@VA3DIAXVSC31.RED001.local> Message-ID: <75ADC307-D462-4CB5-8F7B-2B3B767A41EA@systeminplace.net> On Jun 28, 2012, at 10:42 AM, Eric Germann wrote: > All, > > I'm trying to understand why a Vyatta 6.4 collection of routers is carping about the following as martian routes: > > 113.107.174.14 > 27.73.1.159 > 94.248.215.60 > 95.26.105.161 > > They don't look like they fall in the traditional martian space. I also wondered if they were addresses without a reverse route, but they have reverse paths in our routing tables (full routes from AS 10796 and 11530). > > Any thoughts? > > EKG > Do you have routing-table entries which cover those IPs? Try "ip route show " as root. Linux NET/4 stack considers (as far as IPv4/IPv6 go) anything that is not in the routing table or an immediate neighbour as "martian." William From egermann at limanews.com Thu Jun 28 10:50:21 2012 From: egermann at limanews.com (Eric Germann) Date: Thu, 28 Jun 2012 08:50:21 -0700 Subject: Question about Martians on Vyatta In-Reply-To: <75ADC307-D462-4CB5-8F7B-2B3B767A41EA@systeminplace.net> References: <6244CA0E5130B349820CA2E8B24DC262537F1B40@VA3DIAXVSC31.RED001.local> <75ADC307-D462-4CB5-8F7B-2B3B767A41EA@systeminplace.net> Message-ID: <6244CA0E5130B349820CA2E8B24DC262537F1B46@VA3DIAXVSC31.RED001.local> Well, I did when I checked them shortly after I saw the log messages. Wondering now if the routes for those bounced and in the "middle" of the bounce, they're considered martian. Thanks! EKG -----Original Message----- From: William Pitcock [mailto:nenolod at systeminplace.net] Sent: Thursday, June 28, 2012 11:45 AM To: Eric Germann Cc: nanog at nanog.org Subject: Re: Question about Martians on Vyatta On Jun 28, 2012, at 10:42 AM, Eric Germann wrote: > All, > > I'm trying to understand why a Vyatta 6.4 collection of routers is carping about the following as martian routes: > > 113.107.174.14 > 27.73.1.159 > 94.248.215.60 > 95.26.105.161 > > They don't look like they fall in the traditional martian space. I also wondered if they were addresses without a reverse route, but they have reverse paths in our routing tables (full routes from AS 10796 and 11530). > > Any thoughts? > > EKG > Do you have routing-table entries which cover those IPs? Try "ip route show " as root. Linux NET/4 stack considers (as far as IPv4/IPv6 go) anything that is not in the routing table or an immediate neighbour as "martian." William From nenolod at systeminplace.net Thu Jun 28 11:12:49 2012 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 28 Jun 2012 11:12:49 -0500 Subject: Question about Martians on Vyatta In-Reply-To: <6244CA0E5130B349820CA2E8B24DC262537F1B46@VA3DIAXVSC31.RED001.local> References: <6244CA0E5130B349820CA2E8B24DC262537F1B40@VA3DIAXVSC31.RED001.local> <75ADC307-D462-4CB5-8F7B-2B3B767A41EA@systeminplace.net> <6244CA0E5130B349820CA2E8B24DC262537F1B46@VA3DIAXVSC31.RED001.local> Message-ID: <18DD9738-EEEC-4F4D-BFF2-B842A88DACAF@systeminplace.net> Hi, On Jun 28, 2012, at 10:50 AM, Eric Germann wrote: > Well, I did when I checked them shortly after I saw the log messages. > > Wondering now if the routes for those bounced and in the "middle" of the bounce, they're considered martian. Yes, that sounds reasonable. Anything that is returned on an interface which doesn't match what it should be in the routing table would also be considered "martian" if routing table entries apply to specific interfaces. Are you running BGP with a default route? That might be causing it as Linux network stack prefers more specific entries, so if you're getting a bounce over a different interface... William From mdevlin at aisle10.net Thu Jun 28 12:15:29 2012 From: mdevlin at aisle10.net (Mike Devlin) Date: Thu, 28 Jun 2012 13:15:29 -0400 Subject: technical contact at ATT Wireless Message-ID: Hi, Would anyone happen to know a contact at ATT wireless that would be able to help diagnose a DNS issue? we are seeing the DNS record for boston.com intermittantly resolve to the wrong IP address, but I am having trouble getting through to the correct people through normal support. Thanks Mike From paul4004 at gmail.com Thu Jun 28 14:35:33 2012 From: paul4004 at gmail.com (PC) Date: Thu, 28 Jun 2012 13:35:33 -0600 Subject: technical contact at ATT Wireless In-Reply-To: References: Message-ID: I wish you the best of luck. While you're at it, I've been also trying to complain about them using RFC1918 (172.16.) address space for the DNS servers they assign to their datacard subscribers. Causes all sorts of problems with people trying to VPN in as the same IP range is used by me. Why they don't use public IP space belonging to them for DNS servers, I do not know. -Paul On Thu, Jun 28, 2012 at 11:15 AM, Mike Devlin wrote: > Hi, > > Would anyone happen to know a contact at ATT wireless that would be able to > help diagnose a DNS issue? we are seeing the DNS record for boston.com > intermittantly resolve to the wrong IP address, but I am having trouble > getting through to the correct people through normal support. > > > Thanks > > Mike > From morrowc.lists at gmail.com Thu Jun 28 14:40:06 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 Jun 2012 15:40:06 -0400 Subject: technical contact at ATT Wireless In-Reply-To: References: Message-ID: On Thu, Jun 28, 2012 at 3:35 PM, PC wrote: > Why they don't use public IP space belonging to them for DNS servers, I do > not know. they have the same addresses used in multiple VRF's? so much simpler for them to manage... From paul4004 at gmail.com Thu Jun 28 15:20:51 2012 From: paul4004 at gmail.com (PC) Date: Thu, 28 Jun 2012 14:20:51 -0600 Subject: technical contact at ATT Wireless In-Reply-To: References: Message-ID: I'm sure they use carrier grade NAT, yes. However, nothing would prevent them from using a unique public IP assigned to them for their DNS servers like others do. Using RFC1918 space for a routed destination of an ISP service (DNS) is particularly problematic for many VPN client configurations with corporate address range overlap. -Paul On Thu, Jun 28, 2012 at 1:40 PM, Christopher Morrow wrote: > On Thu, Jun 28, 2012 at 3:35 PM, PC wrote: > > > Why they don't use public IP space belonging to them for DNS servers, I > do > > not know. > > they have the same addresses used in multiple VRF's? so much simpler > for them to manage... > From lou at metron.com Thu Jun 28 15:31:56 2012 From: lou at metron.com (Lou Katz) Date: Thu, 28 Jun 2012 13:31:56 -0700 Subject: Constant low-level attack Message-ID: <20120628203156.GA29870@metron.com> The other day, I looked carefully at my auth.log (Xubuntu 11.04) and discovered many lines of the form: Jun 28 13:13:54 localhost sshd[12654]: Bad protocol version identification '\200F\001\003\001' from 94.252.177.159 In the past day, I have recorded about 20,000 unique IP addresses used for this type of probe. I doubt if this is a surprise to anyone - my question is twofold: 1. Does anyone want this evergrowing list of, I assume, compromised machines? 2. Is there anything useful to do with this info other than put the IP addresses into a firewall reject table? I have done that and do see a certain amount of repeat hits. -=[L]=- -- From morrowc.lists at gmail.com Thu Jun 28 15:50:47 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 28 Jun 2012 16:50:47 -0400 Subject: technical contact at ATT Wireless In-Reply-To: References: Message-ID: On Thu, Jun 28, 2012 at 4:20 PM, PC wrote: > I'm sure they use carrier grade NAT, yes. I'm sure it's not 'carrier grade', but it does play one on tv... > However, nothing would prevent them from using a unique public IP assigned > to them for their DNS servers like others do. sure. they could do lots of things. > Using RFC1918 space for a routed destination of an ISP service (DNS) is > particularly problematic for many VPN client configurations with corporate > address range overlap. of course, but you aren't supposed to be doing that on their network anyway... so says the nice man from sprint 4 nanogs ago. -chris (yes, I realize that people use the 'wireless' network for all manner of things that the 'wireless carriers' are not always happy about, but hell, they do give out 'internet protocol' connections, they ought to expect people to 'use' them, eh?) From tshaw at oitc.com Thu Jun 28 16:52:36 2012 From: tshaw at oitc.com (TR Shaw) Date: Thu, 28 Jun 2012 17:52:36 -0400 Subject: Constant low-level attack In-Reply-To: <20120628203156.GA29870@metron.com> References: <20120628203156.GA29870@metron.com> Message-ID: <90182E62-192D-4FCD-9805-EF9088423D1D@oitc.com> On Jun 28, 2012, at 4:31 PM, Lou Katz wrote: > The other day, I looked carefully at my auth.log (Xubuntu 11.04) and discovered many lines > of the form: > > Jun 28 13:13:54 localhost sshd[12654]: Bad protocol version identification '\200F\001\003\001' from 94.252.177.159 > > In the past day, I have recorded about 20,000 unique IP addresses used for this type of probe. > I doubt if this is a surprise to anyone - my question is twofold: > > 1. Does anyone want this evergrowing list of, I assume, compromised machines? > 2. Is there anything useful to do with this info other than put the IP addresses into a firewall reject table? I have done > that and do see a certain amount of repeat hits. Just a note that if you were running fail2ban.org you would get automatic updates of your firewall and share the IPs with the community and get the advantage of the communities detections as well. From denys at visp.net.lb Thu Jun 28 16:53:56 2012 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Fri, 29 Jun 2012 00:53:56 +0300 Subject: Constant low-level attack In-Reply-To: <20120628203156.GA29870@metron.com> References: <20120628203156.GA29870@metron.com> Message-ID: <2c00f91466e833d17a77ba92bfb547a7@visp.net.lb> On 2012-06-28 23:31, Lou Katz wrote: > The other day, I looked carefully at my auth.log (Xubuntu 11.04) and > discovered many lines > of the form: > > Jun 28 13:13:54 localhost sshd[12654]: Bad protocol version > identification '\200F\001\003\001' from 94.252.177.159 > > In the past day, I have recorded about 20,000 unique IP addresses > used for this type of probe. > I doubt if this is a surprise to anyone - my question is twofold: > > 1. Does anyone want this evergrowing list of, I assume, compromised > machines? > 2. Is there anything useful to do with this info other than put the > IP addresses into a firewall reject table? I have done > that and do see a certain amount of repeat hits. > > -=[L]=- You can use fail2ban to block bruteforcing hosts automatically and even report to your mail their whois info http://www.fail2ban.org/ --- Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L. From jof at thejof.com Thu Jun 28 20:21:15 2012 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 28 Jun 2012 18:21:15 -0700 Subject: technical contact at ATT Wireless In-Reply-To: References: Message-ID: On Thu, Jun 28, 2012 at 1:50 PM, Christopher Morrow wrote: > of course, but you aren't supposed to be doing that on their network > anyway... so says the nice man from sprint 4 nanogs ago. That, and if you are tunneling in, it's good practice to forward over any DNS traffic as well (or all, depending on the application). That way, if you have internal names or special resolvers setup, you'll hit that as well. Cheers, jof From jmaslak at antelope.net Thu Jun 28 21:35:03 2012 From: jmaslak at antelope.net (Joel Maslak) Date: Thu, 28 Jun 2012 20:35:03 -0600 Subject: technical contact at ATT Wireless In-Reply-To: References: Message-ID: On Thu, Jun 28, 2012 at 1:35 PM, PC wrote: > While you're at it, I've been also trying to complain about them using > RFC1918 (172.16.) address space for the DNS servers they assign to their > datacard subscribers. ?Causes all sorts of problems with people trying to > VPN in as the same IP range is used by me. Which is why enterprises generally shouldn't use RFC1918 IPs for servers when clients are located on networks not controlled by the same entity. Servers that serve multiple administration domains (such as VPN users on AT&T - or on some random home Linksys box) probably shouldn't be addressed using addresses that conceivably could be used at the other end. But I'm probably fighting a losing battle saying that... It's why at my last enterprise net admin jobs, I refused to establish a site-to-site VPN session with organizations using RFC1918 space as part of the tunnel definition (it's amazing how few organizations wanted to use global IPs for inter-domain routing, but most came around, although I had to loan IP addresses to several so they could static NAT their servers behind them). It's simple: If I wouldn't accept IPs in that range over a public BGP peering, I didn't want it over a private static route either. I couldn't control what you did for RFC1918, nor could you control what I did - so I exposed public IPs, and expected you to do the same. :) RFC1918 and VPN becomes non-scalable fast when you connect to lots of different organizations - it doesn't take long before two organizations you connect to both want to use 172.16.0.x/24 or 10.0.0.x/24 or 192.168.0.0/24, or similar). The same logic goes for VPN clients - if one end is potentially using RFC1918, the other end better not use it. Since you can usually only control one end of the VPN for road-warrior VPN, it's best to make that end not use RFC1918. Otherwise you may find you need to route 192.168.x.y, but that just so happens to be the user's default gateway, name server, printer, or other key device. Of course having another set of NAT addresses for CGN will solve everything (yes, that's sarcastic, but I can predict how they'll be used to "solve" this type of problem). Just because "it usually works" doesn't mean using RFC1918 addresses for left and/or right subnets in a VPN is a good idea. From cb.list6 at gmail.com Thu Jun 28 21:53:36 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 28 Jun 2012 19:53:36 -0700 Subject: technical contact at ATT Wireless In-Reply-To: References: Message-ID: On Thu, Jun 28, 2012 at 7:35 PM, Joel Maslak wrote: > On Thu, Jun 28, 2012 at 1:35 PM, PC wrote: > >> While you're at it, I've been also trying to complain about them using >> RFC1918 (172.16.) address space for the DNS servers they assign to their >> datacard subscribers. ?Causes all sorts of problems with people trying to >> VPN in as the same IP range is used by me. > > Which is why enterprises generally shouldn't use RFC1918 IPs for > servers when clients are located on networks not controlled by the > same entity. ?Servers that serve multiple administration domains (such > as VPN users on AT&T - or on some random home Linksys box) probably > shouldn't be addressed using addresses that conceivably could be used > at the other end. ?But I'm probably fighting a losing battle saying > that... > > It's why at my last enterprise net admin jobs, I refused to establish > a site-to-site VPN session with organizations using RFC1918 space as > part of the tunnel definition (it's amazing how few organizations > wanted to use global IPs for inter-domain routing, but most came > around, although I had to loan IP addresses to several so they could > static NAT their servers behind them). ?It's simple: If I wouldn't > accept IPs in that range over a public BGP peering, I didn't want it > over a private static route either. ?I couldn't control what you did > for RFC1918, nor could you control what I did - so I exposed public > IPs, and expected you to do the same. ?:) > > RFC1918 and VPN becomes non-scalable fast when you connect to lots of > different organizations - it doesn't take long before two > organizations you connect to both want to use 172.16.0.x/24 or > 10.0.0.x/24 or 192.168.0.0/24, or similar). ?The same logic goes for > VPN clients - if one end is potentially using RFC1918, the other end > better not use it. ?Since you can usually only control one end of the > VPN for road-warrior VPN, it's best to make that end not use RFC1918. > Otherwise you may find you need to route 192.168.x.y, but that just so > happens to be the user's default gateway, name server, printer, or > other key device. ?Of course having another set of NAT addresses for > CGN will solve everything (yes, that's sarcastic, but I can predict > how they'll be used to "solve" this type of problem). > > Just because "it usually works" doesn't mean using RFC1918 addresses > for left and/or right subnets in a VPN is a good idea. > And, then there is this case where AT&T DSL is moving towards 10.x.x.x in the access network and they are guiding customers to move off that network in their LANs http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address- NET NET, ipv4 is getting more unreliable every day. Probably should consider IPv6 more strongly. And, getting AT&T to change their infrastructure is an exercise in futility. Your time is better spent changing your VPN to tunnel all traffic, including DNS, and / or moving to use an alternate DNS server. CB From jared at puck.nether.net Thu Jun 28 22:20:46 2012 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 28 Jun 2012 23:20:46 -0400 Subject: technical contact at ATT Wireless In-Reply-To: References: Message-ID: <21CE5D5A-E48D-43CF-A4FD-195DA503237C@puck.nether.net> On Jun 28, 2012, at 10:35 PM, Joel Maslak wrote: > Which is why enterprises generally shouldn't use RFC1918 IPs for > servers when clients are located on networks not controlled by the > same entity. Servers that serve multiple administration domains (such > as VPN users on AT&T - or on some random home Linksys box) probably > shouldn't be addressed using addresses that conceivably could be used > at the other end. But I'm probably fighting a losing battle saying > that... I've worked at places that do some combination of all public, all private and a mix.. Usually the places that work best have all public as they avoid mtu and other issues that arise. I expect the enterprise world to start coming around in the years to come to understand how they have damaged networking for the companies. - Jared From grizz at dipd.com Thu Jun 28 23:25:36 2012 From: grizz at dipd.com (Matt Griswold) Date: Thu, 28 Jun 2012 23:25:36 -0500 Subject: Peeringdb down? In-Reply-To: <4FDADF55.4090009@ascc.net> References: <4FDADF55.4090009@ascc.net> Message-ID: FWIW, server move is complete which should mean the end of outages, feel free to email me or support at peeringdb.com with any outstanding issues. On Jun 15, 2012 2:08 AM, "Ethern Lin" wrote: > web site is down but traceroute is ok. > > Packets > Pings > Host Loss% Snt Last Avg > Best Wrst StDev > 1. 140.109.1.1 0.0% 10 1.2 3.4 > 1.2 6.4 2.0 > 2. 140.109.255.213 0.0% 10 0.7 0.7 > 0.4 1.1 0.3 > 3. 202.169.174.77 0.0% 10 0.5 0.5 > 0.4 0.9 0.1 > 4. 202.169.174.226 0.0% 10 130.4 130.6 > 130.4 131.0 0.2 > 5. 64.209.107.45 0.0% 10 131.1 141.0 > 130.5 226.0 30.0 > 6. 69.31.111.222 20.0% 10 193.5 193.5 > 191.7 195.0 1.4 > 7. 69.31.111.137 0.0% 10 193.9 193.8 > 193.7 193.9 0.1 > 8. 69.31.111.6 0.0% 10 190.6 190.9 > 190.6 191.3 0.3 > 9. 75.102.0.114 0.0% 10 193.0 192.5 > 190.9 198.2 2.1 > 10. 205.234.211.82 0.0% 10 191.1 190.8 > 190.4 191.3 0.3 > > port 80 does open but not work: > > % tcptraceroute www.peeringdb.com > Selected device le0, address 140.109.1.6, port 51755 for outgoing packets > Tracing the path to www.peeringdb.com (205.234.211.82) on TCP port 80, 30 > hops max > 1 fe-1-1-br5.ascc.net (140.109.1.1) 6.804 ms 9.758 ms 9.510 ms > 2 140.109.255.213 (140.109.255.213) 9.994 ms 9.585 ms 10.506 ms > 3 202.169.174.77 (202.169.174.77) 9.477 ms 9.629 ms 9.992 ms > 4 202.169.174.226 (202.169.174.226) 130.602 ms 130.264 ms 130.229 ms > 5 64.209.107.45 (64.209.107.45) 130.324 ms 130.345 ms 133.022 ms > 6 * * * > 7 ae1-40g.cr1.ord1.us.nlayer.net (69.31.111.133) 190.646 ms 190.187 > ms 228.519 ms > 8 po6.ar1.ord1.us.scnet.net (69.31.111.58) 190.645 ms 190.590 ms > 246.995 ms > 9 ge0-49.aggr4302.ord2.us.scnet.**net(75.102.0.110) 198.134 ms 199.110 ms 195.075 ms > 10 www.peeringdb.com (205.234.211.82) [open] 190.322 ms 190.450 ms > 190.454 ms > > % telnet www.peeringdb.com 80 > Trying 205.234.211.82... > Connected to www.peeringdb.com. > Escape character is '^]'. > Connection closed by foreign host. > > cheers, > Ethern > > ==============================**======== > Ethern Lin > Network Division > Computing Center, ACADEMIA SINICA > AS Number: 9264 > Phone: +886-2-66149953 > TANet VoIP: 93909953 > Fax: +886-2-66146444 > ==============================**======== > > > ? 2012/6/15 ?? 02:41, Righa Shake ??: > >> Hey, >> >> Anybody able to access peeringdb today? >> >> Regards, >> Righa Shake >> >> On Fri, Jun 8, 2012 at 7:04 PM, Darius Jahandarie >> >wrote: >> >> On Fri, Jun 8, 2012 at 12:03 PM, Darius Jahandarie >>> wrote: >>> >>>> However, when the web interface goes down, usually you can still get >>>> information with the whois and finger interfaces: >>>> >>> And of course, this is what I meant by the finger interface: >>> >>> d82h214:~ Darius$ finger as4436 at peeringdb.com >>> >>> >>> >>> Still early. >>> >>> -- >>> Darius Jahandarie >>> >>> >>> >> -- >> ==============================**======== >> Ethern Lin >> Network Division >> Computing Center, ACADEMIA SINICA >> AS Number: 9264 >> Phone: +886-2-66149953 >> TANet VoIP: 93909953 >> Fax: +886-2-66146444 >> ==============================**======== >> > From nurul at apnic.net Thu Jun 28 23:52:06 2012 From: nurul at apnic.net (Roman) Date: Fri, 29 Jun 2012 14:52:06 +1000 Subject: IPV6 ACL command to block ICMPv6 Type and code Message-ID: <4FED3476.9010905@apnic.net> Hi, I am looking for Cisco IOS command to block specific ICMPv6 message type and code. For example how to block only code 1 (communication with destination administratively prohibited) of message type 1 (destination unreachable). All other code will be permited. deny icmp any any type 1 code 1 In my router I can see these: Router(config-ipv6-acl)#deny icmp any any destination-unreachable ? auth Match on authentication header dest-option Destination Option header (all types) dest-option-type Destination Option header with type dscp Match packets with given dscp value flow-label Flow label log Log matches against this entry log-input Log matches against this entry, including input mobility Mobility header (all types) mobility-type Mobility header with type routing Routing header (all types) routing-type Routing header with type sequence Sequence number for this entry time-range Specify a time-range My IOS is c2800nm-ipvoicek9-mz.124-24.T2 Regards Rom From mysidia at gmail.com Fri Jun 29 00:29:32 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 29 Jun 2012 00:29:32 -0500 Subject: IPV6 ACL command to block ICMPv6 Type and code In-Reply-To: <4FED3476.9010905@apnic.net> References: <4FED3476.9010905@apnic.net> Message-ID: On 6/28/12, Roman wrote: > Hi, > unreachable). All other code will be permited. > In my router I can see these: > > Router(config-ipv6-acl)#deny icmp any any destination-unreachable ? ... destination-unreachable in this case pertains to type #1 code #3 try deny icmp any any no-admin or deny icmp any any 1 1 -- -JH From ahebert at pubnix.net Fri Jun 29 07:54:35 2012 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 29 Jun 2012 08:54:35 -0400 Subject: Constant low-level attack In-Reply-To: <90182E62-192D-4FCD-9805-EF9088423D1D@oitc.com> References: <20120628203156.GA29870@metron.com> <90182E62-192D-4FCD-9805-EF9088423D1D@oitc.com> Message-ID: <4FEDA58B.4050509@pubnix.net> Hi, We implemented fail2ban about a year ago to cut down on incoming spamming (down from 500k+ emails a day to 20k) Now what can I do with the ~11,000 IP's I identify as spammer every week :( Reporting them to their Telco is pretty much a waste of time... they are not about to lose customers to something as trivial as computer security. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 06/28/12 17:52, TR Shaw wrote: > On Jun 28, 2012, at 4:31 PM, Lou Katz wrote: > >> The other day, I looked carefully at my auth.log (Xubuntu 11.04) and discovered many lines >> of the form: >> >> Jun 28 13:13:54 localhost sshd[12654]: Bad protocol version identification '\200F\001\003\001' from 94.252.177.159 >> >> In the past day, I have recorded about 20,000 unique IP addresses used for this type of probe. >> I doubt if this is a surprise to anyone - my question is twofold: >> >> 1. Does anyone want this evergrowing list of, I assume, compromised machines? >> 2. Is there anything useful to do with this info other than put the IP addresses into a firewall reject table? I have done >> that and do see a certain amount of repeat hits. > Just a note that if you were running fail2ban.org you would get automatic updates of your firewall and share the IPs with the community and get the advantage of the communities detections as well. > > > From rsk at gsp.org Fri Jun 29 08:30:31 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 29 Jun 2012 09:30:31 -0400 Subject: Constant low-level attack In-Reply-To: <20120628203156.GA29870@metron.com> References: <20120628203156.GA29870@metron.com> Message-ID: <20120629133031.GA9629@gsp.org> On Thu, Jun 28, 2012 at 01:31:56PM -0700, Lou Katz wrote: > 2. Is there anything useful to do with this info other than put the IP addresses into a firewall reject table? Do you need to allow inbound ssh connections from the entire planet? If not, then head over to ipdeny.com and grab the relevant network allocations for the countries that you *do* need to allow them from. Block everyone else, allow only the countries you need. This won't solve your problem completely, but it'll take a substantial bite out of it, and it'll minimize the number of additional point entries that you need for annoying hosts whose connections originate in the set of countries you need to allow. Then: do you need to allow inbound ssh connections from all operating systems? If not, then use passive OS fingerprinting to block those which originate from operating systems known not to be in use, particularly if those operatng systems happen to be the ones running on a few hundred million compromised systems. (Obviously, this technique is far less effective is you can't do that. My condolences.) And then: consider, instead of point blocks for the remaining annoyances, use the enclosing /24. A lot of compromised hosts are not on static addresses, and guessing that they will bounce around inside (roughly) a /24 is often a good enough approximation to reality that it works. Your mileage may vary. And then: scotch. Macallan. 18-year. You've earned it. ---rsk From tyler.haske at gmail.com Fri Jun 29 09:37:41 2012 From: tyler.haske at gmail.com (Tyler Haske) Date: Fri, 29 Jun 2012 10:37:41 -0400 Subject: technical contact at ATT Wireless In-Reply-To: References: Message-ID: > RFC1918 and VPN becomes non-scalable fast when you connect to lots of > different organizations - it doesn't take long before two > organizations you connect to both want to use 172.16.0.x/24 or > 10.0.0.x/24 or 192.168.0.0/24, or similar). ?The same logic goes for > VPN clients - if one end is potentially using RFC1918, the other end > better not use it. ?Since you can usually only control one end of the > VPN for road-warrior VPN, it's best to make that end not use RFC1918. > Otherwise you may find you need to route 192.168.x.y, but that just so > happens to be the user's default gateway, name server, printer, or > other key device. ?Of course having another set of NAT addresses for > CGN will solve everything (yes, that's sarcastic, but I can predict > how they'll be used to "solve" this type of problem). > > Just because "it usually works" doesn't mean using RFC1918 addresses > for left and/or right subnets in a VPN is a good idea. My workplace solves this by just NATing again. It isn't the best solution but it does work. Put aside a 10.0.0.0/16 and whenever you have a NATed network you want to connect a VPN to on the edge just static NAT the addresses to make them unique again. Their 172.16.x.x becomes your 10.2.x.x. I dunno about 'not scalable'. I guess if your connecting to thousands of networks it won't work well, but for a a few hundred it works well enough. I'm sorry you don't like it, and I know IPv6 will wash all this away soon enough, but where I'm working we have no plans to implement IPv6, or require our vendors/partners to readdress their networks to get a VPN up. From jared at puck.nether.net Fri Jun 29 09:51:06 2012 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 29 Jun 2012 10:51:06 -0400 Subject: technical contact at ATT Wireless In-Reply-To: References: Message-ID: <7CC35544-B0D0-40B4-9766-AF4813D745E9@puck.nether.net> On Jun 29, 2012, at 10:37 AM, Tyler Haske wrote: > I'm sorry you don't like it, and I know IPv6 will wash all this away > soon enough, but where I'm working we have no plans to implement IPv6, > or require our vendors/partners to readdress their networks to get a > VPN up. Just because there are no plans, this doesn't mean you shouldn't bring it up. Even if its a "radar"/"future" issue for their networking team, it does raise the profile in the asks with others. - Jared From tyler.haske at gmail.com Fri Jun 29 10:33:11 2012 From: tyler.haske at gmail.com (Tyler Haske) Date: Fri, 29 Jun 2012 11:33:11 -0400 Subject: technical contact at ATT Wireless In-Reply-To: <7CC35544-B0D0-40B4-9766-AF4813D745E9@puck.nether.net> References: <7CC35544-B0D0-40B4-9766-AF4813D745E9@puck.nether.net> Message-ID: On Fri, Jun 29, 2012 at 10:51 AM, Jared Mauch wrote: > > On Jun 29, 2012, at 10:37 AM, Tyler Haske wrote: > >> I'm sorry you don't like it, and I know IPv6 will wash all this away >> soon enough, but where I'm working we have no plans to implement IPv6, >> or require our vendors/partners to readdress their networks to get a >> VPN up. > > Just because there are no plans, this doesn't mean you shouldn't bring it up. > > Even if its a "radar"/"future" issue for their networking team, it does raise > the profile in the asks with others. > > - Jared Let it be known that I hate NAT with the burning passion of a million suns. But I'm the junior in my workplace, and this is the advice of the head honchos. I can easily see both sides of this. I would say with a few implementations, (maybe 25 or fewer) NATing isn't that difficult. Granted we both know that NAT breaks basically everything and makes troubleshooting a TON MORE FUN. But plenty of people out there (my workplace included) would argue this till the cows come home. From cscora at apnic.net Fri Jun 29 13:46:27 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Jun 2012 04:46:27 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201206291846.q5TIkRx1021664@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 30 Jun, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 414947 Prefixes after maximum aggregation: 175422 Deaggregation factor: 2.37 Unique aggregates announced to Internet: 202271 Total ASes present in the Internet Routing Table: 41386 Prefixes per ASN: 10.03 Origin-only ASes present in the Internet Routing Table: 33302 Origin ASes announcing only one prefix: 15652 Transit ASes present in the Internet Routing Table: 5545 Transit-only ASes present in the Internet Routing Table: 133 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 27 Max AS path prepend of ASN ( 51742) 24 Prefixes from unregistered ASNs in the Routing Table: 388 Unregistered ASNs in the Routing Table: 122 Number of 32-bit ASNs allocated by the RIRs: 2907 Number of 32-bit ASNs visible in the Routing Table: 2539 Prefixes from 32-bit ASNs in the Routing Table: 6532 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 184 Number of addresses announced to Internet: 2570382252 Equivalent to 153 /8s, 52 /16s and 235 /24s Percentage of available address space announced: 69.3 Percentage of allocated address space announced: 69.4 Percentage of available address space allocated: 99.9 Percentage of address space in use by end-sites: 93.0 Total number of prefixes smaller than registry allocations: 143966 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 101216 Total APNIC prefixes after maximum aggregation: 32691 APNIC Deaggregation factor: 3.10 Prefixes being announced from the APNIC address blocks: 101660 Unique aggregates announced from the APNIC address blocks: 41966 APNIC Region origin ASes present in the Internet Routing Table: 4712 APNIC Prefixes per ASN: 21.57 APNIC Region origin ASes announcing only one prefix: 1241 APNIC Region transit ASes present in the Internet Routing Table: 752 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 239 Number of APNIC addresses announced to Internet: 703244928 Equivalent to 41 /8s, 234 /16s and 170 /24s Percentage of available APNIC address space announced: 82.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 152291 Total ARIN prefixes after maximum aggregation: 77306 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 153229 Unique aggregates announced from the ARIN address blocks: 68328 ARIN Region origin ASes present in the Internet Routing Table: 15177 ARIN Prefixes per ASN: 10.10 ARIN Region origin ASes announcing only one prefix: 5747 ARIN Region transit ASes present in the Internet Routing Table: 1606 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1081167232 Equivalent to 64 /8s, 113 /16s and 77 /24s Percentage of available ARIN address space announced: 57.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 103797 Total RIPE prefixes after maximum aggregation: 54908 RIPE Deaggregation factor: 1.89 Prefixes being announced from the RIPE address blocks: 105956 Unique aggregates announced from the RIPE address blocks: 66912 RIPE Region origin ASes present in the Internet Routing Table: 16636 RIPE Prefixes per ASN: 6.37 RIPE Region origin ASes announcing only one prefix: 8058 RIPE Region transit ASes present in the Internet Routing Table: 2679 Average RIPE Region AS path length visible: 4.9 Max RIPE Region AS path length visible: 27 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1671 Number of RIPE addresses announced to Internet: 633563396 Equivalent to 37 /8s, 195 /16s and 105 /24s Percentage of available RIPE address space announced: 92.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 41665 Total LACNIC prefixes after maximum aggregation: 8295 LACNIC Deaggregation factor: 5.02 Prefixes being announced from the LACNIC address blocks: 44210 Unique aggregates announced from the LACNIC address blocks: 21613 LACNIC Region origin ASes present in the Internet Routing Table: 1607 LACNIC Prefixes per ASN: 27.51 LACNIC Region origin ASes announcing only one prefix: 434 LACNIC Region transit ASes present in the Internet Routing Table: 306 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 21 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 607 Number of LACNIC addresses announced to Internet: 111606184 Equivalent to 6 /8s, 166 /16s and 249 /24s Percentage of available LACNIC address space announced: 66.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 9252 Total AfriNIC prefixes after maximum aggregation: 2168 AfriNIC Deaggregation factor: 4.27 Prefixes being announced from the AfriNIC address blocks: 9708 Unique aggregates announced from the AfriNIC address blocks: 3313 AfriNIC Region origin ASes present in the Internet Routing Table: 549 AfriNIC Prefixes per ASN: 17.68 AfriNIC Region origin ASes announcing only one prefix: 172 AfriNIC Region transit ASes present in the Internet Routing Table: 123 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 40494848 Equivalent to 2 /8s, 105 /16s and 231 /24s Percentage of available AfriNIC address space announced: 40.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2700 11118 1203 Korea Telecom (KIX) 17974 1971 541 77 PT TELEKOMUNIKASI INDONESIA 7545 1689 301 87 TPG Internet Pty Ltd 4755 1597 386 154 TATA Communications formerly 9829 1304 1085 28 BSNL National Internet Backbo 9583 1168 87 508 Sify Limited 4808 1109 2052 314 CNCGROUP IP network: China169 7552 1100 1062 11 Vietel Corporation 24560 1035 385 165 Bharti Airtel Ltd., Telemedia 9498 968 291 64 BHARTI Airtel Ltd. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3397 3790 189 bellsouth.net, inc. 7029 3210 986 157 Windstream Communications Inc 18566 2090 382 180 Covad Communications 1785 1930 681 132 PaeTec Communications, Inc. 22773 1655 2911 121 Cox Communications, Inc. 20115 1651 1573 616 Charter Communications 4323 1573 1043 384 Time Warner Telecom 30036 1446 272 750 Mediacom Communications Corp 7018 1252 10027 820 AT&T WorldNet Services 11492 1186 216 362 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1675 544 16 Corbina telecom 2118 1288 97 14 EUnet/RELCOM Autonomous Syste 12479 783 731 92 Uni2 Autonomous System 34984 716 189 175 BILISIM TELEKOM 6830 690 2234 438 UPC Distribution Services 31148 683 37 9 FreeNet ISP 20940 663 209 513 Akamai Technologies European 8551 582 364 61 Bezeq International 13188 503 100 10 Educational Network 3320 495 8443 408 Deutsche Telekom AG Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1980 344 205 TVCABLE BOGOTA 28573 1966 1213 54 NET Servicos de Comunicao S.A 6503 1527 418 65 AVANTEL, S.A. 7303 1454 933 192 Telecom Argentina Stet-France 8151 1370 3066 339 UniNet S.A. de C.V. 27947 706 74 94 Telconet S.A 11172 643 91 74 Servicios Alestra S.A de C.V 3816 589 248 86 Empresa Nacional de Telecomun 22047 583 326 15 VTR PUNTO NET S.A. 14117 567 65 59 Telefonica del Sur S.A. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1269 958 13 TEDATA 24863 859 274 35 LINKdotNET AS number 6713 500 649 18 Itissalat Al-MAGHRIB 24835 321 80 8 RAYA Telecom - Egypt 3741 262 905 223 The Internet Solution 33776 210 12 21 Starcomms Nigeria Limited 12258 197 28 62 Vodacom Internet Company 16637 169 664 87 MTN Network Solutions 29975 167 571 19 Vodacom 15706 164 32 6 Sudatel Internet Exchange Aut Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3397 3790 189 bellsouth.net, inc. 7029 3210 986 157 Windstream Communications Inc 4766 2700 11118 1203 Korea Telecom (KIX) 18566 2090 382 180 Covad Communications 10620 1980 344 205 TVCABLE BOGOTA 17974 1971 541 77 PT TELEKOMUNIKASI INDONESIA 28573 1966 1213 54 NET Servicos de Comunicao S.A 1785 1930 681 132 PaeTec Communications, Inc. 7545 1689 301 87 TPG Internet Pty Ltd 8402 1675 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7029 3210 3053 Windstream Communications Inc 28573 1966 1912 NET Servicos de Comunicao S.A 18566 2090 1910 Covad Communications 17974 1971 1894 PT TELEKOMUNIKASI INDONESIA 1785 1930 1798 PaeTec Communications, Inc. 10620 1980 1775 TVCABLE BOGOTA 8402 1675 1659 Corbina telecom 7545 1689 1602 TPG Internet Pty Ltd 22773 1655 1534 Cox Communications, Inc. 4766 2700 1497 Korea Telecom (KIX) Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 29760 UNALLOCATED 12.145.34.0/23 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/21 12654 RIPE NCC RIS Project 128.0.24.0/24 12654 RIPE NCC RIS Project Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 5.102.168.0/21 50300 Custodian Ltd. 5.104.0.0/24 47883 KIBRIS MOBILE TELEKOMUNIKASYO 5.104.0.0/20 47883 KIBRIS MOBILE TELEKOMUNIKASYO 5.104.1.0/24 47883 KIBRIS MOBILE TELEKOMUNIKASYO 5.104.2.0/24 47883 KIBRIS MOBILE TELEKOMUNIKASYO 5.104.3.0/24 47883 KIBRIS MOBILE TELEKOMUNIKASYO 5.104.4.0/24 47883 KIBRIS MOBILE TELEKOMUNIKASYO 5.104.5.0/24 47883 KIBRIS MOBILE TELEKOMUNIKASYO 5.104.6.0/24 47883 KIBRIS MOBILE TELEKOMUNIKASYO 5.104.7.0/24 47883 KIBRIS MOBILE TELEKOMUNIKASYO Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:13 /10:28 /11:83 /12:236 /13:464 /14:836 /15:1513 /16:12290 /17:6342 /18:10751 /19:20840 /20:29627 /21:31358 /22:40928 /23:38970 /24:216921 /25:1232 /26:1485 /27:864 /28:42 /29:64 /30:18 /31:0 /32:23 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2619 3210 Windstream Communications Inc 18566 2040 2090 Covad Communications 6389 1871 3397 bellsouth.net, inc. 30036 1383 1446 Mediacom Communications Corp 8402 1372 1675 Corbina telecom 11492 1149 1186 Cable One 22773 1087 1655 Cox Communications, Inc. 6503 1059 1527 AVANTEL, S.A. 1785 1041 1930 PaeTec Communications, Inc. 8452 1030 1269 TEDATA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:568 2:734 3:1 4:13 5:95 6:3 8:434 12:2010 13:1 14:632 15:12 16:3 17:5 20:24 23:190 24:1786 27:1317 31:997 32:56 33:2 34:2 36:9 37:594 38:816 39:1 40:128 41:3114 42:142 44:3 46:1462 47:2 49:419 50:564 52:13 54:12 55:7 56:1 57:34 58:989 59:499 60:253 61:1230 62:1001 63:2036 64:4253 65:2254 66:4471 67:2019 68:1152 69:3199 70:982 71:503 72:1834 74:2607 75:475 76:332 77:955 78:902 79:491 80:1219 81:948 82:669 83:526 84:504 85:1192 86:422 87:932 88:342 89:1736 90:300 91:4978 92:579 93:1366 94:1592 95:1239 96:372 97:318 98:906 99:39 100:18 101:251 103:1214 106:103 107:189 108:354 109:1411 110:786 111:938 112:415 113:631 114:650 115:826 116:928 117:733 118:923 119:1237 120:350 121:695 122:1671 123:1098 124:1396 125:1258 128:553 129:198 130:254 131:634 132:291 133:22 134:245 135:61 136:213 137:240 138:336 139:175 140:494 141:254 142:435 143:374 144:534 145:76 146:509 147:287 148:768 149:318 150:156 151:175 152:473 153:175 154:17 155:433 156:219 157:381 158:191 159:620 160:343 161:269 162:352 163:192 164:654 165:411 166:583 167:473 168:909 169:126 170:890 171:145 172:5 173:1765 174:627 175:430 176:553 177:872 178:1534 180:1267 181:98 182:1010 183:244 184:533 185:1 186:1864 187:1089 188:1350 189:1602 190:5752 192:6008 193:5546 194:4546 195:3430 196:1196 197:164 198:3672 199:4821 200:5924 201:1981 202:8683 203:8633 204:4334 205:2537 206:2806 207:2792 208:4043 209:3615 210:2778 211:1555 212:2029 213:1921 214:847 215:83 216:5111 217:1570 218:550 219:318 220:1233 221:570 222:321 223:353 End of report From owen at delong.com Fri Jun 29 14:36:57 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Jun 2012 15:36:57 -0400 Subject: technical contact at ATT Wireless In-Reply-To: References: <7CC35544-B0D0-40B4-9766-AF4813D745E9@puck.nether.net> Message-ID: <0CBD997C-4211-42B0-8BB1-3EE1DDCFC300@delong.com> > Let it be known that I hate NAT with the burning passion of a million > suns. But I'm the junior in my workplace, and this is the advice of > the head honchos. I can easily see both sides of this. I would say > with a few implementations, (maybe 25 or fewer) NATing isn't that > difficult. > > Granted we both know that NAT breaks basically everything and makes > troubleshooting a TON MORE FUN. But plenty of people out there (my > workplace included) would argue this till the cows come home. Yep... While this environment would benefit greatly from deploying IPv6 on both sides of the connection, the reality is that NAT is easy enough and works well enough for the implementor that they will leave it's various pain points for the people that have to deal with it after implementation and they won't select IPv6 as a solution because it would involve slightly more pain up front. However, the networks on both sides of these equations will have to face IPv6 in the relatively near future anyway, unless they aren't actually talking to the internet in which case, it doesn't really matter what addresses or protocols they use. Owen From cidr-report at potaroo.net Fri Jun 29 17:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Jun 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201206292200.q5TM02ge002521@wattle.apnic.net> BGP Update Report Interval: 21-Jun-12 -to- 28-Jun-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 55563 1.9% 28.1 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS9829 41479 1.5% 31.8 -- BSNL-NIB National Internet Backbone 3 - AS13188 38016 1.3% 70.5 -- BANKINFORM-AS TOV "Bank-Inform" 4 - AS5800 35008 1.2% 134.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 5 - AS24560 30326 1.1% 29.3 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 6 - AS12479 29579 1.0% 38.0 -- UNI2-AS France Telecom Espana SA 7 - AS8452 25140 0.9% 19.1 -- TE-AS TE-AS 8 - AS28573 25016 0.9% 12.6 -- NET Servicos de Comunicao S.A. 9 - AS17813 21150 0.7% 159.0 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 10 - AS7552 20962 0.7% 19.0 -- VIETEL-AS-AP Vietel Corporation 11 - AS2697 20353 0.7% 100.8 -- ERX-ERNET-AS Education and Research Network 12 - AS13118 19764 0.7% 411.8 -- ASN-YARTELECOM OJSC Rostelecom 13 - AS20115 18732 0.7% 11.3 -- CHARTER-NET-HKY-NC - Charter Communications 14 - AS17621 17293 0.6% 113.8 -- CNCGROUP-SH China Unicom Shanghai network 15 - AS24863 16472 0.6% 18.9 -- LINKdotNET-AS 16 - AS19361 15264 0.5% 448.9 -- Atrium Telecomunicacoes Ltda 17 - AS7029 13362 0.5% 3.9 -- WINDSTREAM - Windstream Communications Inc 18 - AS4323 12157 0.4% 7.7 -- TWTC - tw telecom holdings, inc. 19 - AS26615 11933 0.4% 13.0 -- Tim Celular S.A. 20 - AS34875 10844 0.4% 62.7 -- YANFES OJSC "Uralsviazinform" TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS40848 2543 0.1% 2543.0 -- FMFCU - Franklin Mint FCU 2 - AS3 1893 0.1% 1960.0 -- OOO-HAS-TELEKOM-AS OOO HAS-TELEKOM 3 - AS3 1409 0.1% 2120.0 -- OOO-HAS-TELEKOM-AS OOO HAS-TELEKOM 4 - AS29126 932 0.0% 932.0 -- DATIQ-AS Datiq B.V. 5 - AS55665 835 0.0% 835.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia 6 - AS45286 824 0.0% 824.0 -- EDIINDONESIA-AS-ID PT EDI INDONESIA 7 - AS30944 733 0.0% 733.0 -- DKD-AS Bendra Lietuvos, JAV ir Rusijos imone uzdaroji akcine bendrove "DKD" 8 - AS19675 2229 0.1% 557.2 -- VCS-AS - Virtacore Systems Inc 9 - AS38142 8093 0.3% 505.8 -- UNAIR-AS-ID Universitas Airlangga 10 - AS19361 15264 0.5% 448.9 -- Atrium Telecomunicacoes Ltda 11 - AS57105 854 0.0% 427.0 -- SUNIMPROF-AS Sunimprof Import Export SRL 12 - AS13118 19764 0.7% 411.8 -- ASN-YARTELECOM OJSC Rostelecom 13 - AS27771 812 0.0% 406.0 -- Instituto Venezolano de Investigaciones Cientificas 14 - AS19406 4345 0.1% 395.0 -- TWRS-MA - Towerstream I, Inc. 15 - AS16535 1122 0.0% 374.0 -- ECHOS-3 - Echostar Holding Purchasing Corporation 16 - AS57201 367 0.0% 367.0 -- EDF-AS Estonian Defence Forces 17 - AS48068 709 0.0% 354.5 -- VISONIC Visonic Ltd 18 - AS23533 338 0.0% 338.0 -- PIP-ASN - Permian Investment Partners, LP 19 - AS32444 1805 0.1% 300.8 -- SAFELINK-JEROME1ASN - Safelink Internet 20 - AS37429 872 0.0% 290.7 -- Spidernet TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 19381 0.7% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 220.196.26.0/24 16991 0.6% AS17621 -- CNCGROUP-SH China Unicom Shanghai network 3 - 159.224.176.0/22 12498 0.4% AS13188 -- BANKINFORM-AS TOV "Bank-Inform" 4 - 159.224.222.0/23 12496 0.4% AS13188 -- BANKINFORM-AS TOV "Bank-Inform" 5 - 41.43.147.0/24 11741 0.4% AS8452 -- TE-AS TE-AS 6 - 182.64.0.0/16 10758 0.4% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 122.161.0.0/16 8770 0.3% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - 62.36.252.0/22 8135 0.3% AS12479 -- UNI2-AS France Telecom Espana SA 9 - 62.36.249.0/24 6626 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 10 - 202.56.215.0/24 6579 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 11 - 62.36.241.0/24 6245 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 12 - 62.36.210.0/24 6099 0.2% AS12479 -- UNI2-AS France Telecom Espana SA 13 - 59.177.48.0/20 5954 0.2% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 14 - 194.63.9.0/24 5160 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 15 - 69.38.178.0/24 4310 0.1% AS19406 -- TWRS-MA - Towerstream I, Inc. 16 - 147.30.240.0/22 3268 0.1% AS9198 -- KAZTELECOM-AS JSC Kazakhtelecom 17 - 59.177.64.0/18 2992 0.1% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 18 - 59.177.144.0/20 2783 0.1% AS17813 -- MTNL-AP Mahanagar Telephone Nigam Ltd. 19 - 146.145.140.0/24 2543 0.1% AS40848 -- FMFCU - Franklin Mint FCU 20 - 115.170.128.0/17 2251 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 29 17:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Jun 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201206292200.q5TM00v3002498@wattle.apnic.net> This report has been generated at Fri Jun 29 21:12:59 2012 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 22-06-12 417401 241597 23-06-12 417626 242305 24-06-12 417693 242428 25-06-12 417814 241881 26-06-12 417414 242356 27-06-12 417776 242461 28-06-12 417970 242449 29-06-12 417364 242229 AS Summary 41522 Number of ASes in routing system 17336 Number of ASes announcing only one prefix 3397 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 113115104 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 29Jun12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 417485 242253 175232 42.0% All ASes AS6389 3397 192 3205 94.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS7029 3246 1630 1616 49.8% WINDSTREAM - Windstream Communications Inc AS22773 1655 136 1519 91.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4766 2715 1299 1416 52.2% KIXS-AS-KR Korea Telecom AS28573 1967 554 1413 71.8% NET Servicos de Comunicao S.A. AS18566 2090 705 1385 66.3% COVAD - Covad Communications Co. AS2118 1288 14 1274 98.9% RELCOM-AS OOO "NPO Relcom" AS4323 1575 386 1189 75.5% TWTC - tw telecom holdings, inc. AS10620 1980 803 1177 59.4% Telmex Colombia S.A. AS1785 1930 813 1117 57.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1597 542 1055 66.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7303 1455 460 995 68.4% Telecom Argentina S.A. AS17974 1971 1091 880 44.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS7552 1100 221 879 79.9% VIETEL-AS-AP Vietel Corporation AS8151 1375 563 812 59.1% Uninet S.A. de C.V. AS18101 947 159 788 83.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1109 347 762 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS9394 892 162 730 81.8% CRNET CHINA RAILWAY Internet(CRNET) AS13977 839 123 716 85.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS3356 1111 467 644 58.0% LEVEL3 Level 3 Communications AS855 688 57 631 91.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS30036 1446 825 621 42.9% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS17676 692 75 617 89.2% GIGAINFRA Softbank BB Corp. AS4780 842 246 596 70.8% SEEDNET Digital United Inc. AS22561 1024 428 596 58.2% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 998 405 593 59.4% VZGNI-TRANSIT - Verizon Online LLC AS24560 1035 461 574 55.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8452 1270 713 557 43.9% TE-AS TE-AS AS4804 649 97 552 85.1% MPX-AS Microplex PTY LTD AS22047 583 31 552 94.7% VTR BANDA ANCHA S.A. Total 43466 14005 29461 67.8% Top 30 total Possible Bogus Routes 5.104.104.0/21 AS24961 FIBREONE-AS myLoc managed IT AG 5.104.144.0/21 AS21263 TELEDATA-AS TeleData Friedrichshafen GmbH 5.112.0.0/12 AS44244 IRANCELL-AS Iran Cell Service and Communication Company 5.112.0.0/13 AS44244 IRANCELL-AS Iran Cell Service and Communication Company 5.120.0.0/13 AS44244 IRANCELL-AS Iran Cell Service and Communication Company 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 14.192.0.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.4.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.8.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.12.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.16.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.20.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.24.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 14.192.28.0/22 AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 70.34.112.0/20 AS27589 MOJOHOST - MOJOHOST 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 HAMELTRONICS - Hameltronics, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 74.115.126.0/24 AS11260 EASTLINK-HSI - EastLink 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 103.12.86.0/23 AS56178 TIMWARNOCK-AS-AP Tim Warnock 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 120.136.17.0/24 AS38779 BMG-AS-ID Badan Meteorologi dan Geofisika 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.14.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.15.0.0/24 AS57871 ASTELECENTR TeleCentr Ltd. 172.45.1.0/24 AS3356 LEVEL3 Level 3 Communications 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.6.49.0/24 AS23148 TERREMARK Terremark 200.24.73.0/24 AS26061 Equant Colombia 200.33.40.0/24 AS11172 Alestra, S. de R.L. de C.V. 200.34.0.0/20 AS6342 Instituto Tecnol?gico y de Estudios Superiores de Monterrey 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 200.75.184.0/21 AS14754 Telgua 200.106.128.0/20 AS3257 TINET-BACKBONE Tinet SpA 200.115.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.140.128.0/19 AS9583 SIFY-AS-IN Sify Limited 202.160.152.0/22 AS10113 EFTEL-AS-AP Eftel Limited. 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.14.0.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.0.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.2.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 204.14.3.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.91.56.0/21 AS22241 IC2NET - IC2NET 208.91.56.0/24 AS22241 IC2NET - IC2NET 208.91.57.0/24 AS22241 IC2NET - IC2NET 208.91.58.0/24 AS22241 IC2NET - IC2NET 208.91.59.0/24 AS22241 IC2NET - IC2NET 208.91.60.0/24 AS22241 IC2NET - IC2NET 208.91.61.0/24 AS22241 IC2NET - IC2NET 208.91.62.0/24 AS22241 IC2NET - IC2NET 208.91.63.0/24 AS22241 IC2NET - IC2NET 208.93.144.0/21 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 208.93.151.0/24 AS30693 EONIX-CORPORATION-AS-PHX01-WWW-INFINITIE-NET - Eonix Corporation 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.202.0/24 AS8513 SKYVISION SkyVision Global Networks Ltd 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.155.176.0/20 AS16706 216.194.160.0/20 AS27876 American Data Networks Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From os10rules at gmail.com Fri Jun 29 17:20:14 2012 From: os10rules at gmail.com (Greg Ihnen) Date: Fri, 29 Jun 2012 17:50:14 -0430 Subject: http/ssl to dropbox.com dying Message-ID: <2A09FE69-5C55-42DB-AD06-E519E03C95E2@gmail.com> From other geographic locations I can connect to the dropbox service and get to their https web page, but from my home connection I can't, unless I vpn around the issue. downforeveryoneorjustme says it's just me, but they're located someplace else geographically, and I don't know if they check the https site. http://www.dropbox.com immediately redirects to https://www.dropbox.com It seems like a transport issue. Is there any tools for checking where an https connection is failing, like a traceroute for https? I'm not sure if the traceroute results are indicative but here it is Macintosh-2:~ gregihnen$ traceroute dropbox.com traceroute: Warning: dropbox.com has multiple addresses; using 199.47.216.179 traceroute to dropbox.com (199.47.216.179), 64 hops max, 52 byte packets 1 router (192.168.7.1) 1786.458 ms 1.670 ms 2.072 ms 2 modem (100.42.12.241) 1644.717 ms 2031.032 ms 2113.805 ms 3 75.7.64.12 (75.7.64.12) 2594.284 ms 1650.347 ms 822.159 ms 4 75.7.64.2 (75.7.64.2) 1528.550 ms 2168.641 ms 1922.285 ms 5 12.91.131.205 (12.91.131.205) 2323.903 ms 3137.965 ms 2138.427 ms 6 cr83.cgcil.ip.att.net (12.122.133.202) 1629.569 ms 1946.842 ms 1621.351 ms 7 cr1.cgcil.ip.att.net (12.123.7.110) 2256.595 ms 1515.060 ms 2418.845 ms 8 gar8.cgcil.ip.att.net (12.122.133.161) 2349.706 ms 2339.392 ms 583.224 ms 9 192.205.37.150 (192.205.37.150) 1396.288 ms 1732.779 ms 2664.270 ms 10 4.69.158.138 (4.69.158.138) 2690.646 ms 4.69.158.130 (4.69.158.130) 2313.195 ms 4.69.158.138 (4.69.158.138) 1261.560 ms 11 ae-3-3.ebr2.denver1.level3.net (4.69.132.61) 1476.892 ms 1819.138 ms 2188.664 ms 12 ae-1-100.ebr1.denver1.level3.net (4.69.151.181) 1490.142 ms 2916.895 ms 2569.848 ms 13 ae-3-3.ebr2.sanjose1.level3.net (4.69.132.57) 4328.125 ms 3226.550 ms 2648.859 ms 14 ae-72-72.csw2.sanjose1.level3.net (4.69.153.22) 2171.863 ms ae-82-82.csw3.sanjose1.level3.net (4.69.153.26) 2675.059 ms ae-92-92.csw4.sanjose1.level3.net (4.69.153.30) 4404.724 ms 15 ae-1-60.edge2.sanjose3.level3.net (4.69.152.17) 3331.595 ms ae-2-70.edge2.sanjose3.level3.net (4.69.152.81) 3112.938 ms 2492.688 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * * * 36 * * * Greg From israel.lugo at lugosys.com Fri Jun 29 19:05:47 2012 From: israel.lugo at lugosys.com (Israel G. Lugo) Date: Sat, 30 Jun 2012 01:05:47 +0100 Subject: http/ssl to dropbox.com dying In-Reply-To: <2A09FE69-5C55-42DB-AD06-E519E03C95E2@gmail.com> References: <2A09FE69-5C55-42DB-AD06-E519E03C95E2@gmail.com> Message-ID: <4FEE42DB.6070106@lugosys.com> Hi, On 06/29/2012 11:20 PM, Greg Ihnen wrote: > It seems like a transport issue. > > Is there any tools for checking where an https connection is failing, like a traceroute for https? GNU/Linux traceroute sends UDP by default. Something along the way could be filtering UDP, so default traceroute may not be indicative. To better replicate the problem, you can tell traceroute to send TCP SYNs to the specific port you're trying to reach (443). Run this as root (it needs raw sockets): # traceroute -M tcp -p 443 dropbox.com Regards, Israel G. Lugo From jbfixurpc at gmail.com Fri Jun 29 22:22:34 2012 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Fri, 29 Jun 2012 22:22:34 -0500 Subject: FYI Netflix is down Message-ID: Seems that they are unreachable at the moment. Called and theres a recorded message stating they are aware of an issue, no details. -Joe From jason at thebaughers.com Fri Jun 29 22:40:44 2012 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 29 Jun 2012 22:40:44 -0500 Subject: FYI Netflix is down In-Reply-To: References: Message-ID: <4FEE753C.4030007@thebaughers.com> Seeing some reports of Pinterest and Instagram down as well. Amazon cloud services being implicated. On 6/29/2012 10:22 PM, Joe Blanchard wrote: > Seems that they are unreachable at the moment. Called and theres a recorded > message stating they are aware of an issue, no details. > > -Joe > > From shortdudey123 at gmail.com Fri Jun 29 22:42:08 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Fri, 29 Jun 2012 22:42:08 -0500 Subject: FYI Netflix is down In-Reply-To: <4FEE753C.4030007@thebaughers.com> References: <4FEE753C.4030007@thebaughers.com> Message-ID: >From Amazon Amazon Elastic Compute Cloud (N. Virginia) (http://status.aws.amazon.com/) 8:21 PM PDT We are investigating connectivity issues for a number of instances in the US-EAST-1 Region. 8:31 PM PDT We are investigating elevated errors rates for APIs in the US-EAST-1 (Northern Virginia) region, as well as connectivity issues to instances in a single availability zone. -Grant On Fri, Jun 29, 2012 at 10:40 PM, Jason Baugher wrote: > Seeing some reports of Pinterest and Instagram down as well. Amazon cloud > services being implicated. > > > On 6/29/2012 10:22 PM, Joe Blanchard wrote: > >> Seems that they are unreachable at the moment. Called and theres a >> recorded >> message stating they are aware of an issue, no details. >> >> -Joe >> >> >> > > > From jamesl at mythostech.com Fri Jun 29 22:42:52 2012 From: jamesl at mythostech.com (James Laszko) Date: Sat, 30 Jun 2012 03:42:52 +0000 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> Message-ID: <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> To further expand: 8:21 PM PDT We are investigating connectivity issues for a number of instances in the US-EAST-1 Region. 8:31 PM PDT We are investigating elevated errors rates for APIs in the US-EAST-1 (Northern Virginia) region, as well as connectivity issues to instances in a single availability zone. 8:40 PM PDT We can confirm that a large number of instances in a single Availability Zone have lost power due to electrical storms in the area. We are actively working to restore power. -----Original Message----- From: Grant Ridder [mailto:shortdudey123 at gmail.com] Sent: Friday, June 29, 2012 8:42 PM To: Jason Baugher Cc: nanog at nanog.org Subject: Re: FYI Netflix is down >From Amazon Amazon Elastic Compute Cloud (N. Virginia) (http://status.aws.amazon.com/) 8:21 PM PDT We are investigating connectivity issues for a number of instances in the US-EAST-1 Region. 8:31 PM PDT We are investigating elevated errors rates for APIs in the US-EAST-1 (Northern Virginia) region, as well as connectivity issues to instances in a single availability zone. -Grant On Fri, Jun 29, 2012 at 10:40 PM, Jason Baugher wrote: > Seeing some reports of Pinterest and Instagram down as well. Amazon > cloud services being implicated. > > > On 6/29/2012 10:22 PM, Joe Blanchard wrote: > >> Seems that they are unreachable at the moment. Called and theres a >> recorded message stating they are aware of an issue, no details. >> >> -Joe >> >> >> > > > From shortdudey123 at gmail.com Fri Jun 29 22:44:43 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Fri, 29 Jun 2012 22:44:43 -0500 Subject: FYI Netflix is down In-Reply-To: <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> Message-ID: I have an instance in zone C and it is up and fine, so it must be A, B, or D that is down. On Fri, Jun 29, 2012 at 10:42 PM, James Laszko wrote: > To further expand: > > 8:21 PM PDT We are investigating connectivity issues for a number of > instances in the US-EAST-1 Region. > > 8:31 PM PDT We are investigating elevated errors rates for APIs in the > US-EAST-1 (Northern Virginia) region, as well as connectivity issues to > instances in a single availability zone. > > 8:40 PM PDT We can confirm that a large number of instances in a single > Availability Zone have lost power due to electrical storms in the area. We > are actively working to restore power. > > -----Original Message----- > From: Grant Ridder [mailto:shortdudey123 at gmail.com] > Sent: Friday, June 29, 2012 8:42 PM > To: Jason Baugher > Cc: nanog at nanog.org > Subject: Re: FYI Netflix is down > > From Amazon > > Amazon Elastic Compute Cloud (N. Virginia) (http://status.aws.amazon.com/ > ) > 8:21 PM PDT We are investigating connectivity issues for a number of > instances in the US-EAST-1 Region. > 8:31 PM PDT We are investigating elevated errors rates for APIs in the > US-EAST-1 (Northern Virginia) region, as well as connectivity issues to > instances in a single availability zone. > > -Grant > > On Fri, Jun 29, 2012 at 10:40 PM, Jason Baugher >wrote: > > > Seeing some reports of Pinterest and Instagram down as well. Amazon > > cloud services being implicated. > > > > > > On 6/29/2012 10:22 PM, Joe Blanchard wrote: > > > >> Seems that they are unreachable at the moment. Called and theres a > >> recorded message stating they are aware of an issue, no details. > >> > >> -Joe > >> > >> > >> > > > > > > > From jason at thebaughers.com Fri Jun 29 22:45:53 2012 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 29 Jun 2012 22:45:53 -0500 Subject: FYI Netflix is down In-Reply-To: <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> Message-ID: <4FEE7671.2060403@thebaughers.com> Nature is such a PITA. On 6/29/2012 10:42 PM, James Laszko wrote: > To further expand: > > 8:21 PM PDT We are investigating connectivity issues for a number of instances in the US-EAST-1 Region. > > 8:31 PM PDT We are investigating elevated errors rates for APIs in the US-EAST-1 (Northern Virginia) region, as well as connectivity issues to instances in a single availability zone. > > 8:40 PM PDT We can confirm that a large number of instances in a single Availability Zone have lost power due to electrical storms in the area. We are actively working to restore power. > > -----Original Message----- > From: Grant Ridder [mailto:shortdudey123 at gmail.com] > Sent: Friday, June 29, 2012 8:42 PM > To: Jason Baugher > Cc: nanog at nanog.org > Subject: Re: FYI Netflix is down > > >From Amazon > > Amazon Elastic Compute Cloud (N. Virginia) (http://status.aws.amazon.com/) > 8:21 PM PDT We are investigating connectivity issues for a number of instances in the US-EAST-1 Region. > 8:31 PM PDT We are investigating elevated errors rates for APIs in the > US-EAST-1 (Northern Virginia) region, as well as connectivity issues to instances in a single availability zone. > > -Grant > > On Fri, Jun 29, 2012 at 10:40 PM, Jason Baugher wrote: > >> Seeing some reports of Pinterest and Instagram down as well. Amazon >> cloud services being implicated. >> >> >> On 6/29/2012 10:22 PM, Joe Blanchard wrote: >> >>> Seems that they are unreachable at the moment. Called and theres a >>> recorded message stating they are aware of an issue, no details. >>> >>> -Joe >>> >>> >>> >> >> > From mike.lyon at gmail.com Fri Jun 29 22:47:11 2012 From: mike.lyon at gmail.com (Mike Lyon) Date: Fri, 29 Jun 2012 20:47:11 -0700 Subject: FYI Netflix is down In-Reply-To: <4FEE7671.2060403@thebaughers.com> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> Message-ID: Whatever happened to UPSs and generators? On Fri, Jun 29, 2012 at 8:45 PM, Jason Baugher wrote: > Nature is such a PITA. > > > On 6/29/2012 10:42 PM, James Laszko wrote: > >> To further expand: >> >> 8:21 PM PDT We are investigating connectivity issues for a number of >> instances in the US-EAST-1 Region. >> >> 8:31 PM PDT We are investigating elevated errors rates for APIs in the >> US-EAST-1 (Northern Virginia) region, as well as connectivity issues to >> instances in a single availability zone. >> >> 8:40 PM PDT We can confirm that a large number of instances in a single >> Availability Zone have lost power due to electrical storms in the area. We >> are actively working to restore power. >> >> -----Original Message----- >> From: Grant Ridder [mailto:shortdudey123 at gmail.**com >> ] >> Sent: Friday, June 29, 2012 8:42 PM >> To: Jason Baugher >> Cc: nanog at nanog.org >> Subject: Re: FYI Netflix is down >> >> >From Amazon >> >> Amazon Elastic Compute Cloud (N. Virginia) ( >> http://status.aws.amazon.com/**) >> 8:21 PM PDT We are investigating connectivity issues for a number of >> instances in the US-EAST-1 Region. >> 8:31 PM PDT We are investigating elevated errors rates for APIs in the >> US-EAST-1 (Northern Virginia) region, as well as connectivity issues to >> instances in a single availability zone. >> >> -Grant >> >> On Fri, Jun 29, 2012 at 10:40 PM, Jason Baugher > >wrote: >> >> Seeing some reports of Pinterest and Instagram down as well. Amazon >>> cloud services being implicated. >>> >>> >>> On 6/29/2012 10:22 PM, Joe Blanchard wrote: >>> >>> Seems that they are unreachable at the moment. Called and theres a >>>> recorded message stating they are aware of an issue, no details. >>>> >>>> -Joe >>>> >>>> >>>> >>>> >>> >>> >> > > > -- Mike Lyon 408-621-4826 mike.lyon at gmail.com http://www.linkedin.com/in/mlyon From ian.m.wilson at gmail.com Fri Jun 29 22:47:31 2012 From: ian.m.wilson at gmail.com (Ian Wilson) Date: Fri, 29 Jun 2012 23:47:31 -0400 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> Message-ID: On Fri, Jun 29, 2012 at 11:44 PM, Grant Ridder wrote: > I have an instance in zone C and it is up and fine, so it must be A, B, or > D that is down. It is my understanding that instance zones are randomized between customers -- so your zone C may be my zone A. Ian -- Ian Wilson ian.m.wilson at gmail.com Solving site load issues with database replication is a lot like solving your own personal problems with heroin -- at first, it sorta works, but after a while things just get out of hand. From shortdudey123 at gmail.com Fri Jun 29 22:49:10 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Fri, 29 Jun 2012 22:49:10 -0500 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> Message-ID: Yes, although, when you launch an instance, you do have the option of selecting a zone if you want. However, once the instance is started it stays in that zone and does not switch. On Fri, Jun 29, 2012 at 10:47 PM, Ian Wilson wrote: > On Fri, Jun 29, 2012 at 11:44 PM, Grant Ridder > wrote: > > I have an instance in zone C and it is up and fine, so it must be A, B, > or > > D that is down. > > It is my understanding that instance zones are randomized between > customers -- so your zone C may be my zone A. > > Ian > -- > Ian Wilson > ian.m.wilson at gmail.com > > Solving site load issues with database replication is a lot like > solving your own personal problems with heroin -- at first, it sorta > works, but after a while things just get out of hand. > From derek at derekivey.com Fri Jun 29 22:48:38 2012 From: derek at derekivey.com (Derek Ivey) Date: Fri, 29 Jun 2012 23:48:38 -0400 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> Message-ID: <4FEE7716.3060407@derekivey.com> I was wondering the same thing! Also, Reddit appears to be really slow right now and I keep getting "reddit is under heavy load right now, sorry. Try again in a few minutes." I wonder if it's related. I believe they use Amazon for some of their stuff. Derek On 6/29/2012 11:47 PM, Mike Lyon wrote: > Whatever happened to UPSs and generators? > > On Fri, Jun 29, 2012 at 8:45 PM, Jason Baugher wrote: > >> Nature is such a PITA. >> >> >> On 6/29/2012 10:42 PM, James Laszko wrote: >> >>> To further expand: >>> >>> 8:21 PM PDT We are investigating connectivity issues for a number of >>> instances in the US-EAST-1 Region. >>> >>> 8:31 PM PDT We are investigating elevated errors rates for APIs in the >>> US-EAST-1 (Northern Virginia) region, as well as connectivity issues to >>> instances in a single availability zone. >>> >>> 8:40 PM PDT We can confirm that a large number of instances in a single >>> Availability Zone have lost power due to electrical storms in the area. We >>> are actively working to restore power. >>> >>> -----Original Message----- >>> From: Grant Ridder [mailto:shortdudey123 at gmail.**com >>> ] >>> Sent: Friday, June 29, 2012 8:42 PM >>> To: Jason Baugher >>> Cc: nanog at nanog.org >>> Subject: Re: FYI Netflix is down >>> >>> >From Amazon >>> >>> Amazon Elastic Compute Cloud (N. Virginia) ( >>> http://status.aws.amazon.com/**) >>> 8:21 PM PDT We are investigating connectivity issues for a number of >>> instances in the US-EAST-1 Region. >>> 8:31 PM PDT We are investigating elevated errors rates for APIs in the >>> US-EAST-1 (Northern Virginia) region, as well as connectivity issues to >>> instances in a single availability zone. >>> >>> -Grant >>> >>> On Fri, Jun 29, 2012 at 10:40 PM, Jason Baugher >>> wrote: >>> Seeing some reports of Pinterest and Instagram down as well. Amazon >>>> cloud services being implicated. >>>> >>>> >>>> On 6/29/2012 10:22 PM, Joe Blanchard wrote: >>>> >>>> Seems that they are unreachable at the moment. Called and theres a >>>>> recorded message stating they are aware of an issue, no details. >>>>> >>>>> -Joe >>>>> >>>>> >>>>> >>>>> >>>> >> >> > From sethm at rollernet.us Fri Jun 29 22:51:28 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 29 Jun 2012 20:51:28 -0700 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> Message-ID: <4FEE77C0.80306@rollernet.us> On 6/29/12 8:47 PM, Mike Lyon wrote: > Whatever happened to UPSs and generators? > You don't need them with The Cloud! But seriously, this is something like the third or fourth time AWS fell over flat in recent memory. ~Seth From shortdudey123 at gmail.com Fri Jun 29 22:52:11 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Fri, 29 Jun 2012 22:52:11 -0500 Subject: FYI Netflix is down In-Reply-To: <4FEE77C0.80306@rollernet.us> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE77C0.80306@rollernet.us> Message-ID: They may use it for content, but reddit.com resolves to IPs own by quest On Fri, Jun 29, 2012 at 10:51 PM, Seth Mattinen wrote: > On 6/29/12 8:47 PM, Mike Lyon wrote: > > Whatever happened to UPSs and generators? > > > > You don't need them with The Cloud! > > But seriously, this is something like the third or fourth time AWS fell > over flat in recent memory. > > ~Seth > > > > From shortdudey123 at gmail.com Fri Jun 29 22:54:43 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Fri, 29 Jun 2012 22:54:43 -0500 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE77C0.80306@rollernet.us> Message-ID: 8:49 PM PDT Power has been restored to the impacted Availability Zone and we are working to bring impacted instances and volumes back online On Fri, Jun 29, 2012 at 10:52 PM, Grant Ridder wrote: > They may use it for content, but reddit.com resolves to IPs own by quest > > > On Fri, Jun 29, 2012 at 10:51 PM, Seth Mattinen wrote: > >> On 6/29/12 8:47 PM, Mike Lyon wrote: >> > Whatever happened to UPSs and generators? >> > >> >> You don't need them with The Cloud! >> >> But seriously, this is something like the third or fourth time AWS fell >> over flat in recent memory. >> >> ~Seth >> >> >> >> > From bill at herrin.us Fri Jun 29 23:03:21 2012 From: bill at herrin.us (William Herrin) Date: Sat, 30 Jun 2012 00:03:21 -0400 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> Message-ID: On Fri, Jun 29, 2012 at 11:42 PM, Grant Ridder wrote: > From Amazon > > Amazon Elastic Compute Cloud (N. Virginia) ?(http://status.aws.amazon.com/) > 8:21 PM PDT We are investigating connectivity issues for a number of > instances in the US-EAST-1 Region. > 8:31 PM PDT We are investigating elevated errors rates for APIs in the > US-EAST-1 (Northern Virginia) region, as well as connectivity issues to > instances in a single availability zone. Major storm: http://www.washingtonpost.com/blogs/capital-weather-gang/post/severe-thunderstorm-watch-through-1-am-for-washington-dc-area/2012/06/29/gJQAY04LCW_blog.html "Storms packing wind gusts of nearly 80 mph have just blown through the D.C.-Baltimore region" https://www.dom.com/storm-center/dominion-electric-outage-summary.jsp Right around 50% of northern Virginia is without power right now. Regards, Bill Herrin Whose generator worked although the first five gas stations I passed had no power. -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sethm at rollernet.us Fri Jun 29 23:11:01 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 29 Jun 2012 21:11:01 -0700 Subject: FYI Netflix is down In-Reply-To: References: Message-ID: <4FEE7C55.9020007@rollernet.us> On 6/29/12 8:22 PM, Joe Blanchard wrote: > Seems that they are unreachable at the moment. Called and theres a recorded > message stating they are aware of an issue, no details. > Streaming services and web; just tried my Roku and it failed to connect. ~Seth From streiner at cluebyfour.org Fri Jun 29 23:22:17 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 30 Jun 2012 00:22:17 -0400 (EDT) Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> Message-ID: On Fri, 29 Jun 2012, Mike Lyon wrote: > Whatever happened to UPSs and generators? They can and do fail. See list archives for numerous reports and examples :) Generators are capable of not starting. ATSs can get into a situation where they don't transfer loads properly, or they can't start the generator(s) UPSs can fail, drain out, or be left in bypass. Breakers can trip and need a manual reset etc... jms > On Fri, Jun 29, 2012 at 8:45 PM, Jason Baugher wrote: > >> Nature is such a PITA. >> >> >> On 6/29/2012 10:42 PM, James Laszko wrote: >> >>> To further expand: >>> >>> 8:21 PM PDT We are investigating connectivity issues for a number of >>> instances in the US-EAST-1 Region. >>> >>> 8:31 PM PDT We are investigating elevated errors rates for APIs in the >>> US-EAST-1 (Northern Virginia) region, as well as connectivity issues to >>> instances in a single availability zone. >>> >>> 8:40 PM PDT We can confirm that a large number of instances in a single >>> Availability Zone have lost power due to electrical storms in the area. We >>> are actively working to restore power. >>> >>> -----Original Message----- >>> From: Grant Ridder [mailto:shortdudey123 at gmail.**com >>> ] >>> Sent: Friday, June 29, 2012 8:42 PM >>> To: Jason Baugher >>> Cc: nanog at nanog.org >>> Subject: Re: FYI Netflix is down >>> >>>> From Amazon >>> >>> Amazon Elastic Compute Cloud (N. Virginia) ( >>> http://status.aws.amazon.com/**) >>> 8:21 PM PDT We are investigating connectivity issues for a number of >>> instances in the US-EAST-1 Region. >>> 8:31 PM PDT We are investigating elevated errors rates for APIs in the >>> US-EAST-1 (Northern Virginia) region, as well as connectivity issues to >>> instances in a single availability zone. >>> >>> -Grant >>> >>> On Fri, Jun 29, 2012 at 10:40 PM, Jason Baugher >>> wrote: >>> >>> Seeing some reports of Pinterest and Instagram down as well. Amazon >>>> cloud services being implicated. >>>> >>>> >>>> On 6/29/2012 10:22 PM, Joe Blanchard wrote: >>>> >>>> Seems that they are unreachable at the moment. Called and theres a >>>>> recorded message stating they are aware of an issue, no details. >>>>> >>>>> -Joe >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> > > > -- > Mike Lyon > 408-621-4826 > mike.lyon at gmail.com > > http://www.linkedin.com/in/mlyon > From j at arpa.com Sat Jun 30 00:38:51 2012 From: j at arpa.com (jamie rishaw) Date: Sat, 30 Jun 2012 00:38:51 -0500 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> Message-ID: you know what's happening even more? ..Amazon not learning their lesson. they just had an outage quite similar.. they "performed a full audit" on electrical systems worldwide, according to the rfo/post mortem. looks like they need to perform a "full and we mean it" audit, and like I've been doing/participating in at dot coms for a decade plus: Actually Do Regular Load tests.. Related/equally to blame: companies that rely heavily on one aws zone, or arguably "one cloud" (period), are asking for it. Please stop these crappy practices, people. Do real world DR testing. Play "What If This City Dropped Off The Map" games, because tonight, parts of VA infact did. Down: Instagram, Pinterest, Netflix, Heroku, Woot. Pocket(Read It Later), and on and on. A bunch of openID sites. A bunch of DNS sites (think zoneedit et al). Infact, probably nearly a /12 if not more of space.. Blame lies both with AWS (again) and with these services providers. They all should know better. -j On Jun 29, 2012 11:22 PM, "Justin M. Streiner" wrote: > On Fri, 29 Jun 2012, Mike Lyon wrote: > > Whatever happened to UPSs and generators? >> > > They can and do fail. See list archives for numerous reports and examples > :) > > Generators are capable of not starting. > ATSs can get into a situation where they don't transfer loads properly, or > they can't start the generator(s) > UPSs can fail, drain out, or be left in bypass. > Breakers can trip and need a manual reset > etc... > > jms > > On Fri, Jun 29, 2012 at 8:45 PM, Jason Baugher > >wrote: >> >> Nature is such a PITA. >>> >>> >>> On 6/29/2012 10:42 PM, James Laszko wrote: >>> >>> To further expand: >>>> >>>> 8:21 PM PDT We are investigating connectivity issues for a number of >>>> instances in the US-EAST-1 Region. >>>> >>>> 8:31 PM PDT We are investigating elevated errors rates for APIs in the >>>> US-EAST-1 (Northern Virginia) region, as well as connectivity issues to >>>> instances in a single availability zone. >>>> >>>> 8:40 PM PDT We can confirm that a large number of instances in a single >>>> Availability Zone have lost power due to electrical storms in the area. >>>> We >>>> are actively working to restore power. >>>> >>>> -----Original Message----- >>>> From: Grant Ridder [mailto:shortdudey123 at gmail.****com< >>>> shortdudey123 at gmail.com> >>>> ] >>>> Sent: Friday, June 29, 2012 8:42 PM >>>> To: Jason Baugher >>>> Cc: nanog at nanog.org >>>> Subject: Re: FYI Netflix is down >>>> >>>> From Amazon >>>>> >>>> >>>> Amazon Elastic Compute Cloud (N. Virginia) ( >>>> http://status.aws.amazon.com/**** ) >>>> 8:21 PM PDT We are investigating connectivity issues for a number of >>>> instances in the US-EAST-1 Region. >>>> 8:31 PM PDT We are investigating elevated errors rates for APIs in the >>>> US-EAST-1 (Northern Virginia) region, as well as connectivity issues to >>>> instances in a single availability zone. >>>> >>>> -Grant >>>> >>>> On Fri, Jun 29, 2012 at 10:40 PM, Jason Baugher >>> >>>>> wrote: >>>>> >>>> >>>> Seeing some reports of Pinterest and Instagram down as well. Amazon >>>> >>>>> cloud services being implicated. >>>>> >>>>> >>>>> On 6/29/2012 10:22 PM, Joe Blanchard wrote: >>>>> >>>>> Seems that they are unreachable at the moment. Called and theres a >>>>> >>>>>> recorded message stating they are aware of an issue, no details. >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> -- >> Mike Lyon >> 408-621-4826 >> mike.lyon at gmail.com >> >> http://www.linkedin.com/in/**mlyon >> >> > From bjorn at leffler.org Sat Jun 30 00:46:58 2012 From: bjorn at leffler.org (Bjorn Leffler) Date: Sat, 30 Jun 2012 15:46:58 +1000 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> Message-ID: On Sat, Jun 30, 2012 at 3:38 PM, jamie rishaw wrote: > ... > Down: Instagram, Pinterest, Netflix, Heroku, Woot. Pocket(Read It Later), > and on and on. ?A bunch of openID sites. ?A bunch of DNS sites (think > zoneedit et al). ?Infact, probably nearly a /12 if not more of space.. > ... Zoneedit doesn't seem to be down . I can both use the website and resolve my domains. From r.engehausen at gmail.com Sat Jun 30 01:07:10 2012 From: r.engehausen at gmail.com (Roy) Date: Fri, 29 Jun 2012 23:07:10 -0700 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> Message-ID: <4FEE978E.8060300@gmail.com> On 6/29/2012 10:38 PM, jamie rishaw wrote: > you know what's happening even more? > > ..Amazon not learning their lesson. > > they just had an outage quite similar.. they "performed a full audit" on > electrical systems worldwide, according to the rfo/post mortem. > > looks like they need to perform a "full and we mean it" audit, and like > I've been doing/participating in at dot coms for a decade plus: Actually Do > Regular Load tests.. > > Related/equally to blame: companies that rely heavily on one aws zone, or > arguably "one cloud" (period), are asking for it. > > Please stop these crappy practices, people. Do real world DR testing. > Play "What If This City Dropped Off The Map" games, because tonight, parts > of VA infact did. > > ... I am not a computer science guy but been around a long time. Data centers and clouds are like software. Once they reach a certain size, its impossible to keep the bugs out. You can test and test your heart out and something will slip by. You can say the same thing about nuclear reactors, Apollo moon missions, the NorthEast power grid, and most other technology disasters. From shortdudey123 at gmail.com Sat Jun 30 01:09:08 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sat, 30 Jun 2012 01:09:08 -0500 Subject: FYI Netflix is down In-Reply-To: <4FEE978E.8060300@gmail.com> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> Message-ID: well one would think that they could at least get power redundancy right... On Sat, Jun 30, 2012 at 1:07 AM, Roy wrote: > On 6/29/2012 10:38 PM, jamie rishaw wrote: > >> you know what's happening even more? >> >> ..Amazon not learning their lesson. >> >> they just had an outage quite similar.. they "performed a full audit" on >> electrical systems worldwide, according to the rfo/post mortem. >> >> looks like they need to perform a "full and we mean it" audit, and like >> I've been doing/participating in at dot coms for a decade plus: Actually >> Do >> Regular Load tests.. >> >> Related/equally to blame: companies that rely heavily on one aws zone, or >> arguably "one cloud" (period), are asking for it. >> >> Please stop these crappy practices, people. Do real world DR testing. >> Play "What If This City Dropped Off The Map" games, because tonight, >> parts >> of VA infact did. >> >> ... >> > > I am not a computer science guy but been around a long time. Data centers > and clouds are like software. Once they reach a certain size, its > impossible to keep the bugs out. You can test and test your heart out and > something will slip by. You can say the same thing about nuclear reactors, > Apollo moon missions, the NorthEast power grid, and most other technology > disasters. > > > > From tyler.haske at gmail.com Sat Jun 30 02:11:56 2012 From: tyler.haske at gmail.com (Tyler Haske) Date: Sat, 30 Jun 2012 03:11:56 -0400 Subject: FYI Netflix is down In-Reply-To: <4FEE978E.8060300@gmail.com> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> Message-ID: > I am not a computer science guy but been around a long time. ?Data centers > and clouds are like software. ?Once they reach a certain size, its > impossible to keep the bugs out. ?You can test and test your heart out and > something will slip by. ?You can say the same thing about nuclear reactors, > Apollo moon missions, the NorthEast power grid, and most other technology > disasters. How to run a datacenter 101. Have more then one location, preferably far apart. It being Amazon I would expect more. :/ From trelane at trelane.net Sat Jun 30 02:15:07 2012 From: trelane at trelane.net (Andrew D Kirch) Date: Sat, 30 Jun 2012 03:15:07 -0400 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> Message-ID: <4FEEA77B.9030507@trelane.net> On 6/30/2012 3:11 AM, Tyler Haske wrote: > How to run a datacenter 101. Have more then one location, preferably > far apart. It being Amazon I would expect more. :/ > Based on? Clouds are nothing more than outsourced responsibility. My business has stopped while my IT department explains to me that it's not their fault because Amazon's down, and I can't exactly fire Amazon. The cloud may be a technological wonder, but as far as business practices go, it's a DISASTER. Andrew From joelja at bogus.com Sat Jun 30 02:24:49 2012 From: joelja at bogus.com (joel jaeggli) Date: Sat, 30 Jun 2012 00:24:49 -0700 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> Message-ID: <4FEEA9C1.1000401@bogus.com> On 6/30/12 12:11 AM, Tyler Haske wrote: >> I am not a computer science guy but been around a long time. Data centers >> and clouds are like software. Once they reach a certain size, its >> impossible to keep the bugs out. You can test and test your heart out and >> something will slip by. You can say the same thing about nuclear reactors, >> Apollo moon missions, the NorthEast power grid, and most other technology >> disasters. > How to run a datacenter 101. Have more then one location, preferably > far apart. It being Amazon I would expect more. :/ there are 7 regions in ec2 three in north america two in asia one in europe and one in south america. us east coast, the one currently being impacted is further subdivided into 5 availability zones. us east 1d appears to be the only one currently being impacted. distributing your application is left as an exercise to the reader. From shrdlu at deaddrop.org Sat Jun 30 02:30:35 2012 From: shrdlu at deaddrop.org (Lynda) Date: Sat, 30 Jun 2012 00:30:35 -0700 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> Message-ID: <4FEEAB1B.7030806@deaddrop.org> On 6/30/2012 12:11 AM, Tyler Haske wrote: > On 6/29/2012 11:07 PM, Roy wrote: >> I am not a computer science guy but been around a long time. Data centers >> and clouds are like software. Once they reach a certain size, its >> impossible to keep the bugs out. You can test and test your heart out and >> something will slip by. You can say the same thing about nuclear reactors, >> Apollo moon missions, the NorthEast power grid, and most other technology >> disasters. > > How to run a datacenter 101. Have more then one location, preferably > far apart. It being Amazon I would expect more. :/ First off. They HAVE more than one location, and they are indeed far apart. That said, it's all mixed together, like some kind of goulash, and the companies who've gone with this particular model for their sites are paying for that fact. Second, and more important. I *was* a "computer science guy" in a past life, and this is nonsense. You can have astonishingly large software projects that just continue to run smoothly, day in, day out, and they don't hit the news, because they don't break. There are data centers that don't hit the news, in precisely the same way. If I had a business, right now, I would not have chosen Amazon's cloud (or anyone's for that matter). I would also not be using Google docs/services, for precisely the same reason. I'm a fan of controlling risk, where possible, and I'd say that this is all in the wrong direction for doing that. No worries, though. It seems we are doomed to continue making the same mistakes, over and over. -- Politicians are like a Slinky. They're really not good for anything, but they still bring a smile to your face when you push them down a flight of stairs. From mysidia at gmail.com Sat Jun 30 06:48:45 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 30 Jun 2012 06:48:45 -0500 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> Message-ID: On 6/30/12, Grant Ridder wrote: > well one would think that they could at least get power redundancy right... It is very similar to suggesting redundancy within a site against building collapse. Reliable power redundancy is very hard and very expensive. Much harder and much more expensive than achieving network redunancy against switch or router failures. And there are always tradeoffs involved, because there is only one utility grid available. There are always some limitations in the amount of isolation possible. You have devices plugged into both power systems. There is some possibility a random device plugged into both systems creates a short in both branches that it plugs into. Both power systems always have to share the same ground, due to safety considerations. Both power systems always have to have fuses or breakers installed, due to safety considerations, and there is always a possibility that various kinds of anomolies cause fuses to simultaneously blow in both systems. -- -JH From streiner at cluebyfour.org Sat Jun 30 06:50:31 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 30 Jun 2012 07:50:31 -0400 (EDT) Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> Message-ID: On Sat, 30 Jun 2012, jamie rishaw wrote: > you know what's happening even more? > > ..Amazon not learning their lesson. I was not giving anyone a free pass or attempting to shrug off the outage. I was just stating that there are many reasons why things break. I haven't seen anything official on this yet, but this looks a lot like a cascading failure. jms From cb.list6 at gmail.com Sat Jun 30 08:12:27 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sat, 30 Jun 2012 06:12:27 -0700 Subject: FYI Netflix is down In-Reply-To: <4FEEA9C1.1000401@bogus.com> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> <4FEEA9C1.1000401@bogus.com> Message-ID: On Jun 30, 2012 12:25 AM, "joel jaeggli" wrote: > > On 6/30/12 12:11 AM, Tyler Haske wrote: >>> >>> I am not a computer science guy but been around a long time. Data centers >>> and clouds are like software. Once they reach a certain size, its >>> impossible to keep the bugs out. You can test and test your heart out and >>> something will slip by. You can say the same thing about nuclear reactors, >>> Apollo moon missions, the NorthEast power grid, and most other technology >>> disasters. >> >> How to run a datacenter 101. Have more then one location, preferably >> far apart. It being Amazon I would expect more. :/ > > there are 7 regions in ec2 three in north america two in asia one in europe and one in south america. > > us east coast, the one currently being impacted is further subdivided into 5 availability zones. > > us east 1d appears to be the only one currently being impacted. > > distributing your application is left as an exercise to the reader. > > +1 Sorry to be the monday morning quarterback, but the sites that went down learned a valuable lesson in single point of failure analysis. A highly redundant and professionally run data center is a single point of failure. Geo-redundancy is key. In fact, i would take distributed data centers over RAID, UPS, or any other "fancy pants" ? mechanisms any day. And, aws East also seems to be cursed. I would run out of west for a while. :-) I would also look into clouds of clouds. ... Who knows. Amazon could have an Enron moment, at which point a corporate entity with a tax id is now a single point of failure. Pay your money, take your chances. CB From mysidia at gmail.com Sat Jun 30 10:06:52 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 30 Jun 2012 10:06:52 -0500 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> <4FEEA9C1.1000401@bogus.com> Message-ID: On 6/30/12, Cameron Byrne wrote: > On Jun 30, 2012 12:25 AM, "joel jaeggli" wrote: >> On 6/30/12 12:11 AM, Tyler Haske wrote: > Geo-redundancy is key. In fact, i would take distributed data centers over > RAID, UPS, or any other "fancy pants" ? mechanisms any day. Geo-redundancy is more expensive than any of those technologies, because it directly impacts every application and reduces performance. It means that, for example, if an application needs to guarantee something is persisted to a distributed database, such as a record that such and such user's credit card has just been charged $X or such and such user has uploaded this blob to the web service ; The round trip time of the longest latency path between any of the redundancy sites, is added to the critical path of the WRITE transaction latency during the commit stage. Because you cannot complete a transaction and ensure you have consistency or correct data, until that transaction reaches a system at the remote site managing the persistence, and is acknowledged as received intact. For example, if you have geo sites, which are a minimum of 250 miles apart; if you recall, light only travels 186.28 miles per millisecond. That means you have a 500 mile round-trip and therefore have added a bare minimum of 2.6 milliseconds of latency to every write transaction, and probably more like 15 milliseconds. If your original transaction latency was at 1 milliseconds. or 1000 transactions per second, AND you require only that the data reaches the remote site and is acknowledged (not that the transaction succeeds at the remote site, before you commit), you are now at a minimum of 2.6 milliseconds average 384 transactions per second. To actually do it safely, you require 3.6 milliseconds, limiting you to an average of 277 transactions per second. If the application is not specially designed for remote site redundancy, then this means you require a scheme such as synchronous storage-level replication to achieve clustering; which has even worse results if there is significant geographic dispersion. RAID transactional latencies are much lower. UPSes and redundant power do not increase transaction latencies at all. -- -JH From sethm at rollernet.us Sat Jun 30 10:23:08 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 30 Jun 2012 08:23:08 -0700 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> Message-ID: <4FEF19DC.9020901@rollernet.us> On 6/30/12 4:50 AM, Justin M. Streiner wrote: > On Sat, 30 Jun 2012, jamie rishaw wrote: > >> you know what's happening even more? >> >> ..Amazon not learning their lesson. > > I was not giving anyone a free pass or attempting to shrug off the > outage. I was just stating that there are many reasons why things > break. I haven't seen anything official on this yet, but this looks a > lot like a cascading failure. > But haven't they all been cascading failures? One can't just say "well it's a huge system, therefore hard". Especially when they claimed to have learned their lesson from previous outwardly similar failures; either they were lying, or didn't really learn anything, or the scope simply exceeds their grasp. If it's too hard for entity X to handle a large system (for whatever "large" means to them), then X needs to break it down into smaller parts that they're capable of handling in a competent manner. ~Seth From r.engehausen at gmail.com Sat Jun 30 10:41:49 2012 From: r.engehausen at gmail.com (Roy) Date: Sat, 30 Jun 2012 08:41:49 -0700 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> Message-ID: <4FEF1E3D.2000701@gmail.com> On 6/30/2012 12:11 AM, Tyler Haske wrote: >> I am not a computer science guy but been around a long time. Data centers >> and clouds are like software. Once they reach a certain size, its >> impossible to keep the bugs out. You can test and test your heart out and >> something will slip by. You can say the same thing about nuclear reactors, >> Apollo moon missions, the NorthEast power grid, and most other technology >> disasters. > How to run a datacenter 101. Have more then one location, preferably > far apart. It being Amazon I would expect more. :/ > . > It doesn't change my theory. You add that complexity, something happens and the failover routing doesn't work as planned. Been there, done that, have the T-shirt. From toddunder at gmail.com Sat Jun 30 11:25:54 2012 From: toddunder at gmail.com (Todd Underwood) Date: Sat, 30 Jun 2012 12:25:54 -0400 Subject: FYI Netflix is down In-Reply-To: <4FEF19DC.9020901@rollernet.us> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> Message-ID: On Jun 30, 2012 11:23 AM, "Seth Mattinen" wrote: > > > But haven't they all been cascading failures? No. They have not. That's not what that term means. 'Cascading failure' has a fairly specific meaning that doesn't imply resilience in the face of decomposition into smaller parts. Cascading failures can occur even when a system is decomposed into small parts, each of which is apparently well run. T From mysidia at gmail.com Sat Jun 30 12:41:02 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 30 Jun 2012 12:41:02 -0500 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> Message-ID: On 6/30/12, Todd Underwood wrote: > On Jun 30, 2012 11:23 AM, "Seth Mattinen" wrote: >> But haven't they all been cascading failures? > No. They have not. That's not what that term means. > > 'Cascading failure' has a fairly specific meaning that doesn't imply > resilience in the face of decomposition into smaller parts. Cascading Not sure where you're going there; Cascading failures are common, but fortunately are usually temporary or have some kind of scope limit. Cascading just means you have a dependency between components, where the failure of one component may result in the failure of a second component, the failure of the second component results in failure of a third component, and this process continues until no more components are dependent or no more components are still operating. This can happen to the small pieces inside of one specific system, causing that system to collapse. It's just as valid to say Cascading failure is across across larger/more complex pieces of different higher level systems, where the components of one system aren't sufficiently independent of those in other systems, causing both systems to fail. Your application logic can be a point of failure, just as readily as your datacenter can. Cascades can happen at a higher level where entire systems are dependant upon entire other systems. And it can happen Organizationally, External dependancy risk occurs when an entire business is dependant on another organization (such as product support), to remotely administer software they sold, and the subcontracter of the product support org. stops doing their job, or a smaller component (one member of their staff) becomes a rogue/malicious element. -- -JH From sethm at rollernet.us Sat Jun 30 13:21:08 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 30 Jun 2012 11:21:08 -0700 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> Message-ID: <4FEF4394.2030108@rollernet.us> On 6/30/12 9:25 AM, Todd Underwood wrote: > > On Jun 30, 2012 11:23 AM, "Seth Mattinen" > wrote: >> >> >> But haven't they all been cascading failures? > > No. They have not. That's not what that term means. > > 'Cascading failure' has a fairly specific meaning that doesn't imply > resilience in the face of decomposition into smaller parts. Cascading > failures can occur even when a system is decomposed into small parts, > each of which is apparently well run. > I honestly have no idea how to parse that since it doesn't jive with my practical view of a cascading failure. ~Seth From toddunder at gmail.com Sat Jun 30 14:04:22 2012 From: toddunder at gmail.com (Todd Underwood) Date: Sat, 30 Jun 2012 15:04:22 -0400 Subject: FYI Netflix is down In-Reply-To: <4FEF4394.2030108@rollernet.us> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> <4FEF4394.2030108@rollernet.us> Message-ID: This was not a cascading failure. It was a simple power outage Cascading failures involve interdependencies among components. T On Jun 30, 2012 2:21 PM, "Seth Mattinen" wrote: > On 6/30/12 9:25 AM, Todd Underwood wrote: > > > > On Jun 30, 2012 11:23 AM, "Seth Mattinen" > > wrote: > >> > >> > >> But haven't they all been cascading failures? > > > > No. They have not. That's not what that term means. > > > > 'Cascading failure' has a fairly specific meaning that doesn't imply > > resilience in the face of decomposition into smaller parts. Cascading > > failures can occur even when a system is decomposed into small parts, > > each of which is apparently well run. > > > > > I honestly have no idea how to parse that since it doesn't jive with my > practical view of a cascading failure. > > ~Seth > > From mysidia at gmail.com Sat Jun 30 14:28:02 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 30 Jun 2012 14:28:02 -0500 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> <4FEF4394.2030108@rollernet.us> Message-ID: On 6/30/12, Todd Underwood wrote: > This was not a cascading failure. It was a simple power outage > Cascading failures involve interdependencies among components. Actually, you can't really say that. It's true that it was a simple power outage for Amazon. Power failed, causing the AWS service at certain locations to experience issues. Any of the issues related to services at locations that didn't lose power are a possible result of cascade. But as for the other possible outages being reported... Instagram, Pinterest, Netflix, Heroku, Woot, Pocket, zoneedit. Possibly Amazon's power failure caused AWS problems, which resulted in issues with these services. Some of these services may actually have had redundancy in place, but experience a failure of their service as a result of unexpected cascade from the affected site. > T -- -JH From mdevlin at aisle10.net Sat Jun 30 14:42:47 2012 From: mdevlin at aisle10.net (Mike Devlin) Date: Sat, 30 Jun 2012 15:42:47 -0400 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> <4FEF4394.2030108@rollernet.us> Message-ID: The last 2 Amazon outages were power issues isolated to just there us-east Virginia data center. I read somewhere that Amazon has something like 70% of their ec2 resources in Virginia and its also their oldest ec2 datacenter..so I am guessing they learned a lot of lessons and are stuck with an aged infrastructure there. I think the real problem here is that a large subset of the customers using ec2 misunderstand the redundancy that is built into the Amazon architecture. You are essentially supposed to view individual virtual machines as bring entirely disposable and make duplicates of everything across availability zones and for extra points across regions. most people instead think that the 2 cents/hour price tag is a massive cost savings and the cloud is invincible..look at the SLA for ec2...Amazon basically doesn't really consider it a real outage unless its more than one availability zone that is down whats more surprising is that netflix was so affected by a single availability zone outage. They are constantly talking about their chaos monkey/simian army tool that purposely breaks random parts of their infrastructure to prove its fault tolerate, or to point out weaknesses to fix. ( http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html) I think the closest thing to a cascading failure they have had was 4/29/11 outage (http://aws.amazon.com/message/65648/) Mike On Jun 30, 2012 3:05 PM, "Todd Underwood" wrote: > This was not a cascading failure. It was a simple power outage > > Cascading failures involve interdependencies among components. > > T > On Jun 30, 2012 2:21 PM, "Seth Mattinen" wrote: > > > On 6/30/12 9:25 AM, Todd Underwood wrote: > > > > > > On Jun 30, 2012 11:23 AM, "Seth Mattinen" > > > wrote: > > >> > > >> > > >> But haven't they all been cascading failures? > > > > > > No. They have not. That's not what that term means. > > > > > > 'Cascading failure' has a fairly specific meaning that doesn't imply > > > resilience in the face of decomposition into smaller parts. Cascading > > > failures can occur even when a system is decomposed into small parts, > > > each of which is apparently well run. > > > > > > > > > I honestly have no idea how to parse that since it doesn't jive with my > > practical view of a cascading failure. > > > > ~Seth > > > > > From sethm at rollernet.us Sat Jun 30 15:03:56 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 30 Jun 2012 13:03:56 -0700 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> <4FEF4394.2030108@rollernet.us> Message-ID: <4FEF5BAC.7040907@rollernet.us> On 6/30/12 12:04 PM, Todd Underwood wrote: > This was not a cascading failure. It was a simple power outage > > Cascading failures involve interdependencies among components. > I guess I'm assuming there were UPS and generator systems involved (and failing) with powering the critical load, but I suppose it could all be direct to utility power. ~Seth From raysonlogin at gmail.com Sat Jun 30 15:08:40 2012 From: raysonlogin at gmail.com (Rayson Ho) Date: Sat, 30 Jun 2012 16:08:40 -0400 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> Message-ID: If I recall correctly, availability zone (AZ) mappings are specific to an AWS account, and in fact there is no way to know if you are running in the same AZ as another AWS account: http://aws.amazon.com/ec2/faqs/#How_can_I_make_sure_that_I_am_in_the_same_Availability_Zone_as_another_developer Also, AWS Elastic Load Balancer (and/or CloudWatch) should be able to detect that some instances are not reachable, and thus can start new instances and remap DNS entries automatically: http://aws.amazon.com/elasticloadbalancing/ This time only 1 AZ is affected by the power outage, so sites with fault tolerance built into their AWS infrastructure should be able to handle the issues relatively easily. Rayson ================================================== Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/ On Fri, Jun 29, 2012 at 11:44 PM, Grant Ridder wrote: > I have an instance in zone C and it is up and fine, so it must be A, B, or > D that is down. > > On Fri, Jun 29, 2012 at 10:42 PM, James Laszko wrote: > >> To further expand: >> >> 8:21 PM PDT We are investigating connectivity issues for a number of >> instances in the US-EAST-1 Region. >> >> ?8:31 PM PDT We are investigating elevated errors rates for APIs in the >> US-EAST-1 (Northern Virginia) region, as well as connectivity issues to >> instances in a single availability zone. >> >> ?8:40 PM PDT We can confirm that a large number of instances in a single >> Availability Zone have lost power due to electrical storms in the area. We >> are actively working to restore power. >> >> -----Original Message----- >> From: Grant Ridder [mailto:shortdudey123 at gmail.com] >> Sent: Friday, June 29, 2012 8:42 PM >> To: Jason Baugher >> Cc: nanog at nanog.org >> Subject: Re: FYI Netflix is down >> >> From Amazon >> >> Amazon Elastic Compute Cloud (N. Virginia) ?(http://status.aws.amazon.com/ >> ) >> 8:21 PM PDT We are investigating connectivity issues for a number of >> instances in the US-EAST-1 Region. >> 8:31 PM PDT We are investigating elevated errors rates for APIs in the >> US-EAST-1 (Northern Virginia) region, as well as connectivity issues to >> instances in a single availability zone. >> >> -Grant >> >> On Fri, Jun 29, 2012 at 10:40 PM, Jason Baugher > >wrote: >> >> > Seeing some reports of Pinterest and Instagram down as well. Amazon >> > cloud services being implicated. >> > >> > >> > On 6/29/2012 10:22 PM, Joe Blanchard wrote: >> > >> >> Seems that they are unreachable at the moment. Called and theres a >> >> recorded message stating they are aware of an issue, no details. >> >> >> >> -Joe >> >> >> >> >> >> >> > >> > >> > >> From randy at psg.com Sat Jun 30 15:09:41 2012 From: randy at psg.com (Randy Bush) Date: Sat, 30 Jun 2012 10:09:41 -1000 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> <4FEEA9C1.1000401@bogus.com> Message-ID: > Sorry to be the monday morning quarterback, but the sites that went > down learned a valuable lesson in single point of failure analysis. as this has happened more than once before, i am less optimistic. or maybe they decided the spof risk was not worth the avoidance costs. randy From jared at puck.nether.net Sat Jun 30 15:13:28 2012 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 30 Jun 2012 16:13:28 -0400 Subject: FYI Netflix is down In-Reply-To: <4FEF5BAC.7040907@rollernet.us> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> <4FEF4394.2030108@rollernet.us> <4FEF5BAC.7040907@rollernet.us> Message-ID: The interesting thing to me is the us population by time zone. If amazon has 70% of servers in the eastern time zone it makes some sense. Mountain + pacific is smaller than central, which is a bit more than half eastern. These stats are older but a good rough gauge: http://answers.google.com/answers/threadview?id=714986 Jared Mauch On Jun 30, 2012, at 4:03 PM, Seth Mattinen wrote: > On 6/30/12 12:04 PM, Todd Underwood wrote: >> This was not a cascading failure. It was a simple power outage >> >> Cascading failures involve interdependencies among components. >> > > I guess I'm assuming there were UPS and generator systems involved (and > failing) with powering the critical load, but I suppose it could all be > direct to utility power. > > ~Seth From scott at doc.net.au Sat Jun 30 15:19:54 2012 From: scott at doc.net.au (Scott Howard) Date: Sat, 30 Jun 2012 13:19:54 -0700 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> <4FEF4394.2030108@rollernet.us> Message-ID: On Sat, Jun 30, 2012 at 12:04 PM, Todd Underwood wrote: > This was not a cascading failure. It was a simple power outage > > Cascading failures involve interdependencies among components. > Not always. Cascading failures can also occur when there is zero dependency between components. The simplest form of this is where one environment fails over to another, but the target environment is not capable of handling the additional load and then "fails" itself as a result (in some form or other, but frequently different to the mode of the original failure). Whilst the Amazon outage might have been a "simple" power outage, it's likely that at least some of the website outages caused were a combination of not just the direct Amazon outage, but also the flow-on effect of their redundancy attempting (but failing) to kick in - potentially making the problem worse than just the Amazon outage caused. Scott From toddunder at gmail.com Sat Jun 30 15:24:41 2012 From: toddunder at gmail.com (Todd Underwood) Date: Sat, 30 Jun 2012 16:24:41 -0400 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> <4FEF4394.2030108@rollernet.us> Message-ID: scott, >> >> This was not a cascading failure. ?It was a simple power outage >> >> Cascading failures involve interdependencies among components. > > > Not always.? Cascading failures can also occur when there is zero dependency > between components.? The simplest form of this is where one environment > fails over to another, but the target environment is not capable of handling > the additional load and then "fails" itself as a result (in some form or > other, but frequently different to the mode of the original failure). indeed. and that is an interdependency among components. in particular, it is a capacity interdependency. > Whilst the Amazon outage might have been a "simple" power outage, it's > likely that at least some of the website outages caused were a combination > of not just the direct Amazon outage, but also the flow-on effect of their > redundancy attempting (but failing) to kick in - potentially making the > problem worse than just the Amazon outage caused. i think you over-estimate these websites. most of them simply have no redundancy (and obviously have no tested, effective redundancy) and were simply hoping that amazon didn't really go down that much. hope is not the best strategy, as it turns out. i suspect that randy is right though: many of these businesses do not promise perfect uptime and can survive these kinds of failures with little loss to business or reputation. twitter has branded it's early failures with a whale that no only didn't hurt it but helped endear the service to millions. when your service fits these criteria, why would you bother doing the complicated systems and application engineering necessary to actually have functional redundancy? it simply isn't worth it. t > > ? Scott From bdha at mirrorshades.net Sat Jun 30 15:45:11 2012 From: bdha at mirrorshades.net (Bryan Horstmann-Allen) Date: Sat, 30 Jun 2012 16:45:11 -0400 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> Message-ID: <20120630204511.GA14160@lab.pobox.com> +------------------------------------------------------------------------------ | On 2012-06-30 16:08:40, Rayson Ho wrote: | | If I recall correctly, availability zone (AZ) mappings are specific to | an AWS account, and in fact there is no way to know if you are running | in the same AZ as another AWS account: | | http://aws.amazon.com/ec2/faqs/#How_can_I_make_sure_that_I_am_in_the_same_Availability_Zone_as_another_developer | | Also, AWS Elastic Load Balancer (and/or CloudWatch) should be able to | detect that some instances are not reachable, and thus can start new | instances and remap DNS entries automatically: | http://aws.amazon.com/elasticloadbalancing/ | | This time only 1 AZ is affected by the power outage, so sites with | fault tolerance built into their AWS infrastructure should be able to | handle the issues relatively easily. Explain Netflix and Heroku last night. Both of whom architect across multiple AZs and have for many years. The API and EBS across the region were also affected. ELB was _also_ affected across the region, and many customers continue to report problems with it. We were told in May of last year after the last massive full-region EBS outage that the "control planes" for the API and related services were being decoupled so issues in a single AZ would not affect all. Seems to not be the case. Just because they offer these features that should help with resiliency doesn't actually mean they _work_ under duress. -- bdha cyberpunk is dead. long live cyberpunk. From mdevlin at aisle10.net Sat Jun 30 15:55:53 2012 From: mdevlin at aisle10.net (Mike Devlin) Date: Sat, 30 Jun 2012 16:55:53 -0400 Subject: FYI Netflix is down In-Reply-To: <20120630204511.GA14160@lab.pobox.com> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <20120630204511.GA14160@lab.pobox.com> Message-ID: On Sat, Jun 30, 2012 at 4:45 PM, Bryan Horstmann-Allen < bdha at mirrorshades.net> wrote: > Explain Netflix and Heroku last night. Both of whom architect across > multiple > AZs and have for many years. > > The API and EBS across the region were also affected. ELB was _also_ > affected > across the region, and many customers continue to report problems with it. > > We were told in May of last year after the last massive full-region EBS > outage > that the "control planes" for the API and related services were being > decoupled > so issues in a single AZ would not affect all. Seems to not be the case. > > Just because they offer these features that should help with resiliency > doesn't > actually mean they _work_ under duress. > -- > But in netflix case, if they architected their environment the way they said they did, why wouldnt they just fail over to us-west? especially at their scale, I wouldn't expect them to be dependent on any AWS function in any region. Mike From bdha at mirrorshades.net Sat Jun 30 16:04:37 2012 From: bdha at mirrorshades.net (Bryan Horstmann-Allen) Date: Sat, 30 Jun 2012 17:04:37 -0400 Subject: FYI Netflix is down In-Reply-To: References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <20120630204511.GA14160@lab.pobox.com> Message-ID: <20120630210436.GA22834@lab.pobox.com> +------------------------------------------------------------------------------ | On 2012-06-30 16:55:53, Mike Devlin wrote: | | But in netflix case, if they architected their environment the way they | said they did, why wouldnt they just fail over to us-west? especially at | their scale, I wouldn't expect them to be dependent on any AWS function in | any region. Have a look at Asgard, the AWS management tool they just open sourced. It implies they rely very heavily on many AWS features, some of which are very much region specific. As to their multi-region capability, I have no idea. I don't think I've ever seen the mention it. -- bdha cyberpunk is dead. long live cyberpunk. From mdevlin at aisle10.net Sat Jun 30 16:13:33 2012 From: mdevlin at aisle10.net (Mike Devlin) Date: Sat, 30 Jun 2012 17:13:33 -0400 Subject: FYI Netflix is down In-Reply-To: <20120630210436.GA22834@lab.pobox.com> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <20120630204511.GA14160@lab.pobox.com> <20120630210436.GA22834@lab.pobox.com> Message-ID: On Sat, Jun 30, 2012 at 5:04 PM, Bryan Horstmann-Allen < bdha at mirrorshades.net> wrote: > > Have a look at Asgard, the AWS management tool they just open sourced. It > implies they rely very heavily on many AWS features, some of which are very > much region specific. > > As to their multi-region capability, I have no idea. I don't think I've > ever > seen the mention it. > -- > bdha > cyberpunk is dead. long live cyberpunk. > yeah, i am sure I am making some assumptions about how much resilience they have been building into their architecture, but since every year they have been getting rid of more and more of their physical infrastructure and putting it fully in AWS, and given the fact they are a pay service, I would think they would account for a region going down Mike From kmedcalf at dessus.com Sat Jun 30 17:15:53 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 30 Jun 2012 16:15:53 -0600 Subject: [c-nsp] NTP Servers In-Reply-To: <001a01cd5156$29082790$7b1876b0$@gmail.com> Message-ID: <67b9d7a824ebf548b02b8606344ea343@mail.dessus.com> > those. The beauty of most appliances is that they're easy to manage. If it > fails, download the latest ISO from company, burn it, boot appliance, > restore it and you're back in business in an hour or so. Keep in mind a > linux kernel running just ntpd and some management necessities like ssh and > http is pretty reliable. Hardly any I/O, just a simple function it does. http is a frilly pink bauble, not a management necessity. Very basic linux with no frilly bauble's, ntpd, sshd, and vi. Supports thousands of clients on a $10 80286 with 640KB RAM booting from a floppy. Add $1000 and you can get the same thing as an "appliance". --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From tshaw at oitc.com Sat Jun 30 17:27:19 2012 From: tshaw at oitc.com (TR Shaw) Date: Sat, 30 Jun 2012 18:27:19 -0400 Subject: Anyone from ATT? Message-ID: <897F9A55-0A17-4BD3-9FB0-9CB59D43D7DD@oitc.com> Please contact me off list. I have problems with our equipment on these two ATT netblocks communicating between one another. AT&T Services, Inc. ATT (NET-12-0-0-0-1) 12.0.0.0 - 12.255.255.255 CFWN Pool ATTCT-NMPL20 ATTW-042909163717 (NET-12-88-176-0-1) 12.88.176.0 - 12.88.191.255 and NetRange: 108.192.0.0 - 108.255.255.255 CIDR: 108.192.0.0/10 OriginAS: AS7132 NetName: SBCIS-SBIS From kmedcalf at dessus.com Sat Jun 30 17:39:36 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 30 Jun 2012 16:39:36 -0600 Subject: [c-nsp] NTP Servers In-Reply-To: <8C6A44F7-FBC7-4F42-9830-22572A96FF3C@puck.nether.net> Message-ID: <7447aaf43870fd4fb89ebc21c0752320@mail.dessus.com> > Or you can ask the it guys to use a windows server... Eg: > > http://support.microsoft.com/kb/816042 That is a joke Jared? You left off the smiley. Windows doesn't do NTP out-of-the-box (Microsoft assertions to the contrary notwithstanding). You can build a reasonably working standard daemon, however don't expect time to be very accurate. Windows out-of-the-box can keep time +/- 10 minutes or so using the Microsoft lets-pretend-NTP. You can build the current standard NTPD distribution on Windows. You can also spend lots of time to make it "work as well as possible" (once you manage to get it to compile, that is). Even so, when you have configured it to the optimality of accuracy, this is what you can expect: remote refid st t when poll reach delay offset jitter ============================================================================== +tic.nrc.ca .PPS. 1 u 13 64 377 55.544 5.913 0.870 -tac.nrc.ca .ATOM. 1 u 48 64 377 56.188 4.768 3.041 -toc.nrc.ca .ATOM. 1 u 1 64 377 55.485 4.758 0.981 +tick.usask.ca .GPS. 1 u 34 64 377 19.566 6.942 5.699 *tock.usask.ca .GPS. 1 u 29 64 377 19.665 5.955 1.937 -clock.isc.org .GPS. 1 u 37 64 377 53.091 8.311 0.649 +clock.sjc.he.ne .CDMA. 1 u 48 64 377 43.591 6.066 2.501 offset: 0.005955 s frequency: 23.346 ppm poll adjust: -30 watchdog timer: 47 s is about the best you will get. Statistics are pretty awful: Date # O.Avg O.Median O.Range O.CI O.Skew O.Kurt F.Avg F.Median F.Range F.CI F.Kurt 2012-01 899 0.765559 0.004198 20.05221 0.000371 -0.56023 0.751151 21.31698 20.9705 2.9685 0.108050 -0.88068 2012-02 9673 0.237434 -7.46502 59.75607 0.000156 -1.43583 8.609085 19.01126 19.3495 5.2995 0.040683 -0.54578 2012-03 1380 -0.02157 -14.8416 44.00043 0.000124 -1.08589 4.559049 18.08941 16.822 7.536 0.045387 0.268831 2012-04 1322 0.196654 21.16261 106.1250 0.000141 -0.48643 26.05868 17.56811 16.812 6.111 0.040561 -0.38021 2012-05 8849 0.118125 27.44213 72.01526 0.000161 0.296114 8.939429 17.88685 15.2595 9.3195 0.080186 1.121740 2012-06 1457 0.409662 -20.2809 63.32684 0.000114 -1.44144 11.98237 20.50724 19.5425 6.7425 0.042372 -0.08891 6102 0.201651 21.16261 106.1250 6.065429 -0.84354 13.78161 18.71838 16.1125 10.1725 0.023443 1.215941 This is from a custom ntpd build using the highest precision that it can manage to coerce from Windoze. Of course, this may be accurate enough for most uses -- at least it does not have to time-step. Doesn't compare to ntpd on linux on an 80286 with 640K ram booting from a floppy, which can maintain time sync within less than 1 ms easily. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From shortdudey123 at gmail.com Sat Jun 30 17:42:42 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Sat, 30 Jun 2012 17:42:42 -0500 Subject: [c-nsp] NTP Servers In-Reply-To: <7447aaf43870fd4fb89ebc21c0752320@mail.dessus.com> References: <8C6A44F7-FBC7-4F42-9830-22572A96FF3C@puck.nether.net> <7447aaf43870fd4fb89ebc21c0752320@mail.dessus.com> Message-ID: I don't understand why anyone would use windows server for anything that needed precision like time. On Sat, Jun 30, 2012 at 5:39 PM, Keith Medcalf wrote: > > > Or you can ask the it guys to use a windows server... Eg: > > > > http://support.microsoft.com/kb/816042 > > That is a joke Jared? You left off the smiley. > > Windows doesn't do NTP out-of-the-box (Microsoft assertions to the > contrary notwithstanding). You can build a reasonably working standard > daemon, however don't expect time to be very accurate. Windows > out-of-the-box can keep time +/- 10 minutes or so using the Microsoft > lets-pretend-NTP. > > You can build the current standard NTPD distribution on Windows. You can > also spend lots of time to make it "work as well as possible" (once you > manage to get it to compile, that is). Even so, when you have configured > it to the optimality of accuracy, this is what you can expect: > > remote refid st t when poll reach delay offset > jitter > > ============================================================================== > +tic.nrc.ca .PPS. 1 u 13 64 377 55.544 5.913 > 0.870 > -tac.nrc.ca .ATOM. 1 u 48 64 377 56.188 4.768 > 3.041 > -toc.nrc.ca .ATOM. 1 u 1 64 377 55.485 4.758 > 0.981 > +tick.usask.ca .GPS. 1 u 34 64 377 19.566 6.942 > 5.699 > *tock.usask.ca .GPS. 1 u 29 64 377 19.665 5.955 > 1.937 > -clock.isc.org .GPS. 1 u 37 64 377 53.091 8.311 > 0.649 > +clock.sjc.he.ne .CDMA. 1 u 48 64 377 43.591 6.066 > 2.501 > > offset: 0.005955 s > frequency: 23.346 ppm > poll adjust: -30 > watchdog timer: 47 s > > is about the best you will get. Statistics are pretty awful: > > Date # O.Avg O.Median O.Range O.CI O.Skew > O.Kurt F.Avg F.Median F.Range F.CI F.Kurt > 2012-01 899 0.765559 0.004198 20.05221 0.000371 -0.56023 > 0.751151 21.31698 20.9705 2.9685 0.108050 -0.88068 > 2012-02 9673 0.237434 -7.46502 59.75607 0.000156 -1.43583 > 8.609085 19.01126 19.3495 5.2995 0.040683 -0.54578 > 2012-03 1380 -0.02157 -14.8416 44.00043 0.000124 -1.08589 > 4.559049 18.08941 16.822 7.536 0.045387 0.268831 > 2012-04 1322 0.196654 21.16261 106.1250 0.000141 -0.48643 > 26.05868 17.56811 16.812 6.111 0.040561 -0.38021 > 2012-05 8849 0.118125 27.44213 72.01526 0.000161 0.296114 > 8.939429 17.88685 15.2595 9.3195 0.080186 1.121740 > 2012-06 1457 0.409662 -20.2809 63.32684 0.000114 -1.44144 > 11.98237 20.50724 19.5425 6.7425 0.042372 -0.08891 > 6102 0.201651 21.16261 106.1250 6.065429 -0.84354 > 13.78161 18.71838 16.1125 10.1725 0.023443 1.215941 > > This is from a custom ntpd build using the highest precision that it can > manage to coerce from Windoze. > > Of course, this may be accurate enough for most uses -- at least it does > not have to time-step. > > Doesn't compare to ntpd on linux on an 80286 with 640K ram booting from a > floppy, which can maintain time sync within less than 1 ms easily. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > > > > From alter3d at alter3d.ca Sat Jun 30 17:52:57 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sat, 30 Jun 2012 18:52:57 -0400 Subject: [c-nsp] NTP Servers In-Reply-To: References: <8C6A44F7-FBC7-4F42-9830-22572A96FF3C@puck.nether.net> <7447aaf43870fd4fb89ebc21c0752320@mail.dessus.com> Message-ID: <4FEF8349.1050804@alter3d.ca> You could have saved yourself a bit of typing by leaving off the last 5 words of that sentence. ;) - Pete On 6/30/2012 6:42 PM, Grant Ridder wrote: > I don't understand why anyone would use windows server for anything that > needed precision like time. > > On Sat, Jun 30, 2012 at 5:39 PM, Keith Medcalf wrote: > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4431 bytes Desc: S/MIME Cryptographic Signature URL: From mysidia at gmail.com Sat Jun 30 18:23:14 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 30 Jun 2012 18:23:14 -0500 Subject: [c-nsp] NTP Servers In-Reply-To: References: <8C6A44F7-FBC7-4F42-9830-22572A96FF3C@puck.nether.net> <7447aaf43870fd4fb89ebc21c0752320@mail.dessus.com> Message-ID: On 6/30/12, Grant Ridder wrote: > I don't understand why anyone would use windows server for anything that > needed precision like time. Probably because they realize that in a Windows domain, their domain controllers already provide a SNTP service with the Windows NT PDC Emulator providing authoritative time for windows time service, and all those windows servers can be enabled as a NTP server with a small configuration change, and Windows Domain clients are required to be synchronized with this using the Windows time service, as a condition for Kerberos authentication and domain logon, for the configuration to be a supported one. So, given you already have those capabilities and those constraints... how do you justify deploying another server for providing a separate time service, running a new OS, instead of just using the same one for all hosts? In many cases it's not "Why use a windows time server" that has to be justified; the burden of proof is to answer the question "What can you say that indicates you should definitely not use a windows time server for the application?" :) -- -JH From rbf+nanog at panix.com Sat Jun 30 19:08:51 2012 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sat, 30 Jun 2012 19:08:51 -0500 Subject: FYI Netflix is down In-Reply-To: References: <4FEE7671.2060403@thebaughers.com> <4FEF19DC.9020901@rollernet.us> <4FEF4394.2030108@rollernet.us> Message-ID: <20120701000851.GA10721@panix.com> On Sat, Jun 30, 2012 at 01:19:54PM -0700, Scott Howard wrote: > On Sat, Jun 30, 2012 at 12:04 PM, Todd Underwood wrote: > > > This was not a cascading failure. It was a simple power outage > > > > Cascading failures involve interdependencies among components. > > > > Not always. Cascading failures can also occur when there is zero > dependency between components. The simplest form of this is where one > environment fails over to another, but the target environment is not > capable of handling the additional load and then "fails" itself as a result > (in some form or other, but frequently different to the mode of the > original failure). That's an interdependency. Environment A is dependent on environment B being up and pulling some of the load away from A; B is dependent on A beingup and pulling some of the load away from B. A Crashes for reason X -> Load Shifts to B -> B Crashes due to load is a classic cascading failure. And it's not limited to software systems. It's how most major blackouts occur (except with more than three steps in the cascade, of course). -- Brett From pauldotwall at gmail.com Sat Jun 30 20:16:52 2012 From: pauldotwall at gmail.com (Paul WALL) Date: Sat, 30 Jun 2012 21:16:52 -0400 Subject: F-ckin Leap Seconds, how do they work? Message-ID: Comments? Drive Slow Paul From mysidia at gmail.com Sat Jun 30 20:19:45 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 30 Jun 2012 20:19:45 -0500 Subject: F-ckin Leap Seconds, how do they work? In-Reply-To: References: Message-ID: http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14. On 6/30/12, Paul WALL wrote: > Comments? > > Drive Slow > Paul > > -- -JH From bonomi at mail.r-bonomi.com Sat Jun 30 21:13:10 2012 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 30 Jun 2012 21:13:10 -0500 (CDT) Subject: F-ckin Leap Seconds, how do they work? In-Reply-To: Message-ID: <201207010213.q612DAbR009810@mail.r-bonomi.com> > From: Paul WALL > Subject: F-ckin Leap Seconds, how do they work? > > Comments? Addressing the Subject question, _as_asked_ -- "Very well". *SNORT* Mechanically, instead of rolling over from second #59 to second #0 of the next minute, it goes 59->60->0. The 'why' is to keep terrestrial clocks in sync with celestial references. From d3e3e3 at gmail.com Sat Jun 30 21:12:55 2012 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sat, 30 Jun 2012 22:12:55 -0400 Subject: F-ckin Leap Seconds, how do they work? In-Reply-To: References: Message-ID: See International Earth Rotation Service, http://www.iers.org/, particularly http://data.iers.org/products/6/15003/orig/bulletina-xxv-026.txt Thanks, Donald ============================= ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell) ?155 Beaver Street,?Milford, MA 01757 USA ?d3e3e3 at gmail.com On Sat, Jun 30, 2012 at 9:16 PM, Paul WALL wrote: > Comments? > > Drive Slow > Paul > From paul at paulgraydon.co.uk Sat Jun 30 21:43:16 2012 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Sat, 30 Jun 2012 16:43:16 -1000 Subject: F-ckin Leap Seconds, how do they work? In-Reply-To: References: Message-ID: <4FEFB944.2010006@paulgraydon.co.uk> On 6/30/2012 3:16 PM, Paul WALL wrote: > Comments? > > Drive Slow > Paul > > Not very well if you have a modern box (RHES/CentOS 6) and Java apps running on them. RHES/CentOS 5 merrily ignored it. Worse, just bouncing the Java stack didn't fix it, it required the box to be rebooted. A sizeable number of annoyed sysadmins tweeting about it this afternoon. Paul From raymond at prolocation.net Sat Jun 30 21:49:57 2012 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Sun, 1 Jul 2012 04:49:57 +0200 (CEST) Subject: F-ckin Leap Seconds, how do they work? In-Reply-To: <4FEFB944.2010006@paulgraydon.co.uk> References: <4FEFB944.2010006@paulgraydon.co.uk> Message-ID: Hi! >> Drive Slow >> Paul > Not very well if you have a modern box (RHES/CentOS 6) and Java apps running > on them. RHES/CentOS 5 merrily ignored it. Worse, just bouncing the Java > stack didn't fix it, it required the box to be rebooted. A sizeable number > of annoyed sysadmins tweeting about it this afternoon. Anything with java running seems hit. We just finished up a firm round of reboots... :( Recent Ubuntu boxes and RHES 6... all the same ... Bye, Raymond. From gbonser at seven.com Sat Jun 30 22:01:39 2012 From: gbonser at seven.com (George Bonser) Date: Sun, 1 Jul 2012 03:01:39 +0000 Subject: F-ckin Leap Seconds, how do they work? In-Reply-To: References: <4FEFB944.2010006@paulgraydon.co.uk> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09DF80D3@RWC-MBX1.corp.seven.com> > > Anything with java running seems hit. > We just finished up a firm round of reboots... :( > > Recent Ubuntu boxes and RHES 6... all the same ... > > Bye, > Raymond. > > Yeah, in the process of doing the same. http://news.ycombinator.com/item?id=4183122 Might try this for machines with Java applications in order to avoid reboot: https://bugzilla.mozilla.org/show_bug.cgi?id=769972 See comment 5 From gbonser at seven.com Sat Jun 30 22:16:10 2012 From: gbonser at seven.com (George Bonser) Date: Sun, 1 Jul 2012 03:16:10 +0000 Subject: F-ckin Leap Seconds, how do they work? In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09DF80D3@RWC-MBX1.corp.seven.com> References: <4FEFB944.2010006@paulgraydon.co.uk> <596B74B410EE6B4CA8A30C3AF1A155EA09DF80D3@RWC-MBX1.corp.seven.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09DF8311@RWC-MBX1.corp.seven.com> > > > > Anything with java running seems hit. > > We just finished up a firm round of reboots... :( > > > > Recent Ubuntu boxes and RHES 6... all the same ... > > > > Bye, > > Raymond. > > > > > > Yeah, in the process of doing the same. > > http://news.ycombinator.com/item?id=4183122 > > Might try this for machines with Java applications in order to avoid > reboot: > > https://bugzilla.mozilla.org/show_bug.cgi?id=769972 > > > See comment 5 > > And we have verified that this clears the issue for us. YMMV. From derek at derekivey.com Sat Jun 30 23:41:25 2012 From: derek at derekivey.com (Derek Ivey) Date: Sun, 01 Jul 2012 00:41:25 -0400 Subject: F-ckin Leap Seconds, how do they work? In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09DF8311@RWC-MBX1.corp.seven.com> References: <4FEFB944.2010006@paulgraydon.co.uk> <596B74B410EE6B4CA8A30C3AF1A155EA09DF80D3@RWC-MBX1.corp.seven.com> <596B74B410EE6B4CA8A30C3AF1A155EA09DF8311@RWC-MBX1.corp.seven.com> Message-ID: <4FEFD4F5.5090306@derekivey.com> We haven't had any issues with any of our VMs. We run several of our own Java/Tomcat apps, Jira, and Confluence on a mixture of Solaris and CentOS 5 and 6. We do not run NTP on our VMs though; instead, we rely on VMware Tools to sync the VMs' time with the ESXi hosts. The ESXi hosts run NTP. On 6/30/2012 11:16 PM, George Bonser wrote: >>> Anything with java running seems hit. >>> We just finished up a firm round of reboots... :( >>> >>> Recent Ubuntu boxes and RHES 6... all the same ... >>> >>> Bye, >>> Raymond. >>> >>> >> Yeah, in the process of doing the same. >> >> http://news.ycombinator.com/item?id=4183122 >> >> Might try this for machines with Java applications in order to avoid >> reboot: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=769972 >> >> >> See comment 5 >> >> > And we have verified that this clears the issue for us. YMMV. > > From cra at WPI.EDU Sat Jun 30 23:57:35 2012 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 1 Jul 2012 00:57:35 -0400 Subject: F-ckin Leap Seconds, how do they work? In-Reply-To: <4FEFD4F5.5090306@derekivey.com> References: <4FEFB944.2010006@paulgraydon.co.uk> <596B74B410EE6B4CA8A30C3AF1A155EA09DF80D3@RWC-MBX1.corp.seven.com> <596B74B410EE6B4CA8A30C3AF1A155EA09DF8311@RWC-MBX1.corp.seven.com> <4FEFD4F5.5090306@derekivey.com> Message-ID: <20120701045734.GE27183@angus.ind.WPI.EDU> Same here with KVM guests on Scientific Linux 6 (RHEL 6 clone) hosts. No issues on SL 6 and CentOS 5 guests. We also do not run NTP on the VMs, only on the hosts. The guest VM kernels did not log any leap second clock change, but appear to have the same time as the hosts. The hosts DID have issues though. The "reset the date" workaround solved the issue immediately, with no requirement to restart anything, including ntpd. The hosts logged leap second clock updates: Jun 30 19:59:59 vmhost kernel: Clock: inserting leap second 23:59:60 UTC My Fedora 16 laptop was also being sluggish due to chromium-browser sucking up CPU. That too was fixed immediately by resetting the date. On Sun, Jul 01, 2012 at 12:41:25AM -0400, Derek Ivey wrote: > We haven't had any issues with any of our VMs. We run several of our > own Java/Tomcat apps, Jira, and Confluence on a mixture of Solaris > and CentOS 5 and 6. We do not run NTP on our VMs though; instead, we > rely on VMware Tools to sync the VMs' time with the ESXi hosts. The > ESXi hosts run NTP. > > On 6/30/2012 11:16 PM, George Bonser wrote: > >>>Anything with java running seems hit. > >>>We just finished up a firm round of reboots... :( > >>> > >>>Recent Ubuntu boxes and RHES 6... all the same ... > >>> > >>>Bye, > >>>Raymond. > >>> > >>> > >>Yeah, in the process of doing the same. > >> > >>http://news.ycombinator.com/item?id=4183122 > >> > >>Might try this for machines with Java applications in order to avoid > >>reboot: > >> > >>https://bugzilla.mozilla.org/show_bug.cgi?id=769972 > >> > >> > >>See comment 5 > >> > >> > >And we have verified that this clears the issue for us. YMMV. From aaron at bavariati.org Sat Jun 30 19:39:02 2012 From: aaron at bavariati.org (Aaron Burt) Date: Sat, 30 Jun 2012 17:39:02 -0700 Subject: [FoRK] FYI Netflix is down In-Reply-To: <4FEEA77B.9030507@trelane.net> References: <4FEE753C.4030007@thebaughers.com> <8078ED370ADA824281219A7B5BADC39B1D61037C@MBX023-W1-CA-5> <4FEE7671.2060403@thebaughers.com> <4FEE978E.8060300@gmail.com> <4FEEA77B.9030507@trelane.net> Message-ID: <20120701003902.GA16380@aaron-acer> On Sat, Jun 30, 2012 at 03:15:07AM -0400, Andrew D Kirch wrote: > On 6/30/2012 3:11 AM, Tyler Haske wrote: > >How to run a datacenter 101. Have more then one location, preferably > >far apart. It being Amazon I would expect more. :/ Amazon has many datacenters and tries to make it easy to diversify. > Based on? Clouds are nothing more than outsourced responsibility. > My business has stopped while my IT department explains to me that > it's not their fault because Amazon's down It *is* their fault. You can blame faulty manufacturing for having a HDD die, but it's IT's fault if it takes out the only copy of your database. AWS 101: Amazon has clearly-marked "Availablity Zones" for a reason. Oh, and business 101: have an exit strategy for every vendor. This outage is mighty interesting. It's surprising how many big operations had poor availability strategies. Also, I've been working on an exit strategy for one of my VM/colo providers, and AWS + colo in NoVa is one of my options. > The cloud may be a technological wonder, but as far as > business practices go, it's a DISASTER. I wouldn't say so. Like any disruptive service, you're getting an acceptably lower-quality product for significantly less money. And like most disruptors, it operates by different rules than the old stuff. Regards, Aaron _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork