April 2011 - Test - lists.nanog.org

The state-level attack on the SSL CA security model
by Martin Millnert 20 Nov '25

20 Nov '25

To my surprise, I did not see a mention in this community of the latest proof of the complete failure of the SSL CA model to actually do what it is supposed to: provide security, rather than a false sense of security. Essentially a state somewhere between Iraq and Pakistan snatched valid certs for: - mail.google.com - www.google.com - login.yahoo.com - login.skype.com - addons.mozilla.org - login.live.com - "global trustee" https://blog.torproject.org/blog/detecting-certificate-authority-compromise… http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html http://www.imperialviolet.org/2011/03/18/revocation.html (on epic failure of cert revocation lists implementations in browsers, failing open (!)) http://blog.mozilla.com/security/2011/03/22/firefox-blocking-fraudulent-cer… http://www.microsoft.com/technet/security/advisory/2524375.mspx For over a week users of browsers, and the internet at large, were/was not informed by COMODO that their security was compromised. "Why not" is beyond many of us. Announcing this high and loud even before fixes were available would not have exposed more users to threats, but less. Conclusion: protecting people must not be a priority in the SSL CA model. In some places, failure of internet security means people die, and it is high time to start serious work to replace this time-and-time again proven flawed model with something that, at the very least, does not fail this tragically. DNSSEC is a good but insufficient start in this particular case. Regards, Martin

28 39

Re: NANOG NYC Event
by Fisher, Shawn 30 Jul '25

30 Jul '25

Personally I like dinosaur bbq, great malt beverages as well, and also blue smoke is great and if you like jazz, check out downstairs. -------------------------- Sent using BlackBerry -----Original Message----- From: andrew young To: Scott Brim CC: nanog(a)nanog.org Sent: Sat May 31 18:28:57 2008 Subject: Re: NANOG NYC Event Speaking of food, ill be going to the Big Apple BBQ fest next weekend: http://bigapplebbq.org/2008/ If you love to eat BBQ, this is a big MUST to cap off your stay in NYC. if you do decided to go, be sure to get the Fastpass: http://www.bigapplebbq.org/2008/index.php?s=fastpass You dont want to wait 30 mins online for food. Don't forget a bib and leave your belt at home. :-) - ------------------------------------ Andrew Young Webair Internet Development, Inc Phone: 1 866 WEBAIR 1 FAX: 516.938.5100 http://www.webair.com andrewy(a)webair.com ------------------------------------- We are interested in any feedback you might have about the service you received. Please contact our technical support consumer care manager directly at 1.866.WEBAIR1 or e-mail customercare(a)webair.com ------------------------------------- On Sat, 2008-05-31 at 18:17 -0400, Scott Brim wrote: > On 5/31/08 12:36 PM, Rod Beck allegedly wrote: > > I strongly suggest that those heading to New York visit the great > > musems, architecture (Saint Patrick's Cathedral), and restaurants. > > You have the American Museum of Natural History, which includes an > > excellent Planetarium and just on the other side of Central Park, the > > Metropolitan Museum of Art and the Guggenheim. There are excellent > > Chinese and Indian restaurants in Lower Manhattan. > > Don't forget about Brooklyn in all this Manhattan praise :-). Consider > the Brooklyn Botanic Garden. It's too late for cherries but the rose > collections will be great. And the best pizza in New York (if you can > get in) is at > http://menupages.com/restaurantdetails.asp?areaid=0&restaurantid=31402&neig… >

15 17

Blocking private AS
by Thomas Magill 27 Nov '13

27 Nov '13

I am thinking about implementing a filter to block all traffic with private AS numbers in the path. I see quite a few in my table though so I am concerned I might block some legitimate traffic. In some cases, these are just prefixes with the private appended to the end but a few have the private as a transit. Is this a good idea or would I likely be blocking too much legitimate traffic? The filter I am using currently shows the following: BGP table version is 5462394, local router ID is 209.112.253.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * i58.68.109.0/24 x.x.x.x 0 100 0 6130 9498 10201 65534 i *> y.y.y.y 0 6130 9498 10201 65534 i * i68.115.224.0/24 x.x.x.x 0 100 0 6130 19151 20115 65011 i *> y.y.y.y 0 6130 19151 20115 65011 i * 85.112.22.0/24 y.y.y.y 0 6130 6939 23148 64532 64532 64532 64532 64532 64532 64532 64532 64532 i *> 93.189.194.0/24 y.y.y.y 0 6130 3549 39386 39386 39386 25233 65000 47146 i * i x.x.x.x 0 100 0 6130 3549 39386 39386 39386 25233 65000 47146 i *> 96.60.243.0/24 y.y.y.y 0 6130 2828 4181 65528 i * i x.x.x.x 0 100 0 6130 2828 4181 65528 i * i96.61.232.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i * i96.61.233.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i * i96.61.234.0/24 x.x.x.x 0 100 0 6130 2828 4181 65527 i *> y.y.y.y 0 6130 2828 4181 65527 i *> 148.207.2.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i *> 148.207.40.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i *> 148.207.97.0/24 y.y.y.y 0 6130 2828 3257 16531 13579 65090 i * i x.x.x.x 0 100 0 6130 2828 3257 16531 13579 65090 i * 170.34.100.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * 170.34.104.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * 170.34.113.0/24 y.y.y.y 0 6130 19151 20115 65011 ? * i174.35.1.0/24 x.x.x.x 0 100 0 6130 16467 64565 i * i174.47.199.0/24 x.x.x.x 0 100 0 6130 2828 4323 15065 65123 i *> y.y.y.y 0 6130 2828 4323 15065 65123 i * i192.109.61.0 x.x.x.x 0 100 0 6130 19151 20115 65011 i *> y.y.y.y 0 6130 19151 20115 65011 i *> 196.216.249.0 y.y.y.y 0 6130 2828 3257 8513 8513 8513 36881 65000 36896 37062 i * i x.x.x.x 0 100 0 6130 2828 3257 8513 8513 8513 36881 65000 36896 37062 i Network Next Hop Metric LocPrf Weight Path *> 209.172.69.128/30 y.y.y.y 0 6130 16467 64565 i * i x.x.x.x 0 100 0 6130 16467 64565 i *> 213.146.161.0 y.y.y.y 0 6130 2828 174 64679 48493 i * i x.x.x.x 0 100 0 6130 2828 174 64679 48493 i Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill@providecommerce.com <mailto:tmagill@providecommerce.com> provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers <http://www.proflowers.com/> | redENVELOPE <http://www.redenvelope.com/> | Cherry Moon Farms <http://www.cherrymoonfarms.com/> | Shari's Berries <http://www.berries.com/>

3 2

Network topology
by Colin Alston 15 Nov '13

15 Nov '13

Hi all I'm considering trying to come up with some means to automatically detect a networks topology and draw pretty pictures. This is somewhat boring though if a network isn't well arranged with VLANs and q-tag trunk routers and so on (It will just look like a big cloud of junk connected off an assumed switch). Is there any kind of cunning trick to detect standard layer2 switches along a path without stuff like STP?

9 12

Inventory and workflow management systems
by vijay gill 26 May '13

26 May '13

What software solution do people use for inventory management for things like riser/conduit drawdown, fiber inventory, physical topology store, CLR/DLR, x-connect, contracts, port inventory, etc. Any experiences in integrating workflow into those packages for work orders, modeling, drawdown levels, etc. /vijay

10 13

Re: Over a decade of DDOS--any progress yet?
by alvaro.sanchez＠adinet.com.uy 04 Oct '11

04 Oct '11

A very common action is to blackhole ddos traffic upstream by sending a bgp route to the next AS with a preestablished community indicating the traffic must be sent to Null0. The route may be very specific, in order to impact as less as possible. This needs previous coordination between providers. Regards. >----Mensaje original---- >De: rdobbins(a)arbor.net >Fecha: 08/12/2010 10:53 >Para: "North American Operators' Group"<nanog(a)nanog.org> >Asunto: Re: Over a decade of DDOS--any progress yet? > > >On Dec 8, 2010, at 7:28 PM, Arturo Servin wrote: > >> One big problem (IMHO) of DDoS is that sources (the host of botnets) may be completely unaware that they are part of a DDoS. I do not mean the bot machine, I mean the ISP connecting those. > >The technology exists to detect and classify this attack traffic, and is deployed in production networks today. > >And of course, the legitimate owners of the botted hosts are generally unaware that their machine is being used for nefarious purposes. > >> In the other hand the target of a DDoS cannot do anything to stop to attack besides adding more BW or contacting one by one the whole path of providers to try to minimize the effect. > >Actually, there're lots of things they can do. > >> I know that this has many security concerns, but would it be good a signalling protocol between ISPs to inform the sources of a DDoS attack in order to take semiautomatic actions to rate-limit the traffic as close as the source? Of course that this is more complex that these three or two lines, but I wonder if this has been considerer in the past. > >It already exists. > >----------------------------------------------------------------------- >Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks.com> > > Sell your computer and buy a guitar. > > > > > >

18 46

Verizon Issues? East Coast US
by ML 03 Aug '11

03 Aug '11

Seeing some packet loss via Cogent. www.internetpulse.net seems to be lighting up.

8 12

IPv6 - a noobs prespective
by Robert Lusby 14 Jun '11

14 Jun '11

As part of my role, I'm responsible, for a small (20 - 25 machine) network in the UK. When it comes to IPv6 I'm a complete noob. So ok - this is how I stand for IPv6: I "get" IPv4, I get NAT, I get why it's needed, and I get why it's evil. I know my IPv4 network inside and out, how DHCP runs and assigns addresses, how that ties in with our VPN, how everything gets channeled via the NAT to our ISP etc ... I also get why we need IPv6, that it means removing the NAT (which, surprise surprise also runs our Firewall), and I that I might need new kit for it. I am however *terrified* of making that move. There is so many new phrases, words, things to think about etc I want to, I'm keen to, and I know we have to, move to IPv6 - but at the moment it just seems so complicated - not least without affecting any IPv4 stuff. Just my own two pence from a noobie point of view. * On a side note - what's the best guide for upgrading a simple Windows network to run on IPv6? I'll take a read.

18 24

World of Warcraft may begin using IPv6 on Tuesday
by Kevin Day 09 Jun '11

09 Jun '11

For those that don't know, World of Warcraft is currently the largest online role playing game, with somewhere over 12 million subscribers. Version 4.1 of the game is expected to be released this Tuesday, which will be automatically pushed to all clients. The current Beta version of 4.1 has full IPv6 support. In the beta, it's automatically enabled if you have native IPv6 (non-6to4, non-Teredo). While Blizzard has been pretty silent about this, barring a last minute revert or delay of this patch, there are suddenly going to be a bunch more users that can potentially use IPv6. And these users are the type who are going to be especially sensitive to latency, jitter and packet loss, since this is a real-time game platform. For those of you with Help Desks who have to support users like this, the associated setting in the game's Options menu is apparently called "Enable IPv6 when available". It's apparently grayed out if you do not have IPv6 at all, unchecked by default if you are on 6to4 or Teredo, and checked by default if you are on native v6. The tooltip says: "Enables the use of IPv6, the technology behind the next-generation Internet. Requires IPv6 connectivity to the internet. Checking this box without IPv6 connectivity may prevent you from playing WoW." Anyone from Activision/Blizzard who would like to chime in with more details? :) -- Kevin

11 11

How do you put a TV station on the Mbone? (was: Royal Wedding...)
by Jay Ashworth 12 May '11

12 May '11

----- Original Message ----- > From: "Ryan Malayter" <malayter(a)gmail.com> > On Apr 28, 11:14 pm, Jay Ashworth <j...(a)baylink.com> wrote: > > > (cough)multicast(cough) > > > > But... but... how do we count the viewers, then? > > Isn't the real problem with global multicast: "How do we ultimately > bill the broadcaster for all that traffic amplification that happened > *inside* every other AS?" It seems like you'd have to do per-packet > accounting at every router, and coordinate billing/reporting amongst > all providers that saw those packets. See, now, I expected to hear that objection. Internet engineers are prone to try to solve this problem in favor of the viewer, and their networks -- with their networks winning in case of a push. *Program providers*, OTOH, have a completely different set of "optimal" parameters -- many of which are directly at odds with that approach, and most of which are completely ignored by Internet engineering types when working on this stuff. And OTGH, even if, say, a local TV station wanted to let people do this sort of thing, *the people they get their programs from* -- both at the Network and the "provider to Network" level -- will expect to have their own say in the matter. *Certainly* there should be a Multicast Cloud, and an easy way for program providers to dump things into it. But, as you say, who's going to pay for it is an issue, and how one enforces that is another even more contentious one. Layer 9 is a *bitch*, isn't it? So: if I *wanted* to put my video in the multicast cloud... how would I do it? I do, after all, now work for a TV network which sells things; this is not an idle question for me: the more people who can see me, the better. Is it a nice, packaged howto, with easily built code? Pointers? Cause it seems to me that the fewer speedbumps there are along the way, the sooner it will happen, all that nassty, nassty commerce, notwithstanding. Cheers, -- jra

36 88