From rdobbins at arbor.net Tue Nov 1 00:19:15 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 1 Nov 2011 05:19:15 +0000 Subject: Manage an enterprise network? Please fill out my survey - for Science! :-) In-Reply-To: References: <5948995898631926267@unknownmsgid> <4EAF6EFA.5000702@gmail.com> <4EAF71E3.7030406@brightok.net> Message-ID: <4B2F33DF-5B04-4B73-943A-8A818E5C7507@arbor.net> On Nov 1, 2011, at 11:44 AM, Cameron Byrne wrote: > Unfotunately ISPs are deploying many middle boxen, frequently in series, for various reasons...cough cough cgn. This AusNOG presentation touches upon the topic: ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From jbates at brightok.net Tue Nov 1 01:28:53 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Nov 2011 01:28:53 -0500 Subject: Manage an enterprise network? Please fill out my survey - for Science! :-) In-Reply-To: <4B2F33DF-5B04-4B73-943A-8A818E5C7507@arbor.net> References: <5948995898631926267@unknownmsgid> <4EAF6EFA.5000702@gmail.com> <4EAF71E3.7030406@brightok.net> <4B2F33DF-5B04-4B73-943A-8A818E5C7507@arbor.net> Message-ID: <4EAF91A5.2040505@brightok.net> On 11/1/2011 12:19 AM, Dobbins, Roland wrote: > On Nov 1, 2011, at 11:44 AM, Cameron Byrne wrote: > >> Unfotunately ISPs are deploying many middle boxen, frequently in series, for various reasons...cough cough cgn. > This AusNOG presentation touches upon the topic: > > > > heh, Until IPv6 is a mainstream, I don't think wireless companies (and soon wireline) have much choice on CGN. I believe there are plenty of CGN products that handle as much or more pps than my Juniper MX960 does. My last DDOS killed the egress pps on 2 of my NSP transits. Neither could send 2Mpps of traffic to me (ie, neither was line rate at 43bytes). I'm confused as to the 6to4 gateway state. Last I checked, all my 6to4 is stateless. My load balancers are also stateless. IPS can be deployed sidelined with hardware packet mirroring and remote updates to router ACLs. I recognize that ISPs may not keep DDOS in mind and reduce state when possible, but there is current tech that can limit state and still deploy the same services. CGN is the exception to the rule, and I've yet to see a way around it in a depleted IPv4 Internet (but as stated, most CGN is designed to handle state to the same performance levels as current router tech). Jack From rdobbins at arbor.net Tue Nov 1 01:41:05 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 1 Nov 2011 06:41:05 +0000 Subject: Manage an enterprise network? Please fill out my survey - for Science! :-) In-Reply-To: <4EAF91A5.2040505@brightok.net> References: <5948995898631926267@unknownmsgid> <4EAF6EFA.5000702@gmail.com> <4EAF71E3.7030406@brightok.net> <4B2F33DF-5B04-4B73-943A-8A818E5C7507@arbor.net> <4EAF91A5.2040505@brightok.net> Message-ID: <18FE168D-5D42-40B9-B3DB-27F58781DD95@arbor.net> On Nov 1, 2011, at 1:28 PM, Jack Bates wrote: > I'm confused as to the 6to4 gateway state. Last I checked, all my 6to4 is stateless. Depends upon the technology being used. I probably should've used a different term. > My load balancers are also stateless. Most are not, or aren't configured to be so (i.e., most seem to be set up to handle the outbound server-to-client comms, too). I see them go down like tenpins in trivial DDoS attacks all the time. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From me at payam124.com Tue Nov 1 01:59:58 2011 From: me at payam124.com (Payam Poursaied) Date: Tue, 1 Nov 2011 10:29:58 +0330 Subject: Network Asset/Service Track/Management Message-ID: <08f701cc9863$e03d74d0$a0b85e70$@com> Hi all I'm looking for a system to keep track of network assets and also periodic services in each pop site. Currently we have about 500 pop-sites. In each site we have DSLAMs, Linecards and also some passive equipments including terminals, racks and .. Also each site may have some recurring fees/services. Something like transit link, power, rental space and . Could you please share your experience with me Best Regards Payam Poursaied -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5605 bytes Desc: not available URL: From babak at farrokhi.net Tue Nov 1 02:38:36 2011 From: babak at farrokhi.net (Babak Farrokhi) Date: Tue, 1 Nov 2011 11:08:36 +0330 Subject: Network Asset/Service Track/Management In-Reply-To: <08f701cc9863$e03d74d0$a0b85e70$@com> References: <08f701cc9863$e03d74d0$a0b85e70$@com> Message-ID: <560B6E25-3AF2-4945-8505-FE2FA38B8BED@farrokhi.net> Hi, I would suggest you use the element management software provided by your vendor. But you may want to take a look at www.ziptie.org for an alternative. Regards, On Nov 1, 2011, at 10:29 AM, Payam Poursaied wrote: > Hi all > > I'm looking for a system to keep track of network assets and also periodic services in each pop site. Currently we have > about 500 pop-sites. In each site we have DSLAMs, Linecards and also some passive equipments including terminals, racks > and .. > > Also each site may have some recurring fees/services. Something like transit link, power, rental space and . > > > > Could you please share your experience with me > > > > Best Regards > > Payam Poursaied > > > -- Babak Farrokhi Network Expert / Unix SA / Security Analyst From mikereedwt at gmail.com Tue Nov 1 04:03:14 2011 From: mikereedwt at gmail.com (Mike Reed) Date: Tue, 1 Nov 2011 09:03:14 +0000 Subject: consumer DSL problems Message-ID: Hi folks, It would seem that my home broadband provider (Orange, formerly known as Wanadoo/Freeserve) have made some networking changes at the weekend. The first I knew of it was when my DSL router refused to connect. It's a vendor-supplied Siemens Gigaset SE572. While it's probably not the best router in the world (most consumer routers are risible), it was generally fine. On complaint, they tell me it's 'old'. Closer inspection reveals it's picking up the DSL carrier signal fine, but failing during LCP negotation Is there a common policy on rendering vendor-supplied CPEs unusable? As a network operator to residential users, would you notify any potentially affected users before making such a change? I am grateful for any insight. Kind regards, Mike From charles at knownelement.com Tue Nov 1 04:22:13 2011 From: charles at knownelement.com (Charles N Wyble) Date: Tue, 01 Nov 2011 04:22:13 -0500 Subject: Network Asset/Service Track/Management In-Reply-To: <560B6E25-3AF2-4945-8505-FE2FA38B8BED@farrokhi.net> References: <08f701cc9863$e03d74d0$a0b85e70$@com> <560B6E25-3AF2-4945-8505-FE2FA38B8BED@farrokhi.net> Message-ID: <4EAFBA45.3070700@knownelement.com> On 11/01/2011 02:38 AM, Babak Farrokhi wrote: > Hi, > > I would suggest you use the element management software provided by your vendor. But you may want to take a look at www.ziptie.org for an alternative. Also nocproject.org From regnauld at nsrc.org Tue Nov 1 04:29:37 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 1 Nov 2011 10:29:37 +0100 Subject: Network Asset/Service Track/Management In-Reply-To: <08f701cc9863$e03d74d0$a0b85e70$@com> References: <08f701cc9863$e03d74d0$a0b85e70$@com> Message-ID: <20111101092937.GG10684@macbook.bluepipe.net> Payam Poursaied (me) writes: > Hi all > > I'm looking for a system to keep track of network assets and also periodic services in each pop site. Currently we have > about 500 pop-sites. In each site we have DSLAMs, Linecards and also some passive equipments including terminals, racks > and .. > > Also each site may have some recurring fees/services. Something like transit link, power, rental space and . > > Could you please share your experience with me Hi Payam, Some of what you mention can be handled with Netdot (https://netdot.uoregon.edu). There is built-in support for maintenance contract definitions, but some customization might be required. The good part about netdot is that it will automate some of the inventory management if it has SNMP access to your devices. Asset mgmt support is rather good for Cisco equipment, but would have to be tested for other vendors. Cheers, Phil From doctorchd at gmail.com Tue Nov 1 04:52:49 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Tue, 1 Nov 2011 11:52:49 +0200 Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: Thanks to everybody who responded. To summarize it all, these are the guides for non-ISP company to use PI IPv6 addresses: case 1: single POP, no plans to have more - get single /48 from your RIR, announce it to one or multiple ISPs that POP is connected to case 1a: multiple separate POPs (no VPN interconnections) - the same as for case 1 but for each POP independently; each POP has individual AS, btw case 2: extranet like multiple POPs interconnected with VPNs - get greater then /48 block (like /44) so each POP gets its /48 part - each POP announces its corresponding /48 prefix to their local ISPs - decide if you wish that traffic from Internet to some POP passes through some other of your POPs (security or other considerations); if this is desirable you may announce the whole aggregate (like /44) additionally to /48 from all or some of the POPs; optionally you may wish to announce /44 with community 'no-export' As for /48 IPv6 blocks being like /24 for IPv4. It really seems that /48 may be the most popular PI block and this may lead to overcrowding of DFZ. Probably, this is logical consequence of getting bigger address space. We needed more IP addresses and we get them. Anyway getting greater then /48 just because you do not want to pollute DFZ is not justified. Thank you. Dmitry Cherkasov 2011/11/1 Ricky Beam : > On Mon, 31 Oct 2011 05:39:57 -0400, Richard Barnes > wrote: >> >> Couldn't you also advertise the /48 from all the sites, if you're >> willing to sort things out over the inter-site VPNs? > > If we're talking about a site-to-site IPsec VPN "over the internet", then > that's a very bad idea. ?Even if "the internet" in this case is entirely > within the same provider's network. (and it doesn't sound like it is.) > > --Ricky > > From streiner at cluebyfour.org Tue Nov 1 06:10:19 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 1 Nov 2011 07:10:19 -0400 (EDT) Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: On Tue, 1 Nov 2011, Dmitry Cherkasov wrote: > case 2: extranet like multiple POPs interconnected with VPNs > - get greater then /48 block (like /44) so each POP gets its /48 part > - each POP announces its corresponding /48 prefix to their local ISPs > - decide if you wish that traffic from Internet to some POP passes > through some other of your POPs (security or other considerations); if > this is desirable you may announce the whole aggregate (like /44) > additionally to /48 from all or some of the POPs; optionally you may > wish to announce /44 with community 'no-export' You really don't need to tag the larger block with no-export. In fact, if the POPs are suitably interconnected on the back end, you really don't need to advertise the /48s all, and just advertise the /44. Depending on your upstreams, you might be able to tag your advertisements with certain BGP communities (will vary from provider to provider) to give you some degree of conrol over traffic distribution. Getting back to the original point, unless someone does something odd with their BGP views, the /48s will be preferred because they're smaller (more specific), and the /44 would only be used if a corresponding /48 prefix doesn't exist in their BGP view. jms From bclark at spectraaccess.com Tue Nov 1 07:05:42 2011 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 01 Nov 2011 08:05:42 -0400 Subject: consumer DSL problems In-Reply-To: References: Message-ID: <4EAFE096.6090401@spectraaccess.com> On 11/01/2011 05:03 AM, Mike Reed wrote: > > Is there a common policy on rendering vendor-supplied CPEs unusable? Yes if they are old. > As a network operator to residential users, would you notify any > potentially affected users before making such a change? Any responsible provider would make sure to notify users before making the change and then not make the change until all users had been upgraded to a new modem...within reason of course...some customer are hard to reach and never respond, so at some point you just have to make the switch. Regards, Bret From paulooi at takizo.com Tue Nov 1 09:25:37 2011 From: paulooi at takizo.com (takizo) Date: Tue, 1 Nov 2011 22:25:37 +0800 Subject: Network Asset/Service Track/Management In-Reply-To: <20111101092937.GG10684@macbook.bluepipe.net> References: <08f701cc9863$e03d74d0$a0b85e70$@com> <20111101092937.GG10684@macbook.bluepipe.net> Message-ID: <0D0E7EDE-E090-409A-AD41-FD22C1C8C0A9@takizo.com> On Nov 1, 2011, at 5:29 PM, Phil Regnauld wrote: > Payam Poursaied (me) writes: >> Hi all >> >> I'm looking for a system to keep track of network assets and also periodic services in each pop site. Currently we have >> about 500 pop-sites. In each site we have DSLAMs, Linecards and also some passive equipments including terminals, racks >> and .. >> >> Also each site may have some recurring fees/services. Something like transit link, power, rental space and . >> >> Could you please share your experience with me > > Hi Payam, > > Some of what you mention can be handled with Netdot (https://netdot.uoregon.edu). > > There is built-in support for maintenance contract definitions, but some > customization might be required. The good part about netdot is that it > will automate some of the inventory management if it has SNMP access to > your devices. Asset mgmt support is rather good for Cisco equipment, but > would have to be tested for other vendors. > > Cheers, > Phil > +1 on Netdot, it's good stuff ;) From chip.gwyn at gmail.com Tue Nov 1 09:35:52 2011 From: chip.gwyn at gmail.com (chip) Date: Tue, 1 Nov 2011 10:35:52 -0400 Subject: Network Asset/Service Track/Management In-Reply-To: <08f701cc9863$e03d74d0$a0b85e70$@com> References: <08f701cc9863$e03d74d0$a0b85e70$@com> Message-ID: For tracking gear, space, racks, power, assets, etc... Might want to take a look at NetZoomDC by Altima Technologies. They're doing some neat stuff. For the recurring fees and such, not quite sure it will meet your needs but there are customizable categories, elements, and what not you can apply to things and create customer reports and stuff. It all runs on top of Microsoft's SQL server, with Excel and Word for reporting functions. I assume anything you can do in an Excel sheet can be hooked into it. --chip On Tue, Nov 1, 2011 at 2:59 AM, Payam Poursaied wrote: > Hi all > > I'm looking for a system to keep track of network assets and also periodic services in each pop site. Currently we have > about 500 pop-sites. In each site we have DSLAMs, Linecards and also some passive equipments including terminals, racks > and .. > > Also each site may have some recurring fees/services. Something like transit link, power, rental space and . > > > > Could you please share your experience with me > > > > Best Regards > > Payam Poursaied > > > > -- Just my $.02, your mileage may vary,? batteries not included, etc.... From owen at delong.com Tue Nov 1 10:13:32 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Nov 2011 08:13:32 -0700 Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: <386FD22B-CD9D-4944-BBAE-2C9BAA1CFF11@delong.com> > > As for /48 IPv6 blocks being like /24 for IPv4. > It really seems that /48 may be the most popular PI block and this may > lead to overcrowding of DFZ. Probably, this is logical consequence of > getting bigger address space. We needed more IP addresses and we get > them. Anyway getting greater then /48 just because you do not want to > pollute DFZ is not justified. > I agree with you except this last statement. If you have a need for more than a /48 and you can announce the aggregate and not the more specifics, it is perfectly valid to get more than a /48 and you should do so in a way that allows you to announce only the aggregate so as to avoid polluting the DFZ. DFZ pollution is not about prefix size, it is about the number of prefixes. In all cases, one should attempt to implement the minimum number of prefixes necessary to effect your desired (or needed) routing policy. Prefix size, OTOH, should relate to the number of end-sites served where each end-site gets a /48. Owen From owen at delong.com Tue Nov 1 10:20:40 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Nov 2011 08:20:40 -0700 Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: On Nov 1, 2011, at 4:10 AM, Justin M. Streiner wrote: > On Tue, 1 Nov 2011, Dmitry Cherkasov wrote: > >> case 2: extranet like multiple POPs interconnected with VPNs >> - get greater then /48 block (like /44) so each POP gets its /48 part >> - each POP announces its corresponding /48 prefix to their local ISPs >> - decide if you wish that traffic from Internet to some POP passes >> through some other of your POPs (security or other considerations); if >> this is desirable you may announce the whole aggregate (like /44) >> additionally to /48 from all or some of the POPs; optionally you may >> wish to announce /44 with community 'no-export' > > You really don't need to tag the larger block with no-export. In fact, > if the POPs are suitably interconnected on the back end, you really > don't need to advertise the /48s all, and just advertise the /44. Depending on your upstreams, you might be able to tag your advertisements with certain BGP communities (will vary from provider to provider) to give you some degree of conrol over traffic distribution. > > Getting back to the original point, unless someone does something odd with their BGP views, the /48s will be preferred because they're smaller (more specific), and the /44 would only be used if a corresponding /48 prefix doesn't exist in their BGP view. > > jms In fact, if you have one or more providers which, in common, serve multiple POPs, it may be desirable to tag the more specifics (/48s) as no-export and leave the /44s exportable. In this way, you can avoid unnecessary DFZ pollution. Owen From lists at mtin.net Tue Nov 1 10:39:46 2011 From: lists at mtin.net (Justin Wilson) Date: Tue, 01 Nov 2011 11:39:46 -0400 Subject: OT:Hotmail mail Admin Message-ID: Hi all, Sorry for the offtopic post. I have a need to talk to a real person at Hotmail regarding a user account. The normal channels aren't getting me what I need. Thanks, Justin From jmaimon at ttec.com Tue Nov 1 11:59:47 2011 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 01 Nov 2011 12:59:47 -0400 Subject: Verizon ISP mailing list / ATM ports Message-ID: <4EB02583.7050004@ttec.com> Hey All, I am looking for verizon ATM/DSL wholesale DSL ports for NY/NJ latas, and I found some verizon-isp mailing lists, but nothing seems current. Off-list replies are welcome. Thanks, Joe From kloch at kl.net Tue Nov 1 13:22:31 2011 From: kloch at kl.net (Kevin Loch) Date: Tue, 01 Nov 2011 14:22:31 -0400 Subject: Colocation providers and ACL requests In-Reply-To: References: Message-ID: <4EB038E7.4070703@kl.net> Christopher Pilkington wrote: > Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as: > > deny udp any a.b.c.d/24 eq 80 > > ?to refuse and tell us we must subscribe to their managed DDOS product? We have always accommodated temporary ACL's for active DDOS attacks. I think that is fairly standard across the ISP/hosting industry. I do feel it is bad practice to regularly implement customer specific ACL's on routers. If a customer wants a managed firewall we have a full range of those services available. - Kevin From carlosm3011 at gmail.com Tue Nov 1 14:20:23 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Tue, 1 Nov 2011 17:20:23 -0200 Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: My take on the issue is that your providers are wise in not wanting to accept prefixes longer than /48s. You should get multiple prefixes, from the same or different RIRs. If there are policies in place which do not allow you to do so, I think it's a good time to discuss them. regards Carlos On Mon, Oct 31, 2011 at 5:56 AM, Dmitry Cherkasov wrote: > Hello, > > Please advice what is the best practice to use IPv6 address block > across distributed locations. > > Recently we obtained our PI /48 from RIPE. The idea was to assign > partial slices from this block to different locations (we have > currently 3 offices in Europe and 2 in USA). All locations are > interconnected with static VPNs. Each location is supposed to > establish BGP session with local ISP. Partial prefix /56 + aggregate > /48 (with long AS PATH) are to be announced by each office. > > The problem we ran across is that ISP in US does not wish to accept > prefixes longer then /48 from us. > Need your advice: is this normal to distribute /48 by /56 parts across > locations or should we obtain separate /48 for each of them? Or maybe > we need /32 that can be split into multiple /48? Anyway we are not ISP > so /48 looks quite reasonable and sufficient for all our needs. > > Thank you. > > Dmitry Cherkasov > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From carlosm3011 at gmail.com Tue Nov 1 14:23:20 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Tue, 1 Nov 2011 17:23:20 -0200 Subject: Mexico? In-Reply-To: <00c401cc9521$2ad65250$8082f6f0$@gmail.com> References: <00c401cc9521$2ad65250$8082f6f0$@gmail.com> Message-ID: Mexico-based networks get their IP blocks (v4 and v6) from NIC Mexico (http://www.nic.mx). NIC Mexico and NIC Brasil are the two NIRs within LACNIC's service area. regards Carlos On Fri, Oct 28, 2011 at 1:24 AM, Ryan Finnesey wrote: > If I want to get a block of IP's issued for a network within Mexico who do I > talk with? ?I have been told arin does not cover Mexico. ?It was my > understand arin covers North America. > > > > Cheers > > Ryan > > > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From cjp at 0x1.net Tue Nov 1 14:51:04 2011 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Tue, 1 Nov 2011 15:51:04 -0400 Subject: Random five character string added to URLs? Message-ID: This might be off-topic, my apologies if so. I seeing requests against a server with initial GET requests in the form: GET /[a-zA-Z]{5}/pagename.html pagename.html being optional. The 5 character string seems to be random. This GET always results in a 404, as our servers don't have these paths. The second request seems to always the same without the modified path, which results in a 20. I initially suspected this was something from an attack or DOS tool, but the traffic doesn't fit such a pattern. Is anyone familiar with what device/service behaves in this fashion? Clearly something layer 7 is between the clients and the server. Provider is without clue regarding this. Google results in many GoDaddy users complaining of same; the server in question is not hosted with them, but I suspect they may be doing something similar. Thanks, -cjp From carlosm3011 at gmail.com Tue Nov 1 14:54:05 2011 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Tue, 1 Nov 2011 17:54:05 -0200 Subject: Outgoing SMTP Servers In-Reply-To: <5F2E5817-06E1-4822-9405-431098D7902A@drtel.com> References: <4EAED155.8040604@mtcc.com> <201110312119.p9VLJEck099196@mail.r-bonomi.com> <5F2E5817-06E1-4822-9405-431098D7902A@drtel.com> Message-ID: The point to make here is: - if an ISP takes the path of blocking tcp/25, then they MUST communicate this appropiately to customers and other users - they also MUST provide alternatives: SMTP over SSL should be allowed (tcp/465), authenticated relay, but *something*. IMO blocking 25/tcp is a side-effect of the failure of the whole ISP system to decisively deal with spammers. It's easier to blind-block 25/tcp than to do proper investigations and to collaborate with law enforcement. I have tried to hand reports with *static* IP addresses, contract identifiers and even home, mobile and work phone numbers of known spammers in Uruguay (I happen to have my personal feud with one that sells dog food), only to be shelved by management on the fears of legal action. I have also trouble swallowing the argument of "blocking 25/tcp is great because it avoids us getting into black lists and reduces spam". Yes, sure, but that doesn't prove it's the right approach in the long run, as you are dealing with symptoms and not causes/sources. It's the same thing as having tons of aspirines each time you have a headache. Even if the pain subsides, you might still have other underlying conditions that in fact are being masqueraded by your "solution". So, as it is often the case in society, we all pay the price. On Mon, Oct 31, 2011 at 11:17 PM, Brian Johnson wrote: > > > Sent from my iPad > > On Oct 31, 2011, at 4:17 PM, "Robert Bonomi" > > > >> There is an at-least-somewhat-valid argument against outbound filtering. >> to wit, various receiving systems may have different policies on what is/ >> is-not 'acceptable' traffic. ?They have a better idea of what is acceptable >> to the recipients (their users), than the originating MTA operator does. An >> originating system cannot accomodate that diversity of opinions _without_ >> getting input from all prospective recipients. >> >> And it is, of course, 'not practical' for every email recipient to notify >> every email 'source' network as to what that recpient considers 'acceptable'. >> > > This is not plausible. It also has nothing to do with a network owner protecting his network from his own users. > >> >> There are only a relative handful of things a _residential_ provider can >> use to "reliably" filter outgoing mail. A non-comprehensive list: >> ?1) 'Greylisting' at the origin is as effective at stopping spam as it is >> ? ? at the destination. >> ?2) Checks for certain kinds of standards violations that legitimate mail >> ? ? software does not make. >> ?3) Check for certain kinds of 'lies' in headers -- things that *cannot* >> ? ? occur in legitimate email. >> ?4) 'Rate-limiting' to detect/quarrantine abnormal traffic levels. >> ?5) Tracking SMTP 'MAIL FROM:" and the "From:" (or 'Resent-From:', if >> ? ? present), and quarrantining on abnormal numbers of different putative >> ? ? origins. >> >> There's no point in checking source addresses against any DNSBL, for reasons >> that should be 'obvious'. ?<*GRIN*> >> >> Further, any sort of "content" filters prevent customers from _discussing_ >> scams in e-mail. >> >> There is a 'hard' problem in letting the source 'opt out' of such filtering, >> because an intentional 'bad guy' will request his outgoing mail not be >> monitored, as well as the person who has a 'legitimate' reason for sending >> messages that might trip mindless content filters. >> >> Statistical note: ?Out of the last roughly 6,000 pieces of spam seen here, >> circa 2,700 were caught by checks 2), and 3) above, and another circa 2,600 >> were in character-sets not supported here. ? Incidentally, spam volume, as >> seen here, is running a bit _under_ 2/3 of all email, down from a peak of >> over 95%. >> > > This misses the point of the thread which is not filtering. It is port 25 blocking. Statistically all of he problems exist on TCP port 25. This is why the filtering is largely effective. > > - Brian > -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net ========================= From jbates at brightok.net Tue Nov 1 15:19:39 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 01 Nov 2011 15:19:39 -0500 Subject: Colocation providers and ACL requests In-Reply-To: <4EB038E7.4070703@kl.net> References: <4EB038E7.4070703@kl.net> Message-ID: <4EB0545B.6080900@brightok.net> On 11/1/2011 1:22 PM, Kevin Loch wrote: > Christopher Pilkington wrote: >> Is it common in the industry for a colocation provider, when requested >> to put an egress ACL facing us such as: >> >> deny udp any a.b.c.d/24 eq 80 >> >> ?to refuse and tell us we must subscribe to their managed DDOS product? > > We have always accommodated temporary ACL's for active DDOS attacks. I > think that is fairly standard across the ISP/hosting industry. > > I do feel it is bad practice to regularly implement customer specific > ACL's on routers. If a customer wants a managed firewall we have a > full range of those services available. > And Managed DDOS products better be a LOT more than an ACL. If I'm going to pay someone to manage DDOS, they will scrub the traffic and let all my legitimate traffic through. That's what I'm paying for. null routing an IP or a simple acl isn't worth paying a dime for. Jack From sfouant at shortestpathfirst.net Tue Nov 1 18:05:22 2011 From: sfouant at shortestpathfirst.net (=?utf-8?B?U3RlZmFuIEZvdWFudA==?=) Date: Tue, 01 Nov 2011 19:05:22 -0400 Subject: =?utf-8?B?UmU6IFJhbmRvbSBmaXZlIGNoYXJhY3RlciBzdHJpbmcgYWRkZWQgdG8gVVJMcz8=?= Message-ID: Is there anything perhaps protecting or intercepting the data on its way to the server, perhaps an Arbor device of some type of load balancer? This type of behavior is quite common when protecting web assets to eliminate zombies and such, but its usually something you would see back to the clients, not tp the server. Also, IIRC, the LOIC DoS tool had this ability to create random strings in the URL, and I believe it did so with 5 characters. Might want to do a packet trace and identify if this is coming from LOIC. Regards, Stefan Fouant Technical Trainer, Juniper Networks GPG Key ID: 0xB4C956EC Sent from my HTC EVO. ----- Reply message ----- From: "Christopher J. Pilkington" Date: Tue, Nov 1, 2011 3:51 pm Subject: Random five character string added to URLs? To: This might be off-topic, my apologies if so. I seeing requests against a server with initial GET requests in the form: GET /[a-zA-Z]{5}/pagename.html pagename.html being optional. The 5 character string seems to be random. This GET always results in a 404, as our servers don't have these paths. The second request seems to always the same without the modified path, which results in a 20. I initially suspected this was something from an attack or DOS tool, but the traffic doesn't fit such a pattern. Is anyone familiar with what device/service behaves in this fashion? Clearly something layer 7 is between the clients and the server. Provider is without clue regarding this. Google results in many GoDaddy users complaining of same; the server in question is not hosted with them, but I suspect they may be doing something similar. Thanks, -cjp From mysidia at gmail.com Tue Nov 1 19:00:54 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 1 Nov 2011 19:00:54 -0500 Subject: Colocation providers and ACL requests In-Reply-To: <4EB038E7.4070703@kl.net> References: <4EB038E7.4070703@kl.net> Message-ID: On Tue, Nov 1, 2011 at 1:22 PM, Kevin Loch wrote: > Christopher Pilkington wrote: > We have always accommodated temporary ACL's for active DDOS attacks. ?I > think that is fairly standard across the ISP/hosting industry. And it's reasonable to accomodate the customer that asks, and reasonable for a customer to ask for a temporary ACL in such situations. However, it's also reasonable for the provider to refuse, and there's nothing wrong with that, unless the provider agreed that they would be willing to do that, and then refused to do something they had already agreed to do. The provider might be especially dissuaded from responding and providing a temporary ACL for free if the DoS is a "small" one based on the provider's definition of small, or if the provider doesn't have or won't allocate the resources to respond, without charging a fee to do so. Or its a cut rate hosting service, and the customer refused to buy the "managed filtering" firewall (or whatever solution). In that case, it's reasonable for the provider to counter the request with "You can buy our such and service, and we will gladly implement that" If this is something you want to be sure you can do, then you should ask the provider about it before signing that colocation contract for IP connectivity, and make sure you have it in writing that the provider will create an ACL on your interface of sufficient length to do what you want.. And be sure you have worked out with the provider how this effects billing in advance. It's quite possible you still have to pay or have said dropped traffic counted against your commit. -- -JH From aservin at lacnic.net Tue Nov 1 19:41:12 2011 From: aservin at lacnic.net (Arturo Servin) Date: Tue, 1 Nov 2011 22:41:12 -0200 Subject: using IPv6 address block across multiple locations In-Reply-To: References: Message-ID: <0A92D0F6-C7D8-4B24-B208-19DC8BC9E815@lacnic.net> Same from LACNIC. This would have justify a /44 or separate /48s for each site. /as On 31 Oct 2011, at 12:45, Justin M. Streiner wrote: > On Mon, 31 Oct 2011, Owen DeLong wrote: > >> Ideally, you should put a /48 at each location. > > Speaking from my experience with getting v6 space from ARIN earlier this year, as long as your documentation is in pretty good order, a /48 per site is pretty easy to get. > > I don't know if the experience is different with other RIRs. > > jms From edward.avanti at gmail.com Tue Nov 1 20:01:37 2011 From: edward.avanti at gmail.com (Edward avanti) Date: Wed, 2 Nov 2011 11:01:37 +1000 Subject: BGP conf Message-ID: Halo, First, I accept this might not really right list for request, have use nsp cisco list but only first post to was succeed, sent several other for past 4 day and none appear (verified by list archive) so please excuse request. I am in need of a cisco config for BGP setup, we have a require to include IX peering at new location as well as our Verizon link, we like to take full bgp from Verizon and send to IX what they send us, I spend days reading google, and so many conflict web site example, so many example seem insecure no prefix list so on. end result to date is only sore eyes, would someone who do same (not need be Verizon) be kind to send us off list working running config (yes without your password heh) or at least how to apply to BGP router including access/prefix list and interfaces so we have an idea on what do, if you take two full BGP feed from two transit carrierin load share and IX, that good, because that our stage three plan, but I can work without two transit. I am not ignorant with cisco 7201, but am total newby to BGP. Best Thanks Edwardo From MGauvin at dryden.ca Tue Nov 1 20:11:55 2011 From: MGauvin at dryden.ca (Mark Gauvin) Date: Tue, 1 Nov 2011 20:11:55 -0500 Subject: BGP conf In-Reply-To: References: Message-ID: <630EAF96-3375-41ED-A681-F982CCF3A781@dryden.ca> Why would you want to advertise full verizon routes out to the ix? You shoud only be advertising your own network via ix Sent from my iPhone On 2011-11-01, at 7:59 PM, "Edward avanti" wrote: > Halo, > First, I accept this might not really right list for request, have > use nsp > cisco list but only first post to was succeed, sent several other > for past > 4 day and none appear (verified by list archive) so please excuse > request. > > I am in need of a cisco config for BGP setup, we have a require to > include > IX peering at new location as well as our Verizon link, we like to > take > full bgp from Verizon and send to IX what they send us, I spend days > reading google, and so many conflict web site example, so many > example seem > insecure no prefix list so on. end result to date is only sore eyes, > would > someone who do same (not need be Verizon) be kind to send us off list > working running config (yes without your password heh) or at least > how to > apply to BGP router including access/prefix list and interfaces so > we have > an idea on what do, if you take two full BGP feed from two transit > carrierin load share and IX, that good, because that our stage three > plan, > but I can work without two transit. > > I am not ignorant with cisco 7201, but am total newby to BGP. > > Best Thanks > Edwardo From jsw at inconcepts.biz Tue Nov 1 20:17:47 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 1 Nov 2011 21:17:47 -0400 Subject: BGP conf In-Reply-To: References: Message-ID: On Tue, Nov 1, 2011 at 9:01 PM, Edward avanti wrote: > many example seem > insecure no prefix list so on. ... > I am not ignorant with cisco 7201, but am total newby to BGP. Your concern about a lack of any prefix-lists in the documentation / examples you have read is justified. If you are connecting to an IX it may offer route-servers which have prefix-lists maintained by the IX staff and tools. However, as you may already know, you will only receive the "best path" to each prefix from an IX route-server. This is often a motive (among others) to establish direct eBGP sessions with other IX members. Once you start doing that, you had better filter routes from those neighbors, or you will subject your network to your peers' mistakes and glitches. If you imagine that the IX has other members like yourself, who also do not know much about BGP, then you can understand why you do not want your peers' mistakes to cause outages on your network. Doing a "cut, replace, and paste" from online examples is obviously a bad idea. If I were you, I would find a local consultant (perhaps someone on the staff of the IX or another member) who can assist you with your initial configuration, and help you in the event of a severe emergency. Otherwise, frankly, you are going to be better off by just buying transit from Verizon and being single-homed. The added complexity of BGP is not an asset to an organization that doesn't have adequate expertise. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From edward.avanti at gmail.com Tue Nov 1 20:18:15 2011 From: edward.avanti at gmail.com (Edward avanti) Date: Wed, 2 Nov 2011 11:18:15 +1000 Subject: BGP conf In-Reply-To: <630EAF96-3375-41ED-A681-F982CCF3A781@dryden.ca> References: <630EAF96-3375-41ED-A681-F982CCF3A781@dryden.ca> Message-ID: Halo, I am not, I wish all transit by Verizon, but if traffic come in from IX, it only fair I send trafic to them if they in that IX, they be closest path anyway. On Wed, Nov 2, 2011 at 11:11 AM, Mark Gauvin wrote: > Why would you want to advertise full verizon routes out to the ix? You > shoud only be advertising your own network via ix > > Sent from my iPhone > > On 2011-11-01, at 7:59 PM, "Edward avanti" > wrote: > > > Halo, > > First, I accept this might not really right list for request, have > > use nsp > > cisco list but only first post to was succeed, sent several other > > for past > > 4 day and none appear (verified by list archive) so please excuse > > request. > > > > I am in need of a cisco config for BGP setup, we have a require to > > include > > IX peering at new location as well as our Verizon link, we like to > > take > > full bgp from Verizon and send to IX what they send us, I spend days > > reading google, and so many conflict web site example, so many > > example seem > > insecure no prefix list so on. end result to date is only sore eyes, > > would > > someone who do same (not need be Verizon) be kind to send us off list > > working running config (yes without your password heh) or at least > > how to > > apply to BGP router including access/prefix list and interfaces so > > we have > > an idea on what do, if you take two full BGP feed from two transit > > carrierin load share and IX, that good, because that our stage three > > plan, > > but I can work without two transit. > > > > I am not ignorant with cisco 7201, but am total newby to BGP. > > > > Best Thanks > > Edwardo > From Gabriel.McCall at thyssenkrupp.com Tue Nov 1 21:28:35 2011 From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel) Date: Tue, 1 Nov 2011 22:28:35 -0400 Subject: BGP conf In-Reply-To: References: Message-ID: Google for "team cymru secure bgp template" for a good starting point. -----Original message----- From: Edward avanti To: "nanog at nanog.org" Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00 Subject: BGP conf Halo, First, I accept this might not really right list for request, have use nsp cisco list but only first post to was succeed, sent several other for past 4 day and none appear (verified by list archive) so please excuse request. I am in need of a cisco config for BGP setup, we have a require to include IX peering at new location as well as our Verizon link, we like to take full bgp from Verizon and send to IX what they send us, I spend days reading google, and so many conflict web site example, so many example seem insecure no prefix list so on. end result to date is only sore eyes, would someone who do same (not need be Verizon) be kind to send us off list working running config (yes without your password heh) or at least how to apply to BGP router including access/prefix list and interfaces so we have an idea on what do, if you take two full BGP feed from two transit carrierin load share and IX, that good, because that our stage three plan, but I can work without two transit. I am not ignorant with cisco 7201, but am total newby to BGP. Best Thanks Edwardo From jeff-kell at utc.edu Tue Nov 1 21:42:38 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 1 Nov 2011 22:42:38 -0400 Subject: Random five character string added to URLs? In-Reply-To: References: Message-ID: <4EB0AE1E.3090904@utc.edu> On 11/1/2011 7:05 PM, Stefan Fouant wrote: > Is there anything perhaps protecting or intercepting the data on its way to the server, perhaps an Arbor device of some type of load balancer? > > This type of behavior is quite common when protecting web assets to eliminate zombies and such, but its usually something you would see back to the clients, not tp the server. I have seen this in SEO-poisoning type of webpage defacement. They anchor a javascript in the main website "frame" and it generates optimization "links" using a numeric suffix or ?argument so that they appear as separate links. If the crawler is recognized (e.g., googlebot) then the SEO page is returned. Jeff From asr at latency.net Wed Nov 2 10:53:37 2011 From: asr at latency.net (Adam Rothschild) Date: Wed, 2 Nov 2011 11:53:37 -0400 Subject: Colocation providers and ACL requests In-Reply-To: References: <4EB038E7.4070703@kl.net> Message-ID: On Tue, Nov 1, 2011 at 8:00 PM, Jimmy Hess wrote: > On Tue, Nov 1, 2011 at 1:22 PM, Kevin Loch wrote: >> We have always accommodated temporary ACL's for active DDOS attacks. ?I >> think that is fairly standard across the ISP/hosting industry. Indeed. We'll do it; ditto every reputable hosting, collocation, or IP transit shop I've come into contact with. > And it's reasonable to accomodate the customer that asks, and > reasonable for a customer to ask for > a temporary ACL in such situations. > > However, it's also reasonable for the provider to refuse, ?and there's > nothing wrong with that, unless the provider agreed that they would be > willing to do that [...] Disagree. Furthermore, I think providers refusing to implement temporary ACLs should be called out on fora such as NANOG, to aid others in the vendor selection process. This is not to say it's sustainable as a repeat or permanent configuration -- possible up-sell and business drivers aside, TCAM exhaustion, performance implications, and man-hours required for ACL maintenance are all very real concerns -- but denying your customers this type of emergency response is bad for the Internet, and goes against basic tenets of customer service. -a From dholmes at mwdh2o.com Wed Nov 2 10:54:16 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 2 Nov 2011 08:54:16 -0700 Subject: BGP conf In-Reply-To: References: Message-ID: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o> This is a perfect example of why it is crucial that inbound route filters be scrupulously maintained in upstream BGP providers. Who knows who is out there. -----Original Message----- From: McCall, Gabriel [mailto:Gabriel.McCall at thyssenkrupp.com] Sent: Tuesday, November 01, 2011 7:29 PM To: Edward avanti; nanog at nanog.org Subject: Re: BGP conf Google for "team cymru secure bgp template" for a good starting point. -----Original message----- From: Edward avanti To: "nanog at nanog.org" Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00 Subject: BGP conf Halo, First, I accept this might not really right list for request, have use nsp cisco list but only first post to was succeed, sent several other for past 4 day and none appear (verified by list archive) so please excuse request. I am in need of a cisco config for BGP setup, we have a require to include IX peering at new location as well as our Verizon link, we like to take full bgp from Verizon and send to IX what they send us, I spend days reading google, and so many conflict web site example, so many example seem insecure no prefix list so on. end result to date is only sore eyes, would someone who do same (not need be Verizon) be kind to send us off list working running config (yes without your password heh) or at least how to apply to BGP router including access/prefix list and interfaces so we have an idea on what do, if you take two full BGP feed from two transit carrierin load share and IX, that good, because that our stage three plan, but I can work without two transit. I am not ignorant with cisco 7201, but am total newby to BGP. Best Thanks Edwardo This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From bhuffake at caida.org Wed Nov 2 12:31:51 2011 From: bhuffake at caida.org (Bradley Huffaker) Date: Wed, 2 Nov 2011 10:31:51 -0700 Subject: Mexico? In-Reply-To: <00c401cc9521$2ad65250$8082f6f0$@gmail.com> References: <00c401cc9521$2ad65250$8082f6f0$@gmail.com> Message-ID: <20111102173151.GB23566@caida.org> LACNIC http://lacnic.net/en/index.html On Thu, Oct 27, 2011 at 11:24:54PM -0400, Ryan Finnesey wrote: > If I want to get a block of IP's issued for a network within Mexico who do I > talk with? I have been told arin does not cover Mexico. It was my > understand arin covers North America. > > > > Cheers > > Ryan > > -- true liberty is the right to be wrong From itsmemattchung at gmail.com Wed Nov 2 16:57:37 2011 From: itsmemattchung at gmail.com (Matt Chung) Date: Wed, 2 Nov 2011 14:57:37 -0700 Subject: Performance Issues - PTR Records Message-ID: I work for a regional ISP and very recently there has been an influx of calls reporting "slowness" when accessing certain websites (i.e google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the session, I have been able to pinpoint the latency at the application layer. After the tcp session has been established, it takes up to 15-20 seconds before the application begins sending data. The root of the problem was that the PTR record for our customer(s) address does not exist. As soon as the record is created, latency from the application is eliminated. This is analogous to latency when accessing a server over SSH when no PTR is available. A seperate packet capture from another customer exhibiting similar performance behavior showed many TCP retransmissions. At first glance, I assumed this was network related however this correlates with the application not responding and inducing retransmissions at the TCP layer (different symptoms, same problem). Historically, there was no compelling reason to create PTR records for our CPE however more and more applications seem to be dependent on it. Although we will be assigning a record for each address, my question is why is the application (specifically HTTP) dependent on a reverse record ? What is the purpose? Hope this is helpful as well -- -Matt Chung From jeffw at he.net Wed Nov 2 17:02:57 2011 From: jeffw at he.net (Jeff Walter) Date: Wed, 02 Nov 2011 15:02:57 -0700 Subject: Performance Issues - PTR Records In-Reply-To: References: Message-ID: <4EB1BE11.7050600@he.net> On 11/2/2011 2:57 PM, Matt Chung wrote: > > Although we will be assigning a record for each address, my question is why > is the application (specifically HTTP) dependent on a reverse record ? > What is the purpose? HTTP has no requirement that the connecting client have reverse DNS setup. Some servers have reverse lookups enabled, and some of those undoubtedly block until the record has been retrieved or all avenues of discovery have been exhausted... and this is likely where the issue exists. As to why the server or the script/application its running needs the record, you'd have to ask the developer. -- Jeff Walter Network Engineer Hurricane Electric, AS6939 -------------- next part -------------- A non-text attachment was scrubbed... Name: jeffw.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: From tayeb.meftah at gmail.com Tue Nov 1 15:36:29 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Tue, 1 Nov 2011 22:36:29 +0200 Subject: IPV6 6to4 and 6In4 Lab Message-ID: <189B79EF119C4BEA96374EAAD13D8594@work> Hello folks, i'm posting this Message to both nanog and afnog lists preferably if i can get one from afnog to work with me a bit for routing IPV6 prefixs over him using at least static or OSPFv3 or BGP (at you like) i want to anounce my /48 optained from a friend as number) and 2002::/16 (6to4 prefixs=) at least for 10min to see real IPV6 traffic. if someone want to help me, please contact me thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (20111102) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From dhubbard at dino.hostasaurus.com Wed Nov 2 17:12:21 2011 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 2 Nov 2011 18:12:21 -0400 Subject: Performance Issues - PTR Records Message-ID: From: Matt Chung [mailto:itsmemattchung at gmail.com] > > Historically, there was no compelling reason to create PTR > records for our CPE however more and more applications seem > to be dependent on it. Although we will be assigning a > record for each address, my question is why > is the application (specifically HTTP) dependent on a reverse record ? > What is the purpose? > As a web host, we frequently find customers who have added Apache rules to their ecommerce sites to block undesirable traffic, such as credit card scammers, etc. Not knowing any better, they often do this by just blocking anything that ends in .in to block Indonesia for example. Well, once you choose to block by resolved name, now that site has to do a dns lookup for every incoming request to see if it resolves to a name that should be blocked. Just one example, but I'm sure there are countless others that also impede performance for IP addresses without a PTR record. David From arturo.servin at gmail.com Wed Nov 2 17:37:29 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 2 Nov 2011 20:37:29 -0200 Subject: IPV6 6to4 and 6In4 Lab In-Reply-To: <189B79EF119C4BEA96374EAAD13D8594@work> References: <189B79EF119C4BEA96374EAAD13D8594@work> Message-ID: <8E119D82-A02D-4B1F-87F8-D6BA00178F5D@gmail.com> Why don't you use just a tunnelbroker? I would take just a few minutes to setup a tunnel. From there, you can do a lot of stuff inside your network. My 2 cents /as On 1 Nov 2011, at 18:36, Meftah Tayeb wrote: > Hello folks, > i'm posting this Message to both nanog and afnog lists > preferably if i can get one from afnog to work with me a bit for routing IPV6 prefixs over him using at least static or OSPFv3 or BGP (at you like) > i want to anounce my /48 optained from a friend as number) and 2002::/16 (6to4 prefixs=) at least for 10min to see real IPV6 traffic. > if someone want to help me, please contact me > thank you > Meftah Tayeb > IT Consulting > http://www.tmvoip.com/ > phone: +21321656139 > Mobile: +213660347746 > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (20111102) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com From tayeb.meftah at gmail.com Tue Nov 1 16:03:47 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Tue, 1 Nov 2011 23:03:47 +0200 Subject: IPV6 6to4 and 6In4 Lab References: <189B79EF119C4BEA96374EAAD13D8594@work> <8E119D82-A02D-4B1F-87F8-D6BA00178F5D@gmail.com> Message-ID: <10C73E92DC014C21A2F42E32ED5F7628@work> like i say, no routing HE.Nett won accept me cause i don't have a AS number ----- Original Message ----- From: "Arturo Servin" To: "Meftah Tayeb" Cc: ; Sent: Thursday, November 03, 2011 12:37 AM Subject: Re: IPV6 6to4 and 6In4 Lab Why don't you use just a tunnelbroker? I would take just a few minutes to setup a tunnel. From there, you can do a lot of stuff inside your network. My 2 cents /as On 1 Nov 2011, at 18:36, Meftah Tayeb wrote: > Hello folks, > i'm posting this Message to both nanog and afnog lists > preferably if i can get one from afnog to work with me a bit for routing > IPV6 prefixs over him using at least static or OSPFv3 or BGP (at you like) > i want to anounce my /48 optained from a friend as number) and 2002::/16 > (6to4 prefixs=) at least for 10min to see real IPV6 traffic. > if someone want to help me, please contact me > thank you > Meftah Tayeb > IT Consulting > http://www.tmvoip.com/ > phone: +21321656139 > Mobile: +213660347746 > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6596 (20111102) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (20111102) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6596 (20111102) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From mpalmer at hezmatt.org Wed Nov 2 18:02:15 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 3 Nov 2011 10:02:15 +1100 Subject: Performance Issues - PTR Records In-Reply-To: References: Message-ID: <20111102230215.GM3297@hezmatt.org> On Wed, Nov 02, 2011 at 06:12:21PM -0400, David Hubbard wrote: > From: Matt Chung [mailto:itsmemattchung at gmail.com] > > Historically, there was no compelling reason to create PTR > > records for our CPE however more and more applications seem > > to be dependent on it. Although we will be assigning a > > record for each address, my question is why > > is the application (specifically HTTP) dependent on a reverse record ? > > What is the purpose? > > As a web host, we frequently find customers who have > added Apache rules to their ecommerce sites to block > undesirable traffic, such as credit card scammers, etc. > Not knowing any better, they often do this by just > blocking anything that ends in .in to block Indonesia > for example. That's even less effective than you'd naively expect, given that Indonesia's TLD is .id... - Matt From dhubbard at dino.hostasaurus.com Wed Nov 2 18:05:04 2011 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Wed, 2 Nov 2011 19:05:04 -0400 Subject: Performance Issues - PTR Records Message-ID: From: Matthew Palmer [mailto:mpalmer at hezmatt.org] > > That's even less effective than you'd naively expect, given > that Indonesia's > TLD is .id... > Umm yeah, simple typo, but I appreciate the help. From bzs at world.std.com Wed Nov 2 18:08:47 2011 From: bzs at world.std.com (Barry Shein) Date: Wed, 2 Nov 2011 19:08:47 -0400 Subject: Performance Issues - PTR Records In-Reply-To: References: Message-ID: <20145.52607.535238.692116@world.std.com> > As a web host, we frequently find customers who have > added Apache rules to their ecommerce sites to block > undesirable traffic, such as credit card scammers, etc. > Not knowing any better, they often do this by just > blocking anything that ends in .in to block Indonesia > for example. Well, once you choose to block by > resolved name, now that site has to do a dns lookup > for every incoming request to see if it resolves to a > name that should be blocked. Another practical problem with this approach is that .IN is India but hey, at least it blocks something :-) -- -Barry Shein, that'd be .ID for Indonesia 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 ben at bjencks.net Wed Nov 2 18:19:37 2011 From: ben at bjencks.net (Ben Jencks) Date: Wed, 2 Nov 2011 19:19:37 -0400 Subject: Performance Issues - PTR Records In-Reply-To: References: Message-ID: <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net> On Nov 2, 2011, at 5:57 PM, Matt Chung wrote: > I work for a regional ISP and very recently there has been an influx of > calls reporting "slowness" when accessing certain websites (i.e > google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the > session, I have been able to pinpoint the latency at the application > layer. After the tcp session has been established, it takes up to 15-20 > seconds before the application begins sending data. The root of the > problem was that the PTR record for our customer(s) address does not > exist. As soon as the record is created, latency from the application is > eliminated. This is analogous to latency when accessing a server over SSH > when no PTR is available. > > A seperate packet capture from another customer exhibiting similar > performance behavior showed many TCP retransmissions. At first glance, I > assumed this was network related however this correlates with the > application not responding and inducing retransmissions at the TCP layer > (different symptoms, same problem). > > Historically, there was no compelling reason to create PTR records for our > CPE however more and more applications seem to be dependent on it. > Although we will be assigning a record for each address, my question is why > is the application (specifically HTTP) dependent on a reverse record ? > What is the purpose? You're returning NXDOMAIN, right? If they're doing a reverse lookup and you return NXDOMAIN it should fail quickly, or else the application is even more horribly broken than just doing reverse lookups would imply. On the other hand, if you're not responding to the PTR request then that could be causing the timeout. -Ben From edward.avanti at gmail.com Wed Nov 2 18:50:59 2011 From: edward.avanti at gmail.com (Edward avanti) Date: Thu, 3 Nov 2011 09:50:59 +1000 Subject: BGP conf In-Reply-To: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o> References: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o> Message-ID: Halo, sorry, my english not so perfect, at no time I mean send to IX what Verizon send me, I'm not THAT stupid hehe I mean if destination/origin is via IX, then send THAT traffic only by IX and not Verizon. On Thu, Nov 3, 2011 at 1:54 AM, Holmes,David A wrote: > This is a perfect example of why it is crucial that inbound route filters > be scrupulously maintained in upstream BGP providers. Who knows who is out > there. > > -----Original Message----- > From: McCall, Gabriel [mailto:Gabriel.McCall at thyssenkrupp.com] > Sent: Tuesday, November 01, 2011 7:29 PM > To: Edward avanti; nanog at nanog.org > Subject: Re: BGP conf > > Google for "team cymru secure bgp template" for a good starting point. > > > -----Original message----- > From: Edward avanti > To: "nanog at nanog.org" > Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00 > Subject: BGP conf > > Halo, > First, I accept this might not really right list for request, have use nsp > cisco list but only first post to was succeed, sent several other for past > 4 day and none appear (verified by list archive) so please excuse request. > > I am in need of a cisco config for BGP setup, we have a require to include > IX peering at new location as well as our Verizon link, we like to take > full bgp from Verizon and send to IX what they send us, I spend days > reading google, and so many conflict web site example, so many example seem > insecure no prefix list so on. end result to date is only sore eyes, would > someone who do same (not need be Verizon) be kind to send us off list > working running config (yes without your password heh) or at least how to > apply to BGP router including access/prefix list and interfaces so we have > an idea on what do, if you take two full BGP feed from two transit > carrierin load share and IX, that good, because that our stage three plan, > but I can work without two transit. > > I am not ignorant with cisco 7201, but am total newby to BGP. > > Best Thanks > Edwardo > > > This communication, together with any attachments or embedded links, is > for the sole use of the intended recipient(s) and may contain information > that is confidential or legally protected. If you are not the intended > recipient, you are hereby notified that any review, disclosure, copying, > dissemination, distribution or use of this communication is strictly > prohibited. If you have received this communication in error, please notify > the sender immediately by return e-mail message and delete the original and > all copies of the communication, along with any attachments or embedded > links, from your system. > From jsw at inconcepts.biz Wed Nov 2 19:01:05 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 2 Nov 2011 20:01:05 -0400 Subject: BGP conf In-Reply-To: References: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o> Message-ID: On Wed, Nov 2, 2011 at 7:50 PM, Edward avanti wrote: > sorry, my english not so perfect, at no time I mean send to IX what Verizon > send me, I'm not THAT stupid hehe > I mean if destination/origin is via IX, then send THAT traffic only by IX > and not Verizon. I understood what you mean. The recommendations in my earlier reply are still the best ones you've received: 1) hire a consultant to assist you both now and with any future problems or 2) do not worry about being multi-homed, because the extra complexity will do you more harm than good Imagine if you took your car to a shop and asked for new tires, and the mechanic said, "well, I have never changed tires before and I'm not sure I have the right tools, but if you give me a couple of days I think I can read about it on the Internet and figure it out." Of course you would not buy tires from him, you would go to another shop. That mechanic would quickly find that, if he wants to sell tires, he needs to learn how to install them or hire someone to do it for him. What you are asking your boss/company to do is trust you to put tires on their car without the right tools or knowledge. The result of that is probably how your network will end up: "a wreck." -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From mysidia at gmail.com Wed Nov 2 19:38:30 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 2 Nov 2011 19:38:30 -0500 Subject: Performance Issues - PTR Records In-Reply-To: <20145.52607.535238.692116@world.std.com> References: <20145.52607.535238.692116@world.std.com> Message-ID: On Wed, Nov 2, 2011 at 6:08 PM, Barry Shein wrote: > Another practical problem with this approach is that .IN is India but > hey, at least it blocks something :-) There are also some services out there that block connections entirely, if the user doesn't have a PTR record. I'm thinking IRC servers, MUDs, and some other services with strange security policies that check for a port 113 IDENT response and RDNS to make a dark magic security decision to block a user who has no PTR. But in the modern world... more commonly, MTAs such as sendmail are often configured to require a valid PTR record. So as an ISP, you may be breaking your user's local MTA if you don't have the correct PTR for their IP addresses. So I would say following the RFCs and implementing the proper PTRs will help with that performance issue as a side-effect of having a valid zone, and head off other issues with possibly less popular services that are still blocking connections based on lack of proper PTR. :) > -- > ? ? ? ?-Barry Shein, that'd be .ID for Indonesia -- -JH From jbates at brightok.net Wed Nov 2 19:44:48 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 02 Nov 2011 19:44:48 -0500 Subject: BGP conf In-Reply-To: References: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o> Message-ID: <4EB1E400.5010601@brightok.net> On 11/2/2011 7:01 PM, Jeff Wheeler wrote: > What you are asking your boss/company to do is trust you to put tires > on their car without the right tools or knowledge. The result of that > is probably how your network will end up: "a wreck." Reminds me of the look on my original boss' face when I said, "Well, I have no BGP experience, but I think I'm going to redo this entire BGP config. It doesn't look right." I then proceeded to try every ? hierarchy under bgp in the then cisco routers and read up on every command until I understood each one. Okay, it was simple, had no route-maps, and used access-lists instead of prefix-lists. It worked for a single 7206 BGP aggregation router. Now I have the mile long monstrosity that uses BGP communities for everything, and of route-maps/policies with prefix-lists for downstream customers. You have to start somewhere. cymru secure bgp templates is probably a good beginning. Careful study of your routing platform, what it supports, and reading up on what it means. If you don't understand something, use vendor specific lists/forums/documentation/google until you do. Jack From paul4004 at gmail.com Wed Nov 2 19:48:45 2011 From: paul4004 at gmail.com (PC) Date: Wed, 2 Nov 2011 18:48:45 -0600 Subject: Performance Issues - PTR Records In-Reply-To: <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net> References: <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net> Message-ID: What happens if the ISP never defines a name server with their RIR for their provider-independent address space? Does ARIN point to somewhere which supplies NXDOMAIN? Just a thought -- I don't have a clue. It is entirely possible they have it pointed to their non-existent or broken DNS. Given current best practices, I see no reason not to assign a generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock. On Wed, Nov 2, 2011 at 5:19 PM, Ben Jencks wrote: > On Nov 2, 2011, at 5:57 PM, Matt Chung wrote: > > > I work for a regional ISP and very recently there has been an influx of > > calls reporting "slowness" when accessing certain websites (i.e > > google.com/voice/b) via HTTP. After performing a tcpdump and analyzing > the > > session, I have been able to pinpoint the latency at the application > > layer. After the tcp session has been established, it takes up to 15-20 > > seconds before the application begins sending data. The root of the > > problem was that the PTR record for our customer(s) address does not > > exist. As soon as the record is created, latency from the application is > > eliminated. This is analogous to latency when accessing a server over > SSH > > when no PTR is available. > > > > A seperate packet capture from another customer exhibiting similar > > performance behavior showed many TCP retransmissions. At first glance, I > > assumed this was network related however this correlates with the > > application not responding and inducing retransmissions at the TCP layer > > (different symptoms, same problem). > > > > Historically, there was no compelling reason to create PTR records for > our > > CPE however more and more applications seem to be dependent on it. > > Although we will be assigning a record for each address, my question is > why > > is the application (specifically HTTP) dependent on a reverse record ? > > What is the purpose? > > You're returning NXDOMAIN, right? If they're doing a reverse lookup and > you return NXDOMAIN it should fail quickly, or else the application is even > more horribly broken than just doing reverse lookups would imply. On the > other hand, if you're not responding to the PTR request then that could be > causing the timeout. > > -Ben > > > From nanog at namor.ca Wed Nov 2 19:58:59 2011 From: nanog at namor.ca (J) Date: Wed, 02 Nov 2011 19:58:59 -0500 Subject: Performance Issues - PTR Records In-Reply-To: References: <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net> Message-ID: <4EB1E753.8080300@namor.ca> PC wrote: > What happens if the ISP never defines a name server with their RIR for > their provider-independent address space? Does ARIN point to somewhere > which supplies NXDOMAIN? Just a thought -- I don't have a clue. > > It is entirely possible they have it pointed to their non-existent or > broken DNS. Given current best practices, I see no reason not to assign a > generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock. I think that returns SERVFAIL somewhere down the line? Does it make sense to reinforce the behaviour (good and bad terms left for another time), while looking forward to v6? From Courtney_Smith at Cable.Comcast.com Wed Nov 2 20:24:16 2011 From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney) Date: Thu, 3 Nov 2011 01:24:16 +0000 Subject: Generating IPv6 list with filtergen.level3.net Message-ID: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E43F@PACDCEXMB04.cable.comcast.com> Anyone out there know how to generate a IPv6 list Level3's filtergen? I tried Google but didn't find anything. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From itsmemattchung at gmail.com Wed Nov 2 20:27:48 2011 From: itsmemattchung at gmail.com (Matt Chung) Date: Wed, 2 Nov 2011 18:27:48 -0700 Subject: Performance Issues - PTR Records In-Reply-To: <4EB1E753.8080300@namor.ca> References: <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net> <4EB1E753.8080300@namor.ca> Message-ID: <4979DA6C-6B78-4032-B024-3977A822182F@gmail.com> We really have no objections to creating records for our IPs however there was no compelling reason previously. With the manifestation of performance issues, we are currently creating a generic record for our addresses. I assumed that the applications would take absent records into consideration instead of waiting and timing out before responding with data. Trying to troubleshoot this issue from the limited visibility is difficult ; the latency the application is introducing is abstracted (unless I am unaware of that troubleshooting technique). Sent from my iPhone On Nov 2, 2011, at 5:58 PM, J wrote: > PC wrote: >> What happens if the ISP never defines a name server with their RIR for >> their provider-independent address space? Does ARIN point to somewhere >> which supplies NXDOMAIN? Just a thought -- I don't have a clue. >> >> It is entirely possible they have it pointed to their non-existent or >> broken DNS. Given current best practices, I see no reason not to assign a >> generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock. > > I think that returns SERVFAIL somewhere down the line? > > Does it make sense to reinforce the behaviour (good and bad terms left for > another time), while looking forward to v6? > From lesmith at ecsis.net Wed Nov 2 20:33:45 2011 From: lesmith at ecsis.net (Larry Smith) Date: Wed, 2 Nov 2011 20:33:45 -0500 Subject: Performance Issues - PTR Records In-Reply-To: <4979DA6C-6B78-4032-B024-3977A822182F@gmail.com> References: <4EB1E753.8080300@namor.ca> <4979DA6C-6B78-4032-B024-3977A822182F@gmail.com> Message-ID: <201111022033.45568.lesmith@ecsis.net> On Wed November 2 2011 20:27, Matt Chung wrote: > I assumed that the applications would take absent records into > consideration instead of waiting and timing out before responding with > data. Trying to troubleshoot this issue from the limited visibility is > difficult ; the latency the application is introducing is abstracted > (unless I am unaware of that troubleshooting technique). When you mis-place your keys do you only look in one place and then give up? The calling server does not know there is "no" record until it exhausts its list of DNS servers, which is probably what is introducing the delay you are seeing (each server trying to find a PTR with each of its upsteams) until they all time out... -- Larry Smith lesmith at ecsis.net From jsw at inconcepts.biz Wed Nov 2 20:58:24 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 2 Nov 2011 21:58:24 -0400 Subject: BGP conf In-Reply-To: <4EB1E400.5010601@brightok.net> References: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o> <4EB1E400.5010601@brightok.net> Message-ID: On Wed, Nov 2, 2011 at 8:44 PM, Jack Bates wrote: > Now I have the mile long monstrosity that uses BGP communities for > everything, and of route-maps/policies with prefix-lists for downstream > customers. You have to start somewhere. > > cymru secure bgp templates is probably a good beginning. I guess ten years of watching RIRs and users de-bogon new /8s didn't teach you why those Cymru examples are more dangerous than they are good. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From Epperson at Colorado.EDU Wed Nov 2 21:00:20 2011 From: Epperson at Colorado.EDU (Kevin Epperson) Date: Wed, 2 Nov 2011 20:00:20 -0600 (MDT) Subject: Generating IPv6 list with filtergen.level3.net In-Reply-To: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E43F@PACDCEXMB04.cable.comcast.com> References: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E43F@PACDCEXMB04.cable.comcast.com> Message-ID: Hi Courtney - Try something like: whois -h filtergen.level3.net "AS3356 -cp -v6" or whois -h filtergen.level3.net "AS3356 -cp -v4v6" Using AS7922 or something of that nature (currently I dont see any v6 routes registered under 7922.) -Kevin On Thu, 3 Nov 2011, Smith, Courtney wrote: > Anyone out there know how to generate a IPv6 list Level3's filtergen? I tried Google but didn't find anything. > > > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > From jbates at brightok.net Wed Nov 2 21:04:04 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 02 Nov 2011 21:04:04 -0500 Subject: BGP conf In-Reply-To: References: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o> <4EB1E400.5010601@brightok.net> Message-ID: <4EB1F694.5050301@brightok.net> On 11/2/2011 8:58 PM, Jeff Wheeler wrote: > On Wed, Nov 2, 2011 at 8:44 PM, Jack Bates wrote: >> Now I have the mile long monstrosity that uses BGP communities for >> everything, and of route-maps/policies with prefix-lists for downstream >> customers. You have to start somewhere. >> >> cymru secure bgp templates is probably a good beginning. > I guess ten years of watching RIRs and users de-bogon new /8s didn't > teach you why those Cymru examples are more dangerous than they are > good. > Have to read the current cymru bgp templates? " ! Team Cymru has removed all static bogon references from this template ! due to the high probability that the application of these bogon filters ! will be a one-time event. Unfortunately many of these templates are ! applied and never re-visited, despite our dire warnings that bogons do ! change. ! ! This doesn't mean bogon filtering can't be accomplished in an automated ! manner. Why not consider peering with our globally distributed bogon ! route-server project? Alternately you can obtain a current and well ! maintained bogon feed from our DNS and RADb services. Read more at the ! link below to learn how! ! ! https://www.team-cymru.org/Services/Bogons/ " From Courtney_Smith at Cable.Comcast.com Wed Nov 2 21:06:09 2011 From: Courtney_Smith at Cable.Comcast.com (Smith, Courtney) Date: Thu, 3 Nov 2011 02:06:09 +0000 Subject: Generating IPv6 list with filtergen.level3.net In-Reply-To: References: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E43F@PACDCEXMB04.cable.comcast.com> Message-ID: <8DD18D69FFC6DB46AE9CDB191CD8B9810F13E4C1@PACDCEXMB04.cable.comcast.com> Thanks!!! ~$ whois -h filtergen.level3.net "RADB::AS7922 -v6" Prefix list for policy RADB::AS7922 = RADB::AS7922 2001:558::/29 2001:558::/31 2601::/28 ~$ Courtney Smith Network Engineer Comcast, National Engineering & Technical Operations NOC:888.662.6386x2x2 http://as7922.peeringdb.com () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -----Original Message----- From: Kevin Epperson [mailto:Epperson at Colorado.EDU] Sent: Wednesday, November 02, 2011 10:00 PM To: Smith, Courtney Cc: 'nanog at nanog.org' Subject: Re: Generating IPv6 list with filtergen.level3.net Hi Courtney - Try something like: whois -h filtergen.level3.net "AS3356 -cp -v6" or whois -h filtergen.level3.net "AS3356 -cp -v4v6" Using AS7922 or something of that nature (currently I dont see any v6 routes registered under 7922.) -Kevin On Thu, 3 Nov 2011, Smith, Courtney wrote: > Anyone out there know how to generate a IPv6 list Level3's filtergen? I tried Google but didn't find anything. > > > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > From mysidia at gmail.com Wed Nov 2 21:09:36 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 2 Nov 2011 21:09:36 -0500 Subject: Performance Issues - PTR Records In-Reply-To: <201111022033.45568.lesmith@ecsis.net> References: <4EB1E753.8080300@namor.ca> <4979DA6C-6B78-4032-B024-3977A822182F@gmail.com> <201111022033.45568.lesmith@ecsis.net> Message-ID: On Wed, Nov 2, 2011 at 8:33 PM, Larry Smith wrote: > On Wed November 2 2011 20:27, Matt Chung wrote: >> I assumed that the applications would take absent records into > When you mis-place your keys do you only look in one place and then give > up? ?The calling server does not know there is "no" record until it exhausts If the reverse zone is properly configured, but just the PTR record is missing, you get NXDOMAIN, which is not "you mis-place your keys"; it's "someone told you authoritatively that your keys don't exist", never existed or no longer existed. If you ask where your key ring went, and Frodo Baggins informs you that it doesn't exist, because it was tossed down into a pool of magma on mount doom, and you trust his reply, you stop looking for it. The only way you don't trust a valid DNS reply is if you are implementing DNSSEC, and the "authoritative proof of non-existence" doesn't validate -- -JH From jsw at inconcepts.biz Wed Nov 2 21:19:11 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 2 Nov 2011 22:19:11 -0400 Subject: BGP conf In-Reply-To: <4EB1F694.5050301@brightok.net> References: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o> <4EB1E400.5010601@brightok.net> <4EB1F694.5050301@brightok.net> Message-ID: On Wed, Nov 2, 2011 at 10:04 PM, Jack Bates wrote: > Have to read the current cymru bgp templates? > > ! manner. Why not consider peering with our globally distributed bogon > ! route-server project? Alternately you can obtain a current and well I'm not telling you something you don't already know, but for the novices who regard this list as a source of expertise, I will explain in greater detail why this is a really dumb idea. If you took a list of bogons over eBGP from Cymru, you would get unused /8s and similar. What you don't get is a route that matches whatever silly thing someone on the DFZ accidentally leaked: a more-specific that will still cause you to route traffic to their leaked prefix out to the Internet (and presumably, to their network.) There is nothing good about this. It's just adding unnecessary complexity for no operational benefit. There is bad about it. It adds complexity and risk. What is that risk? If you decide that the Cymru "distributed bogon route-server" is for you, and simply rewrite next-hops received on that session to Null0, it is possible that Cymru could make an error, or otherwise introduce non-bogon routes into your network as if they were bogons, causing black-holes. This is obviously too much to risk for something that has no operational benefit. The Cymru guys do many positive things. One of the more questionable things they do, though, is operate a route-server with the intention of black-holing botnet C&C IPs on a very wide scale. This is certainly a positive thing to do, but it was not done in a transparent manner; and in fact didn't even have management approval at Cogent when they configured it on their network. There was no established channel to find out why your IP address appeared on this list or to get it removed. All it took for me to get the whole idea canned at Cogent was one inquiry to management, asking why engineers had quietly started using a clandestine blackhole list operated by a third-party and would not give any answers to a customer if one of their IPs appeared on that list. The IP address I inquired about was certainly not a botnet C&C node, and how it ended up on that list is a mystery. I'm not saying there was any malicious intent, but it was a mistake at least. Trusting that "bogon" black-hole list to do something you don't even need to do anyway is not smart. It's *especially* not smart for some novice who doesn't understand the implications of his decision. This is the danger of "cut & paste engineering." -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jeff-kell at utc.edu Wed Nov 2 22:46:00 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Wed, 2 Nov 2011 23:46:00 -0400 Subject: BGP conf In-Reply-To: References: <922ACC42D498884AA02B3565688AF99533FF197C1D@USEXMBS01.mwd.h2o> <4EB1E400.5010601@brightok.net> Message-ID: <4EB20E78.70903@utc.edu> On 11/2/2011 9:58 PM, Jeff Wheeler wrote: > I guess ten years of watching RIRs and users de-bogon new /8s didn't > teach you why those Cymru examples are more dangerous than they are good. If you follow "all" the CYMRU examples and subscribe to the BGP bogon feed, that isn't an issue... Jeff From lmay at nframe.com Wed Nov 2 23:45:53 2011 From: lmay at nframe.com (Larry May) Date: Thu, 3 Nov 2011 00:45:53 -0400 Subject: BGP conf In-Reply-To: Message-ID: <053E179161004E4C91C8613916AA37B90551A361@nframemail01.nframe.local> Participants, This thread makes me want to LAUGH and VOMIT at the same time... This guy is asking for advice and all this list can do is poke and make fun at him for trying to learn the right way to do things... We ALL need to remember...NONE of us come out of the womb being BGP experts... and anyone who says they are...are lying through their teeth. I have had to work with such people who talked a big game...but in the end didn't know their ass from a hole in the ground. And to the original post Edward...if you follow "team CYMRU" you are pretty much on the right path to being successful in your ventures... -----Original Message----- From: Edward avanti [mailto:edward.avanti at gmail.com] Sent: Wednesday, November 02, 2011 7:51 PM To: Holmes, David A; nanog at nanog.org" Subject: Re: BGP conf Halo, sorry, my english not so perfect, at no time I mean send to IX what Verizon send me, I'm not THAT stupid hehe I mean if destination/origin is via IX, then send THAT traffic only by IX and not Verizon. On Thu, Nov 3, 2011 at 1:54 AM, Holmes,David A wrote: > This is a perfect example of why it is crucial that inbound route filters > be scrupulously maintained in upstream BGP providers. Who knows who is out > there. > > -----Original message----- > From: Edward avanti > To: "nanog at nanog.org" > Sent: Wed, Nov 2, 2011 01:01:37 GMT+00:00 > Subject: BGP conf > > Halo, > First, I accept this might not really right list for request, have use nsp > cisco list but only first post to was succeed, sent several other for past > 4 day and none appear (verified by list archive) so please excuse request. > > I am in need of a cisco config for BGP setup, we have a require to include > IX peering at new location as well as our Verizon link, we like to take > full bgp from Verizon and send to IX what they send us, I spend days > reading google, and so many conflict web site example, so many example seem > insecure no prefix list so on. end result to date is only sore eyes, would > someone who do same (not need be Verizon) be kind to send us off list > working running config (yes without your password heh) or at least how to > apply to BGP router including access/prefix list and interfaces so we have > an idea on what do, if you take two full BGP feed from two transit > carrierin load share and IX, that good, because that our stage three plan, > but I can work without two transit. > > I am not ignorant with cisco 7201, but am total newby to BGP. > > Best Thanks > Edwardo > > > This communication, together with any attachments or embedded links, is > for the sole use of the intended recipient(s) and may contain information > that is confidential or legally protected. If you are not the intended > recipient, you are hereby notified that any review, disclosure, copying, > dissemination, distribution or use of this communication is strictly > prohibited. If you have received this communication in error, please notify > the sender immediately by return e-mail message and delete the original and > all copies of the communication, along with any attachments or embedded > links, from your system. > From ljb at merit.edu Thu Nov 3 12:47:32 2011 From: ljb at merit.edu (Larry Blunk) Date: Thu, 03 Nov 2011 13:47:32 -0400 Subject: Performance Issues - PTR Records In-Reply-To: References: Message-ID: <4EB2D3B4.7060700@merit.edu> On 11/02/2011 05:57 PM, Matt Chung wrote: > I work for a regional ISP and very recently there has been an influx of > calls reporting "slowness" when accessing certain websites (i.e > google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the > session, I have been able to pinpoint the latency at the application > layer. After the tcp session has been established, it takes up to 15-20 > seconds before the application begins sending data. The root of the > problem was that the PTR record for our customer(s) address does not > exist. As soon as the record is created, latency from the application is > eliminated. This is analogous to latency when accessing a server over SSH > when no PTR is available. > > A seperate packet capture from another customer exhibiting similar > performance behavior showed many TCP retransmissions. At first glance, I > assumed this was network related however this correlates with the > application not responding and inducing retransmissions at the TCP layer > (different symptoms, same problem). > > Historically, there was no compelling reason to create PTR records for our > CPE however more and more applications seem to be dependent on it. > Although we will be assigning a record for each address, my question is why > is the application (specifically HTTP) dependent on a reverse record ? > What is the purpose? > > Hope this is helpful as well > We recently encountered a similar issue with a customer. The sites that had slowness issues were configured to use the traditional Google Analytics javascript instead of the newer asynchronous code. The problem was not the lack of a PTR record, but rather the in-addr delegation was pointing to lame servers that were no longer responding (hence the long timeouts as the Google servers attempted to perform reverse lookups on the client IP's). As others have pointed out, as long as there's a valid nameserver responding, a lack of PTR record would not cause issues as an NXDOMAIN record would be sent back immediately and the Google Analytics server will move on. -Larry Blunk Merit From nonobvious at gmail.com Thu Nov 3 16:15:19 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 3 Nov 2011 14:15:19 -0700 Subject: Outgoing SMTP Servers In-Reply-To: References: <13175F96BDC3B34AB1425BAE905B3CE50BA685A7@ltiserver.lti.local> <50840E86-BDA3-498D-9BD2-80DB30760642@delong.com> <21422.1319729013@turing-police.cc.vt.edu> <33536.1319751497@turing-police.cc.vt.edu> <4EAA056E.5010006@altadena.net> <62968.1319816515@turing-police.cc.vt.edu> <327761D3-53F7-4B52-9424-FC694FBB6851@delong.com> <025FE4D2-3B13-440B-BADC-AA1F5B3384DB@delong.com> Message-ID: On Mon, Oct 31, 2011 at 6:23 AM, Brian Johnson wrote: > For clarity it's really bad for ISPs to block ports other than 25 for the purposes of mail flow control... correct? Yes, correct. If you're using another mail submission port, you're connecting to a mail service that has the responsibility not to let spam escape, and your ISP has done its job of stopping point-source pollution. >Bill>I've got a strong preference for ISPs to run a >Bill>Block-25-by-default/Enable-when-asked. ?[...] > This is, of course, exactly why this blocking is done. It looks like you're missing half my point, which is the Enable-when-asked part. There are users who are perfectly legitimately running MTAs at home, whether for reliability or privacy (e.g. so they can run SMTP-over-TLS end-to-end) or just simplicity, and ISPs shouldn't be blocking them (unless they're spammers, of course.) > My take on this is that it IS best practice to have users use the submission port (587) for mail submission from the MUA to an MTA. If you're running an MTA service, then yes. If you're running a transport service, then not necessarily. -- ---- ? ? ? ? ? ?? Thanks;? ?? Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From tayeb.meftah at gmail.com Thu Nov 3 06:36:54 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Thu, 3 Nov 2011 13:36:54 +0200 Subject: looking for SixXS administtrator Message-ID: <850F5DED855449888BD784F3ED7BDDE9@work> Hello please could one of the SixXS admin contact me privatly ? thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6600 (20111104) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From jeroen at unfix.org Fri Nov 4 08:48:52 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 04 Nov 2011 14:48:52 +0100 Subject: looking for SixXS administtrator In-Reply-To: <850F5DED855449888BD784F3ED7BDDE9@work> References: <850F5DED855449888BD784F3ED7BDDE9@work> Message-ID: <4EB3ED44.4090806@unfix.org> On 2011-11-03 12:36 , Meftah Tayeb wrote: > Hello > please could one of the SixXS admin contact me privatly ? As was previously pointed out to you on these very lists: http://www.sixxs.net/contact/ Greets, Jeroen From tayeb.meftah at gmail.com Thu Nov 3 07:22:38 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Thu, 3 Nov 2011 14:22:38 +0200 Subject: looking for SixXS administtrator References: <850F5DED855449888BD784F3ED7BDDE9@work> <4EB3ED44.4090806@unfix.org> Message-ID: <044665A02784425F8FEE8E68D9FBBF1B@work> dear Jeroen, why i'm posting here is that cause Sixxs never reply to my query. ----- Original Message ----- From: "Jeroen Massar" To: "Meftah Tayeb" Cc: ; Sent: Friday, November 04, 2011 3:48 PM Subject: Re: looking for SixXS administtrator > On 2011-11-03 12:36 , Meftah Tayeb wrote: >> Hello >> please could one of the SixXS admin contact me privatly ? > > As was previously pointed out to you on these very lists: > > http://www.sixxs.net/contact/ > > Greets, > Jeroen > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6601 (20111104) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6601 (20111104) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From jeroen at unfix.org Fri Nov 4 09:01:53 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 04 Nov 2011 15:01:53 +0100 Subject: looking for SixXS administtrator In-Reply-To: <044665A02784425F8FEE8E68D9FBBF1B@work> References: <850F5DED855449888BD784F3ED7BDDE9@work> <4EB3ED44.4090806@unfix.org> <044665A02784425F8FEE8E68D9FBBF1B@work> Message-ID: <4EB3F051.9060103@unfix.org> On 2011-11-03 13:22 , Meftah Tayeb wrote: > dear Jeroen, > why i'm posting here is that cause Sixxs never reply to my query. http://mailman.nanog.org/pipermail/nanog/2011-September/040108.html "i don't need this stupid SixXs at all anymore." Please keep it that way. Greets, Jeroen From trelane at trelane.net Fri Nov 4 10:18:37 2011 From: trelane at trelane.net (Andrew Kirch) Date: Fri, 04 Nov 2011 11:18:37 -0400 Subject: looking for SixXS administtrator In-Reply-To: <4EB3F051.9060103@unfix.org> References: <850F5DED855449888BD784F3ED7BDDE9@work> <4EB3ED44.4090806@unfix.org> <044665A02784425F8FEE8E68D9FBBF1B@work> <4EB3F051.9060103@unfix.org> Message-ID: <4EB4024D.9070107@trelane.net> On 11/4/2011 10:01 AM, Jeroen Massar wrote: I realize you're volunteers, but grow up. good grief children these days. Andrew From jeroen at unfix.org Fri Nov 4 11:02:30 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 04 Nov 2011 17:02:30 +0100 Subject: looking for SixXS administtrator In-Reply-To: <4EB4024D.9070107@trelane.net> References: <850F5DED855449888BD784F3ED7BDDE9@work> <4EB3ED44.4090806@unfix.org> <044665A02784425F8FEE8E68D9FBBF1B@work> <4EB3F051.9060103@unfix.org> <4EB4024D.9070107@trelane.net> Message-ID: <4EB40C96.8080007@unfix.org> On 2011-11-04 16:18 , Andrew Kirch wrote: > On 11/4/2011 10:01 AM, Jeroen Massar wrote: > > I realize you're volunteers, but grow up. We already did quite some time ago, which means we have full time jobs nowadays and guess what goes first before all those whining people ;) As this is a mailing list for operational content though, I suggest you address your problems to info at sixxs.net if you still have them, they will then be handled in due time. > good grief children these days. Nothing worse than old whiny folks eh ;) Greets, Jeroen From harbor235 at gmail.com Fri Nov 4 11:09:44 2011 From: harbor235 at gmail.com (harbor235) Date: Fri, 4 Nov 2011 12:09:44 -0400 Subject: MPLS TE Message-ID: TE lab testing flushing out how TE works, configured a primary and backup tunnel between PEs, both directions. Primary is dynamic and backup is explicit, initially priorities were the same, I then choose to make one tunnel preferred over the other adjusting the priorities, I choose the tunnel that was backup to become primary to watch the traffic shift. (primary path was P1-P2-P3, backup path P1-P3). However, the traffic did not shift, a manual shut on a P3-P2 interface made the traffic shift, reintroduction kept the traffic on P1-P3, then a "mpls traffic reoptimize" moved the traffic back to P1-P2-P3. Obviously the preferred MPLS tunnel is still P1-P2-P3 even though I configured "tunnel mpls traffic-eng priority 1 1" on P1-P3 and "tunnel mpls traffic-eng priority 7 7" on P1-P2-P3. What am I missing here? My setup: CE-----PE-----P1----------P3-------PE----CE \ / \ / P2 Mike From list-nanog2 at dragon.net Fri Nov 4 11:28:14 2011 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Fri, 04 Nov 2011 09:28:14 -0700 Subject: Performance Issues - PTR Records In-Reply-To: References: <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net> Message-ID: <20111104162814.24EFAC0DC81@fafnir.remote.dragon.net> paul4004> It is entirely possible they have it pointed to their paul4004> non-existent or broken DNS. Given current best practices, I paul4004> see no reason not to assign a generic paul4004> x.x.x.x-dynamic.customer.isp.com DNS across their netblock. It's already been pointed out that lame delegations are more likely problems for many. But the "we'll just pre-fill in-addr to avoid problems" isn't going to work for ip6.arpa. If anyone has enough hardware to serve the zone for a /48 (64k * 4bil * 4bil * bytes-in-record), I'd love to see it. :) We need to get web and app folks to stop counting on ip6.arpa/in-addr.arpa as a validation of trustworthiness. PTR make some sense for validating servers, MTAs, etc. and it's handy for traceroute but it was never a great tool and it's getting less useful with time. From avitkovsky at emea.att.com Fri Nov 4 11:49:31 2011 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Fri, 4 Nov 2011 17:49:31 +0100 Subject: MPLS TE In-Reply-To: References: Message-ID: Hello Mike, What exactly do you mean by primary and backup please? As the tunnel "mpls traffic-eng priority" cmd simply only specifies the setup and hold priorities (you'd use those when there are tunnels carrying low priority traffic filling up the available TE BW -and you need to setup a tunnel carrying voice through that link -because the primary link failed -the higher setup priority of the voice tunnel would knock down some of the scavenger tunnels with lower hold priority) Now I'm not sure but I guess you can't have one tunnel act as backup for a specific te-tunnel Though you can configure a te-tunnel to act as a backup for a link Since one of your tunnels is dynamic it can be re-established around the failed link Though which tunnel is going to be used to forward traffic is based on how you instruct the trafic to use one of the tunnes as primary path adam -----Original Message----- From: harbor235 [mailto:harbor235 at gmail.com] Sent: Friday, November 04, 2011 5:10 PM To: NANOG list Subject: MPLS TE TE lab testing flushing out how TE works, configured a primary and backup tunnel between PEs, both directions. Primary is dynamic and backup is explicit, initially priorities were the same, I then choose to make one tunnel preferred over the other adjusting the priorities, I choose the tunnel that was backup to become primary to watch the traffic shift. (primary path was P1-P2-P3, backup path P1-P3). However, the traffic did not shift, a manual shut on a P3-P2 interface made the traffic shift, reintroduction kept the traffic on P1-P3, then a "mpls traffic reoptimize" moved the traffic back to P1-P2-P3. Obviously the preferred MPLS tunnel is still P1-P2-P3 even though I configured "tunnel mpls traffic-eng priority 1 1" on P1-P3 and "tunnel mpls traffic-eng priority 7 7" on P1-P2-P3. What am I missing here? My setup: CE-----PE-----P1----------P3-------PE----CE \ / \ / P2 Mike From harbor235 at gmail.com Fri Nov 4 12:00:00 2011 From: harbor235 at gmail.com (harbor235) Date: Fri, 4 Nov 2011 13:00:00 -0400 Subject: MPLS TE In-Reply-To: References: Message-ID: I am also looking at FRR which uses a backup tunnel for fast convergence. I did however not think about the dynamic nature of the tunnel and the potential for reestablishment. Mike On Fri, Nov 4, 2011 at 12:49 PM, Vitkovsky, Adam wrote: > Hello Mike, > What exactly do you mean by primary and backup please? > As the tunnel "mpls traffic-eng priority" cmd simply only specifies the > setup and hold priorities > (you'd use those when there are tunnels carrying low priority traffic > filling up the available TE BW -and you need to setup a tunnel carrying > voice through that link -because the primary link failed -the higher setup > priority of the voice tunnel would knock down some of the scavenger tunnels > with lower hold priority) > > Now I'm not sure but I guess you can't have one tunnel act as backup for a > specific te-tunnel > Though you can configure a te-tunnel to act as a backup for a link > > Since one of your tunnels is dynamic it can be re-established around the > failed link > > Though which tunnel is going to be used to forward traffic is based on how > you instruct the trafic to use one of the tunnes as primary path > > > adam > > > -----Original Message----- > From: harbor235 [mailto:harbor235 at gmail.com] > Sent: Friday, November 04, 2011 5:10 PM > To: NANOG list > Subject: MPLS TE > > TE lab testing flushing out how TE works, configured a primary and backup > tunnel between PEs, both directions. > Primary is dynamic and backup is explicit, initially priorities were the > same, I then choose > to make one tunnel preferred over the other adjusting the priorities, I > choose the tunnel that was backup > to become primary to watch the traffic shift. (primary path was P1-P2-P3, > backup path P1-P3). However, > the traffic did not shift, a manual shut on a P3-P2 interface made the > traffic shift, reintroduction > kept the traffic on P1-P3, then a "mpls traffic reoptimize" moved the > traffic back to P1-P2-P3. > > Obviously the preferred MPLS tunnel is still P1-P2-P3 even though I > configured "tunnel mpls traffic-eng priority 1 1" > on P1-P3 and "tunnel mpls traffic-eng priority 7 7" on P1-P2-P3. What am I > missing here? > > > My setup: > > > > CE-----PE-----P1----------P3-------PE----CE > \ / > \ / > P2 > > > Mike > From tim at pelican.org Fri Nov 4 12:07:39 2011 From: tim at pelican.org (Tim Franklin) Date: Fri, 04 Nov 2011 17:07:39 -0000 (GMT) Subject: Performance Issues - PTR Records In-Reply-To: <20111104162814.24EFAC0DC81@fafnir.remote.dragon.net> Message-ID: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org> > It's already been pointed out that lame delegations are more likely > problems for many. But the "we'll just pre-fill in-addr to avoid > problems" isn't going to work for ip6.arpa. If anyone has enough > hardware to serve the zone for a /48 (64k * 4bil * 4bil * > bytes-in-record), I'd love to see it. :) If PTR exists in zone file, serve it. Else, synthesize generic reverse. Jobsagoodun. > We need to get web and app folks to stop counting on > ip6.arpa/in-addr.arpa as a validation of trustworthiness. PTR make some > sense for validating servers, MTAs, etc. and it's handy for traceroute > but it was never a great tool and it's getting less useful with time. I've always seen it as a reasonable indication of a) minimum level of clue and b) giving a damn. If you can't be bothered or don't know how to provide even basic generic rDNS for your network, there's a reasonable chance you're lacking in other areas of network / user management. (Not "you" personally, of course). Regards, Tim. From cscora at apnic.net Fri Nov 4 14:17:41 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Nov 2011 05:17:41 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201111041917.pA4JHfLA026978@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, 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 05 Nov, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 380959 Prefixes after maximum aggregation: 166564 Deaggregation factor: 2.29 Unique aggregates announced to Internet: 187114 Total ASes present in the Internet Routing Table: 39222 Prefixes per ASN: 9.71 Origin-only ASes present in the Internet Routing Table: 32367 Origin ASes announcing only one prefix: 15483 Transit ASes present in the Internet Routing Table: 5264 Transit-only ASes present in the Internet Routing Table: 133 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1628 Unregistered ASNs in the Routing Table: 862 Number of 32-bit ASNs allocated by the RIRs: 1925 Number of 32-bit ASNs visible in the Routing Table: 1591 Prefixes from 32-bit ASNs in the Routing Table: 3686 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 86 Number of addresses announced to Internet: 2489977408 Equivalent to 148 /8s, 106 /16s and 10 /24s Percentage of available address space announced: 67.2 Percentage of allocated address space announced: 67.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.6 Total number of prefixes smaller than registry allocations: 160771 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 94863 Total APNIC prefixes after maximum aggregation: 31059 APNIC Deaggregation factor: 3.05 Prefixes being announced from the APNIC address blocks: 91315 Unique aggregates announced from the APNIC address blocks: 38279 APNIC Region origin ASes present in the Internet Routing Table: 4595 APNIC Prefixes per ASN: 19.87 APNIC Region origin ASes announcing only one prefix: 1270 APNIC Region transit ASes present in the Internet Routing Table: 716 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 21 Number of APNIC region 32-bit ASNs visible in the Routing Table: 101 Number of APNIC addresses announced to Internet: 629651296 Equivalent to 37 /8s, 135 /16s and 183 /24s Percentage of available APNIC address space announced: 79.9 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-132095, 132096-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: 145925 Total ARIN prefixes after maximum aggregation: 74475 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 117809 Unique aggregates announced from the ARIN address blocks: 48321 ARIN Region origin ASes present in the Internet Routing Table: 14739 ARIN Prefixes per ASN: 7.99 ARIN Region origin ASes announcing only one prefix: 5639 ARIN Region transit ASes present in the Internet Routing Table: 1559 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 804645888 Equivalent to 47 /8s, 245 /16s and 236 /24s Percentage of available ARIN address space announced: 63.9 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: 91828 Total RIPE prefixes after maximum aggregation: 51035 RIPE Deaggregation factor: 1.80 Prefixes being announced from the RIPE address blocks: 84299 Unique aggregates announced from the RIPE address blocks: 54500 RIPE Region origin ASes present in the Internet Routing Table: 16084 RIPE Prefixes per ASN: 5.24 RIPE Region origin ASes announcing only one prefix: 7968 RIPE Region transit ASes present in the Internet Routing Table: 2531 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1108 Number of RIPE addresses announced to Internet: 491707840 Equivalent to 29 /8s, 78 /16s and 221 /24s Percentage of available RIPE address space announced: 79.2 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 196608-198655 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: 35936 Total LACNIC prefixes after maximum aggregation: 7912 LACNIC Deaggregation factor: 4.54 Prefixes being announced from the LACNIC address blocks: 35352 Unique aggregates announced from the LACNIC address blocks: 18553 LACNIC Region origin ASes present in the Internet Routing Table: 1545 LACNIC Prefixes per ASN: 22.88 LACNIC Region origin ASes announcing only one prefix: 446 LACNIC Region transit ASes present in the Internet Routing Table: 281 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: 366 Number of LACNIC addresses announced to Internet: 92827520 Equivalent to 5 /8s, 136 /16s and 111 /24s Percentage of available LACNIC address space announced: 61.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: 8537 Total AfriNIC prefixes after maximum aggregation: 2007 AfriNIC Deaggregation factor: 4.25 Prefixes being announced from the AfriNIC address blocks: 6608 Unique aggregates announced from the AfriNIC address blocks: 1974 AfriNIC Region origin ASes present in the Internet Routing Table: 491 AfriNIC Prefixes per ASN: 13.46 AfriNIC Region origin ASes announcing only one prefix: 160 AfriNIC Region transit ASes present in the Internet Routing Table: 108 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: 4 Number of AfriNIC addresses announced to Internet: 27570432 Equivalent to 1 /8s, 164 /16s and 177 /24s Percentage of available AfriNIC address space announced: 41.1 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 2514 11129 974 Korea Telecom (KIX) 17974 1630 511 36 PT TELEKOMUNIKASI INDONESIA 7545 1614 303 87 TPG Internet Pty Ltd 4755 1548 637 174 TATA Communications formerly 7552 1394 1064 7 Vietel Corporation 9829 1166 989 28 BSNL National Internet Backbo 9583 1092 80 500 Sify Limited 4808 1090 2103 312 CNCGROUP IP network: China169 24560 964 343 218 Bharti Airtel Ltd., Telemedia 18101 954 135 150 Reliance Infocom Ltd Internet 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 3547 3814 223 bellsouth.net, inc. 7029 2337 1016 198 Windstream Communications Inc 18566 2094 383 177 Covad Communications 1785 1844 680 122 PaeTec Communications, Inc. 4323 1623 1078 389 Time Warner Telecom 20115 1596 1547 621 Charter Communications 22773 1462 2907 100 Cox Communications, Inc. 30036 1402 254 671 Mediacom Communications Corp 19262 1395 4728 400 Verizon Global Networks 7018 1317 7045 862 AT&T WorldNet Services 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 1449 416 14 Corbina telecom 6830 650 1927 414 UPC Distribution Services 34984 596 110 184 BILISIM TELEKOM 12479 545 628 51 Uni2 Autonomous System 20940 542 179 425 Akamai Technologies European 3320 507 8169 387 Deutsche Telekom AG 3292 481 2074 406 TDC Tele Danmark 8866 461 133 26 Bulgarian Telecommunication C 31148 406 22 114 FreeNet ISP 8551 402 354 43 Bezeq International 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 1699 314 156 TVCABLE BOGOTA 28573 1479 1043 79 NET Servicos de Comunicao S.A 8151 1430 2937 346 UniNet S.A. de C.V. 7303 1236 751 171 Telecom Argentina Stet-France 27947 591 72 84 Telconet S.A 22047 580 322 17 VTR PUNTO NET S.A. 6503 565 434 68 AVANTEL, S.A. 7738 553 1050 31 Telecomunicacoes da Bahia S.A 3816 537 233 95 Empresa Nacional de Telecomun 11172 524 85 95 Servicios Alestra S.A de C.V 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 24863 801 146 36 LINKdotNET AS number 8452 652 446 12 TEDATA 15475 443 74 8 Nile Online 36992 285 415 21 Etisalat MISR 3741 281 939 230 The Internet Solution 15706 240 32 6 Sudatel Internet Exchange Aut 33776 239 13 8 Starcomms Nigeria Limited 6713 235 519 14 Itissalat Al-MAGHRIB 29571 218 17 13 Ci Telecom Autonomous system 12258 196 28 57 Vodacom Internet Company 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 3547 3814 223 bellsouth.net, inc. 4766 2514 11129 974 Korea Telecom (KIX) 7029 2337 1016 198 Windstream Communications Inc 18566 2094 383 177 Covad Communications 1785 1844 680 122 PaeTec Communications, Inc. 10620 1699 314 156 TVCABLE BOGOTA 17974 1630 511 36 PT TELEKOMUNIKASI INDONESIA 4323 1623 1078 389 Time Warner Telecom 7545 1614 303 87 TPG Internet Pty Ltd 20115 1596 1547 621 Charter Communications 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 2337 2139 Windstream Communications Inc 18566 2094 1917 Covad Communications 1785 1844 1722 PaeTec Communications, Inc. 17974 1630 1594 PT TELEKOMUNIKASI INDONESIA 10620 1699 1543 TVCABLE BOGOTA 4766 2514 1540 Korea Telecom (KIX) 7545 1614 1527 TPG Internet Pty Ltd 8402 1449 1435 Corbina telecom 28573 1479 1400 NET Servicos de Comunicao S.A 7552 1394 1387 Vietel Corporation 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 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 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 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.0.0/16 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 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 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:12 /10:27 /11:81 /12:236 /13:465 /14:809 /15:1422 /16:12027 /17:6052 /18:10085 /19:19946 /20:27559 /21:27705 /22:37171 /23:35262 /24:198635 /25:1153 /26:1357 /27:761 /28:166 /29:4 /30:0 /31:0 /32:5 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2187 3547 bellsouth.net, inc. 18566 2043 2094 Covad Communications 7029 2005 2337 Windstream Communications Inc 10620 1594 1699 TVCABLE BOGOTA 8402 1424 1449 Corbina telecom 30036 1363 1402 Mediacom Communications Corp 11492 1117 1155 Cable One 1785 1057 1844 PaeTec Communications, Inc. 7011 1051 1169 Citizens Utilities 22773 950 1462 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:416 2:476 4:15 5:1 6:3 8:361 12:1955 13:1 14:541 15:11 16:3 17:7 20:9 23:58 24:1682 27:1024 31:673 32:65 33:2 34:2 36:4 38:758 40:110 41:2691 42:55 44:3 46:1025 47:3 49:299 50:443 52:13 55:6 56:2 57:47 58:902 59:497 60:361 61:1115 62:1086 63:1966 64:4057 65:2302 66:4278 67:2003 68:1163 69:3184 70:882 71:384 72:1802 74:2608 75:388 76:316 77:963 78:874 79:480 80:1131 81:844 82:520 83:528 84:619 85:1153 86:398 87:976 88:356 89:1593 90:235 91:4255 92:535 93:1536 94:1300 95:1088 96:428 97:286 98:936 99:37 101:225 103:432 106:70 107:84 108:72 109:1155 110:661 111:797 112:341 113:486 114:620 115:715 116:882 117:723 118:877 119:1265 120:344 121:695 122:1572 123:1007 124:1352 125:1355 128:245 129:189 130:164 131:627 132:148 133:21 134:221 135:54 136:212 137:142 138:286 139:122 140:489 141:317 142:389 143:410 144:491 145:64 146:465 147:220 148:641 149:267 150:169 151:194 152:447 153:178 154:7 155:385 156:208 157:361 158:155 159:485 160:333 161:214 162:371 163:173 164:511 165:369 166:540 167:439 168:820 169:145 170:880 171:86 172:4 173:1708 174:679 175:417 176:278 177:369 178:1082 180:1139 181:38 182:653 183:221 184:387 185:1 186:1328 187:764 188:1061 189:1147 190:5167 192:5931 193:5050 194:3558 195:3112 196:1265 197:167 198:3629 199:4175 200:5513 201:1695 202:8573 203:8478 204:4315 205:2370 206:2674 207:2820 208:4037 209:3580 210:2720 211:1457 212:2083 213:1780 214:813 215:95 216:4918 217:1603 218:564 219:342 220:1254 221:517 222:322 223:269 End of report From michael.rocco.sabino at gmail.com Fri Nov 4 15:39:43 2011 From: michael.rocco.sabino at gmail.com (Michael Sabino) Date: Fri, 4 Nov 2011 15:39:43 -0500 Subject: Route server: Route-server.ip.att.net Message-ID: Hi, Could you give me the relevant configs explaining why when I traceroute to 12.83.43.9 on route-server.ip.att.net, the first hop is " j6300.cbbtier3.att.net (12.0.1.202)". However, when I type "show ip route 12.83.43.9", the RIB shows, "* 12.122.83.91, from 12.122.83.91, 7w0d ago". I asked someone who is knowledgeable about the matter, and he seems to think that you can change the interface which sends back ICMP unreachables, but I don't know how to do this on my own simulated equipment. Also, I have noticed that when I traceroute to any ip address on the internet from my home connection, the last hop that's in common with all traceroutes is 12.83.43.9. This is a hop after several hops which seem to be filtered. What is the purpose of this IP? Are there any publically available documentation that would help me understand the process of aggregating multiple DSLAMs, etc on my at&t u-verse connection? I am a CCNA/CCNP student in college and this would help me understand WANs better. Thanks Michael R. Sabino michael.rocco.sabino at gmail.com From keegan.holley at sungard.com Fri Nov 4 15:46:03 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Fri, 4 Nov 2011 16:46:03 -0400 Subject: Route server: Route-server.ip.att.net In-Reply-To: References: Message-ID: Did you do a show ip route for 12.122.83.91? It's probably a loopback of the nearest BGP peer it may not be the actual next hop interface IP though. Not sure about the blocked hops, but I can think of a few explanations. Overall the point of that router is to provide a view of the route table and not the physical hops from one point to another. Since actual customer traffic wouldn't flow through the route server the first few hops are probably irrelevant. 2011/11/4 Michael Sabino > Hi, > > Could you give me the relevant configs explaining why when I traceroute to > 12.83.43.9 on route-server.ip.att.net, the first hop is " > j6300.cbbtier3.att.net (12.0.1.202)". However, when I type "show ip route > 12.83.43.9", the RIB shows, "* 12.122.83.91, from 12.122.83.91, 7w0d ago". > > I asked someone who is knowledgeable about the matter, and he seems to > think that you can change the interface which sends back ICMP unreachables, > but I don't know how to do this on my own simulated equipment. > > Also, I have noticed that when I traceroute to any ip address on the > internet from my home connection, the last hop that's in common with all > traceroutes is 12.83.43.9. This is a hop after several hops which seem to > be filtered. What is the purpose of this IP? > > Are there any publically available documentation that would help me > understand the process of aggregating multiple DSLAMs, etc on my at&t > u-verse connection? > > I am a CCNA/CCNP student in college and this would help me understand WANs > better. > > > Thanks > > Michael R. Sabino > michael.rocco.sabino at gmail.com > > From prox at prolixium.com Fri Nov 4 15:59:22 2011 From: prox at prolixium.com (Mark Kamichoff) Date: Fri, 4 Nov 2011 16:59:22 -0400 Subject: Route server: Route-server.ip.att.net In-Reply-To: References: Message-ID: <20111104205922.GA27068@prolixium.com> On Fri, Nov 04, 2011 at 03:39:43PM -0500, Michael Sabino wrote: > Could you give me the relevant configs explaining why when I > traceroute to 12.83.43.9 on route-server.ip.att.net, the first hop is > " j6300.cbbtier3.att.net (12.0.1.202)". However, when I type "show ip > route 12.83.43.9", the RIB shows, "* 12.122.83.91, from 12.122.83.91, > 7w0d ago". A couple things here: 12.122.83.91 is the BGP next-hop in the RIB. It needs to be resolved. In this case it's being resolved via a /13 static route: route-server>sho ip route 12.122.83.91 Routing entry for 12.120.0.0/13 Known via "static", distance 1, metric 0 Redistributing via bgp 65000 Advertised by bgp 65000 Routing Descriptor Blocks: * 12.0.1.1, via GigabitEthernet0/1 Route metric is 0, traffic share count is 1 In real life it'd probably be resolved via an IGP such as OSPF or IS-IS, but this is a route server, not a transit router. So, the real next-hop is 12.0.1.1. You can also verify this with the following, since it's a Cisco box: route-server>show ip cef 12.83.43.9 12.0.0.0/9 nexthop 12.0.1.1 GigabitEthernet0/1 However, you don't see 12.0.1.1 in the traceroute because it looks to be the VRRP address of the Juniper J6300 upstream router (just judging by the hostname): route-server>sho arp 12.0.1.1 Protocol Address Age (min) Hardware Addr Type Interface Internet 12.0.1.1 81 0000.5e00.0101 ARPA GigabitEthernet0/1 The MAC address is a giveaway that it's VRRP, since 00-00-5E-00-01 is reserved by IANA for VRRP (IPv4 only): http://tools.ietf.org/html/rfc5798#section-7.3 The Juniper router will send back ICMP TTL-exceeded messages from the real IP on its interface, which appears to be 12.0.1.202. Hope this helps. - Mark -- Mark Kamichoff prox at prolixium.com http://www.prolixium.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From james at freedomnet.co.nz Fri Nov 4 16:21:41 2011 From: james at freedomnet.co.nz (James Jones) Date: Fri, 4 Nov 2011 17:21:41 -0400 Subject: TR-69 and linux Message-ID: Does anyone know of a open TR-69 implementation for linux? Also to take it one step further, does anyone of one that works in tandem with a web gui like openwrt? From cidr-report at potaroo.net Fri Nov 4 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Nov 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201111042200.pA4M00Ck057405@wattle.apnic.net> BGP Update Report Interval: 27-Oct-11 -to- 03-Nov-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 33708 2.2% 55.3 -- BSNL-NIB National Internet Backbone 2 - AS8402 32620 2.1% 27.4 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS14420 25170 1.6% 53.4 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 4 - AS32528 23722 1.6% 4744.4 -- ABBOTT Abbot Labs 5 - AS38040 22818 1.5% 1629.9 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 6 - AS5800 19466 1.3% 79.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 7 - AS9498 16593 1.1% 42.9 -- BBIL-AP BHARTI Airtel Ltd. 8 - AS4274 14284 0.9% 187.9 -- ERX-AU-NET Assumption University 9 - AS16916 12491 0.8% 12491.0 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 10 - AS7552 11981 0.8% 8.8 -- VIETEL-AS-AP Vietel Corporation 11 - AS3475 11876 0.8% 152.3 -- DNIC-AS-03475 - Navy Network Information Center (NNIC) 12 - AS30890 11312 0.7% 31.6 -- EVOLVA EUROLAN SOLUTIONS SRL 13 - AS26615 11293 0.7% 32.3 -- Tim Celular S.A. 14 - AS8866 11264 0.7% 352.0 -- BTC-AS Bulgarian Telecommunication Company Plc. 15 - AS17974 11092 0.7% 7.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 16 - AS16010 10735 0.7% 86.6 -- RUSTAVI2ONLINEAS Caucasus Online LLC 17 - AS45514 10244 0.7% 34.1 -- TELEMEDIA-SMB-AS-AP Bharti Airtel Ltd., TELEMEDIA Services, for SMB customers 18 - AS3352 10129 0.7% 4.9 -- TELEFONICA-DATA-ESPANA TELEFONICA DE ESPANA 19 - AS7029 9950 0.7% 7.3 -- WINDSTREAM - Windstream Communications Inc 20 - AS45595 9764 0.6% 41.2 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS16916 12491 0.8% 12491.0 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 2 - AS57090 4891 0.3% 4891.0 -- SNSREAAL SNS REAAL N.V. 3 - AS32528 23722 1.6% 4744.4 -- ABBOTT Abbot Labs 4 - AS17408 3137 0.2% 3137.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 5 - AS38040 22818 1.5% 1629.9 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 6 - AS9562 9496 0.6% 1356.6 -- MSU-TH-AP Mahasarakham University 7 - AS22042 1311 0.1% 1311.0 -- FLOWUSLLC - Flow Traders US LLC 8 - AS17425 4774 0.3% 1193.5 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 9 - AS47528 1140 0.1% 1140.0 -- INTELECOM-AS Intelecom Group ASA 10 - AS21789 4335 0.3% 1083.8 -- 168-244 - Lowe's Companies, Inc. 11 - AS55696 1016 0.1% 1016.0 -- SCOM-AS-ID Starcom Solusindo PT. 12 - AS25429 6413 0.4% 916.1 -- CBI-AS CBINET, Bujumbura, Burundi. 13 - AS56939 713 0.1% 713.0 -- CREDOS Credo-S Ltd. 14 - AS45615 693 0.1% 693.0 -- NRW NRW Holdings Limited 15 - AS45771 601 0.0% 601.0 -- WESTLINK-PH TELERURAL COMMUNICATION MANAGEMENT INC. 16 - AS46983 599 0.0% 599.0 -- SAML-ASN - Southpaw Asset Management LP 17 - AS6072 7420 0.5% 530.0 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com 18 - AS10445 1796 0.1% 449.0 -- HTG - Huntleigh Telcom 19 - AS29356 419 0.0% 419.0 -- NESTLE Nestle Switzerland 20 - AS43389 396 0.0% 396.0 -- EULOGOS EULOGOS SPA TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 14325 0.9% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 206.80.93.0/24 12491 0.8% AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 3 - 130.36.34.0/24 11856 0.7% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 11856 0.7% AS32528 -- ABBOTT Abbot Labs 5 - 213.16.48.0/24 11076 0.7% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 6 - 196.2.14.0/24 5688 0.3% AS25429 -- CBI-AS CBINET, Bujumbura, Burundi. 7 - 194.53.211.0/24 4891 0.3% AS57090 -- SNSREAAL SNS REAAL N.V. 8 - 180.180.248.0/24 4762 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 9 - 180.180.253.0/24 4762 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 10 - 180.180.250.0/24 4760 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 11 - 180.180.249.0/24 4561 0.3% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 12 - 84.204.132.0/24 4499 0.3% AS20632 -- PETERSTAR-AS PeterStar 13 - 180.180.255.0/24 3829 0.2% AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT Public Company Limited 14 - 202.41.70.0/24 3515 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 15 - 202.171.192.0/20 3239 0.2% AS4788 -- TMNET-AS-AP TM Net, Internet Service Provider 16 - 202.153.174.0/24 3137 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 17 - 221.183.16.0/23 3072 0.2% AS65500 -- -Private Use AS- AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 18 - 202.93.40.0/24 2624 0.2% AS4761 -- INDOSAT-INP-AP INDOSAT Internet Network Provider 19 - 202.151.6.0/24 2378 0.1% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 20 - 202.151.7.0/24 2378 0.1% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 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 Nov 4 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Nov 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201111042200.pA4M00Rj057400@wattle.apnic.net> This report has been generated at Fri Nov 4 21:12:12 2011 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 28-10-11 381389 224100 29-10-11 381588 224071 30-10-11 381765 223954 31-10-11 381720 223778 01-11-11 382078 223922 02-11-11 382192 224106 03-11-11 382733 224459 04-11-11 382870 224689 AS Summary 39319 Number of ASes in routing system 16583 Number of ASes announcing only one prefix 3547 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108768256 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'). --- 04Nov11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 383194 224787 158407 41.3% All ASes AS6389 3547 226 3321 93.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2094 406 1688 80.6% COVAD - Covad Communications Co. AS4766 2514 993 1521 60.5% KIXS-AS-KR Korea Telecom AS22773 1462 110 1352 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1544 231 1313 85.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1624 391 1233 75.9% TWTC - tw telecom holdings, inc. AS1785 1847 786 1061 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1481 425 1056 71.3% NET Servicos de Comunicao S.A. AS19262 1395 400 995 71.3% VZGNI-TRANSIT - Verizon Online LLC AS10620 1699 710 989 58.2% Telmex Colombia S.A. AS7552 1394 424 970 69.6% VIETEL-AS-AP Vietel Corporation AS7303 1236 331 905 73.2% Telecom Argentina S.A. AS8402 1441 612 829 57.5% CORBINA-AS OJSC "Vimpelcom" AS18101 955 151 804 84.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7029 2378 1591 787 33.1% WINDSTREAM - Windstream Communications Inc AS4808 1090 344 746 68.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS8151 1432 690 742 51.8% Uninet S.A. de C.V. AS30036 1402 676 726 51.8% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS7545 1614 944 670 41.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1116 463 653 58.5% LEVEL3 Level 3 Communications AS24560 964 336 628 65.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4804 705 95 610 86.5% MPX-AS Microplex PTY LTD AS17676 678 70 608 89.7% GIGAINFRA Softbank BB Corp. AS20115 1596 992 604 37.8% CHARTER-NET-HKY-NC - Charter Communications AS17974 1629 1048 581 35.7% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS3549 1022 453 569 55.7% GBLX Global Crossing Ltd. AS22561 932 372 560 60.1% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 580 33 547 94.3% VTR BANDA ANCHA S.A. AS17488 943 411 532 56.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS7011 1169 646 523 44.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 43483 15360 28123 64.7% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 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- 41.222.79.0/24 AS37345 MEDALLION 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 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.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 185.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.24.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 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 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 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.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 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.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 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 cb.list6 at gmail.com Fri Nov 4 17:04:10 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 4 Nov 2011 15:04:10 -0700 Subject: IPv6 beta support for Android phones Message-ID: FYI. T-Mobile USA now has opt-in beta support for an Android phone on IPv6, more info here https://sites.google.com/site/tmoipv6/lg-mytouch As far as i know, this is the first Android phone that support IPv6 on the GSM/UMTS mobile interface. Previous version of Android phones supported IPv6 on WiFi and LTE. Cameron From pete at altadena.net Fri Nov 4 18:45:44 2011 From: pete at altadena.net (Pete Carah) Date: Fri, 04 Nov 2011 19:45:44 -0400 Subject: IPv6 beta support for Android phones In-Reply-To: References: Message-ID: <4EB47928.3030503@altadena.net> On 11/04/2011 06:04 PM, Cameron Byrne wrote: > FYI. > > T-Mobile USA now has opt-in beta support for an Android phone on IPv6, > more info here https://sites.google.com/site/tmoipv6/lg-mytouch Very good. > > As far as i know, this is the first Android phone that support IPv6 on > the GSM/UMTS mobile interface. Previous version of Android phones > supported IPv6 on WiFi and LTE. My iPhone (old 3G, 4.2.1) supports v6 on wifi (I can see it at the other end of connections; the UI status page refuses to admit to ipv6 though.) It appears to use only eui64 addresses and not privacy ones (this from perusing web and mail logs at the server end). I don't know about any other medium since as far as I can see, AT&T's network doesn't (yet) support v6 on umts or gsm/edge :-( -- Pete From joelja at bogus.com Fri Nov 4 19:00:10 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 4 Nov 2011 17:00:10 -0700 Subject: IPv6 beta support for Android phones In-Reply-To: <4EB47928.3030503@altadena.net> References: <4EB47928.3030503@altadena.net> Message-ID: <1D420F82-B75C-437F-A0BE-4DAF004B45A6@bogus.com> The cellular radios firmware doesn't support ipv6(on your iPhone)... Sent from my iPhone On Nov 4, 2011, at 4:45 PM, Pete Carah wrote: > On 11/04/2011 06:04 PM, Cameron Byrne wrote: >> FYI. >> >> T-Mobile USA now has opt-in beta support for an Android phone on IPv6, >> more info here https://sites.google.com/site/tmoipv6/lg-mytouch > Very good. >> >> As far as i know, this is the first Android phone that support IPv6 on >> the GSM/UMTS mobile interface. Previous version of Android phones >> supported IPv6 on WiFi and LTE. > My iPhone (old 3G, 4.2.1) supports v6 on wifi (I can see it at the other > end of connections; the > UI status page refuses to admit to ipv6 though.) It appears to use only > eui64 addresses and not > privacy ones (this from perusing web and mail logs at the server end). > > I don't know about any other medium since as far as I can see, AT&T's > network doesn't (yet) > support v6 on umts or gsm/edge :-( > > -- Pete > > > From mysidia at gmail.com Fri Nov 4 19:26:02 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 4 Nov 2011 19:26:02 -0500 Subject: Performance Issues - PTR Records In-Reply-To: <20111104162814.24EFAC0DC81@fafnir.remote.dragon.net> References: <25ECCB35-6EE1-40BE-8B35-6A6994318C80@bjencks.net> <20111104162814.24EFAC0DC81@fafnir.remote.dragon.net> Message-ID: On Fri, Nov 4, 2011 at 11:28 AM, Paul Ebersman wrote: > It's already been pointed out that lame delegations are more likely > problems for many. But the "we'll just pre-fill in-addr to avoid > problems" isn't going to work for ip6.arpa. If anyone has enough > hardware to serve the zone for a /48 (64k * 4bil * 4bil * > bytes-in-record), I'd love to see it. :) [snip] I can serve the zone for a /48 by creating a "sparse" zone. That is... when you ask my DNS server what such and such PTR reverses too, what I don't have a DNS entry for, it can tell you something generic. There is no need for me to physically create 64k*4bil*4bil on a disk or memory area somewhere. I can make a plugin for my DNS server to hand you the generic result when you ask my DNS server what something reverses to... That is, I can serve you an ephemeral record without requiring an extra byte of storage beyond the life of your query :) -- -JH From jbates at brightok.net Fri Nov 4 19:37:37 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Nov 2011 19:37:37 -0500 Subject: MPLS TE In-Reply-To: References: Message-ID: <4EB48551.1070200@brightok.net> On 11/4/2011 12:00 PM, harbor235 wrote: > I am also looking at FRR which uses a backup tunnel for fast convergence. I > did however not think > about the dynamic nature of the tunnel and the potential for > reestablishment. > > Even with primary/secondary paths, the secondary path will normally not get used if the primary can resignal to a different path. Implementations can get very vendor specific. Each vendor supports different subsets of the necessary protocols. I just had a single vendor network, that due to lack of SRLG support in their lower end boxes (and lack of admin-group in FRR) required setting facility based FRR with many bypasses (which luckily they did support at all levels and the manual bypasses did support admin-groups for setup). The only time I usually use dual LSPs is to support load balancing across multiple circuits where vendor support is limited (1 LSP down each pipe, IGP balance between them, each LSP has secondary path on opposite pipe). The idea of MPLS is that the LSP should NOT be down. A path might go down and FRR/secondy paths might come into play, but the LSP itself should still be handling traffic. Even in complicated QOS setups, you can have primary, and multiple secondaries to allow stepdown of what a circuit should be reserving, and priorities to even preempt circuits to lower class of service (imagine a secondary trying for what it currently has without preemption, but then that failing, sets different requirements and preempts lesser circuits). In simpler topologies where I don't need TE and I just want FRR, I've been playing with Juniper's LFA implementation. One of my current plans is using RSVP/FRR for mpls only services and using LFA for global routing. It works for my specific layout, and the only annoyance is setting BGP next-hops correctly. Jack From jack at bonyari.com Fri Nov 4 20:31:14 2011 From: jack at bonyari.com (Jack Morgan) Date: Fri, 04 Nov 2011 18:31:14 -0700 Subject: TR-69 and linux In-Reply-To: References: Message-ID: <4EB491E2.405@bonyari.com> On 11/04/2011 02:21 PM, James Jones wrote: > Does anyone know of a open TR-69 implementation for linux? Also to take it > one step further, does anyone of one that works in tandem with a web gui > like openwrt? This companies product is based off of TR-69 running on a Linux device to a web gui applicaiton. http://www.clearaccess.com/ -- Jack Morgan Pub 4096R/761D8E0A 2010-09-13 Jack Morgan Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From list-nanog2 at dragon.net Fri Nov 4 21:44:42 2011 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Fri, 04 Nov 2011 19:44:42 -0700 Subject: Performance Issues - PTR Records In-Reply-To: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org> References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org> Message-ID: <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net> tim> If PTR exists in zone file, serve it. Else, synthesize generic tim> reverse. Jobsagoodun. If all we're doing is lying with some generic answer that we hack our server to produce, why are we bothering? At that point, you're not proving clue. You're proving you at least bought a solution from someone with a clue... My contention is that (at least for end hosts), PTR records are mostly pointless and just overhead for DNS servers. From jra at baylink.com Fri Nov 4 21:57:33 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 4 Nov 2011 22:57:33 -0400 (EDT) Subject: Performance Issues - PTR Records In-Reply-To: Message-ID: <9655164.1668.1320461853541.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > There is no need for me to physically create 64k*4bil*4bil on a disk or memory area > somewhere. I can make a plugin for my DNS server to hand you the generic result > when you ask my DNS server what something reverses to... > > That is, I can serve you an ephemeral record without requiring an > extra byte of storage beyond the life of your query :) This is precisely the approach taken by the DNS server package written by the tech folks at the late, lamented MindSpring -- the name of which eludes me for the moment. 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 gary.steers at sharedband.com Sat Nov 5 04:45:42 2011 From: gary.steers at sharedband.com (Gary Steers) Date: Sat, 5 Nov 2011 09:45:42 -0000 Subject: Severe Packet loss Message-ID: Hi Guys, Is anyone else having major issue's tonight/this morning? We our having issue's and our upstream provider is reporting route flaps, the say its affecting quite a few networks but just checking if anyone else is having issue's??? Gary From tknchris at gmail.com Sat Nov 5 08:31:33 2011 From: tknchris at gmail.com (chris) Date: Sat, 5 Nov 2011 09:31:33 -0400 Subject: Severe Packet loss In-Reply-To: References: Message-ID: quite a bit of information you have there anyone else think the internet is a little flaky today? *facepalm* On Sat, Nov 5, 2011 at 5:45 AM, Gary Steers wrote: > Hi Guys, > > > > Is anyone else having major issue's tonight/this morning? > > > > We our having issue's and our upstream provider is reporting route > flaps, the say its affecting quite a few networks but just checking if > anyone else is having issue's??? > > > > Gary > > From blake at pfankuch.me Sat Nov 5 10:53:56 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Sat, 5 Nov 2011 15:53:56 +0000 Subject: Severe Packet loss In-Reply-To: References: Message-ID: Understanding this is a little vague, I can say that I did see "weirdness" in connectivity from a datacenter in Seattle to LA, Dallas to LA and Amazon West US to Dallas, and Denver to Seattle about 2am to 3am MDT. If you could provide what carriers you are on, maybe we can compare notes? -----Original Message----- From: Gary Steers [mailto:gary.steers at sharedband.com] Sent: Saturday, November 05, 2011 3:46 AM To: nanog at nanog.org Subject: Severe Packet loss Hi Guys, Is anyone else having major issue's tonight/this morning? We our having issue's and our upstream provider is reporting route flaps, the say its affecting quite a few networks but just checking if anyone else is having issue's??? Gary From randy at psg.com Sat Nov 5 11:38:51 2011 From: randy at psg.com (Randy Bush) Date: Sat, 05 Nov 2011 17:38:51 +0100 Subject: Severe Packet loss In-Reply-To: References: Message-ID: > Is anyone else having major issue's tonight/this morning? > > We our having issue's and our upstream provider is reporting route > flaps, the say its affecting quite a few networks but just checking if > anyone else is having issue's??? "The internet is broken" "Yes dear. Care to tell me which part?" From streiner at cluebyfour.org Sat Nov 5 12:26:10 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 5 Nov 2011 13:26:10 -0400 (EDT) Subject: Severe Packet loss In-Reply-To: References: Message-ID: On Sat, 5 Nov 2011, Gary Steers wrote: > Is anyone else having major issue's tonight/this morning? > > We our having issue's and our upstream provider is reporting route > flaps, the say its affecting quite a few networks but just checking if > anyone else is having issue's??? You'll generally get more helpful responses from NANOG and other forums if you provide more detail than "major issue's[sic]" and "route flaps". People will be more inclined to help or offer suggestions if you provide details and have done some research into the problem already. For example: What major issues were you seeing? Can those issues be defined with traceroutes, snapshots of BGP route views, reproducible difficulties in reaching a particular site, etc? What other carriers were reporting problems? Can you provide a source and destination address that is having connectivity issues? When you say "our upstream provider", are you single-homed or multi-homed? Speaking from my own little corner of the world, I haven't seen any major connectivity problems here in the past 24 hours. jms From w3yni1 at gmail.com Sat Nov 5 13:05:50 2011 From: w3yni1 at gmail.com (Charles Mills) Date: Sat, 5 Nov 2011 14:05:50 -0400 Subject: Severe Packet loss In-Reply-To: References: Message-ID: Cogent had some planned maintenance during the 2-4a timeframe. Furthermore there was some sluggishness and packet loss for some of my customers that *seemed* to be centered around Ashburn, VA around 9-9:30 but cleared up before I could get a good look at it or even before where it was situated. Chuck On Sat, Nov 5, 2011 at 1:26 PM, Justin M. Streiner wrote: > On Sat, 5 Nov 2011, Gary Steers wrote: > > Is anyone else having major issue's tonight/this morning? >> >> We our having issue's and our upstream provider is reporting route >> flaps, the say its affecting quite a few networks but just checking if >> anyone else is having issue's??? >> > > You'll generally get more helpful responses from NANOG and other forums if > you provide more detail than "major issue's[sic]" and "route flaps". People > will be more inclined to help or offer suggestions if you provide details > and have done some research into the problem already. > > For example: > What major issues were you seeing? Can those issues be defined with > traceroutes, snapshots of BGP route views, reproducible difficulties in > reaching a particular site, etc? What other carriers were reporting > problems? Can you provide a source and destination address that is having > connectivity issues? > > When you say "our upstream provider", are you single-homed or multi-homed? > > Speaking from my own little corner of the world, I haven't seen any major > connectivity problems here in the past 24 hours. > > jms > > From tom at ninjabadger.net Sun Nov 6 09:50:08 2011 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 06 Nov 2011 15:50:08 +0000 Subject: Severe Packet loss In-Reply-To: References: Message-ID: <1320594608.6199.3.camel@teh-desktop> On Sat, 2011-11-05 at 17:38 +0100, Randy Bush wrote: > "The internet is broken" > > "Yes dear. Care to tell me which part?" Was it just the bias of my nationality that prompted me to repeat this out-loud with a posh, British accent? :) Tom From tom at ninjabadger.net Sun Nov 6 10:32:57 2011 From: tom at ninjabadger.net (Tom Hill) Date: Sun, 06 Nov 2011 16:32:57 +0000 Subject: IPv6 beta support for Android phones In-Reply-To: References: Message-ID: <1320597177.6199.8.camel@teh-desktop> On Fri, 2011-11-04 at 15:04 -0700, Cameron Byrne wrote: > FYI. > > T-Mobile USA now has opt-in beta support for an Android phone on IPv6, > more info here https://sites.google.com/site/tmoipv6/lg-mytouch Very, very good. I hope T-Mobile UK (and elsewhere in the world) take heed. I have to wonder why they've chosen to go with IPv6-only & DNS/NAT64 instead of a dual-stack approach. Is there a particular restriction that prevents this? > As far as i know, this is the first Android phone that support IPv6 on > the GSM/UMTS mobile interface. Previous version of Android phones > supported IPv6 on WiFi and LTE. Indeed, the 'Network Info II' application will show you the IPv6 addresses gained on WiFi interfaces (if anyone's interested). My Galaxy S (unlocked/orig.) does this very well. I wonder if it's possible to provide IPv6 support for UMTS/GSM via firmware and/or software updates from Samsung? Tom From lbstreamer at gmail.com Sun Nov 6 12:01:24 2011 From: lbstreamer at gmail.com (Louis P) Date: Sun, 06 Nov 2011 19:01:24 +0100 Subject: Historical records of IP allocations Message-ID: <4EB6CB74.6060003@gmail.com> Hello, Does anyone know if it's possible to get old records (AS numbers...) of an IP allocation ? I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/ But only the country and allocation date are included. The IP range I would like to have more information about is 109.190.0.0/17 (it was Russian before and now French). Thanks in advance, Regards, Louis P. From nanog at namor.ca Sun Nov 6 13:41:49 2011 From: nanog at namor.ca (J) Date: Sun, 06 Nov 2011 13:41:49 -0600 Subject: Historical records of IP allocations In-Reply-To: <4EB6CB74.6060003@gmail.com> References: <4EB6CB74.6060003@gmail.com> Message-ID: <4EB6E2FD.5090807@namor.ca> Louis P wrote: > Hello, > Does anyone know if it's possible to get old records (AS numbers...) of > an IP allocation ? > I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/ > But only the country and allocation date are included. > > The IP range I would like to have more information about is > 109.190.0.0/17 (it was Russian before and now French). > > Thanks in advance, > Regards, > Louis P. Cymru has something like that, don't they? I'm not sure how far back it goes. http://www.team-cymru.org/Services/ip-to-asn.html From robt at cymru.com Sun Nov 6 16:06:06 2011 From: robt at cymru.com (Rob Thomas) Date: Sun, 06 Nov 2011 17:06:06 -0500 Subject: Historical records of IP allocations In-Reply-To: <4EB6E2FD.5090807@namor.ca> References: <4EB6CB74.6060003@gmail.com> <4EB6E2FD.5090807@namor.ca> Message-ID: <4EB704CE.7000303@cymru.com> Hi, team. > Cymru has something like that, don't they? I'm not sure how far back > it goes. > > http://www.team-cymru.org/Services/ip-to-asn.html That's a more real-time view, so it won't be much use for historical research. Louis: I did look in our archives, but only found AS35540 OVH-TELECOM OVH Telecom as the origin. Other folks on this list may have data that goes further back. Thanks, Rob. -- Rob Thomas Team Cymru https://www.team-cymru.org/ "Say little and do much." M Avot 1:15 From wilhelm at ripe.net Sun Nov 6 16:34:45 2011 From: wilhelm at ripe.net (Rene Wilhelm) Date: Sun, 06 Nov 2011 23:34:45 +0100 Subject: Historical records of IP allocations In-Reply-To: <4EB6CB74.6060003@gmail.com> References: <4EB6CB74.6060003@gmail.com> Message-ID: <4EB70B85.3040103@ripe.net> On 11/6/11 7:01 PM, Louis P wrote: > Hello, > Does anyone know if it's possible to get old records (AS numbers...) > of an IP allocation ? > I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/ > But only the country and allocation date are included. Have a look at stat.ripe.net , specifically the 'routing history' box. http://stat.ripe.net/query/routing-history/109.190.0.0/17 shows the less specific 109.190/16 was originated by AS35408 from approximately january 2010 to july 2010. -- Rene > > The IP range I would like to have more information about is > 109.190.0.0/17 (it was Russian before and now French). > > Thanks in advance, > Regards, > Louis P. > > From tom+nanog at oneshoeco.com Sun Nov 6 19:00:52 2011 From: tom+nanog at oneshoeco.com (Tom Lanyon) Date: Mon, 7 Nov 2011 11:30:52 +1030 Subject: Performance Issues - PTR Records In-Reply-To: <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net> References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org> <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net> Message-ID: On 05/11/2011, at 1:14 PM, Paul Ebersman wrote: > tim> If PTR exists in zone file, serve it. Else, synthesize generic > tim> reverse. Jobsagoodun. > > If all we're doing is lying with some generic answer that we hack our > server to produce, why are we bothering? Because some applications rely on it working (for some definition of "working"). > My contention is that (at least for end hosts), PTR records are mostly > pointless and just overhead for DNS servers. If you haven't set up PTR records for your end hosts, realistically you're going to be serving NXDOMAINs for them anyway, so there's not really any overhead introduced by supplying something generic instead... Tom From marka at isc.org Sun Nov 6 19:10:21 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 07 Nov 2011 12:10:21 +1100 Subject: Performance Issues - PTR Records In-Reply-To: Your message of "Mon, 07 Nov 2011 11:30:52 +1030." References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org> <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net> Message-ID: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> In message , Tom Lanyon wri tes: > On 05/11/2011, at 1:14 PM, Paul Ebersman wrote: > > tim> If PTR exists in zone file, serve it. Else, synthesize generic > > tim> reverse. Jobsagoodun. > >=20 > > If all we're doing is lying with some generic answer that we hack our > > server to produce, why are we bothering? > > Because some applications rely on it working (for some definition of = > "working"). > > > My contention is that (at least for end hosts), PTR records are mostly > > pointless and just overhead for DNS servers. > > If you haven't set up PTR records for your end hosts, realistically = > you're going to be serving NXDOMAINs for them anyway, so there's not = > really any overhead introduced by supplying something generic instead... > > Tom Except you also have to supply the A/AAAA records as well. MacOS and Windows can both populate the reverse zone for you as can dhcp servers. The practice of filling out the reverse zone with fake PTR record started before there was wide spread support for UPDATE/DNS. There isn't any need for this to be done anymore. Machines are capable of adding records for themselves. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From craams at staff.ains.net.au Sun Nov 6 19:36:03 2011 From: craams at staff.ains.net.au (Curtis Raams) Date: Mon, 7 Nov 2011 01:36:03 +0000 Subject: Bulk purchase of some Cisco 857 routers Message-ID: Hello, I have a client who is seeking to purchase 150 second hand Cisco 857 routers. We are unable to supply this quantity since we no longer inventory the items. Does anyone on the list have a large quantity they want to get rid of? [Description: map] Curtis Raams General Manager of ICT Level 6, 140 Queen St. Melbourne Victoria 3000 T: 03 8665 8305 F: 03 9945 7502 M: 0404 394 904 E: craams at staff.ains.net.au W: www.ains.com.au This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify us immediately by telephone on 1300 887 877 and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. BE GREEN! Read from the screen. From mysidia at gmail.com Sun Nov 6 19:57:51 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 6 Nov 2011 19:57:51 -0600 Subject: Performance Issues - PTR Records In-Reply-To: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org> <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net> <20111107011021.5CEB316CD13E@drugs.dv.isc.org> Message-ID: On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews wrote: > MacOS and Windows can both populate the reverse zone for you as can > dhcp servers. > The practice of filling out the reverse zone with fake PTR record [...] OK.. let's say you're a DSL provider. Are you going to have your DHCP server populating the forward and reverse DNS? With what, the account holder's name? somename.example.com ? Wouldn't you say blahblah192-168-0-2.city.state.dsl.example.com provides more useful information? First of all, you know that the IP address is an end user, an access network's end user's one IP address, an endpoint, rather than a subnet assigned to an actual multinode network. Second of all, you know it's an ISP, and you have city and state information of the network service. This is more useful than arbitrary user made up hostname. The hostname is more meaningful on "real networks" such as SMB LANs, Enterprise intranets, web farms, server networks, and other places where generic records should not be assigned, but the PTR should be the actual hostname. If the IP address is dynamic or autoconfigured for _those_ types of networks, then yes, automatic RDNS registration makes sense. If it's static, not so much. Dynamic DNS registration is also complicated to make secure.... as in preventing hosts from updating other hosts' records or mucking around the zone in other unwanted ways requires complex key management and ACL configuration > > -- > Mark Andrews, ISC -- -JH From bonomi at mail.r-bonomi.com Sun Nov 6 20:16:39 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 6 Nov 2011 20:16:39 -0600 (CST) Subject: Performance Issues - PTR Records In-Reply-To: Message-ID: <201111070216.pA72Gd7V047900@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sun Nov 6 19:58:58 2011 > Date: Sun, 6 Nov 2011 19:57:51 -0600 > Subject: Re: Performance Issues - PTR Records > From: Jimmy Hess > To: Mark Andrews > Cc: nanog at nanog.org > > On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews wrote: > > MacOS and Windows can both populate the reverse zone for you as can > > dhcp servers. > > The practice of filling out the reverse zone with fake PTR record [...] > > OK.. let's say you're a DSL provider. Are you going to have your > DHCP server populating the forward and reverse DNS? With what, the > account holder's name? somename.example.com ? I'll suggest that (a) IF the addresses do migrate among different customers of the ISP, (b) the addresses handed out are publicly routable, AND (c) the CPE has to 'authenticate' itself to the head-end, then it is _very_ useful *to*the*ISP* to have dynamically-assigned DNS records of the form: cust.{accountid}.{locationid}.ISP.{com/net/TLD} or something of the sort. Something of that sort can save a -lot- of time/effort in identifying the customer involved in a complaint. From cmadams at hiwaay.net Sun Nov 6 20:45:03 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 6 Nov 2011 20:45:03 -0600 Subject: Performance Issues - PTR Records In-Reply-To: <201111070216.pA72Gd7V047900@mail.r-bonomi.com> References: <201111070216.pA72Gd7V047900@mail.r-bonomi.com> Message-ID: <20111107024502.GA20080@hiwaay.net> Once upon a time, Robert Bonomi said: > I'll suggest that (a) IF the addresses do migrate among different customers > of the ISP, (b) the addresses handed out are publicly routable, AND (c) the > CPE has to 'authenticate' itself to the head-end, then it is _very_ useful > *to*the*ISP* to have dynamically-assigned DNS records of the form: > cust.{accountid}.{locationid}.ISP.{com/net/TLD} > or something of the sort. Putting a customer ID in reverse DNS would probably be a violation of privacy policies. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From richard.barnes at gmail.com Sun Nov 6 20:45:33 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Mon, 7 Nov 2011 03:45:33 +0100 Subject: Historical records of IP allocations In-Reply-To: <4EB6CB74.6060003@gmail.com> References: <4EB6CB74.6060003@gmail.com> Message-ID: Sounds like a good application for INRDB: RIPEstat also has at least its routing history, back as far as 2006: On Sun, Nov 6, 2011 at 7:01 PM, Louis P wrote: > Hello, > Does anyone know if it's possible to get old records (AS numbers...) of an > IP allocation ? > I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/ > But only the country and allocation date are included. > > The IP range I would like to have more information about is 109.190.0.0/17 > (it was Russian before and now French). > > Thanks in advance, > Regards, > Louis P. > > From tom+nanog at oneshoeco.com Sun Nov 6 20:51:29 2011 From: tom+nanog at oneshoeco.com (Tom Lanyon) Date: Mon, 7 Nov 2011 13:21:29 +1030 Subject: Performance Issues - PTR Records In-Reply-To: <201111070216.pA72Gd7V047900@mail.r-bonomi.com> References: <201111070216.pA72Gd7V047900@mail.r-bonomi.com> Message-ID: <06E4635F-2601-468B-832B-C10EE351117E@oneshoeco.com> On 07/11/2011, at 12:46 PM, Robert Bonomi wrote: >> OK.. let's say you're a DSL provider. Are you going to have your >> DHCP server populating the forward and reverse DNS? With what, the >> account holder's name? somename.example.com ? > > I'll suggest that (a) IF the addresses do migrate among different customers > of the ISP, (b) the addresses handed out are publicly routable, AND (c) the > CPE has to 'authenticate' itself to the head-end, then it is _very_ useful > *to*the*ISP* to have dynamically-assigned DNS records of the form: > cust.{accountid}.{locationid}.ISP.{com/net/TLD} > or something of the sort. > > Something of that sort can save a -lot- of time/effort in identifying the > customer involved in a complaint. Surely that's only useful if they're still allocated the address at the time of investigating said complaint; a dynamically updating DNS record like this is really no substitution for accurate accounting records in your RADIUS system. Tom From marka at isc.org Sun Nov 6 21:19:35 2011 From: marka at isc.org (Mark Andrews) Date: Mon, 07 Nov 2011 14:19:35 +1100 Subject: Performance Issues - PTR Records In-Reply-To: Your message of "Sun, 06 Nov 2011 19:57:51 MDT." References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org> <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net> <20111107011021.5CEB316CD13E@drugs.dv.isc.org> Message-ID: <20111107031935.1A29416D3DA6@drugs.dv.isc.org> In message , Jimmy Hess writes: > On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews wrote: > > MacOS and Windows can both populate the reverse zone for you as can > > dhcp servers. > > The practice of filling out the reverse zone with fake PTR record [...] > > OK.. let's say you're a DSL provider. Are you going to have your > DHCP server populating the forward and reverse DNS? With what, the > account holder's name? somename.example.com ? With what the machine told you to populate it with. If the hostname isn't specified in the request uses your default naming scheme. > Wouldn't you say blahblah192-168-0-2.city.state.dsl.example.com > provides more useful information? No. > First of all, you know that the IP address is an end user, an access > network's end user's one IP address, > an endpoint, rather than a subnet assigned to an actual multinode network. Is it? Even today with IPv4 you don't have to hand out single addresses to customers. > Second of all, you know it's an ISP, and you have city and state > information of the network service. > This is more useful than arbitrary user made up hostname. In your opinion. It may not be in the customer's opinion and they are the ones leasing the address. > The hostname is more meaningful on "real networks" such as SMB LANs, > Enterprise intranets, web farms, server networks, and other places > where generic records should not be assigned, but the PTR should be > the actual hostname. New flash. "real networks" already exist in homes. The only reason they arn't visible outside the home is that ISP's have been ridiculously slow in making IPv6 available to the homes and with that the potential for directly address machines. > If the IP address is dynamic or autoconfigured for _those_ types of > networks, then yes, automatic RDNS registration makes sense. If it's > static, not so much. > Dynamic DNS registration is also complicated to make secure.... as > in preventing hosts from updating other hosts' records or mucking > around the zone in other unwanted ways requires complex key > management and ACL configuration No. It's not really complicated to make secure. It's quite possible to prevent machines muking up others records. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From brett at the-watsons.org Sun Nov 6 22:43:11 2011 From: brett at the-watsons.org (Brett Watson) Date: Sun, 6 Nov 2011 21:43:11 -0700 Subject: Performance Issues - PTR Records In-Reply-To: References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org> <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net> <20111107011021.5CEB316CD13E@drugs.dv.isc.org> Message-ID: On Nov 6, 2011, at 6:57 PM, Jimmy Hess wrote: > On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews wrote: >> MacOS and Windows can both populate the reverse zone for you as can >> dhcp servers. >> The practice of filling out the reverse zone with fake PTR record [...] > > OK.. let's say you're a DSL provider. Are you going to have your > DHCP server populating the forward and reverse DNS? With what, the > account holder's name? somename.example.com ? Is this discussion seriously happening, again? Really? I don't think it's been 2 full months since the last round. From paul4004 at gmail.com Sun Nov 6 22:48:34 2011 From: paul4004 at gmail.com (PC) Date: Sun, 6 Nov 2011 21:48:34 -0700 Subject: IPv6 beta support for Android phones In-Reply-To: <1320597177.6199.8.camel@teh-desktop> References: <1320597177.6199.8.camel@teh-desktop> Message-ID: Is there any way this beta can be used in conjunction with other t-mobile data products (such as pre or post paid SIMs used in data cards/USB dongles)? On Sun, Nov 6, 2011 at 9:32 AM, Tom Hill wrote: > On Fri, 2011-11-04 at 15:04 -0700, Cameron Byrne wrote: > > FYI. > > > > T-Mobile USA now has opt-in beta support for an Android phone on IPv6, > > more info here https://sites.google.com/site/tmoipv6/lg-mytouch > > Very, very good. I hope T-Mobile UK (and elsewhere in the world) take > heed. > > I have to wonder why they've chosen to go with IPv6-only & DNS/NAT64 > instead of a dual-stack approach. Is there a particular restriction that > prevents this? > > > As far as i know, this is the first Android phone that support IPv6 on > > the GSM/UMTS mobile interface. Previous version of Android phones > > supported IPv6 on WiFi and LTE. > > Indeed, the 'Network Info II' application will show you the IPv6 > addresses gained on WiFi interfaces (if anyone's interested). My Galaxy > S (unlocked/orig.) does this very well. > > I wonder if it's possible to provide IPv6 support for UMTS/GSM via > firmware and/or software updates from Samsung? > > Tom > > > From cb.list6 at gmail.com Sun Nov 6 23:31:48 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 6 Nov 2011 21:31:48 -0800 Subject: IPv6 beta support for Android phones In-Reply-To: <1320597177.6199.8.camel@teh-desktop> References: <1320597177.6199.8.camel@teh-desktop> Message-ID: On Sun, Nov 6, 2011 at 8:32 AM, Tom Hill wrote: > On Fri, 2011-11-04 at 15:04 -0700, Cameron Byrne wrote: >> FYI. >> >> T-Mobile USA now has opt-in beta support for an Android phone on IPv6, >> more info here https://sites.google.com/site/tmoipv6/lg-mytouch > > Very, very good. I hope T-Mobile UK (and elsewhere in the world) take > heed. > > I have to wonder why they've chosen to go with IPv6-only & DNS/NAT64 > instead of a dual-stack approach. Is there a particular restriction that > prevents this? > There are a variety of reasons. Most prominent is that if the issue is lack of IPv4 addresses (public and private), dual-stack does not solve this problem, each device still gets an IPv4 address. Another major issue is that in GSM/UMTS (3GPP pre-release 9), having dual-stack means having 2 attachments to the network, one for v4 and one for v6. Most mobile providers pay for most of their network kit in terms of these attachments known as PDP. Consequently, dual-stack doubles the of the packet-core network. If we take the licensing and contractual parts out of the equations, double the attachments means double the signalling and mobility events ... resulting in double the CPU / Memory / blah ... LTE does not have the dual attachment problem since there is the concept of having v4 and v6 in one attachment, but it does not change the fact that there are not enough IPv4 addresses to go around, especially from a strategic planning perspective (let's design this once for 5 to 10+ year life ...) >> As far as i know, this is the first Android phone that support IPv6 on >> the GSM/UMTS mobile interface. ?Previous version of Android phones >> supported IPv6 on WiFi and LTE. > > Indeed, the 'Network Info II' application will show you the IPv6 > addresses gained on WiFi interfaces (if anyone's interested). My Galaxy > S (unlocked/orig.) does this very well. > > I wonder if it's possible to provide IPv6 support for UMTS/GSM via > firmware and/or software updates from Samsung? > That's a good question for Samsung. Most vendors would rather have you buy a new device :( CB > Tom > > > From dhubbard at dino.hostasaurus.com Mon Nov 7 00:14:29 2011 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Mon, 7 Nov 2011 01:14:29 -0500 Subject: Cell-based OOB management devices Message-ID: Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David From sethm at rollernet.us Mon Nov 7 00:21:33 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 06 Nov 2011 22:21:33 -0800 Subject: Cell-based OOB management devices In-Reply-To: References: Message-ID: <4EB778ED.3010702@rollernet.us> On 11/6/11 10:14 PM, David Hubbard wrote: > Hi all, I am looking at cellular-based devices as a higher > speed alternative to dial-up backup access methods for > out of band management during emergencies. I was > wondering if anyone had experiences with such devices > they could share? > > Devices I've found include Sierra Wireless AirLink Raven X, > Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I > have no experience with any but they all appear to support > the Sprint network which I assume would be ideal due to > not having usage caps on data (currently). The Opengear > device runs linux and has four serial ports, a usb port > for additional storage and ethernet, so it seems to have > some small advantages over the others since it could double > as an emergency self-contained management station you can > SSH into and run diagnostics from. All appear to have > VPN/gateway support. > > What none of them are clear on is how you would connect > to it over cellular since I assume you're just paying for > a typical data plan and it will randomly obtain IP > addresses. Maybe some type of dynamic dns service so you > can easily figure out your device's current IP? How > stable is the access to the device? Any idea if any of > them can do ipv6? > With the Cisco 3G WIC cards they'll do a static IP or a tunnel. I'd presume something similar can be done with other options if you ask. ~Seth From rdobbins at arbor.net Mon Nov 7 00:21:31 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 7 Nov 2011 06:21:31 +0000 Subject: Cell-based OOB management devices In-Reply-To: References: Message-ID: On Nov 7, 2011, at 1:14 PM, David Hubbard wrote: > Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for > out of band management during emergencies. Some of the lower-end Cisco routers have '3G' interfaces available as an option, I believe. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From lucas at cs.ucla.edu Mon Nov 7 00:34:05 2011 From: lucas at cs.ucla.edu (Lucas Wang) Date: Sun, 6 Nov 2011 22:34:05 -0800 Subject: Historical records of IP allocations In-Reply-To: <0737E427-68A2-4AC6-8F7A-1B2B81D45AC3@cs.ucla.edu> References: <4EB6CB74.6060003@gmail.com> <0737E427-68A2-4AC6-8F7A-1B2B81D45AC3@cs.ucla.edu> Message-ID: We started keeping track of whois databases from March 20th this year, and our earliest data shows it belongs to a Russian company called DIMEDIA LLC. Now the latest whois shows it belongs to "OVH Telecom" located in France. On Nov 6, 2011, at 10:58 AM, Louis P wrote: > Hello, > Does anyone know if it's possible to get old records (AS numbers...) of an IP allocation ? > I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/ > But only the country and allocation date are included. > > The IP range I would like to have more information about is 109.190.0.0/17 (it was Russian before and now French). > > Thanks in advance, > Regards, > Louis P. From bjorn at mork.no Mon Nov 7 00:50:48 2011 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Mon, 07 Nov 2011 07:50:48 +0100 Subject: Performance Issues - PTR Records In-Reply-To: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> (Mark Andrews's message of "Mon, 07 Nov 2011 12:10:21 +1100") References: <80cdf68e-c9b5-42bb-bfc0-bebfc0cb83d0@mail.pelican.org> <20111105024443.60D3DC18F5B@fafnir.remote.dragon.net> <20111107011021.5CEB316CD13E@drugs.dv.isc.org> Message-ID: <87ty6g1l4n.fsf@nemi.mork.no> Mark Andrews writes: > The practice of filling out the reverse zone with fake PTR record > started before there was wide spread support for UPDATE/DNS. There > isn't any need for this to be done anymore. Machines are capable > of adding records for themselves. How do I setup this for DHCPv6-PD? Say, I delegate 2001:db8:42::/48 to the end user. Should I delegate reverse DNS as well? If so, to whom? Or is it the CPEs responibility to dynamically add records for whatever addresses it sees on the internal LAN(s)? Are there CPEs capable of doing this? Or will the end systems themselves do the update against my DNS server? If so, how do I authenticate that? Bj?rn From swmike at swm.pp.se Mon Nov 7 01:02:34 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 7 Nov 2011 08:02:34 +0100 (CET) Subject: IPv6 beta support for Android phones In-Reply-To: References: <1320597177.6199.8.camel@teh-desktop> Message-ID: On Sun, 6 Nov 2011, Cameron Byrne wrote: > LTE does not have the dual attachment problem since there is the concept > of having v4 and v6 in one attachment, but it does not change the fact > that there are not enough IPv4 addresses to go around, especially from a > strategic planning perspective (let's design this once for 5 to 10+ year > life ...) Actually, GTPv2 with v4v6 bearer works in GSM/UMTS as well, but one has to software upgrade all components to make sure it's supported. Unfortunately this is still a future roadmap item for a lot of vendors. This of course needs to be supported in the end user devices as well, but the LTE dongles when in 2G/3G will hopefully still support this. -- Mikael Abrahamsson email: swmike at swm.pp.se From bonomi at mail.r-bonomi.com Mon Nov 7 01:09:19 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 7 Nov 2011 01:09:19 -0600 (CST) Subject: Performance Issues - PTR Records In-Reply-To: <06E4635F-2601-468B-832B-C10EE351117E@oneshoeco.com> Message-ID: <201111070709.pA779JpT049171@mail.r-bonomi.com> Tom Lanyon opined: > >> OK.. let's say you're a DSL provider. Are you going to have your > >> DHCP server populating the forward and reverse DNS? With what, the > >> account holder's name? somename.example.com ? > > > > I'll suggest that (a) IF the addresses do migrate among different customers > > of the ISP, (b) the addresses handed out are publicly routable, AND (c) the > > CPE has to 'authenticate' itself to the head-end, then it is _very_ useful > > *to*the*ISP* to have dynamically-assigned DNS records of the form: > > cust.{accountid}.{locationid}.ISP.{com/net/TLD} > > or something of the sort. > > > > Something of that sort can save a -lot- of time/effort in identifying the > > customer involved in a complaint. > > Surely that's only useful if they're still allocated the address at the time > of investigating said complaint; a dynamically updating DNS record like thi > s is really no substitution for accurate accounting records in your RADIUS s > ystem. You're missing some 'obvious' considerations. Consider a spam complaint sent with 'full headers' included. The rDNS _at_the_time_of_the_crime_ is present in the complaint. Yes, you need to confirm that -that- customer was on that IP at that time -- but having an identifier for the customer makes the verification check much quicker/simpler, and requires less skils on the part of the front-line person dealing with the complaint. No, it doesn't *always* provide a short-cut to identification, but it is useful "often enough' to be well worth considering. From Valdis.Kletnieks at vt.edu Mon Nov 7 01:34:17 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 07 Nov 2011 02:34:17 -0500 Subject: Performance Issues - PTR Records In-Reply-To: Your message of "Mon, 07 Nov 2011 01:09:19 CST." <201111070709.pA779JpT049171@mail.r-bonomi.com> References: <201111070709.pA779JpT049171@mail.r-bonomi.com> Message-ID: <22432.1320651257@turing-police.cc.vt.edu> On Mon, 07 Nov 2011 01:09:19 CST, Robert Bonomi said: > You're missing some 'obvious' considerations. Consider a spam complaint > sent with 'full headers' included. The rDNS _at_the_time_of_the_crime_ > is present in the complaint. And if the rDNS isn't provided, any sane MTA will have included the IP address and timestamp involved, which shouldn't take you all *that* much longer to track down to one of your users. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mysidia at gmail.com Mon Nov 7 02:51:07 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 7 Nov 2011 02:51:07 -0600 Subject: Performance Issues - PTR Records In-Reply-To: <22432.1320651257@turing-police.cc.vt.edu> References: <201111070709.pA779JpT049171@mail.r-bonomi.com> <22432.1320651257@turing-police.cc.vt.edu> Message-ID: On Mon, Nov 7, 2011 at 1:34 AM, wrote: > On Mon, 07 Nov 2011 01:09:19 CST, Robert Bonomi said: >> You're missing some 'obvious' considerations. ?Consider a spam complaint >> sent with 'full headers' included. ?The rDNS _at_the_time_of_the_crime_ >> is present in the complaint. > And if the rDNS isn't provided, any sane MTA will have included the IP address > and timestamp involved, which shouldn't take you all *that* much longer to > track down to one of your users. I wouldn't take for granted that "IP address plus timestamp" can be used to track down a user after the fact. This is not always the case, plenty of times it is not; the user may not be logged on anymore, and there might be no historical data available, or the lifetime of the historical data short enough, that it expired before the complaint came in, possibly 24 hours or more later. Especially not on shared LANs, where an unruly user might actually select some random IP address and use it without permission. The RDNS will help in some of those cases if you don't keep/have sufficient information to identify a user by IP address, if your ability to create a mapping is unreliable... for example, you can't really be sure about accurate clock synchronization in the timestamps of the MTAs to any detail info you may have. But even with RDNS there is still a matching problem... DNS records have TTLs. The old mapping for an IP address can live in a cache for a significant amount of time. Sometimes unruly DNS servers or unruly applications fail to correctly implement DNS, and wind up holding a record past its TTL... an "old PTR mapping" for the IP address may be reported in message headers. The result can be a previous customer's ID in such a scheme would appear in the complaint. Now I suppose you could include another piece of info in the reverse record .registeredat.checksum And then if the purported timestamp in the complaint is after the 'next DNS record registration time' + TTL you know that the RDNS on the complaint listed is invalid To maintain integrity in that case... you would need to ensure the IP address could not be recycled to another user before all DNS records cached at the logoff time + DNS registration interval expired. -- -JH From leigh.porter at ukbroadband.com Mon Nov 7 03:08:13 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 7 Nov 2011 09:08:13 +0000 Subject: IPv6 beta support for Android phones In-Reply-To: References: <1320597177.6199.8.camel@teh-desktop> Message-ID: > > LTE does not have the dual attachment problem since there is the > concept of having v4 and v6 in one attachment, but it does not change > the fact that there are not enough IPv4 addresses to go around, > especially from a strategic planning perspective (let's design this > once for 5 to 10+ year life ...) > Most networks seem to dish out address space behind a LSN box these days. I have three dongle things from three networks in the UK, none of them give me a public address. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From tom at ninjabadger.net Mon Nov 7 03:54:14 2011 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 07 Nov 2011 09:54:14 +0000 Subject: IPv6 beta support for Android phones In-Reply-To: References: <1320597177.6199.8.camel@teh-desktop> Message-ID: <1320659656.2054.0.camel@teh-desktop> Hi Cameron, On Sun, 2011-11-06 at 21:31 -0800, Cameron Byrne wrote: > > There are a variety of reasons. Most prominent is that if the issue > is lack of IPv4 addresses (public and private), dual-stack does not > solve this problem, each device still gets an IPv4 address. Another > major issue is that in GSM/UMTS (3GPP pre-release 9), having > dual-stack means having 2 attachments to the network, one for v4 and > one for v6. Most mobile providers pay for most of their network kit > in terms of these attachments known as PDP. Consequently, dual-stack > doubles the of the packet-core network. If we take the licensing and > contractual parts out of the equations, double the attachments means > double the signalling and mobility events ... resulting in double the > CPU / Memory / blah ... That'll probably explain it... Thanks. :) > LTE does not have the dual attachment problem since there is the > concept of having v4 and v6 in one attachment, but it does not change > the fact that there are not enough IPv4 addresses to go around, > especially from a strategic planning perspective (let's design this > once for 5 to 10+ year life ...) If only the UK was as far ahead on LTE as the US! Tom From sthaug at nethelp.no Mon Nov 7 07:46:48 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 07 Nov 2011 14:46:48 +0100 (CET) Subject: Performance Issues - PTR Records In-Reply-To: <87ty6g1l4n.fsf@nemi.mork.no> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> Message-ID: <20111107.144648.74734213.sthaug@nethelp.no> > > The practice of filling out the reverse zone with fake PTR record > > started before there was wide spread support for UPDATE/DNS. There > > isn't any need for this to be done anymore. Machines are capable > > of adding records for themselves. > > How do I setup this for DHCPv6-PD? Say, I delegate 2001:db8:42::/48 to > the end user. Should I delegate reverse DNS as well? If so, to whom? > > Or is it the CPEs responibility to dynamically add records for whatever > addresses it sees on the internal LAN(s)? Are there CPEs capable of > doing this? > > Or will the end systems themselves do the update against my DNS server? > If so, how do I authenticate that? With my ISP hat on, I find the idea of customer CPEs updating their own PTR records to be completely unacceptable. So I guess I'll either live without the reverse DNS, or use a name server that can synthesize answers on the fly. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jeremyparr at gmail.com Mon Nov 7 07:47:23 2011 From: jeremyparr at gmail.com (Jeremy Parr) Date: Mon, 7 Nov 2011 08:47:23 -0500 Subject: Performance Issues - PTR Records In-Reply-To: References: Message-ID: On 2 November 2011 17:57, Matt Chung wrote: > I work for a regional ISP and very recently there has been an influx of > calls reporting "slowness" when accessing certain websites (i.e > google.com/voice/b) via HTTP. *snip* > I have been experiencing this same issue as an end user, my ISP does not provide PTR records for their address pools. YouTube, xkcd, Mozilla.org, among others, are slow to load initially. Coming from AS15146 here. From leigh.porter at ukbroadband.com Mon Nov 7 07:52:46 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 7 Nov 2011 13:52:46 +0000 Subject: Performance Issues - PTR Records In-Reply-To: <20111107.144648.74734213.sthaug@nethelp.no> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no>,<20111107.144648.74734213.sthaug@nethelp.no> Message-ID: <40117B81-3201-4649-BA7E-C6800D923535@ukbroadband.com> On 7 Nov 2011, at 13:48, "sthaug at nethelp.no" wrote: >>> The practice of filling out the reverse zone with fake PTR record >>> started before there was wide spread support for UPDATE/DNS. There >>> isn't any need for this to be done anymore. Machines are capable >>> of adding records for themselves. >> >> How do I setup this for DHCPv6-PD? Say, I delegate 2001:db8:42::/48 to >> the end user. Should I delegate reverse DNS as well? If so, to whom? >> >> Or is it the CPEs responibility to dynamically add records for whatever >> addresses it sees on the internal LAN(s)? Are there CPEs capable of >> doing this? >> >> Or will the end systems themselves do the update against my DNS server? >> If so, how do I authenticate that? > > With my ISP hat on, I find the idea of customer CPEs updating their > own PTR records to be completely unacceptable. So I guess I'll either > live without the reverse DNS, or use a name server that can synthesize > answers on the fly. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > Indeed, there is no way I would allow that either. But really, providing a reverse zone and forward zone to match is a case of five minutes and a shell script or a DNS that as Steinar said, will synthesise results. It's really not all that difficult.. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From bjorn at mork.no Mon Nov 7 08:00:31 2011 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Mon, 07 Nov 2011 15:00:31 +0100 Subject: Performance Issues - PTR Records In-Reply-To: <40117B81-3201-4649-BA7E-C6800D923535@ukbroadband.com> (Leigh Porter's message of "Mon, 7 Nov 2011 13:52:46 +0000") References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> <20111107.144648.74734213.sthaug@nethelp.no> <40117B81-3201-4649-BA7E-C6800D923535@ukbroadband.com> Message-ID: <87fwi0118g.fsf@nemi.mork.no> Leigh Porter writes: > Indeed, there is no way I would allow that either. But really, > providing a reverse zone and forward zone to match is a case of five > minutes and a shell script or a DNS that as Steinar said, will > synthesise results. > > It's really not all that difficult.. No, not at all. It's just totally pointless. Any IPv6 address is just as pretty as a synthesized name. Maybe even prettier. Do you prefer "2001:db8:1::2" or "20010db8000100000000000000000002.rev.example.com"? If we're going to provide any reverse DNS for end users, then it is because we can create names which actually improves something. Bj?rn From todd at borked.ca Mon Nov 7 09:00:34 2011 From: todd at borked.ca (Todd Snyder) Date: Mon, 7 Nov 2011 10:00:34 -0500 Subject: TATA problems? Message-ID: We seem to be having some problems with our tata links - first seen in EU about 45 minutes ago, now we're seeing problems in NA. I'm focused on DNS, so I'm seeing a lot of timeouts/servfails, but our networking folks are talking about links dropping. Anyone else seeing oddness on the NA Internet right now? http://downrightnow.com/ confirms - something is up. cheers, t. From ppauly at gmail.com Mon Nov 7 09:04:19 2011 From: ppauly at gmail.com (Peter Pauly) Date: Mon, 7 Nov 2011 10:04:19 -0500 Subject: Time Warner Telecom problems Message-ID: Gizmodo is reporting problems at Time Warner Telecom .... we're suffering from it too and calls to the NOC have not been answered so far... does anyone have any further information? http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us From bortzmeyer at nic.fr Mon Nov 7 09:05:34 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 7 Nov 2011 16:05:34 +0100 Subject: TATA problems? In-Reply-To: References: Message-ID: <20111107150534.GA21702@nic.fr> On Mon, Nov 07, 2011 at 10:00:34AM -0500, Todd Snyder wrote a message of 12 lines which said: > We seem to be having some problems with our tata links They probably use Juniper routers :-) From drew.weaver at thenap.com Mon Nov 7 09:05:57 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 7 Nov 2011 10:05:57 -0500 Subject: Time Warner Telecom problems In-Reply-To: References: Message-ID: The current line is Level3 is currently having an issue where they have certain code versions of a certain router vendor deployed. They haven't said anything yet, so it's still kind of sketchy. -----Original Message----- From: Peter Pauly [mailto:ppauly at gmail.com] Sent: Monday, November 07, 2011 10:04 AM To: nanog at nanog.org Subject: Time Warner Telecom problems Gizmodo is reporting problems at Time Warner Telecom .... we're suffering from it too and calls to the NOC have not been answered so far... does anyone have any further information? http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us From tim at interworx.nl Mon Nov 7 09:06:07 2011 From: tim at interworx.nl (Tim Vollebregt) Date: Mon, 07 Nov 2011 16:06:07 +0100 Subject: TATA problems? In-Reply-To: References: Message-ID: <4EB7F3DF.5040006@interworx.nl> Hi, This issue seems to be much bigger, we lost about 20 Level3 and some TATA sessions. Also we lost about 15% of our total traffic. On #IX there are rumours about Junos version 10.3R2.11 being core dumped and rebooted, which makes sense. Currently traffic is restored. Tim On 07-11-11 16:00, Todd Snyder wrote: > We seem to be having some problems with our tata links - first seen in EU > about 45 minutes ago, now we're seeing problems in NA. I'm focused on DNS, > so I'm seeing a lot of timeouts/servfails, but our networking folks are > talking about links dropping. > > Anyone else seeing oddness on the NA Internet right now? > > http://downrightnow.com/ confirms - something is up. > > cheers, > > t. From lane.powers at swat.coop Mon Nov 7 09:06:10 2011 From: lane.powers at swat.coop (Lane Powers) Date: Mon, 07 Nov 2011 09:06:10 -0600 Subject: Time Warner Telecom problems In-Reply-To: Message-ID: L3 reported multiple links bouncing nationwide in the US approx 30 minutes ago. Causing multiple IP issues. Lane -- Lane Powers On 11/7/11 9:04 AM, "Peter Pauly" wrote: >Gizmodo is reporting problems at Time Warner Telecom .... we're suffering >from it too and calls to the NOC have not been answered so far... does >anyone have any further information? > >http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us > From drew.weaver at thenap.com Mon Nov 7 09:08:01 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 7 Nov 2011 10:08:01 -0500 Subject: Time Warner Telecom problems In-Reply-To: References: Message-ID: Any idea where this information can be found publically? -----Original Message----- From: Lane Powers [mailto:lane.powers at swat.coop] Sent: Monday, November 07, 2011 10:06 AM To: Peter Pauly; nanog at nanog.org Subject: Re: Time Warner Telecom problems L3 reported multiple links bouncing nationwide in the US approx 30 minutes ago. Causing multiple IP issues. Lane -- Lane Powers On 11/7/11 9:04 AM, "Peter Pauly" wrote: >Gizmodo is reporting problems at Time Warner Telecom .... we're suffering >from it too and calls to the NOC have not been answered so far... does >anyone have any further information? > >http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us > From Mark.Calkins at twtelecom.com Mon Nov 7 09:09:17 2011 From: Mark.Calkins at twtelecom.com (Calkins, Mark) Date: Mon, 7 Nov 2011 15:09:17 +0000 Subject: Time Warner Telecom problems In-Reply-To: References: Message-ID: <0EB48B40EDC6C643AC36ADE613C78DEF0FEF97B5@SRVMSXMBDEN4.ad.twtelecom.com> I believe you are referring to Time Warner Cable. There is no such thing as Time Warner Telecom anymore. -----Original Message----- From: Peter Pauly [mailto:ppauly at gmail.com] Sent: Monday, November 07, 2011 8:04 AM To: nanog at nanog.org Subject: Time Warner Telecom problems Gizmodo is reporting problems at Time Warner Telecom .... we're suffering from it too and calls to the NOC have not been answered so far... does anyone have any further information? http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us ------------- The content contained in this electronic message is not intended to constitute formation of a contract binding tw telecom. tw telecom will be contractually bound only upon execution, by an authorized officer, of a contract including agreed terms and conditions or by express application of its tariffs. This message is intended only for the use of the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of this E-Mail or by telephone. From lane.powers at swat.coop Mon Nov 7 09:10:18 2011 From: lane.powers at swat.coop (Lane Powers) Date: Mon, 07 Nov 2011 09:10:18 -0600 Subject: Time Warner Telecom problems In-Reply-To: Message-ID: If your an L3 transit customer you should be able to refer to event id 5197215. Not sure if they have published anything otherwise, it is still very early. In our case we had to drop our L3 sessions until the storm passes. Lane On 11/7/11 9:08 AM, "Drew Weaver" wrote: >Any idea where this information can be found publically? > >-----Original Message----- >From: Lane Powers [mailto:lane.powers at swat.coop] >Sent: Monday, November 07, 2011 10:06 AM >To: Peter Pauly; nanog at nanog.org >Subject: Re: Time Warner Telecom problems > >L3 reported multiple links bouncing nationwide in the US approx 30 minutes >ago. Causing multiple IP issues. > > >Lane >-- >Lane Powers > >On 11/7/11 9:04 AM, "Peter Pauly" wrote: > >>Gizmodo is reporting problems at Time Warner Telecom .... we're suffering >>from it too and calls to the NOC have not been answered so far... does >>anyone have any further information? >> >>http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us >> > > > > > From tom at ninjabadger.net Mon Nov 7 09:08:55 2011 From: tom at ninjabadger.net (Tom Hill) Date: Mon, 07 Nov 2011 15:08:55 +0000 Subject: TATA problems? In-Reply-To: References: Message-ID: <1320678667.4104.1.camel@teh-desktop> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: > We seem to be having some problems with our tata links - first seen in EU > about 45 minutes ago, now we're seeing problems in NA. I'm focused on DNS, > so I'm seeing a lot of timeouts/servfails, but our networking folks are > talking about links dropping. > > Anyone else seeing oddness on the NA Internet right now? > > http://downrightnow.com/ confirms - something is up. There are widespread issues across the Internet; certain versions of Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' message. (That's the running theory at least). It's affected multiple service providers, globally, not just those connected to TATA. Tom From jlewis at lewis.org Mon Nov 7 09:12:30 2011 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 7 Nov 2011 10:12:30 -0500 (EST) Subject: Time Warner Telecom problems In-Reply-To: References: Message-ID: On Mon, 7 Nov 2011, Peter Pauly wrote: > Gizmodo is reporting problems at Time Warner Telecom .... we're suffering > from it too and calls to the NOC have not been answered so far... does > anyone have any further information? > > http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us I noticed just a little while ago that we're having a lot of DNS fail. Initial findings were that several of the root-servers we were trying to reach via our TWTelecom link were unreachable after 2 hops into TWT. 4 64-128-130-233.static.twtelecom.NET (64.128.130.233) 2.399 ms 2.298 ms 2.338 ms 5 mia2-pr1-xe-1-3-0-0.us.twtelecom.net (66.192.253.18) 11.571 ms 11.552 ms 9.467 ms 6 * * * 7 * * * 8 * * * For instance, a.root-servers.net is pingable from a rackspace server, but not from our network (unless I shut off TWT, at which point it is, but it's apparently not the same a.root-servers.net instance rackspace sees). I assume this is one of the root-servers being anycast. Shutting off our BGP with TWT didn't appear to help (though the root-servers became reachable)...so I assume there's more going on than just TWT routing fail. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From leigh.porter at ukbroadband.com Mon Nov 7 09:29:30 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 7 Nov 2011 15:29:30 +0000 Subject: Performance Issues - PTR Records In-Reply-To: <87fwi0118g.fsf@nemi.mork.no> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> <20111107.144648.74734213.sthaug@nethelp.no> <40117B81-3201-4649-BA7E-C6800D923535@ukbroadband.com>, <87fwi0118g.fsf@nemi.mork.no> Message-ID: <53A4963F-4969-4A60-BF06-E690C7324863@ukbroadband.com> On 7 Nov 2011, at 14:03, "Bj?rn Mork" wrote: > Leigh Porter writes: > >> Indeed, there is no way I would allow that either. But really, >> providing a reverse zone and forward zone to match is a case of five >> minutes and a shell script or a DNS that as Steinar said, will >> synthesise results. >> >> It's really not all that difficult.. > > No, not at all. It's just totally pointless. Any IPv6 address is just > as pretty as a synthesized name. Maybe even prettier. Do you prefer > "2001:db8:1::2" or "20010db8000100000000000000000002.rev.example.com"? > > If we're going to provide any reverse DNS for end users, then it is > because we can create names which actually improves something. > > > Bj?rn > > Yup it is pointless.. Mine are all ipadrress.domain which is of course, pointless.. I suppose at least somebody would glean that perhaps its a home user rather than a business or server on that address but that's all. With IPv6 arguably even more pointless as you say. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From rvandolson at esri.com Mon Nov 7 09:28:18 2011 From: rvandolson at esri.com (Ray Van Dolson) Date: Mon, 7 Nov 2011 07:28:18 -0800 Subject: Time Warner Telecom problems In-Reply-To: References: Message-ID: <20111107152817.GA29715@esri.com> On Mon, Nov 07, 2011 at 07:04:19AM -0800, Peter Pauly wrote: > Gizmodo is reporting problems at Time Warner Telecom .... we're suffering > from it too and calls to the NOC have not been answered so far... does > anyone have any further information? > > http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us FWIW, my home TWC connection dropped this morning for about 15 minutes (Southern California around 6:30AM'ish). Still could ping the default gateway, but packets weren't traversing much beyond that. Didn't investigate further, just headed into work. Ray From jared at puck.nether.net Mon Nov 7 09:31:31 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 7 Nov 2011 10:31:31 -0500 Subject: General Internet Instability In-Reply-To: <1320678667.4104.1.camel@teh-desktop> References: <1320678667.4104.1.camel@teh-desktop> Message-ID: On Nov 7, 2011, at 10:08 AM, Tom Hill wrote: > On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: >> We seem to be having some problems with our tata links - first seen in EU >> about 45 minutes ago, now we're seeing problems in NA. I'm focused on DNS, >> so I'm seeing a lot of timeouts/servfails, but our networking folks are >> talking about links dropping. >> >> Anyone else seeing oddness on the NA Internet right now? >> >> http://downrightnow.com/ confirms - something is up. > > There are widespread issues across the Internet; certain versions of > Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' > message. > > (That's the running theory at least). > > It's affected multiple service providers, globally, not just those > connected to TATA. Pretty much any major BGP event will impact multiple providers. A threshold you should use to view the general instability (which I find valuable, you may as well) is route views data. If you look at the BGP UPDATES archive sizes, you can see when something happens, e.g.: http://archive.routeviews.org/bgpdata/2011.11/UPDATES/ Take a look at the size of the updates.20111107.1400.bz2 file and the 1415 file. They are abnormally large compared to a normal period of time. This shows there were a lot of updates out there being processed and a reference to levels of instability. If you are not feeding route views or similar community projects, please consider doing so. It helps paint the view for those doing analysis. - Jared From nanog at maunier.org Mon Nov 7 09:33:15 2011 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Mon, 7 Nov 2011 16:33:15 +0100 Subject: TATA problems? In-Reply-To: <1320678667.4104.1.camel@teh-desktop> References: <1320678667.4104.1.camel@teh-desktop> Message-ID: 2011/11/7 Tom Hill > On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: > > We seem to be having some problems with our tata links - first seen in EU > > about 45 minutes ago, now we're seeing problems in NA. I'm focused on > DNS, > > so I'm seeing a lot of timeouts/servfails, but our networking folks are > > talking about links dropping. > > > > Anyone else seeing oddness on the NA Internet right now? > > > > http://downrightnow.com/ confirms - something is up. > > There are widespread issues across the Internet; certain versions of > Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' > message. > > (That's the running theory at least). > > It's affected multiple service providers, globally, not just those > connected to TATA. > > Tom > > > On our side all our 10.3R2.11 core dumped which made all our interfaces flapped. I've been told 10.4R1.9 is affected too. -- Pierre-Yves Maunier From leigh.porter at ukbroadband.com Mon Nov 7 09:45:18 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 7 Nov 2011 15:45:18 +0000 Subject: TATA problems? In-Reply-To: References: <1320678667.4104.1.camel@teh-desktop>, Message-ID: <7994AF08-0622-434F-974F-FC9269469176@ukbroadband.com> My 10.4r1.9 boxes died also but I saw interfaces go down whilst bgpd seemed stable. -- Leigh On 7 Nov 2011, at 15:34, "Pierre-Yves Maunier" wrote: > 2011/11/7 Tom Hill > >> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: >>> We seem to be having some problems with our tata links - first seen in EU >>> about 45 minutes ago, now we're seeing problems in NA. I'm focused on >> DNS, >>> so I'm seeing a lot of timeouts/servfails, but our networking folks are >>> talking about links dropping. >>> >>> Anyone else seeing oddness on the NA Internet right now? >>> >>> http://downrightnow.com/ confirms - something is up. >> >> There are widespread issues across the Internet; certain versions of >> Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' >> message. >> >> (That's the running theory at least). >> >> It's affected multiple service providers, globally, not just those >> connected to TATA. >> >> Tom >> >> >> > On our side all our 10.3R2.11 core dumped which made all our interfaces > flapped. > I've been told 10.4R1.9 is affected too. > > -- > Pierre-Yves Maunier > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From jgreco at ns.sol.net Mon Nov 7 09:54:25 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 7 Nov 2011 09:54:25 -0600 (CST) Subject: Time Warner Telecom problems In-Reply-To: Message-ID: <201111071554.pA7FsPHb045359@aurora.sol.net> > Gizmodo is reporting problems at Time Warner Telecom .... we're suffering > from it too and calls to the NOC have not been answered so far... does > anyone have any further information? > > http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us Actually, it looks to me like they mean "Time Warner", because that's what they said. The company once known as "Time Warner Telecom" has always been a different entity, and hasn't been known as that in some time, now being called "twtelecom." Much of that company is what was once known as inc.net, a Milwaukee area provider of the '90's. Time Warner Cable appears to have experienced an implosion this morning, being out of service for about 11 minutes. During that time, packets originating here in Milwaukee quickly died in Chicago; 1 76.46.192.1 8.320 ms 9.900 ms 7.974 ms 2 24.160.230.32 7.967 ms 5.975 ms 8.479 ms 3 24.160.229.132 8.471 ms 7.969 ms 10.991 ms 4 24.160.229.193 9.972 ms 9.973 ms 24.160.229.197 9.985 ms 5 * * * 6 * * * while packets destined for RR all seemed to be headed out to SJC, from what I can tell. ... 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 kelly at hawknetworks.com Mon Nov 7 09:55:33 2011 From: kelly at hawknetworks.com (Kelly Kane) Date: Mon, 7 Nov 2011 07:55:33 -0800 Subject: TATA problems? In-Reply-To: <4EB7F3DF.5040006@interworx.nl> References: <4EB7F3DF.5040006@interworx.nl> Message-ID: On Mon, Nov 7, 2011 at 07:06, Tim Vollebregt wrote: > > On #IX there are rumours about Junos version 10.3R2.11 being core dumped and > rebooted, which makes sense. Perhaps related to Juniper PSN-2011-08-327? Did the whole router reboot, or just the service module? We saw one TATA session, and one Abovenet session flap. Kelly From blake at ispn.net Mon Nov 7 10:02:13 2011 From: blake at ispn.net (Blake Hudson) Date: Mon, 07 Nov 2011 10:02:13 -0600 Subject: Time Warner Telecom problems In-Reply-To: <201111071554.pA7FsPHb045359@aurora.sol.net> References: <201111071554.pA7FsPHb045359@aurora.sol.net> Message-ID: <4EB80105.8060703@ispn.net> Joe Greco wrote the following on 11/7/2011 9:54 AM: >> Gizmodo is reporting problems at Time Warner Telecom .... we're suffering >> from it too and calls to the NOC have not been answered so far... does >> anyone have any further information? >> >> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us > Actually, it looks to me like they mean "Time Warner", because that's > what they said. > > The company once known as "Time Warner Telecom" has always been a > different entity, and hasn't been known as that in some time, now > being called "twtelecom." Much of that company is what was once > known as inc.net, a Milwaukee area provider of the '90's. > > Time Warner Cable appears to have experienced an implosion this morning, > being out of service for about 11 minutes. During that time, packets > originating here in Milwaukee quickly died in Chicago; Using the looking glass from TWtelecom, we saw 30-60min outage (roughly 8:30AM to 9:30AM CST) between the Kansas City location and our own server room in Kansas City. Other TWtelecom locations appeared to be unaffected. Perhaps TWtelecom is served by Timewarner or shares equipment in KC. Either way, none of our KC customers who were served via TWtelecom or Timewarner were able to reach us. Packets would hit Level 3 Communications and die in either direction at the border between L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa. http://lglass.twtelecom.net/ From straterra at fuhell.com Mon Nov 7 10:04:59 2011 From: straterra at fuhell.com (Thomas York) Date: Mon, 7 Nov 2011 11:04:59 -0500 Subject: Time Warner Telecom problems In-Reply-To: <4EB80105.8060703@ispn.net> References: <201111071554.pA7FsPHb045359@aurora.sol.net> <4EB80105.8060703@ispn.net> Message-ID: FWIW, We saw issues here in Indianapolis between TWTC and L3 up until a few minutes ago. --Thomas York -----Original Message----- From: Blake Hudson [mailto:blake at ispn.net] Sent: Monday, November 07, 2011 11:02 AM To: nanog at nanog.org Subject: Re: Time Warner Telecom problems Joe Greco wrote the following on 11/7/2011 9:54 AM: >> Gizmodo is reporting problems at Time Warner Telecom .... we're >> suffering from it too and calls to the NOC have not been answered so >> far... does anyone have any further information? >> >> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us > Actually, it looks to me like they mean "Time Warner", because that's > what they said. > > The company once known as "Time Warner Telecom" has always been a > different entity, and hasn't been known as that in some time, now > being called "twtelecom." Much of that company is what was once known > as inc.net, a Milwaukee area provider of the '90's. > > Time Warner Cable appears to have experienced an implosion this > morning, being out of service for about 11 minutes. During that time, > packets originating here in Milwaukee quickly died in Chicago; Using the looking glass from TWtelecom, we saw 30-60min outage (roughly 8:30AM to 9:30AM CST) between the Kansas City location and our own server room in Kansas City. Other TWtelecom locations appeared to be unaffected. Perhaps TWtelecom is served by Timewarner or shares equipment in KC. Either way, none of our KC customers who were served via TWtelecom or Timewarner were able to reach us. Packets would hit Level 3 Communications and die in either direction at the border between L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa. http://lglass.twtelecom.net/ From jlewis at lewis.org Mon Nov 7 10:06:57 2011 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 7 Nov 2011 11:06:57 -0500 (EST) Subject: Time Warner Telecom problems In-Reply-To: <0EB48B40EDC6C643AC36ADE613C78DEF0FEF97B5@SRVMSXMBDEN4.ad.twtelecom.com> References: <0EB48B40EDC6C643AC36ADE613C78DEF0FEF97B5@SRVMSXMBDEN4.ad.twtelecom.com> Message-ID: On Mon, 7 Nov 2011, Calkins, Mark wrote: > I believe you are referring to Time Warner Cable. There is no such thing as Time Warner Telecom anymore. It's just TW Telecom now. http://www.twtelecom.com/ ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jpchaba at cs.wisc.edu Mon Nov 7 10:07:52 2011 From: jpchaba at cs.wisc.edu (Joseph Chabarek) Date: Mon, 07 Nov 2011 10:07:52 -0600 Subject: Router and interface naming convention survey Message-ID: <4EB80258.6080501@cs.wisc.edu> I am doing a survey to see what naming conventions are used for routers and router interfaces as part of a measurement study that I am conducting as a student at the University of Wisconsin Madison. If you are interested in participating please fill out my form at: https://docs.google.com/spreadsheet/viewform?formkey=dE1OYmVGcjlxV1YtZjB1QmJ4bmg1aUE6MQ I am aware that this issue has been discussed extensively on nanog (and other lists). The purpose of this survey is to see in a structured manner which networks use which conventions, and get an idea for how automated the process of PTR record generation is across different providers. I am happy to provide high level results from the survey to anyone that is interested. Thanks for any feedback! -Joe http://www.cs.wisc.edu/~jpchaba From cb.list6 at gmail.com Mon Nov 7 10:09:24 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 7 Nov 2011 08:09:24 -0800 Subject: Cell-based OOB management devices In-Reply-To: References: Message-ID: On Nov 6, 2011 10:15 PM, "David Hubbard" wrote: > > Hi all, I am looking at cellular-based devices as a higher > speed alternative to dial-up backup access methods for > out of band management during emergencies. I was > wondering if anyone had experiences with such devices > they could share? > > Devices I've found include Sierra Wireless AirLink Raven X, > Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I > have no experience with any but they all appear to support > the Sprint network which I assume would be ideal due to > not having usage caps on data (currently). The Opengear > device runs linux and has four serial ports, a usb port > for additional storage and ethernet, so it seems to have > some small advantages over the others since it could double > as an emergency self-contained management station you can > SSH into and run diagnostics from. All appear to have > VPN/gateway support. > > What none of them are clear on is how you would connect > to it over cellular since I assume you're just paying for > a typical data plan and it will randomly obtain IP > addresses. Maybe some type of dynamic dns service so you > can easily figure out your device's current IP? How > stable is the access to the device? Any idea if any of > them can do ipv6? > Another good question is if the 3g modem is firewalled by the mobile provider so that incoming connections are blocked. Cb > Thanks! > > David > > From todd at hatescomputers.org Mon Nov 7 10:09:35 2011 From: todd at hatescomputers.org (Todd Snyder) Date: Mon, 7 Nov 2011 11:09:35 -0500 Subject: General Internet Instability In-Reply-To: References: <1320678667.4104.1.camel@teh-desktop> Message-ID: Can anyone point to any authoritative updates about this? On Mon, Nov 7, 2011 at 10:31 AM, Jared Mauch wrote: > On Nov 7, 2011, at 10:08 AM, Tom Hill wrote: > > > On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: > >> We seem to be having some problems with our tata links - first seen in > EU > >> about 45 minutes ago, now we're seeing problems in NA. I'm focused on > DNS, > >> so I'm seeing a lot of timeouts/servfails, but our networking folks are > >> talking about links dropping. > >> > >> Anyone else seeing oddness on the NA Internet right now? > >> > >> http://downrightnow.com/ confirms - something is up. > > > > There are widespread issues across the Internet; certain versions of > > Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' > > message. > > > > (That's the running theory at least). > > > > It's affected multiple service providers, globally, not just those > > connected to TATA. > > > Pretty much any major BGP event will impact multiple providers. > > A threshold you should use to view the general instability (which I find > valuable, you may as well) is route views data. > > If you look at the BGP UPDATES archive sizes, you can see when something > happens, e.g.: > > http://archive.routeviews.org/bgpdata/2011.11/UPDATES/ > > Take a look at the size of the updates.20111107.1400.bz2 file and the 1415 > file. They are abnormally large compared to a normal period of time. This > shows there were a lot of updates out there being processed and a reference > to levels of instability. > > If you are not feeding route views or similar community projects, please > consider doing so. It helps paint the view for those doing analysis. > > - Jared > From accesss801 at gmail.com Mon Nov 7 10:08:42 2011 From: accesss801 at gmail.com (Dan) Date: Mon, 7 Nov 2011 09:08:42 -0700 Subject: TATA problems? In-Reply-To: References: <4EB7F3DF.5040006@interworx.nl> Message-ID: <2CC473DD-67DA-425C-A47C-0E33222E8ABA@gmail.com> We got a panic message about the PFE that core'd and looks like it restarted our FPC's. JUNOS 10.2R2.11 -Dan On Nov 7, 2011, at 8:55 AM, Kelly Kane wrote: > On Mon, Nov 7, 2011 at 07:06, Tim Vollebregt wrote: >> >> On #IX there are rumours about Junos version 10.3R2.11 being core dumped and >> rebooted, which makes sense. > > Perhaps related to Juniper PSN-2011-08-327? Did the whole router > reboot, or just the service module? > > We saw one TATA session, and one Abovenet session flap. > > Kelly > From bhmccie at gmail.com Mon Nov 7 10:14:32 2011 From: bhmccie at gmail.com (-Hammer-) Date: Mon, 07 Nov 2011 10:14:32 -0600 Subject: General Internet Instability In-Reply-To: References: <1320678667.4104.1.camel@teh-desktop> Message-ID: <4EB803E8.5070805@gmail.com> I'm struggling to do the same. All the various "Internet Health" sites show(ed) some upticks in negative performance but I don't have any specifics. We are a Gomez customer and Gomez is showing issues In St. Louis (SAVVIS) and Philly (L3) that specifically impacts the availability of our applications but it's not clear on the underlying reason. I'm giving cautious updates to management because even though it's obvious something is going on I don't have anything official except random email threads. Looking for more insight before misinforming management. -Hammer- "I was a normal American nerd" -Jack Herer On 11/07/2011 10:09 AM, Todd Snyder wrote: > Can anyone point to any authoritative updates about this? > > On Mon, Nov 7, 2011 at 10:31 AM, Jared Mauch wrote: > > >> On Nov 7, 2011, at 10:08 AM, Tom Hill wrote: >> >> >>> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: >>> >>>> We seem to be having some problems with our tata links - first seen in >>>> >> EU >> >>>> about 45 minutes ago, now we're seeing problems in NA. I'm focused on >>>> >> DNS, >> >>>> so I'm seeing a lot of timeouts/servfails, but our networking folks are >>>> talking about links dropping. >>>> >>>> Anyone else seeing oddness on the NA Internet right now? >>>> >>>> http://downrightnow.com/ confirms - something is up. >>>> >>> There are widespread issues across the Internet; certain versions of >>> Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' >>> message. >>> >>> (That's the running theory at least). >>> >>> It's affected multiple service providers, globally, not just those >>> connected to TATA. >>> >> >> Pretty much any major BGP event will impact multiple providers. >> >> A threshold you should use to view the general instability (which I find >> valuable, you may as well) is route views data. >> >> If you look at the BGP UPDATES archive sizes, you can see when something >> happens, e.g.: >> >> http://archive.routeviews.org/bgpdata/2011.11/UPDATES/ >> >> Take a look at the size of the updates.20111107.1400.bz2 file and the 1415 >> file. They are abnormally large compared to a normal period of time. This >> shows there were a lot of updates out there being processed and a reference >> to levels of instability. >> >> If you are not feeding route views or similar community projects, please >> consider doing so. It helps paint the view for those doing analysis. >> >> - Jared >> >> From jrex at CS.Princeton.EDU Mon Nov 7 10:16:52 2011 From: jrex at CS.Princeton.EDU (Jennifer Rexford) Date: Mon, 7 Nov 2011 11:16:52 -0500 Subject: Router and interface naming convention survey In-Reply-To: <4EB80258.6080501@cs.wisc.edu> References: <4EB80258.6080501@cs.wisc.edu> Message-ID: Joe, > I am doing a survey to see what naming conventions are used for routers and router interfaces as part of a measurement study On a related note, you might be interested in a study we did a few years ago about errors in naming router interfaces, where a router in one location has a name suggestive of a different location (e.g., because a network administrator did not update the DNS entries for the interface names). See Ming Zhang, Yaoping Ruan, Vivek Pai, and Jennifer Rexford, "How DNS misnaming distorts Internet topology mapping," Proc. USENIX Annual Technical Conference, May/June 2006. http://www.cs.princeton.edu/~jrex/papers/dns06.pdf http://www.cs.princeton.edu/~jrex/talks/dns06.ppt In particular, we found that a few "errors" in the DNS names for router interfaces could lead to significant distortions in measurement studies -- e.g., a study might wrongly conclude that path inflation is very high because traceroute measurements wrongly suggested that the traffic traverses a particular sequence of cities... Best wishes... -- Jen From rgolodner at infratection.com Mon Nov 7 10:27:07 2011 From: rgolodner at infratection.com (Richard Golodner) Date: Mon, 07 Nov 2011 10:27:07 -0600 Subject: General Internet Instability In-Reply-To: References: <1320678667.4104.1.camel@teh-desktop> Message-ID: <1320683227.2220.108.camel@Andromeda> On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote: > Can anyone point to any authoritative updates about this? I think Jared's suggestion was about as close as your going to get for right now. Look at the size of the files he mentioned as compared to the average size of the others. Hopefully someone will come forth with an authoritative answer later today. Richard Golodner From jared at puck.nether.net Mon Nov 7 10:37:47 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 7 Nov 2011 11:37:47 -0500 Subject: General Internet Instability In-Reply-To: <1320683227.2220.108.camel@Andromeda> References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda> Message-ID: On Nov 7, 2011, at 11:27 AM, Richard Golodner wrote: > On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote: >> Can anyone point to any authoritative updates about this? > > I think Jared's suggestion was about as close as your going to get for > right now. Look at the size of the files he mentioned as compared to the > average size of the others. > Hopefully someone will come forth with an authoritative answer later > today. > Richard Golodner > One can do some analysis of the files to determine what prefixes and autonomous system neighbors were impacted. I can do some of this as I have some other tools that quickly process this data if people are interested. Please send those replies/votes off list to me directly. - Jared From todd at hatescomputers.org Mon Nov 7 10:40:03 2011 From: todd at hatescomputers.org (Todd Snyder) Date: Mon, 7 Nov 2011 11:40:03 -0500 Subject: General Internet Instability In-Reply-To: <1320683227.2220.108.camel@Andromeda> References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda> Message-ID: On Mon, Nov 7, 2011 at 11:27 AM, Richard Golodner < rgolodner at infratection.com> wrote: > On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote: > > Can anyone point to any authoritative updates about this? > > I think Jared's suggestion was about as close as your going to get > for > right now. Look at the size of the files he mentioned as compared to the > average size of the others. > Hopefully someone will come forth with an authoritative answer later > today. > Richard Golodner > > Management don't understand or care about BGP updates, they just want to know if the problem is ours, and if it's not, who to blame :) thank goodness for NANOG - updates here have been helpful explaining things to management. t. From dispensa at phonefactor.com Mon Nov 7 10:41:59 2011 From: dispensa at phonefactor.com (Steve Dispensa) Date: Mon, 7 Nov 2011 10:41:59 -0600 Subject: NANOG Digest, Vol 46, Issue 15 In-Reply-To: References: Message-ID: <0F7F9A82BB0DBB4396A9F8386D0E0612071F65A3@pos-exch1.corp.positivenetworks.net> Level 3 was down in KC, Chi, and San Jose (at least) for us between about 8:10 and 8:40, plus or minus. Brought down SureWest in KC too. -Steve > -----Original Message----- > From: nanog-request at nanog.org [mailto:nanog-request at nanog.org] > Sent: Monday, November 07, 2011 10:05 AM > To: nanog at nanog.org > Subject: NANOG Digest, Vol 46, Issue 15 > > 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: Time Warner Telecom problems (Jon Lewis) > 2. Re: Performance Issues - PTR Records (Leigh Porter) > 3. Re: Time Warner Telecom problems (Ray Van Dolson) > 4. General Internet Instability (Jared Mauch) > 5. Re: TATA problems? (Pierre-Yves Maunier) > 6. Re: TATA problems? (Leigh Porter) > 7. Re: Time Warner Telecom problems (Joe Greco) > 8. Re: TATA problems? (Kelly Kane) > 9. Re: Time Warner Telecom problems (Blake Hudson) > 10. RE: Time Warner Telecom problems (Thomas York) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Nov 2011 10:12:30 -0500 (EST) > From: Jon Lewis > To: Peter Pauly > Cc: nanog at nanog.org > Subject: Re: Time Warner Telecom problems > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Mon, 7 Nov 2011, Peter Pauly wrote: > > > Gizmodo is reporting problems at Time Warner Telecom .... we're > suffering > > from it too and calls to the NOC have not been answered so far... does > > anyone have any further information? > > > > http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us > > I noticed just a little while ago that we're having a lot of DNS fail. > Initial findings were that several of the root-servers we were trying to > reach via our TWTelecom link were unreachable after 2 hops into TWT. > > 4 64-128-130-233.static.twtelecom.NET (64.128.130.233) 2.399 ms 2.298 > ms 2.338 ms > 5 mia2-pr1-xe-1-3-0-0.us.twtelecom.net (66.192.253.18) 11.571 ms > 11.552 ms 9.467 ms > 6 * * * > 7 * * * > 8 * * * > > For instance, a.root-servers.net is pingable from a rackspace server, but > not from our network (unless I shut off TWT, at which point it is, but > it's apparently not the same a.root-servers.net instance rackspace sees). > I assume this is one of the root-servers being anycast. > > Shutting off our BGP with TWT didn't appear to help (though the > root-servers became reachable)...so I assume there's more going on than > just TWT routing fail. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Nov 2011 15:29:30 +0000 > From: Leigh Porter > To: Bj?rn Mork > Cc: "nanog at nanog.org" > Subject: Re: Performance Issues - PTR Records > Message-ID: <53A4963F-4969-4A60-BF06-E690C7324863 at ukbroadband.com> > Content-Type: text/plain; charset="iso-8859-1" > > > > On 7 Nov 2011, at 14:03, "Bj?rn Mork" wrote: > > > Leigh Porter writes: > > > >> Indeed, there is no way I would allow that either. But really, > >> providing a reverse zone and forward zone to match is a case of five > >> minutes and a shell script or a DNS that as Steinar said, will > >> synthesise results. > >> > >> It's really not all that difficult.. > > > > No, not at all. It's just totally pointless. Any IPv6 address is just > > as pretty as a synthesized name. Maybe even prettier. Do you prefer > > "2001:db8:1::2" or "20010db8000100000000000000000002.rev.example.com"? > > > > If we're going to provide any reverse DNS for end users, then it is > > because we can create names which actually improves something. > > > > > > Bj?rn > > > > > > Yup it is pointless.. Mine are all ipadrress.domain which is of course, > pointless.. I suppose at least somebody would glean that perhaps its a > home user rather than a business or server on that address but that's all. > > With IPv6 arguably even more pointless as you say. > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Nov 2011 07:28:18 -0800 > From: Ray Van Dolson > To: nanog at nanog.org > Subject: Re: Time Warner Telecom problems > Message-ID: <20111107152817.GA29715 at esri.com> > Content-Type: text/plain; charset=us-ascii > > On Mon, Nov 07, 2011 at 07:04:19AM -0800, Peter Pauly wrote: > > Gizmodo is reporting problems at Time Warner Telecom .... we're > suffering > > from it too and calls to the NOC have not been answered so far... does > > anyone have any further information? > > > > http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us > > FWIW, my home TWC connection dropped this morning for about 15 minutes > (Southern California around 6:30AM'ish). Still could ping the default > gateway, but packets weren't traversing much beyond that. > > Didn't investigate further, just headed into work. > > Ray > > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Nov 2011 10:31:31 -0500 > From: Jared Mauch > To: Tom Hill > Cc: nanog at nanog.org > Subject: General Internet Instability > Message-ID: > Content-Type: text/plain; charset=us-ascii > > On Nov 7, 2011, at 10:08 AM, Tom Hill wrote: > > > On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: > >> We seem to be having some problems with our tata links - first seen in > EU > >> about 45 minutes ago, now we're seeing problems in NA. I'm focused on > DNS, > >> so I'm seeing a lot of timeouts/servfails, but our networking folks are > >> talking about links dropping. > >> > >> Anyone else seeing oddness on the NA Internet right now? > >> > >> http://downrightnow.com/ confirms - something is up. > > > > There are widespread issues across the Internet; certain versions of > > Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' > > message. > > > > (That's the running theory at least). > > > > It's affected multiple service providers, globally, not just those > > connected to TATA. > > > Pretty much any major BGP event will impact multiple providers. > > A threshold you should use to view the general instability (which I find > valuable, you may as well) is route views data. > > If you look at the BGP UPDATES archive sizes, you can see when something > happens, e.g.: > > http://archive.routeviews.org/bgpdata/2011.11/UPDATES/ > > Take a look at the size of the updates.20111107.1400.bz2 file and the 1415 > file. They are abnormally large compared to a normal period of time. > This shows there were a lot of updates out there being processed and a > reference to levels of instability. > > If you are not feeding route views or similar community projects, please > consider doing so. It helps paint the view for those doing analysis. > > - Jared > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Nov 2011 16:33:15 +0100 > From: Pierre-Yves Maunier > To: Tom Hill > Cc: nanog at nanog.org > Subject: Re: TATA problems? > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > 2011/11/7 Tom Hill > > > On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: > > > We seem to be having some problems with our tata links - first seen in > EU > > > about 45 minutes ago, now we're seeing problems in NA. I'm focused on > > DNS, > > > so I'm seeing a lot of timeouts/servfails, but our networking folks > are > > > talking about links dropping. > > > > > > Anyone else seeing oddness on the NA Internet right now? > > > > > > http://downrightnow.com/ confirms - something is up. > > > > There are widespread issues across the Internet; certain versions of > > Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' > > message. > > > > (That's the running theory at least). > > > > It's affected multiple service providers, globally, not just those > > connected to TATA. > > > > Tom > > > > > > > On our side all our 10.3R2.11 core dumped which made all our interfaces > flapped. > I've been told 10.4R1.9 is affected too. > > -- > Pierre-Yves Maunier > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Nov 2011 15:45:18 +0000 > From: Leigh Porter > To: Pierre-Yves Maunier > Cc: "nanog at nanog.org" > Subject: Re: TATA problems? > Message-ID: <7994AF08-0622-434F-974F-FC9269469176 at ukbroadband.com> > Content-Type: text/plain; charset="us-ascii" > > > My 10.4r1.9 boxes died also but I saw interfaces go down whilst bgpd > seemed stable. > > -- > Leigh > > > On 7 Nov 2011, at 15:34, "Pierre-Yves Maunier" wrote: > > > 2011/11/7 Tom Hill > > > >> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: > >>> We seem to be having some problems with our tata links - first seen in > EU > >>> about 45 minutes ago, now we're seeing problems in NA. I'm focused on > >> DNS, > >>> so I'm seeing a lot of timeouts/servfails, but our networking folks > are > >>> talking about links dropping. > >>> > >>> Anyone else seeing oddness on the NA Internet right now? > >>> > >>> http://downrightnow.com/ confirms - something is up. > >> > >> There are widespread issues across the Internet; certain versions of > >> Juniper firmware have core dumped after seeing a particular BGP > 'UPDATE' > >> message. > >> > >> (That's the running theory at least). > >> > >> It's affected multiple service providers, globally, not just those > >> connected to TATA. > >> > >> Tom > >> > >> > >> > > On our side all our 10.3R2.11 core dumped which made all our interfaces > > flapped. > > I've been told 10.4R1.9 is affected too. > > > > -- > > Pierre-Yves Maunier > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > > ------------------------------ > > Message: 7 > Date: Mon, 7 Nov 2011 09:54:25 -0600 (CST) > From: Joe Greco > To: ppauly at gmail.com (Peter Pauly) > Cc: nanog at nanog.org > Subject: Re: Time Warner Telecom problems > Message-ID: <201111071554.pA7FsPHb045359 at aurora.sol.net> > Content-Type: text/plain; charset=us-ascii > > > Gizmodo is reporting problems at Time Warner Telecom .... we're > suffering > > from it too and calls to the NOC have not been answered so far... does > > anyone have any further information? > > > > http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us > > Actually, it looks to me like they mean "Time Warner", because that's > what they said. > > The company once known as "Time Warner Telecom" has always been a > different entity, and hasn't been known as that in some time, now > being called "twtelecom." Much of that company is what was once > known as inc.net, a Milwaukee area provider of the '90's. > > Time Warner Cable appears to have experienced an implosion this morning, > being out of service for about 11 minutes. During that time, packets > originating here in Milwaukee quickly died in Chicago; > > 1 76.46.192.1 8.320 ms 9.900 ms 7.974 ms > 2 24.160.230.32 7.967 ms 5.975 ms 8.479 ms > 3 24.160.229.132 8.471 ms 7.969 ms 10.991 ms > 4 24.160.229.193 9.972 ms 9.973 ms > 24.160.229.197 9.985 ms > 5 * * * > 6 * * * > > while packets destined for RR all seemed to be headed out to SJC, from > what I can tell. > > ... 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. > > > > ------------------------------ > > Message: 8 > Date: Mon, 7 Nov 2011 07:55:33 -0800 > From: Kelly Kane > To: Tim Vollebregt > Cc: nanog at nanog.org > Subject: Re: TATA problems? > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Mon, Nov 7, 2011 at 07:06, Tim Vollebregt wrote: > > > > On #IX there are rumours about Junos version 10.3R2.11 being core dumped > and > > rebooted, which makes sense. > > Perhaps related to Juniper PSN-2011-08-327? Did the whole router > reboot, or just the service module? > > We saw one TATA session, and one Abovenet session flap. > > Kelly > > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Nov 2011 10:02:13 -0600 > From: Blake Hudson > To: nanog at nanog.org > Subject: Re: Time Warner Telecom problems > Message-ID: <4EB80105.8060703 at ispn.net> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > Joe Greco wrote the following on 11/7/2011 9:54 AM: > >> Gizmodo is reporting problems at Time Warner Telecom .... we're > suffering > >> from it too and calls to the NOC have not been answered so far... does > >> anyone have any further information? > >> > >> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us > > Actually, it looks to me like they mean "Time Warner", because that's > > what they said. > > > > The company once known as "Time Warner Telecom" has always been a > > different entity, and hasn't been known as that in some time, now > > being called "twtelecom." Much of that company is what was once > > known as inc.net, a Milwaukee area provider of the '90's. > > > > Time Warner Cable appears to have experienced an implosion this morning, > > being out of service for about 11 minutes. During that time, packets > > originating here in Milwaukee quickly died in Chicago; > > Using the looking glass from TWtelecom, we saw 30-60min outage (roughly > 8:30AM to 9:30AM CST) between the Kansas City location and our own > server room in Kansas City. Other TWtelecom locations appeared to be > unaffected. Perhaps TWtelecom is served by Timewarner or shares > equipment in KC. Either way, none of our KC customers who were served > via TWtelecom or Timewarner were able to reach us. Packets would hit > Level 3 Communications and die in either direction at the border between > L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa. > http://lglass.twtelecom.net/ > > > > ------------------------------ > > Message: 10 > Date: Mon, 7 Nov 2011 11:04:59 -0500 > From: "Thomas York" > To: "'Blake Hudson'" , > Subject: RE: Time Warner Telecom problems > Message-ID: > Content-Type: text/plain; charset="utf-8" > > FWIW, We saw issues here in Indianapolis between TWTC and L3 up until a > few minutes ago. > > --Thomas York > > -----Original Message----- > From: Blake Hudson [mailto:blake at ispn.net] > Sent: Monday, November 07, 2011 11:02 AM > To: nanog at nanog.org > Subject: Re: Time Warner Telecom problems > > > Joe Greco wrote the following on 11/7/2011 9:54 AM: > >> Gizmodo is reporting problems at Time Warner Telecom .... we're > >> suffering from it too and calls to the NOC have not been answered so > >> far... does anyone have any further information? > >> > >> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us > > Actually, it looks to me like they mean "Time Warner", because that's > > what they said. > > > > The company once known as "Time Warner Telecom" has always been a > > different entity, and hasn't been known as that in some time, now > > being called "twtelecom." Much of that company is what was once known > > as inc.net, a Milwaukee area provider of the '90's. > > > > Time Warner Cable appears to have experienced an implosion this > > morning, being out of service for about 11 minutes. During that time, > > packets originating here in Milwaukee quickly died in Chicago; > > Using the looking glass from TWtelecom, we saw 30-60min outage (roughly > 8:30AM to 9:30AM CST) between the Kansas City location and our own server > room in Kansas City. Other TWtelecom locations appeared to be unaffected. > Perhaps TWtelecom is served by Timewarner or shares equipment in KC. > Either way, none of our KC customers who were served via TWtelecom or > Timewarner were able to reach us. Packets would hit Level 3 Communications > and die in either direction at the border between > L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa. > http://lglass.twtelecom.net/ > > > > > > End of NANOG Digest, Vol 46, Issue 15 > ************************************* From leigh.porter at ukbroadband.com Mon Nov 7 10:43:52 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 7 Nov 2011 16:43:52 +0000 Subject: General Internet Instability In-Reply-To: References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda>, Message-ID: On 7 Nov 2011, at 16:41, "Todd Snyder" wrote: > On Mon, Nov 7, 2011 at 11:27 AM, Richard Golodner < > rgolodner at infratection.com> wrote: > >> On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote: >>> Can anyone point to any authoritative updates about this? >> >> I think Jared's suggestion was about as close as your going to get >> for >> right now. Look at the size of the files he mentioned as compared to the >> average size of the others. >> Hopefully someone will come forth with an authoritative answer later >> today. >> Richard Golodner >> >> > Management don't understand or care about BGP updates, they just want to > know if the problem is ours, and if it's not, who to blame :) > > thank goodness for NANOG - updates here have been helpful explaining things > to management. > > t. > Just blame Shub Internet.. Oh no, I've said it now! -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From bhmccie at gmail.com Mon Nov 7 10:41:13 2011 From: bhmccie at gmail.com (-Hammer-) Date: Mon, 07 Nov 2011 10:41:13 -0600 Subject: General Internet Instability In-Reply-To: <1320683227.2220.108.camel@Andromeda> References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda> Message-ID: <4EB80A29.1070006@gmail.com> So the file size was 30% higher implies that the number of updates is larger and therefore there is instability? I see the logic but if you scroll thru that page (the whole month of November) there are tons of >1M files. Trying to see what is different about today.... -Hammer- "I was a normal American nerd" -Jack Herer On 11/07/2011 10:27 AM, Richard Golodner wrote: > On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote: > >> Can anyone point to any authoritative updates about this? >> > I think Jared's suggestion was about as close as your going to get for > right now. Look at the size of the files he mentioned as compared to the > average size of the others. > Hopefully someone will come forth with an authoritative answer later > today. > Richard Golodner > > > From nanog at maunier.org Mon Nov 7 10:43:43 2011 From: nanog at maunier.org (Pierre-Yves Maunier) Date: Mon, 7 Nov 2011 17:43:43 +0100 Subject: TATA problems? In-Reply-To: References: <4EB7F3DF.5040006@interworx.nl> Message-ID: 2011/11/7 Kelly Kane > On Mon, Nov 7, 2011 at 07:06, Tim Vollebregt wrote: > > > > On #IX there are rumours about Junos version 10.3R2.11 being core dumped > and > > rebooted, which makes sense. > > Perhaps related to Juniper PSN-2011-08-327? Did the whole router > reboot, or just the service module? > > We saw one TATA session, and one Abovenet session flap. > > Kelly > > On our side we did not have any reboot, just a core dump generated and all interfaces flapped. -- Pierre-Yves Maunier From deric.kwok2000 at gmail.com Mon Nov 7 10:45:13 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Mon, 7 Nov 2011 11:45:13 -0500 Subject: mtu question. more should be better, right? Message-ID: Hi all When I setup the server mtu as 9100. why I have to configure the switch mtu 9300 to make it working? What this extra 200 bytes is for what purpose? ls it standard? What is disadvantage of setting our all internal networks (host / equipment) mtu more than 1500? Thank you for your advice. From jared at puck.nether.net Mon Nov 7 10:45:25 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 7 Nov 2011 11:45:25 -0500 Subject: General Internet Instability In-Reply-To: <4EB80A29.1070006@gmail.com> References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com> Message-ID: On Nov 7, 2011, at 11:41 AM, -Hammer- wrote: > So the file size was 30% higher implies that the number of updates is larger and therefore there is instability? I see the logic but if you scroll thru that page (the whole month of November) there are tons of >1M files. Trying to see what is different about today.... This is an easy benchmark to gauge overall stability. Large files mean something was unstable. Then you need to actually look at them to see *why*. Also since the files are compressed you lose some visibility into what is really in them. - Jared From bhmccie at gmail.com Mon Nov 7 10:50:03 2011 From: bhmccie at gmail.com (-Hammer-) Date: Mon, 07 Nov 2011 10:50:03 -0600 Subject: General Internet Instability In-Reply-To: References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com> Message-ID: <4EB80C3B.6050302@gmail.com> Thank you. This is somewhat of a learning opportunity for me. I hit all the generic Internet health sites and I understand that there IS an issue. Now I'm getting to learn how you guys attempt to understand WHY we had an issue. But my point is the same. If this is the case than the entire month of November reflects "instability" where I see transitions from 600k to 1M between updates. Yet we didn't experience the same negative customer experience for those. So how do you see the difference with todays events? Digging into files now. -Hammer- "I was a normal American nerd" -Jack Herer On 11/07/2011 10:45 AM, Jared Mauch wrote: > On Nov 7, 2011, at 11:41 AM, -Hammer- wrote: > > >> So the file size was 30% higher implies that the number of updates is larger and therefore there is instability? I see the logic but if you scroll thru that page (the whole month of November) there are tons of>1M files. Trying to see what is different about today.... >> > This is an easy benchmark to gauge overall stability. Large files mean something was unstable. Then you need to actually look at them to see *why*. Also since the files are compressed you lose some visibility into what is really in them. > > - Jared From joelja at bogus.com Mon Nov 7 10:52:51 2011 From: joelja at bogus.com (Joel jaeggli) Date: Mon, 07 Nov 2011 08:52:51 -0800 Subject: General Internet Instability In-Reply-To: References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda> Message-ID: <4EB80CE3.4060508@bogus.com> On 11/7/11 08:37 , Jared Mauch wrote: > > On Nov 7, 2011, at 11:27 AM, Richard Golodner wrote: > >> On Mon, 2011-11-07 at 11:09 -0500, Todd Snyder wrote: >>> Can anyone point to any authoritative updates about this? >> >> I think Jared's suggestion was about as close as your going to get for >> right now. Look at the size of the files he mentioned as compared to the >> average size of the others. >> Hopefully someone will come forth with an authoritative answer later >> today. >> Richard Golodner >> > > One can do some analysis of the files to determine what prefixes and autonomous > system neighbors were impacted. > > I can do some of this as I have some other tools that quickly process this data > if people are interested. Please send those replies/votes off list to me directly. according to my peakflow the level-3 update spike was from ~1408 utc to ~1424 utc. > - Jared > From jared at puck.nether.net Mon Nov 7 11:01:13 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 7 Nov 2011 12:01:13 -0500 Subject: real data [Re: General Internet Instability] In-Reply-To: <4EB80A29.1070006@gmail.com> References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com> Message-ID: Here's some real data for those interested. It seems a quick view seems many TATA <-> Level3 and TATA <-> GBLX sets of instability. Combined with the overall update levels seen over that 30 minutes, we saw ~1.566M updates at route views. Compared with the 24h prior (2011.11.06 14:15 as reference) we see ~17-20x the updates in the same time period. Now take your control plane and make it work 17-20x as hard, and you can see why we had some even general instability. I don't have better tools for doing a more detailed analysis at this time, but this should get you started in talking to others about what happened. (There were no stand-out prefixes for this time-period, they all had about the same number of updates per prefix). #Updates|Filename --------+----------------- 42041 20111106.1415.out 727711 20111107.1400.out 838894 20111107.1415.out 2011.11.07 14:15 datafile - Most updates/as-path (complete as seen @ rviews) Count AS_PATH -----+---------------------------- 4563 3549 3356 3172 3549 3356 11492 2912 8492 3356 6453 4755 2729 812 6453 4755 2695 3549 6453 14080 10620 2504 3549 3356 11492 11492 11492 2421 3549 3356 7029 2362 3356 209 721 27064 2244 3356 209 20115 2130 3356 209 22561 2044 7018 6453 14080 10620 2000 3356 209 1934 3549 3356 2907 1909 3356 15412 18101 1821 3549 6453 4755 1807 3356 6453 4755 1660 8492 3356 174 1634 3549 3356 18566 1619 3549 3356 4837 17623 1617 7018 6453 4755 1581 2497 6453 7545 7545 7545 1496 8492 3356 209 721 27064 1478 2497 6453 4755 1437 8492 8928 3356 11492 11492 11492 1427 3356 3549 3216 8402 1395 3356 701 19262 1362 8492 3356 209 20115 1357 3549 7843 7843 7843 10796 1336 3549 3356 6830 6830 6830 1259 2497 3356 1238 3356 9498 1229 812 6453 14080 10620 1229 3356 6453 14080 10620 1221 3356 9121 42926 1220 3549 3356 29314 1203 3549 3356 680 680 680 680 680 1194 2497 3356 5650 7011 1165 2497 3356 9498 1151 8001 4436 7843 10796 1150 3549 3356 15412 18101 18101 18101 18101 17803 1106 8492 3356 6762 7303 1105 3549 3356 55410 45528 1098 3549 3356 15412 18101 17803 1073 3549 7843 7843 7843 1072 3549 3356 7713 17974 1069 3549 3356 15290 1041 3356 3549 1032 3549 3356 11992 1030 3356 4323 1021 3549 6453 7843 11351 1020 8492 8928 3356 7843 11351 1016 2497 3356 11492 1014 3356 2907 1011 7018 3356 2907 2011.11.07 14:00 datafile - Most updates/as-path (complete as seen @ rviews) Count AS_PATH -----+---------------------------- 3894 3356 6453 4755 3504 3549 3356 2930 812 6453 4755 2793 3549 6453 4755 2254 3549 3356 11492 11492 11492 2235 812 6453 14080 10620 1826 2497 6453 4755 1795 3549 3356 7029 1753 3356 3549 1689 7018 6453 14080 10620 1653 812 6453 4755 17488 1649 3549 3356 18566 1613 2497 3356 1568 3549 3356 6830 6830 6830 1496 7018 6453 4755 1419 3549 6453 14080 10620 1394 3356 701 19262 1389 3356 9121 42926 1382 3549 3356 21565 1293 3549 6453 4755 17488 1252 3549 3356 13407 1188 2497 3356 5650 7011 1156 7018 6453 4755 17488 1154 3356 6453 14080 10620 1127 3356 701 3216 8402 1106 8492 9002 3549 6762 7303 1104 3549 3356 4837 17623 1049 39756 3356 7018 1048 39756 3257 7018 1035 2497 6453 7713 17974 1008 3356 3320 From iljitsch at muada.com Mon Nov 7 11:01:40 2011 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 7 Nov 2011 18:01:40 +0100 Subject: mtu question. more should be better, right? In-Reply-To: References: Message-ID: On 7 Nov 2011, at 17:45 , Deric Kwok wrote: > When I setup the server mtu as 9100. why I have to configure the > switch mtu 9300 to make it working? > What this extra 200 bytes is for what purpose? ls it standard? To avoid problems you really want to set the MTU of all your IP devices on the same subnet to the same value. On the switches the MTU needs to be big enough to accommodate the MTU that the hosts and the routers use, but there's no harm in it being larger. (Although you may be using up memory for nothing.) One complication is that not everyone has the same understanding of packet sizes. For IP the MTU is the size of the largest IP packet that can be carried, but layer 2 people sometimes add 14 or 18 bytes to that and layer 1 people maybe even 38. (14 = ethernet header, 18 = ethernet header + frame check sequence, 38 = header, FCS, preamble, start of frame delimiter and interframe gap.) > What is disadvantage of setting our all internal networks (host / > equipment) mtu more than 1500? Mostly that you'll be hitting path MTU discovery more often. However, this will not cause many issues unlike the case where you use an MTU _smaller_ than 1500. Don't set a larger MTU on slow networks (certainly not on 10 Mbps) because long packets sit in queues for a long time at low speeds, getting in the way of interactive traffic such as VoIP. Above 11k the ethernet frame check sequence catches fewer errors. From bhmccie at gmail.com Mon Nov 7 11:13:25 2011 From: bhmccie at gmail.com (-Hammer-) Date: Mon, 07 Nov 2011 11:13:25 -0600 Subject: real data [Re: General Internet Instability] In-Reply-To: References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com> Message-ID: <4EB811B5.60302@gmail.com> Jared, This is good stuff and I'm understanding how you interpret the data. So this confirms what we are seeing. How do we take this towards a root cause? Mash it with the Juniper threads and see where it goes? -Hammer- "I was a normal American nerd" -Jack Herer On 11/07/2011 11:01 AM, Jared Mauch wrote: > Here's some real data for those interested. It seems a quick view seems many TATA<-> Level3 and TATA<-> GBLX sets of instability. > > Combined with the overall update levels seen over that 30 minutes, we saw ~1.566M updates at route views. > > Compared with the 24h prior (2011.11.06 14:15 as reference) we see ~17-20x the updates in the same time period. Now take your control plane and make it work 17-20x as hard, and you can see why we had some even general instability. > > I don't have better tools for doing a more detailed analysis at this time, but this should get you started in talking to others about what happened. (There were no stand-out prefixes for this time-period, they all had about the same number of updates per prefix). > > #Updates|Filename > --------+----------------- > 42041 20111106.1415.out > 727711 20111107.1400.out > 838894 20111107.1415.out > > 2011.11.07 14:15 datafile - Most updates/as-path (complete as seen @ rviews) > Count AS_PATH > -----+---------------------------- > 4563 3549 3356 > 3172 3549 3356 11492 > 2912 8492 3356 6453 4755 > 2729 812 6453 4755 > 2695 3549 6453 14080 10620 > 2504 3549 3356 11492 11492 11492 > 2421 3549 3356 7029 > 2362 3356 209 721 27064 > 2244 3356 209 20115 > 2130 3356 209 22561 > 2044 7018 6453 14080 10620 > 2000 3356 209 > 1934 3549 3356 2907 > 1909 3356 15412 18101 > 1821 3549 6453 4755 > 1807 3356 6453 4755 > 1660 8492 3356 174 > 1634 3549 3356 18566 > 1619 3549 3356 4837 17623 > 1617 7018 6453 4755 > 1581 2497 6453 7545 7545 7545 > 1496 8492 3356 209 721 27064 > 1478 2497 6453 4755 > 1437 8492 8928 3356 11492 11492 11492 > 1427 3356 3549 3216 8402 > 1395 3356 701 19262 > 1362 8492 3356 209 20115 > 1357 3549 7843 7843 7843 10796 > 1336 3549 3356 6830 6830 6830 > 1259 2497 3356 > 1238 3356 9498 > 1229 812 6453 14080 10620 > 1229 3356 6453 14080 10620 > 1221 3356 9121 42926 > 1220 3549 3356 29314 > 1203 3549 3356 680 680 680 680 680 > 1194 2497 3356 5650 7011 > 1165 2497 3356 9498 > 1151 8001 4436 7843 10796 > 1150 3549 3356 15412 18101 18101 18101 18101 17803 > 1106 8492 3356 6762 7303 > 1105 3549 3356 55410 45528 > 1098 3549 3356 15412 18101 17803 > 1073 3549 7843 7843 7843 > 1072 3549 3356 7713 17974 > 1069 3549 3356 15290 > 1041 3356 3549 > 1032 3549 3356 11992 > 1030 3356 4323 > 1021 3549 6453 7843 11351 > 1020 8492 8928 3356 7843 11351 > 1016 2497 3356 11492 > 1014 3356 2907 > 1011 7018 3356 2907 > > > > 2011.11.07 14:00 datafile - Most updates/as-path (complete as seen @ rviews) > Count AS_PATH > -----+---------------------------- > 3894 3356 6453 4755 > 3504 3549 3356 > 2930 812 6453 4755 > 2793 3549 6453 4755 > 2254 3549 3356 11492 11492 11492 > 2235 812 6453 14080 10620 > 1826 2497 6453 4755 > 1795 3549 3356 7029 > 1753 3356 3549 > 1689 7018 6453 14080 10620 > 1653 812 6453 4755 17488 > 1649 3549 3356 18566 > 1613 2497 3356 > 1568 3549 3356 6830 6830 6830 > 1496 7018 6453 4755 > 1419 3549 6453 14080 10620 > 1394 3356 701 19262 > 1389 3356 9121 42926 > 1382 3549 3356 21565 > 1293 3549 6453 4755 17488 > 1252 3549 3356 13407 > 1188 2497 3356 5650 7011 > 1156 7018 6453 4755 17488 > 1154 3356 6453 14080 10620 > 1127 3356 701 3216 8402 > 1106 8492 9002 3549 6762 7303 > 1104 3549 3356 4837 17623 > 1049 39756 3356 7018 > 1048 39756 3257 7018 > 1035 2497 6453 7713 17974 > 1008 3356 3320 > > > From jra at baylink.com Mon Nov 7 12:14:04 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 7 Nov 2011 13:14:04 -0500 (EST) Subject: General Internet Instability In-Reply-To: Message-ID: <13715771.1878.1320689644662.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leigh Porter" > Just blame Shub Internet.. > > Oh no, I've said it now! Nah; Brad took down everything but the webserver years ago. :-) 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 dnewman at networktest.com Mon Nov 7 12:41:32 2011 From: dnewman at networktest.com (David Newman) Date: Mon, 07 Nov 2011 10:41:32 -0800 Subject: mtu question. more should be better, right? In-Reply-To: References: Message-ID: <4EB8265C.1080202@networktest.com> On 11/7/11 8:45 AM, Deric Kwok wrote: > When I setup the server mtu as 9100. why I have to configure the > switch mtu 9300 to make it working? > > What this extra 200 bytes is for what purpose? ls it standard? MTUs above 2000 bytes are nonstandard. The most recent Ethernet spec, 802.3-2008, defines a maxBasicFrameSize of 1518 octets and a maxEnvelopeFrameSize size of 2000 octets to accommodate various encap mechanisms. > What is disadvantage of setting our all internal networks (host / > equipment) mtu more than 1500? In a single data center at 1-Gbit/s rates or above, probably none, provided all devices support and use the same MTU. In other scenarios jumbos can lead to the various problems Iljitsch mentioned. dn From lbstreamer at gmail.com Mon Nov 7 13:27:12 2011 From: lbstreamer at gmail.com (Louis P) Date: Mon, 07 Nov 2011 20:27:12 +0100 Subject: Historical records of IP allocations In-Reply-To: References: <4EB6CB74.6060003@gmail.com> <0737E427-68A2-4AC6-8F7A-1B2B81D45AC3@cs.ucla.edu> Message-ID: <4EB83110.6050302@gmail.com> Ripe Routing History seems to be efficient, showing me the AS and for how long the prefix was announced. This question showed me how pointless can be geoip databases (lots of users in this range are also redirected to Neetherland version of Yahoo and Youtube, me, I get some ad in russian). I don't understand why not whois-ing RIRs to obtain country. Thank you all for your replies (and thanks to people who kept traces of records). Louis P Le 07/11/2011 07:34, Lucas Wang a ?crit : > We started keeping track of whois databases from March 20th this year, > and our earliest data shows it belongs to a Russian company called DIMEDIA LLC. > Now the latest whois shows it belongs to "OVH Telecom" located in France. > > On Nov 6, 2011, at 10:58 AM, Louis P wrote: > >> Hello, >> Does anyone know if it's possible to get old records (AS numbers...) of an IP allocation ? >> I found on RIPE these data : ftp://ftp.ripe.net/pub/stats/ripencc/ >> But only the country and allocation date are included. >> >> The IP range I would like to have more information about is 109.190.0.0/17 (it was Russian before and now French). >> >> Thanks in advance, >> Regards, >> Louis P. From jvanoppen at spectrumnet.us Mon Nov 7 13:52:59 2011 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Mon, 7 Nov 2011 19:52:59 +0000 Subject: TATA problems? In-Reply-To: <1320678667.4104.1.camel@teh-desktop> References: <1320678667.4104.1.camel@teh-desktop> Message-ID: We saw several customers go away this morning as well. Our network itself is cisco so we did not see anything directly. John van Oppen @ AS11404. -----Original Message----- From: Tom Hill [mailto:tom at ninjabadger.net] Sent: Monday, November 07, 2011 7:09 AM To: nanog at nanog.org Subject: Re: TATA problems? On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: > We seem to be having some problems with our tata links - first seen in > EU about 45 minutes ago, now we're seeing problems in NA. I'm focused > on DNS, so I'm seeing a lot of timeouts/servfails, but our networking > folks are talking about links dropping. > > Anyone else seeing oddness on the NA Internet right now? > > http://downrightnow.com/ confirms - something is up. There are widespread issues across the Internet; certain versions of Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' message. (That's the running theory at least). It's affected multiple service providers, globally, not just those connected to TATA. Tom From ebais at a2b-internet.com Mon Nov 7 14:40:01 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 7 Nov 2011 21:40:01 +0100 Subject: General Internet Instability In-Reply-To: <4EB80C3B.6050302@gmail.com> References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com> <4EB80C3B.6050302@gmail.com> Message-ID: <013601cc9d8d$6ccdd4c0$46697e40$@com> I just got pointed towards the following : https://twitter.com/#!/JuniperNetworks/status/133637820081389568 And a (re)post on Pastbin : http://pastebin.com/HBWiH92j Juniper Networks replied to my post on Twitter: https://twitter.com/#!/erikbais/status/133641575585677312 That they are working on an official public URL for all to read. Regards, Erik Bais A2B Internet From mathews at hawaii.edu Mon Nov 7 15:29:41 2011 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Mon, 07 Nov 2011 16:29:41 -0500 Subject: real data In-Reply-To: References: <1320678667.4104.1.camel@teh-desktop> <1320683227.2220.108.camel@Andromeda> <4EB80A29.1070006@gmail.com> Message-ID: <8EA4C0C1-D6C4-4FA8-9AAD-CCDCC31554EF@hawaii.edu> On 11/7/2011 12:01 PM, Jared Mauch wrote: > ..... It seems a quick view seems many TATA <-> Level3 and TATA <-> GBLX sets of instability. > > Combined with the overall update levels seen over that 30 minutes, we saw ~1.566M updates at route views. > Compared with the 24h prior (2011.11.06 14:15 as reference) we see ~17-20x the updates in the same time period. Now take your control plane and make it work 17-20x as hard, and you can see why we had some even general instability. Jared: Thanks, for posting this, and for sharing data. Too bad it is not Huawei that is involved. It has precluded someone, somewhere, from framing this SNAFU, a coordinated global Cyber Event, instigated by the Chinese PLA. 8-;) Then, there is still time for that. [again, tongue firmly planted into cheek] -- Dr. Robert Mathews, D.Phil. Distinguished Senior Research Scholar - National Security Affairs & US Industrial Preparedness University of Hawai'i (OSIA) |-- Sent from "the mother-ship," high above the "blue planet." From leigh.porter at ukbroadband.com Mon Nov 7 16:09:55 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 7 Nov 2011 22:09:55 +0000 Subject: TATA problems? In-Reply-To: References: <1320678667.4104.1.camel@teh-desktop>, Message-ID: <5492067E-903D-4A15-912F-E5328C5CE3F2@ukbroadband.com> Any thoughts on just how wide read this was? Did every Juniper that receives Internet BGP updates with the affected software break? Or did it die out quite quickly? -- Leigh On 7 Nov 2011, at 19:55, "John van Oppen" wrote: > We saw several customers go away this morning as well. Our network itself is cisco so we did not see anything directly. > > John van Oppen > @ AS11404. > > > -----Original Message----- > From: Tom Hill [mailto:tom at ninjabadger.net] > Sent: Monday, November 07, 2011 7:09 AM > To: nanog at nanog.org > Subject: Re: TATA problems? > > On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: >> We seem to be having some problems with our tata links - first seen in >> EU about 45 minutes ago, now we're seeing problems in NA. I'm focused >> on DNS, so I'm seeing a lot of timeouts/servfails, but our networking >> folks are talking about links dropping. >> >> Anyone else seeing oddness on the NA Internet right now? >> >> http://downrightnow.com/ confirms - something is up. > > There are widespread issues across the Internet; certain versions of Juniper firmware have core dumped after seeing a particular BGP 'UPDATE' > message. > > (That's the running theory at least). > > It's affected multiple service providers, globally, not just those connected to TATA. > > Tom > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From bhmccie at gmail.com Mon Nov 7 16:07:34 2011 From: bhmccie at gmail.com (-Hammer-) Date: Mon, 07 Nov 2011 16:07:34 -0600 Subject: TATA problems? In-Reply-To: <5492067E-903D-4A15-912F-E5328C5CE3F2@ukbroadband.com> References: <1320678667.4104.1.camel@teh-desktop>, <5492067E-903D-4A15-912F-E5328C5CE3F2@ukbroadband.com> Message-ID: <4EB856A6.6070907@gmail.com> This was posted on pastebin earlier today in case it helps. 1. View Bulletin PSN-2011-08-327 2. Title MX Series MPC crash in Ktree::createFourWayNode after BGP UPDATE 3. Products Affected This issue can affect any MX Series router with port concentrators based on the Trio chipset -- such as the MPC or embedded into the MX80 -- with active protocol-based route prefix additions/deletions occurring. 4. Platforms Affected 5. Security 6. JUNOS 11.x 7. MX-series 8. JUNOS 10.x 9. SIRT Security Advisory 10. SIRT Security Notice 11. Revision Number 1 12. Issue Date 2011-08-08 13. 14. PSN Issue : 15. MPCs (Modular Port Concentrators) installed in an MX Series router may crash upon receipt of very specific and unlikely route prefix install/delete actions, such as a BGP routing update. The set of route prefix updates is non-deterministic and exceedingly unlikely to occur. Junos versions affected include 10.0, 10.1, 10.2, 10.3, 10.4 prior to 10.4R6, and 11.1 prior to 11.1R4. The trigger for the MPC crash was determined to be a valid BGP UPDATE received from a registered network service provider, although this one UPDATE was determined to not be solely responsible for the crashes. A complex sequence of preconditions is required to trigger this crash. Both IPv4 and IPv6 routing prefix updates can trigger this MPC crash. 16. 17. There is no indication that this issue was triggered maliciously. Given the complexity of conditions required to trigger this issue, the probability of exploiting this defect is extremely low. 18. 19. The assertions (crash) all occurred in the code used to store routing information, called Ktree, on the MPC. Due to the order and mix of adds and deletes to the tree, certain combinations of address adds and deletes can corrupt the data structures within the MPC, which in turn can cause this line card crash. The MPC recovers and returns to service quickly, and without operator intervention. 20. 21. This issue only affects MX Series routers with port concentrators based on the Trio chipset, such as the MPC or embedded into the MX80. No other product or platform is vulnerable to this issue. 22. 23. Solution: 24. The Ktree code has been updated and enhanced to ensure that combinations and permutations of routing updates will not corrupt the state of the line card. Extensive testing has been performed to validate an exceedingly large combination and permutation of route prefix additions and deletions. 25. 26. All Junos OS software releases built on or after 2011-08-03 have fixed this specific issue. Releases containing the fix specifically include: 10.0S18, 10.4R6, 11.1R4, 11.2R1, and all subsequent releases (i.e. all releases built after 11.2R1). 27. 28. This issue is being tracked as PR 610864. While this PR may not be viewable by customers, it can be used as a reference when discussing the issue with JTAC. 29. 30. KB16765 - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies. 31. 32. Workarounds 33. No known workaround exists for this issue. -Hammer- "I was a normal American nerd" -Jack Herer On 11/07/2011 04:09 PM, Leigh Porter wrote: > Any thoughts on just how wide read this was? Did every Juniper that receives Internet BGP updates with the affected software break? Or did it die out quite quickly? > > From stu at spacehopper.org Mon Nov 7 16:12:48 2011 From: stu at spacehopper.org (Stuart Henderson) Date: Mon, 7 Nov 2011 22:12:48 +0000 (UTC) Subject: IPv6 beta support for Android phones References: <1320597177.6199.8.camel@teh-desktop> Message-ID: On 2011-11-07, Leigh Porter wrote: >> >> LTE does not have the dual attachment problem since there is the >> concept of having v4 and v6 in one attachment, but it does not change >> the fact that there are not enough IPv4 addresses to go around, >> especially from a strategic planning perspective (let's design this >> once for 5 to 10+ year life ...) >> > > Most networks seem to dish out address space behind a LSN box these days. > > I have three dongle things from three networks in the UK, none of them give me a public address. Though there is at least one UK provider giving out fixed addresses (single and routed netblocks) on 3g From joe at nethead.com Mon Nov 7 16:28:25 2011 From: joe at nethead.com (Joe Hamelin) Date: Mon, 7 Nov 2011 14:28:25 -0800 Subject: Cell-based OOB management devices In-Reply-To: References: Message-ID: > > On Nov 6, 2011 10:15 PM, "David Hubbard" > wrote: > > > > Hi all, I am looking at cellular-based devices as a higher > > speed alternative to dial-up backup access methods for > > out of band management during emergencies. > I've used the Digi devices for Clearwire site OOB and in many retail situations where they are use for backup connection and for when the wire line hasn't been delivered yet. They do come with a static IP address if you request (and pay?) for it. They can come from the shared mobile IP range (RFC 2002) so that you can keep the static IP as you move between tower sites. You can also get them "piped" right in to your net via a VPN, although I suspect that is only affordable for a very large install base. Real world 3G bandwidth is about 1Mb/s down and 300Kb/s down. RTT (ping) is around 185ms to a local IXP (which kinda sucks for terminal support, but still better than a POTS modem.) -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From ed at edgeoc.net Mon Nov 7 16:38:14 2011 From: ed at edgeoc.net (Edward Salonia) Date: Mon, 7 Nov 2011 22:38:14 +0000 Subject: Cell-based OOB management devices Message-ID: <291656980-1320705496-cardhu_decombobulator_blackberry.rim.net-2132388056-@b4.c2.bise6.blackberry> I would look into Uplogix. I've seen them demo their products at Cisco Live a couple of times and they seem very good. - You can connect a cellular modem to them. - They can store backup device configs. - They can store IOS images. - They can even xmodem an image to a device if it gets stuck in ROMMON. - Some of this can even be automated by their device. ------Original Message------ From: David Hubbard To: nanog at nanog.org Subject: Cell-based OOB management devices Sent: Nov 7, 2011 1:14 AM Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David From ebarrios at gobarrios.com Mon Nov 7 16:56:58 2011 From: ebarrios at gobarrios.com (ebarrios at gobarrios.com) Date: Mon, 07 Nov 2011 15:56:58 -0700 Subject: Cell-based OOB management devices Message-ID: <20111107155658.c33affd8db45087daf3b7a3394399b61.6e1c0fcce3.wbe@email02.secureserver.net> From jra at baylink.com Mon Nov 7 17:07:18 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 7 Nov 2011 18:07:18 -0500 (EST) Subject: [outages] Time Warner Cable outage In-Reply-To: <1A8A762BD508624A8BDAB9F5E1638F946014CE15BD@comsrv01.fg.local> Message-ID: <17336195.1942.1320707238908.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Dustin Rhodes" > Sounded like someone was broadcasting a BGP route with an invalid > attribute and caused BGP session restarts or Core Dumps/crashes on any > Juniper router running version 10.4 Well, it *is* getting on towards Christmas... Cheers, -- jr '*really*, Juniper?' 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 jra at baylink.com Mon Nov 7 20:41:52 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 7 Nov 2011 21:41:52 -0500 (EST) Subject: [outages] More notes In-Reply-To: Message-ID: <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jonathan Lassoff" > > It's too bad that Junipers bugs aren't listed publicly. For clueful > network operations, having this information available to them could > have enabled them to properly weigh the risk of evaluating and > certifying versions of their operating systems. The reason it's called "gambling" is that sometimes, you lose. 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 clayton at haydel.org Mon Nov 7 20:43:13 2011 From: clayton at haydel.org (clayton at haydel.org) Date: Mon, 7 Nov 2011 21:43:13 -0500 Subject: XO blocking individual IP's Message-ID: <741f8279bada1343342d857e18f7495d.squirrel@emailmg.ipower.com> I'm hoping someone has had the same experiences, and is further toward a resolution on this than I am. About 6 months ago, we noticed that XO was blackholing one specific IP out of a /24. Traces to that IP stopped on XO's network, traces to anything else out of the block went through fine. XO finally admitted that they had a new security system that identifies suspicious traffic and automatically blocks the IP for 30 minutes. We had to get the IP in question "whitelisted" by their security guys. The traffic was all legit, it was just on a high port # that they considered suspicious. There have several more cases like this, and XO has not been forthcoming with information. We're either looking to be exempted from this filtering or at least get a detailed description of how the system works. I'm not sure how they think this is acceptable from a major transit provider. Anybody else had similar problems? Clayton Haydel From jra at baylink.com Mon Nov 7 20:51:42 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 7 Nov 2011 21:51:42 -0500 (EST) Subject: XO blocking individual IP's In-Reply-To: <741f8279bada1343342d857e18f7495d.squirrel@emailmg.ipower.com> Message-ID: <1822304.1989.1320720702784.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: clayton at haydel.org > There have several more cases like this, and XO has not been forthcoming > with information. We're either looking to be exempted from this filtering > or at least get a detailed description of how the system works. I'm not > sure how they think this is acceptable from a major transit provider. "transit provider". Is XO the end-access provider for either you or the destination site? Or are both of those on some other connection, and XO is a bystander along the way? 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 clayton at haydel.org Mon Nov 7 21:06:25 2011 From: clayton at haydel.org (clayton at haydel.org) Date: Mon, 7 Nov 2011 22:06:25 -0500 Subject: XO blocking individual IP's In-Reply-To: <1822304.1989.1320720702784.JavaMail.root@benjamin.baylink.com> References: <1822304.1989.1320720702784.JavaMail.root@benjamin.baylink.com> Message-ID: <8cd9ddd28acb187bf24131339f00e806.squirrel@emailmg.ipower.com> > "transit provider". Is XO the end-access provider for either you or the > destination site? Or are both of those on some other connection, and XO > is a bystander along the way? We're a direct customer. The IP's that I've seen them block have been both on our network and on remote networks, so I suspect their filtering would affect any traffic that happened to pass over XO. Clayton Haydel From nickellman at gmail.com Mon Nov 7 21:37:55 2011 From: nickellman at gmail.com (brian nikell) Date: Mon, 7 Nov 2011 20:37:55 -0700 Subject: [outages] More notes In-Reply-To: <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com> References: <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com> Message-ID: Actually, Juniper does disclose code bugs. Though not always to the public at first, importantly to Juniper customers. Juniper had advised all of their customers last August of this bug, however Level3 chose to continue running it on their peer routers. Thus if Level3 and its clue(full) management might have listened to their operators & network engineers.... cheers On Mon, Nov 7, 2011 at 7:41 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Jonathan Lassoff" > > > > > It's too bad that Junipers bugs aren't listed publicly. For clueful > > network operations, having this information available to them could > > have enabled them to properly weigh the risk of evaluating and > > certifying versions of their operating systems. > > The reason it's called "gambling" is that sometimes, you lose. > > 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 > > -- -B From blake at pfankuch.me Mon Nov 7 22:34:23 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Tue, 8 Nov 2011 04:34:23 +0000 Subject: XO blocking individual IP's In-Reply-To: <741f8279bada1343342d857e18f7495d.squirrel@emailmg.ipower.com> References: <741f8279bada1343342d857e18f7495d.squirrel@emailmg.ipower.com> Message-ID: Oh yes! Good lord I about went insane with this. I was working with a customer single homed to cBeyond. I spent 3 hours on the phone with cBeyond to figure out what was going on, it looks like a broken route. Come to find out it was an XO "security null". The engineer on the phone from cBeyond said to me "Well, I have learned 2 things today. 1, XO nulls for 'security purposes' at random. 2, I am no longer shocked by any ridiculous policy I will ever come across again." In this case majority traffic was going from cBeyond to anywhere (via XO) and being eaten, however it was VERY tough to diagnose as all parties involved assumed this would not be occurring between source and destination without good public documentation or at least any record of this happening to someone else. Also I guess we all assumed that major bandwidth players don't filter anything. I personally think its good on paper, but very bad real life until there is a way to notify the end customer of the violation quickly. This issue literally took 3 full weeks to figure out what was going on. Yes this works great in a colo datacenter as you have the customer contact info (hopefully). But in the case where my customers provider was having the IP filtered by their transit it was hell to diagnose. In my case the customer had a single infected machine that was making outbound connections on TCP3389 in the range of about 100 connections every 5 minutes and because of this was entirely being "security nulled". Blake -----Original Message----- From: clayton at haydel.org [mailto:clayton at haydel.org] Sent: Monday, November 07, 2011 7:43 PM To: nanog at nanog.org Subject: XO blocking individual IP's I'm hoping someone has had the same experiences, and is further toward a resolution on this than I am. About 6 months ago, we noticed that XO was blackholing one specific IP out of a /24. Traces to that IP stopped on XO's network, traces to anything else out of the block went through fine. XO finally admitted that they had a new security system that identifies suspicious traffic and automatically blocks the IP for 30 minutes. We had to get the IP in question "whitelisted" by their security guys. The traffic was all legit, it was just on a high port # that they considered suspicious. There have several more cases like this, and XO has not been forthcoming with information. We're either looking to be exempted from this filtering or at least get a detailed description of how the system works. I'm not sure how they think this is acceptable from a major transit provider. Anybody else had similar problems? Clayton Haydel From joly at punkcast.com Tue Nov 8 00:42:20 2011 From: joly at punkcast.com (Joly MacFie) Date: Tue, 8 Nov 2011 01:42:20 -0500 Subject: IPv6World:Asia - Deployment Experience with IPv6 Message-ID: For any of you who are working late, we are just about to start (2am-4am EST) a live webcast of a "Deployment Experience with IPv6" event from Hong Kong. Fred Baker is the keynote speaker. Webcast: http://www.livestream.com/internetsocietychapters/ More info: http://isoc-ny.org/p2/?p=2630 -- --------------------------------------------------------------- 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 bortzmeyer at nic.fr Tue Nov 8 02:21:37 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 8 Nov 2011 09:21:37 +0100 Subject: [outages] More notes In-Reply-To: References: <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com> Message-ID: <20111108082137.GA20928@nic.fr> On Mon, Nov 07, 2011 at 08:37:55PM -0700, brian nikell wrote a message of 38 lines which said: > Actually, Juniper does disclose code bugs. Though not always to the > public at first, importantly to Juniper customers. Juniper had > advised all of their customers last August of this bug, however > Level3 chose to continue running it on their peer routers. Thus if > Level3 and its clue(full) management might have listened to their > operators & network engineers.... I disagree. The official bug statement from Juniper in August was trying very hard to downplay the importance of the bug ("Given the complexity of conditions required to trigger this issue, the probability of exploiting this defect is extremely low"). No wonder so few people (and not only at Level-3) did not upgrade. From leigh.porter at ukbroadband.com Tue Nov 8 02:52:38 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 8 Nov 2011 08:52:38 +0000 Subject: XO blocking individual IP's In-Reply-To: References: <741f8279bada1343342d857e18f7495d.squirrel@emailmg.ipower.com>, Message-ID: So if you want to launch a DoS attack against a specific IP address you spoof TCP3389 SYNs to networks single homed to XO and they will null it for you. -- Leigh On 8 Nov 2011, at 04:36, "Blake T. Pfankuch" wrote: > Oh yes! Good lord I about went insane with this. I was working with a customer single homed to cBeyond. I spent 3 hours on the phone with cBeyond to figure out what was going on, it looks like a broken route. Come to find out it was an XO "security null". The engineer on the phone from cBeyond said to me "Well, I have learned 2 things today. 1, XO nulls for 'security purposes' at random. 2, I am no longer shocked by any ridiculous policy I will ever come across again." > > In this case majority traffic was going from cBeyond to anywhere (via XO) and being eaten, however it was VERY tough to diagnose as all parties involved assumed this would not be occurring between source and destination without good public documentation or at least any record of this happening to someone else. Also I guess we all assumed that major bandwidth players don't filter anything. > > I personally think its good on paper, but very bad real life until there is a way to notify the end customer of the violation quickly. This issue literally took 3 full weeks to figure out what was going on. Yes this works great in a colo datacenter as you have the customer contact info (hopefully). But in the case where my customers provider was having the IP filtered by their transit it was hell to diagnose. In my case the customer had a single infected machine that was making outbound connections on TCP3389 in the range of about 100 connections every 5 minutes and because of this was entirely being "security nulled". > > Blake > > -----Original Message----- > From: clayton at haydel.org [mailto:clayton at haydel.org] > Sent: Monday, November 07, 2011 7:43 PM > To: nanog at nanog.org > Subject: XO blocking individual IP's > > > I'm hoping someone has had the same experiences, and is further toward a resolution on this than I am. About 6 months ago, we noticed that XO was blackholing one specific IP out of a /24. Traces to that IP stopped on XO's network, traces to anything else out of the block went through fine. > XO finally admitted that they had a new security system that identifies suspicious traffic and automatically blocks the IP for 30 minutes. We had to get the IP in question "whitelisted" by their security guys. The traffic was all legit, it was just on a high port # that they considered suspicious. > > There have several more cases like this, and XO has not been forthcoming with information. We're either looking to be exempted from this filtering or at least get a detailed description of how the system works. I'm not sure how they think this is acceptable from a major transit provider. > Anybody else had similar problems? > > > Clayton Haydel > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From bjorn at mork.no Tue Nov 8 02:59:34 2011 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 08 Nov 2011 09:59:34 +0100 Subject: [outages] More notes In-Reply-To: <20111108082137.GA20928@nic.fr> (Stephane Bortzmeyer's message of "Tue, 8 Nov 2011 09:21:37 +0100") References: <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com> <20111108082137.GA20928@nic.fr> Message-ID: <87ipmvyop5.fsf@nemi.mork.no> Stephane Bortzmeyer writes: > ("Given the > complexity of conditions required to trigger this issue, the > probability of exploiting this defect is extremely low"). Which translates to "This bug has such catastrophic consequenses that we do not want to disclose how to trigger it." Do you think any such bug would be discovered and/or disclosed *at all* unless it already was triggered in the wild? And if it was triggered once, what are the chances it will happen again? Bj?rn From seth.mos at dds.nl Tue Nov 8 03:02:32 2011 From: seth.mos at dds.nl (Seth Mos) Date: Tue, 08 Nov 2011 10:02:32 +0100 Subject: Performance Issues - PTR Records In-Reply-To: <20111107.144648.74734213.sthaug@nethelp.no> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> <20111107.144648.74734213.sthaug@nethelp.no> Message-ID: <4EB8F028.8040607@dds.nl> On 7-11-2011 14:46, sthaug at nethelp.no wrote: >>> The practice of filling out the reverse zone with fake PTR record >>> started before there was wide spread support for UPDATE/DNS. There >>> isn't any need for this to be done anymore. Machines are capable >>> of adding records for themselves. >> >> How do I setup this for DHCPv6-PD? Say, I delegate 2001:db8:42::/48 to >> the end user. Should I delegate reverse DNS as well? If so, to whom? >> >> Or is it the CPEs responibility to dynamically add records for whatever >> addresses it sees on the internal LAN(s)? Are there CPEs capable of >> doing this? >> >> Or will the end systems themselves do the update against my DNS server? >> If so, how do I authenticate that? > > With my ISP hat on, I find the idea of customer CPEs updating their > own PTR records to be completely unacceptable. So I guess I'll either > live without the reverse DNS, or use a name server that can synthesize > answers on the fly. That seems like a really nice feature, create a reverse record to spoof a mail server and the reverse DNS will match up. If the domain does not employ SPF it will look legit, forward and reverse won't match up ofcourse. Not sure how many mailservers have issues with that if the reverse matches up. Sounds like a fine way to employ a spam botnet. Regards, Seth From bmanning at vacation.karoshi.com Tue Nov 8 04:56:31 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Nov 2011 10:56:31 +0000 Subject: where was my white knight.... Message-ID: <20111108105631.GB5979@vacation.karoshi.com.> how would a sidr-enabled routing infrastructure have fared in yesterdays routing circus? /bill From marka at isc.org Tue Nov 8 05:05:12 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 08 Nov 2011 22:05:12 +1100 Subject: Performance Issues - PTR Records In-Reply-To: Your message of "Tue, 08 Nov 2011 10:02:32 BST." <4EB8F028.8040607@dds.nl> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl> Message-ID: <20111108110512.72E8116E19F7@drugs.dv.isc.org> In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes: > On 7-11-2011 14:46, sthaug at nethelp.no wrote: > >>> The practice of filling out the reverse zone with fake PTR record > >>> started before there was wide spread support for UPDATE/DNS. There > >>> isn't any need for this to be done anymore. Machines are capable > >>> of adding records for themselves. > >> > >> How do I setup this for DHCPv6-PD? Say, I delegate 2001:db8:42::/48 to > >> the end user. Should I delegate reverse DNS as well? If so, to whom? > >> > >> Or is it the CPEs responibility to dynamically add records for whatever > >> addresses it sees on the internal LAN(s)? Are there CPEs capable of > >> doing this? > >> > >> Or will the end systems themselves do the update against my DNS server? > >> If so, how do I authenticate that? > > > > With my ISP hat on, I find the idea of customer CPEs updating their > > own PTR records to be completely unacceptable. So I guess I'll either > > live without the reverse DNS, or use a name server that can synthesize > > answers on the fly. > > That seems like a really nice feature, create a reverse record to spoof > a mail server and the reverse DNS will match up. > > If the domain does not employ SPF it will look legit, forward and > reverse won't match up ofcourse. Not sure how many mailservers have > issues with that if the reverse matches up. > > Sounds like a fine way to employ a spam botnet. Sounds like FUD. Who has trusted the contents of a PTR record in the last 2 decades? > Regards, > > Seth -- 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 Tue Nov 8 05:11:15 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Nov 2011 11:11:15 +0000 Subject: Performance Issues - PTR Records In-Reply-To: <20111108110512.72E8116E19F7@drugs.dv.isc.org> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl> <20111108110512.72E8116E19F7@drugs.dv.isc.org> Message-ID: <20111108111115.GC5979@vacation.karoshi.com.> On Tue, Nov 08, 2011 at 10:05:12PM +1100, Mark Andrews wrote: > > In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes: > > On 7-11-2011 14:46, sthaug at nethelp.no wrote: > > >>> The practice of filling out the reverse zone with fake PTR record > > >>> started before there was wide spread support for UPDATE/DNS. There > > >>> isn't any need for this to be done anymore. Machines are capable > > >>> of adding records for themselves. > > >> > > >> How do I setup this for DHCPv6-PD? Say, I delegate 2001:db8:42::/48 to > > >> the end user. Should I delegate reverse DNS as well? If so, to whom? > > >> > > >> Or is it the CPEs responibility to dynamically add records for whatever > > >> addresses it sees on the internal LAN(s)? Are there CPEs capable of > > >> doing this? > > >> > > >> Or will the end systems themselves do the update against my DNS server? > > >> If so, how do I authenticate that? > > > > > > With my ISP hat on, I find the idea of customer CPEs updating their > > > own PTR records to be completely unacceptable. So I guess I'll either > > > live without the reverse DNS, or use a name server that can synthesize > > > answers on the fly. > > > > That seems like a really nice feature, create a reverse record to spoof > > a mail server and the reverse DNS will match up. > > > > If the domain does not employ SPF it will look legit, forward and > > reverse won't match up ofcourse. Not sure how many mailservers have > > issues with that if the reverse matches up. > > > > Sounds like a fine way to employ a spam botnet. > > Sounds like FUD. Who has trusted the contents of a PTR record in the > last 2 decades? > > > Regards, > > > > Seth > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org the same people who trust the contents of an A record in the last 2 decades. /bill From jeroen at unfix.org Tue Nov 8 05:13:54 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 08 Nov 2011 12:13:54 +0100 Subject: Performance Issues - PTR Records In-Reply-To: <20111108110512.72E8116E19F7@drugs.dv.isc.org> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl> <20111108110512.72E8116E19F7@drugs.dv.isc.org> Message-ID: <4EB90EF2.3030100@unfix.org> On 2011-11-08 12:05 , Mark Andrews wrote: > In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes: [..] > Sounds like FUD. Who has trusted the contents of a PTR record in the > last 2 decades? Lots of tools (read: SSH, Spam-checks, oh and IRCd's ;) trust PTR, but only if the reverse => forward => reverse. And you don't want to know how many silly people enable the "if user comes from .in they must be from Indonesia^WIndia thus block them" Apache option as recently mentioned on this very thread. Also, note that your precious operating system will likely store the PTR, sometimes even without doing the reverse->forward->reverse check. As such, you set up a PTR + Forward properly for a host, try to 'hack' a box by password guessing, the log entries will only have the PTR recorded, and you just drop the PTR+Forward from DNS (as they are under your control) the admin comes in, sees all those nice hosts in their logs but as it is gone from DNS will never ever find you. This especially goes for 'who' (utmp) which makes that mistake. Fortunately SSH at least logs both IP + hostname, the more info the better. That said though the PTR->forward->PTR check is a proper check and a really great way to figure out if the source SMTP host was actually set up with at least some admin doing it the right way. If they can't be bothered to set that up, why should you bother to accept that mail, or a better choice, just score it a bit negatively at least. Greets, Jeroen From ryan at u13.net Tue Nov 8 06:04:18 2011 From: ryan at u13.net (Ryan Rawdon) Date: Tue, 8 Nov 2011 07:04:18 -0500 Subject: XO blocking individual IP's In-Reply-To: <8cd9ddd28acb187bf24131339f00e806.squirrel@emailmg.ipower.com> References: <1822304.1989.1320720702784.JavaMail.root@benjamin.baylink.com> <8cd9ddd28acb187bf24131339f00e806.squirrel@emailmg.ipower.com> Message-ID: On Nov 7, 2011, at 10:06 PM, clayton at haydel.org wrote: > >> "transit provider". Is XO the end-access provider for either you or the >> destination site? Or are both of those on some other connection, and XO >> is a bystander along the way? > > We're a direct customer. The IP's that I've seen them block have been > both on our network and on remote networks, so I suspect their filtering > would affect any traffic that happened to pass over XO. > While troubleshooting another issue last week, someone in the NOC at one of our ISPs mentioned that they had encountered something similar recently. "This looks suspiciously like another XO issue we ran across in the last few months where they used a network security device that blocked 'suspicious' traffic on particular ports (although it was tcp based from what I could remember)." In our case the symptoms looked like GBLX was eating traffic which hashed to a certain theoretical link (certain src-dst-srcport-dstport combinations) in a LAG or similar, but it was happening right near the XO-GBLX edge in the forward path so it's possible it was a security device at XO's edge. From marka at isc.org Tue Nov 8 06:27:31 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 08 Nov 2011 23:27:31 +1100 Subject: Performance Issues - PTR Records In-Reply-To: Your message of "Tue, 08 Nov 2011 12:13:54 BST." <4EB90EF2.3030100@unfix.org> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl> <20111108110512.72E8116E19F7@drugs.dv.isc.org> <4EB90EF2.3030100@unfix.org> Message-ID: <20111108122731.DF12116E2475@drugs.dv.isc.org> In message <4EB90EF2.3030100 at unfix.org>, Jeroen Massar writes: > On 2011-11-08 12:05 , Mark Andrews wrote: > > In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes: > [..] > > Sounds like FUD. Who has trusted the contents of a PTR record in the > > last 2 decades? > > Lots of tools (read: SSH, Spam-checks, oh and IRCd's ;) trust PTR, but > only if the reverse => forward => reverse. And you don't want to know > how many silly people enable the "if user comes from .in they must be > from Indonesia^WIndia thus block them" Apache option as recently > mentioned on this very thread. They arn't trusting the reverse record. They are trusting the forward record to verify the reverse record. They know that the reverse record is untrustworthy as the owner of the reverse zone can put whatever they want there without spoofing anything. > Also, note that your precious operating system will likely store the > PTR, sometimes even without doing the reverse->forward->reverse check. > As such, you set up a PTR + Forward properly for a host, try to 'hack' a > box by password guessing, the log entries will only have the PTR > recorded, and you just drop the PTR+Forward from DNS (as they are under > your control) the admin comes in, sees all those nice hosts in their > logs but as it is gone from DNS will never ever find you. This > especially goes for 'who' (utmp) which makes that mistake. Fortunately > SSH at least logs both IP + hostname, the more info the better. Who trusts logs of names without actual addresses? No one sane does. > That said though the PTR->forward->PTR check is a proper check and a > really great way to figure out if the source SMTP host was actually set > up with at least some admin doing it the right way. If they can't be > bothered to set that up, why should you bother to accept that mail, or a > better choice, just score it a bit negatively at least. Which only works as a filter because ISP's decided to prevent home users from putting valid PTR records in the DNS for their own machines. It has nothing to do with clue or knowlege. > Greets, > Jeroen -- 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 Tue Nov 8 06:34:47 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 8 Nov 2011 12:34:47 +0000 Subject: where was my white knight.... In-Reply-To: <20111108105631.GB5979@vacation.karoshi.com.> References: <20111108105631.GB5979@vacation.karoshi.com.> Message-ID: On Nov 8, 2011, at 5:56 PM, wrote: > how would a sidr-enabled routing infrastructure have fared in yesterdays routing circus? The effects of large amounts of route-churn on the auth chain - perhaps DANE? - might've been interesting . . . ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From jeroen at unfix.org Tue Nov 8 08:25:04 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 08 Nov 2011 15:25:04 +0100 Subject: Performance Issues - PTR Records In-Reply-To: <20111108122731.DF12116E2475@drugs.dv.isc.org> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl> <20111108110512.72E8116E19F7@drugs.dv.isc.org> <4EB90EF2.3030100@unfix.org> <20111108122731.DF12116E2475@drugs.dv.isc.org> Message-ID: <4EB93BC0.9090503@unfix.org> On 2011-11-08 13:27 , Mark Andrews wrote: > In message <4EB90EF2.3030100 at unfix.org>, Jeroen Massar writes: >> On 2011-11-08 12:05 , Mark Andrews wrote: >>> In message <4EB8F028.8040607 at dds.nl>, Seth Mos writes: >> [..] >>> Sounds like FUD. Who has trusted the contents of a PTR record in the >>> last 2 decades? >> >> Lots of tools (read: SSH, Spam-checks, oh and IRCd's ;) trust PTR, but >> only if the reverse => forward => reverse. And you don't want to know >> how many silly people enable the "if user comes from .in they must be >> from Indonesia^WIndia thus block them" Apache option as recently >> mentioned on this very thread. > > They arn't trusting the reverse record. They are trusting the forward > record to verify the reverse record. They know that the reverse record > is untrustworthy as the owner of the reverse zone can put whatever they > want there without spoofing anything. Of course that is the case. The PTR itself is useless, but in combo with checking it with the forward it is a very valuable resource. (Add DNSSEC to the mix and you are even sure that nobody spoofed it on the wire for you ;) >> Also, note that your precious operating system will likely store the >> PTR, sometimes even without doing the reverse->forward->reverse check. > >> As such, you set up a PTR + Forward properly for a host, try to 'hack' a >> box by password guessing, the log entries will only have the PTR >> recorded, and you just drop the PTR+Forward from DNS (as they are under >> your control) the admin comes in, sees all those nice hosts in their >> logs but as it is gone from DNS will never ever find you. This >> especially goes for 'who' (utmp) which makes that mistake. Fortunately >> SSH at least logs both IP + hostname, the more info the better. > > Who trusts logs of names without actual addresses? No one sane > does. Well, only one decade back some people from this very list mentioned that to a certain OS that is used quite a lot by a lot of people: http://www.freebsd.org/cgi/query-pr.cgi?pr=22595 And today that is still the case: http://www.freebsd.org/cgi/man.cgi?query=utmp&sektion=5 Note there is just ut_host there is no address being stored, I hope you yourself btw don't use any FreeBSD based devices as otherwise that little attempt at an insult goes for you too ;) >> That said though the PTR->forward->PTR check is a proper check and a >> really great way to figure out if the source SMTP host was actually set >> up with at least some admin doing it the right way. If they can't be >> bothered to set that up, why should you bother to accept that mail, or a >> better choice, just score it a bit negatively at least. > > Which only works as a filter because ISP's decided to prevent home > users from putting valid PTR records in the DNS for their own > machines. It has nothing to do with clue or knowlege. I don't think ISPs 'decide' to not let users set up reverse DNS, it is generally a 'feature' for which they can ask more moneyz. If ISPs would allow it (which I am for btw) then they only pass the test anyway if they can properly setup reverse->forward->reverse. Which is likely the case anyway for quite some ISPs who populate reverses with a matching forward&reverse based on the IP. Greets, Jeroen From jra at baylink.com Tue Nov 8 08:27:40 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 8 Nov 2011 09:27:40 -0500 (EST) Subject: XO blocking individual IP's In-Reply-To: <8cd9ddd28acb187bf24131339f00e806.squirrel@emailmg.ipower.com> Message-ID: <28839839.2035.1320762460523.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: clayton at haydel.org > > "transit provider". Is XO the end-access provider for either you or the > > destination site? Or are both of those on some other connection, and XO > > is a bystander along the way? > > We're a direct customer. The IP's that I've seen them block have been > both on our network and on remote networks, so I suspect their > filtering would affect any traffic that happened to pass over XO. Ah, ok. Well, that certainly gives them standing to be filtering the traffic; whether you think their reasoning is justified becomes a different level of question at that point. I concur with you that their filtering probably isn't justified, but I suspect you'd find your contract permits 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 antonio.ferretti at telecomitalia.it Tue Nov 8 08:34:36 2011 From: antonio.ferretti at telecomitalia.it (Ferretti Antonio) Date: Tue, 8 Nov 2011 15:34:36 +0100 Subject: Juniper MX960 Mqchip packet lenght error Message-ID: <7F682CB8F5E45A4899F807AA4FEA854213DD9A3D@GRFMBX707RM001.griffon.local> Hi all, After upgrading Juniper MX960 from 4x10Gbe DPCE to 16x10Gbe MPC, I see strange log messages like this: Fpc10 MQCHIP(0) LI Packet length error, pt entry 22 Seems to be only a "cosmetic" message, but today my team found some traffic dropped on interface on this card (before we only request check about log message). Has anyone the same problem? My software release is Junos 10.3R3.7. Thanks in advance. Antonio Ferretti Network Engineer Telecom Italia Sparkle Backbone IP&Data Operations Seabone 2nd Level Support Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From antonio.ferretti at telecomitalia.it Tue Nov 8 09:33:00 2011 From: antonio.ferretti at telecomitalia.it (Ferretti Antonio) Date: Tue, 8 Nov 2011 16:33:00 +0100 Subject: R: Juniper MX960 Mqchip packet lenght error In-Reply-To: <19992_1320765182_4EB946FE_19992_10550_1_26812F15C2B5A8438D1C9BFCDEF73FEC2571539680@PMEXCB1A.intranet-paris.francetelecom.fr> References: <7F682CB8F5E45A4899F807AA4FEA854213DD9A3D@GRFMBX707RM001.griffon.local> <19992_1320765182_4EB946FE_19992_10550_1_26812F15C2B5A8438D1C9BFCDEF73FEC2571539680@PMEXCB1A.intranet-paris.francetelecom.fr> Message-ID: <7F682CB8F5E45A4899F807AA4FEA854213DD9AB2@GRFMBX707RM001.griffon.local> Thx David, PR587266 seems to be related to "maximum-packet-lenght" command that is not present in my config. Biggest problem in this case are dropped packet on interface: Physical interface: xe-10/0/1, Enabled, Physical link is Up Interface index: 363, SNMP ifIndex: 645, Generation: 483 Description: No Description Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, Loopback: None, Source filtering: Disabled, Flow control: Enabled Device flags : Present Running Interface flags: SNMP-Traps Internal: 0x4000 Link flags : None CoS queues : 8 supported, 8 maximum usable queues Hold-times : Up 0 ms, Down 0 ms Current address: 00:24:dc:49:be:73, Hardware address: 00:24:dc:49:be:73 Last flapped : 2011-10-27 03:11:07 UTC (1w5d 12:18 ago) Statistics last cleared: 2011-11-08 13:15:03 UTC (02:14:38 ago) Traffic statistics: Input bytes : 4674308593808 5182909688 bps Output bytes : 6092283580895 6656998280 bps Input packets: 8393093736 1149495 pps Output packets: 6971170539 941600 pps IPv6 transit statistics: Input bytes : 23569859 Output bytes : 0 Input packets: 197870 Output packets: 0 Dropped traffic statistics due to STP State: Input bytes : 0 Output bytes : 0 Input packets: 0 Output packets: 0 Input errors: Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0 Output errors: Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0 Egress queues: 8 supported, 8 in use Queue counters: Queued packets Transmitted packets Dropped packets 0 be 6973872756 6887958719 85914037 1 ef 25695717 25695717 0 2 ef1 2062122 2062122 0 3 ef2 21430966 21430966 0 4 af 2605818 2605818 0 5 af1 1577987 1577987 0 6 nc 5928647 5928647 0 7 nc1 24705296 24705296 0 I'm wondering if is something related to CoS that is managed in different way from the two type of linecard. Regards Antonio Ferretti Network Engineer Telecom Italia Sparkle TIS.AD.NDO.O Backbone IP&Data Operations Seabone 2nd Level Support Via di Macchia Palocco, 223 00125 Roma, Italia -----Messaggio originale----- Da: david.roy at orange.com [mailto:david.roy at orange.com] Inviato: marted? 8 novembre 2011 16.13 A: Ferretti Antonio; nanog at nanog.org Oggetto: RE: Juniper MX960 Mqchip packet lenght error Hi, See the PR587266. Maybe you have Syslog/log statement in a FW filter term. Regards David David Roy Orange - IP Domestic Backbone - TAC Tel. +33(0)299876472 Mob. +33(0)685522213 Email. david.roy at orange.com Skype : davidroy.35 JNCIE-SP #703 Guest Haiku : IS-IS screams, BGP peers are flapping: I want my mommy! -----Message d'origine----- De : Ferretti Antonio [mailto:antonio.ferretti at telecomitalia.it] Envoy? : mardi 8 novembre 2011 15:35 ? : nanog at nanog.org Objet : Juniper MX960 Mqchip packet lenght error Hi all, After upgrading Juniper MX960 from 4x10Gbe DPCE to 16x10Gbe MPC, I see strange log messages like this: Fpc10 MQCHIP(0) LI Packet length error, pt entry 22 Seems to be only a "cosmetic" message, but today my team found some traffic dropped on interface on this card (before we only request check about log message). Has anyone the same problem? My software release is Junos 10.3R3.7. Thanks in advance. Antonio Ferretti Network Engineer Telecom Italia Sparkle Backbone IP&Data Operations Seabone 2nd Level Support Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. ******************************************************************************** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ******************************************************************************** Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. From suess13 at cfl.rr.com Tue Nov 8 09:42:58 2011 From: suess13 at cfl.rr.com (Suess13) Date: Tue, 8 Nov 2011 10:42:58 -0500 Subject: NANOG Digest, Vol 46, Issue 15 In-Reply-To: <0F7F9A82BB0DBB4396A9F8386D0E0612071F65A3@pos-exch1.corp.positivenetworks.net> References: <0F7F9A82BB0DBB4396A9F8386D0E0612071F65A3@pos-exch1.corp.positivenetworks.net> Message-ID: Juniper core dump issue, patch is on the way. On Nov 7, 2011, at 11:41 AM, "Steve Dispensa" wrote: > Level 3 was down in KC, Chi, and San Jose (at least) for us between > about 8:10 and 8:40, plus or minus. Brought down SureWest in KC too. > > -Steve > >> -----Original Message----- >> From: nanog-request at nanog.org [mailto:nanog-request at nanog.org] >> Sent: Monday, November 07, 2011 10:05 AM >> To: nanog at nanog.org >> Subject: NANOG Digest, Vol 46, Issue 15 >> >> 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: Time Warner Telecom problems (Jon Lewis) >> 2. Re: Performance Issues - PTR Records (Leigh Porter) >> 3. Re: Time Warner Telecom problems (Ray Van Dolson) >> 4. General Internet Instability (Jared Mauch) >> 5. Re: TATA problems? (Pierre-Yves Maunier) >> 6. Re: TATA problems? (Leigh Porter) >> 7. Re: Time Warner Telecom problems (Joe Greco) >> 8. Re: TATA problems? (Kelly Kane) >> 9. Re: Time Warner Telecom problems (Blake Hudson) >> 10. RE: Time Warner Telecom problems (Thomas York) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 7 Nov 2011 10:12:30 -0500 (EST) >> From: Jon Lewis >> To: Peter Pauly >> Cc: nanog at nanog.org >> Subject: Re: Time Warner Telecom problems >> Message-ID: >> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> >> On Mon, 7 Nov 2011, Peter Pauly wrote: >> >>> Gizmodo is reporting problems at Time Warner Telecom .... we're >> suffering >>> from it too and calls to the NOC have not been answered so far... > does >>> anyone have any further information? >>> >>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us >> >> I noticed just a little while ago that we're having a lot of DNS fail. >> Initial findings were that several of the root-servers we were trying > to >> reach via our TWTelecom link were unreachable after 2 hops into TWT. >> >> 4 64-128-130-233.static.twtelecom.NET (64.128.130.233) 2.399 ms > 2.298 >> ms 2.338 ms >> 5 mia2-pr1-xe-1-3-0-0.us.twtelecom.net (66.192.253.18) 11.571 ms >> 11.552 ms 9.467 ms >> 6 * * * >> 7 * * * >> 8 * * * >> >> For instance, a.root-servers.net is pingable from a rackspace server, > but >> not from our network (unless I shut off TWT, at which point it is, but >> it's apparently not the same a.root-servers.net instance rackspace > sees). >> I assume this is one of the root-servers being anycast. >> >> Shutting off our BGP with TWT didn't appear to help (though the >> root-servers became reachable)...so I assume there's more going on > than >> just TWT routing fail. >> >> ---------------------------------------------------------------------- >> Jon Lewis, MCP :) | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 7 Nov 2011 15:29:30 +0000 >> From: Leigh Porter >> To: Bj?rn Mork >> Cc: "nanog at nanog.org" >> Subject: Re: Performance Issues - PTR Records >> Message-ID: <53A4963F-4969-4A60-BF06-E690C7324863 at ukbroadband.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> >> >> On 7 Nov 2011, at 14:03, "Bj?rn Mork" wrote: >> >>> Leigh Porter writes: >>> >>>> Indeed, there is no way I would allow that either. But really, >>>> providing a reverse zone and forward zone to match is a case of > five >>>> minutes and a shell script or a DNS that as Steinar said, will >>>> synthesise results. >>>> >>>> It's really not all that difficult.. >>> >>> No, not at all. It's just totally pointless. Any IPv6 address is > just >>> as pretty as a synthesized name. Maybe even prettier. Do you prefer >>> "2001:db8:1::2" or > "20010db8000100000000000000000002.rev.example.com"? >>> >>> If we're going to provide any reverse DNS for end users, then it is >>> because we can create names which actually improves something. >>> >>> >>> Bj?rn >>> >>> >> >> Yup it is pointless.. Mine are all ipadrress.domain which is of > course, >> pointless.. I suppose at least somebody would glean that perhaps its a >> home user rather than a business or server on that address but that's > all. >> >> With IPv6 arguably even more pointless as you say. >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Mon, 7 Nov 2011 07:28:18 -0800 >> From: Ray Van Dolson >> To: nanog at nanog.org >> Subject: Re: Time Warner Telecom problems >> Message-ID: <20111107152817.GA29715 at esri.com> >> Content-Type: text/plain; charset=us-ascii >> >> On Mon, Nov 07, 2011 at 07:04:19AM -0800, Peter Pauly wrote: >>> Gizmodo is reporting problems at Time Warner Telecom .... we're >> suffering >>> from it too and calls to the NOC have not been answered so far... > does >>> anyone have any further information? >>> >>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us >> >> FWIW, my home TWC connection dropped this morning for about 15 minutes >> (Southern California around 6:30AM'ish). Still could ping the default >> gateway, but packets weren't traversing much beyond that. >> >> Didn't investigate further, just headed into work. >> >> Ray >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Mon, 7 Nov 2011 10:31:31 -0500 >> From: Jared Mauch >> To: Tom Hill >> Cc: nanog at nanog.org >> Subject: General Internet Instability >> Message-ID: >> Content-Type: text/plain; charset=us-ascii >> >> On Nov 7, 2011, at 10:08 AM, Tom Hill wrote: >> >>> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: >>>> We seem to be having some problems with our tata links - first seen > in >> EU >>>> about 45 minutes ago, now we're seeing problems in NA. I'm focused > on >> DNS, >>>> so I'm seeing a lot of timeouts/servfails, but our networking folks > are >>>> talking about links dropping. >>>> >>>> Anyone else seeing oddness on the NA Internet right now? >>>> >>>> http://downrightnow.com/ confirms - something is up. >>> >>> There are widespread issues across the Internet; certain versions of >>> Juniper firmware have core dumped after seeing a particular BGP > 'UPDATE' >>> message. >>> >>> (That's the running theory at least). >>> >>> It's affected multiple service providers, globally, not just those >>> connected to TATA. >> >> >> Pretty much any major BGP event will impact multiple providers. >> >> A threshold you should use to view the general instability (which I > find >> valuable, you may as well) is route views data. >> >> If you look at the BGP UPDATES archive sizes, you can see when > something >> happens, e.g.: >> >> http://archive.routeviews.org/bgpdata/2011.11/UPDATES/ >> >> Take a look at the size of the updates.20111107.1400.bz2 file and the > 1415 >> file. They are abnormally large compared to a normal period of time. >> This shows there were a lot of updates out there being processed and a >> reference to levels of instability. >> >> If you are not feeding route views or similar community projects, > please >> consider doing so. It helps paint the view for those doing analysis. >> >> - Jared >> >> >> ------------------------------ >> >> Message: 5 >> Date: Mon, 7 Nov 2011 16:33:15 +0100 >> From: Pierre-Yves Maunier >> To: Tom Hill >> Cc: nanog at nanog.org >> Subject: Re: TATA problems? >> Message-ID: >> > >> Content-Type: text/plain; charset=ISO-8859-1 >> >> 2011/11/7 Tom Hill >> >>> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: >>>> We seem to be having some problems with our tata links - first > seen in >> EU >>>> about 45 minutes ago, now we're seeing problems in NA. I'm > focused on >>> DNS, >>>> so I'm seeing a lot of timeouts/servfails, but our networking > folks >> are >>>> talking about links dropping. >>>> >>>> Anyone else seeing oddness on the NA Internet right now? >>>> >>>> http://downrightnow.com/ confirms - something is up. >>> >>> There are widespread issues across the Internet; certain versions of >>> Juniper firmware have core dumped after seeing a particular BGP > 'UPDATE' >>> message. >>> >>> (That's the running theory at least). >>> >>> It's affected multiple service providers, globally, not just those >>> connected to TATA. >>> >>> Tom >>> >>> >>> >> On our side all our 10.3R2.11 core dumped which made all our > interfaces >> flapped. >> I've been told 10.4R1.9 is affected too. >> >> -- >> Pierre-Yves Maunier >> >> >> ------------------------------ >> >> Message: 6 >> Date: Mon, 7 Nov 2011 15:45:18 +0000 >> From: Leigh Porter >> To: Pierre-Yves Maunier >> Cc: "nanog at nanog.org" >> Subject: Re: TATA problems? >> Message-ID: <7994AF08-0622-434F-974F-FC9269469176 at ukbroadband.com> >> Content-Type: text/plain; charset="us-ascii" >> >> >> My 10.4r1.9 boxes died also but I saw interfaces go down whilst bgpd >> seemed stable. >> >> -- >> Leigh >> >> >> On 7 Nov 2011, at 15:34, "Pierre-Yves Maunier" > wrote: >> >>> 2011/11/7 Tom Hill >>> >>>> On Mon, 2011-11-07 at 10:00 -0500, Todd Snyder wrote: >>>>> We seem to be having some problems with our tata links - first > seen in >> EU >>>>> about 45 minutes ago, now we're seeing problems in NA. I'm > focused on >>>> DNS, >>>>> so I'm seeing a lot of timeouts/servfails, but our networking > folks >> are >>>>> talking about links dropping. >>>>> >>>>> Anyone else seeing oddness on the NA Internet right now? >>>>> >>>>> http://downrightnow.com/ confirms - something is up. >>>> >>>> There are widespread issues across the Internet; certain versions > of >>>> Juniper firmware have core dumped after seeing a particular BGP >> 'UPDATE' >>>> message. >>>> >>>> (That's the running theory at least). >>>> >>>> It's affected multiple service providers, globally, not just those >>>> connected to TATA. >>>> >>>> Tom >>>> >>>> >>>> >>> On our side all our 10.3R2.11 core dumped which made all our > interfaces >>> flapped. >>> I've been told 10.4R1.9 is affected too. >>> >>> -- >>> Pierre-Yves Maunier >>> >>> > ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security > System. >>> For more information please visit http://www.messagelabs.com/email >>> > ______________________________________________________________________ >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> >> ------------------------------ >> >> Message: 7 >> Date: Mon, 7 Nov 2011 09:54:25 -0600 (CST) >> From: Joe Greco >> To: ppauly at gmail.com (Peter Pauly) >> Cc: nanog at nanog.org >> Subject: Re: Time Warner Telecom problems >> Message-ID: <201111071554.pA7FsPHb045359 at aurora.sol.net> >> Content-Type: text/plain; charset=us-ascii >> >>> Gizmodo is reporting problems at Time Warner Telecom .... we're >> suffering >>> from it too and calls to the NOC have not been answered so far... > does >>> anyone have any further information? >>> >>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us >> >> Actually, it looks to me like they mean "Time Warner", because that's >> what they said. >> >> The company once known as "Time Warner Telecom" has always been a >> different entity, and hasn't been known as that in some time, now >> being called "twtelecom." Much of that company is what was once >> known as inc.net, a Milwaukee area provider of the '90's. >> >> Time Warner Cable appears to have experienced an implosion this > morning, >> being out of service for about 11 minutes. During that time, packets >> originating here in Milwaukee quickly died in Chicago; >> >> 1 76.46.192.1 8.320 ms 9.900 ms 7.974 ms >> 2 24.160.230.32 7.967 ms 5.975 ms 8.479 ms >> 3 24.160.229.132 8.471 ms 7.969 ms 10.991 ms >> 4 24.160.229.193 9.972 ms 9.973 ms >> 24.160.229.197 9.985 ms >> 5 * * * >> 6 * * * >> >> while packets destined for RR all seemed to be headed out to SJC, from >> what I can tell. >> >> ... 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. >> >> >> >> ------------------------------ >> >> Message: 8 >> Date: Mon, 7 Nov 2011 07:55:33 -0800 >> From: Kelly Kane >> To: Tim Vollebregt >> Cc: nanog at nanog.org >> Subject: Re: TATA problems? >> Message-ID: >> > >> Content-Type: text/plain; charset=UTF-8 >> >> On Mon, Nov 7, 2011 at 07:06, Tim Vollebregt wrote: >>> >>> On #IX there are rumours about Junos version 10.3R2.11 being core > dumped >> and >>> rebooted, which makes sense. >> >> Perhaps related to Juniper PSN-2011-08-327? Did the whole router >> reboot, or just the service module? >> >> We saw one TATA session, and one Abovenet session flap. >> >> Kelly >> >> >> >> ------------------------------ >> >> Message: 9 >> Date: Mon, 07 Nov 2011 10:02:13 -0600 >> From: Blake Hudson >> To: nanog at nanog.org >> Subject: Re: Time Warner Telecom problems >> Message-ID: <4EB80105.8060703 at ispn.net> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> >> Joe Greco wrote the following on 11/7/2011 9:54 AM: >>>> Gizmodo is reporting problems at Time Warner Telecom .... we're >> suffering >>>> from it too and calls to the NOC have not been answered so far... > does >>>> anyone have any further information? >>>> >>>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us >>> Actually, it looks to me like they mean "Time Warner", because > that's >>> what they said. >>> >>> The company once known as "Time Warner Telecom" has always been a >>> different entity, and hasn't been known as that in some time, now >>> being called "twtelecom." Much of that company is what was once >>> known as inc.net, a Milwaukee area provider of the '90's. >>> >>> Time Warner Cable appears to have experienced an implosion this > morning, >>> being out of service for about 11 minutes. During that time, > packets >>> originating here in Milwaukee quickly died in Chicago; >> >> Using the looking glass from TWtelecom, we saw 30-60min outage > (roughly >> 8:30AM to 9:30AM CST) between the Kansas City location and our own >> server room in Kansas City. Other TWtelecom locations appeared to be >> unaffected. Perhaps TWtelecom is served by Timewarner or shares >> equipment in KC. Either way, none of our KC customers who were served >> via TWtelecom or Timewarner were able to reach us. Packets would hit >> Level 3 Communications and die in either direction at the border > between >> L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa. >> http://lglass.twtelecom.net/ >> >> >> >> ------------------------------ >> >> Message: 10 >> Date: Mon, 7 Nov 2011 11:04:59 -0500 >> From: "Thomas York" >> To: "'Blake Hudson'" , >> Subject: RE: Time Warner Telecom problems >> Message-ID: >> Content-Type: text/plain; charset="utf-8" >> >> FWIW, We saw issues here in Indianapolis between TWTC and L3 up until > a >> few minutes ago. >> >> --Thomas York >> >> -----Original Message----- >> From: Blake Hudson [mailto:blake at ispn.net] >> Sent: Monday, November 07, 2011 11:02 AM >> To: nanog at nanog.org >> Subject: Re: Time Warner Telecom problems >> >> >> Joe Greco wrote the following on 11/7/2011 9:54 AM: >>>> Gizmodo is reporting problems at Time Warner Telecom .... we're >>>> suffering from it too and calls to the NOC have not been answered > so >>>> far... does anyone have any further information? >>>> >>>> http://gizmodo.com/5857010/massive-time-warner-outage-hits-the-us >>> Actually, it looks to me like they mean "Time Warner", because > that's >>> what they said. >>> >>> The company once known as "Time Warner Telecom" has always been a >>> different entity, and hasn't been known as that in some time, now >>> being called "twtelecom." Much of that company is what was once > known >>> as inc.net, a Milwaukee area provider of the '90's. >>> >>> Time Warner Cable appears to have experienced an implosion this >>> morning, being out of service for about 11 minutes. During that > time, >>> packets originating here in Milwaukee quickly died in Chicago; >> >> Using the looking glass from TWtelecom, we saw 30-60min outage > (roughly >> 8:30AM to 9:30AM CST) between the Kansas City location and our own > server >> room in Kansas City. Other TWtelecom locations appeared to be > unaffected. >> Perhaps TWtelecom is served by Timewarner or shares equipment in KC. >> Either way, none of our KC customers who were served via TWtelecom or >> Timewarner were able to reach us. Packets would hit Level 3 > Communications >> and die in either direction at the border between >> L3 and TW. FWIW, TW was showing a good BGP route to us and vise versa. >> http://lglass.twtelecom.net/ >> >> >> >> >> >> End of NANOG Digest, Vol 46, Issue 15 >> ************************************* > From mleber at he.net Tue Nov 8 12:01:04 2011 From: mleber at he.net (Mike Leber) Date: Tue, 08 Nov 2011 10:01:04 -0800 Subject: where was my white knight.... In-Reply-To: <20111108105631.GB5979@vacation.karoshi.com.> References: <20111108105631.GB5979@vacation.karoshi.com.> Message-ID: <4EB96E60.9090707@he.net> We saw an increase in IPv6 traffic which correlated time wise with the onset of this IPv4 incident. Happy eyeballs in action, automatically shifting what it could. Mike. On 11/8/11 2:56 AM, bmanning at vacation.karoshi.com wrote: > how would a sidr-enabled routing infrastructure have fared in yesterdays routing circus? > > /bill > From Valdis.Kletnieks at vt.edu Tue Nov 8 12:05:27 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 08 Nov 2011 13:05:27 -0500 Subject: [outages] More notes In-Reply-To: Your message of "Tue, 08 Nov 2011 09:21:37 +0100." <20111108082137.GA20928@nic.fr> References: <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com> <20111108082137.GA20928@nic.fr> Message-ID: <6995.1320775527@turing-police.cc.vt.edu> On Tue, 08 Nov 2011 09:21:37 +0100, Stephane Bortzmeyer said: > I disagree. The official bug statement from Juniper in August was > trying very hard to downplay the importance of the bug ("Given the > complexity of conditions required to trigger this issue, the > probability of exploiting this defect is extremely low"). No wonder so > few people (and not only at Level-3) did not upgrade. August (and if that's when the *fix* came out, the bug is even older). September. October. November. So maybe the probability *is* low. And if JunOS is anything like CIsco IOS, a lot of shops didn't upgrade because the newer release has *other* issues in their environments. Nobody wants to upgrade to fix a once-ever-few-months bug if it also buys them a daily crash in something else. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bmanning at vacation.karoshi.com Tue Nov 8 12:14:59 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Nov 2011 18:14:59 +0000 Subject: where was my white knight.... In-Reply-To: <4EB96E60.9090707@he.net> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> Message-ID: <20111108181459.GA13752@vacation.karoshi.com.> that was/is kindof orthoginal to the question... would the sidr plan for routing security have been a help in this event? nice to know unsecured IPv6 took some of the load when the unsecured IPv4 path failed. the answer seems to be NO, it would not have helped and would have actually contributed to network instability with large numbers of validation requests sent to the sidr/ca nodes... /bill On Tue, Nov 08, 2011 at 10:01:04AM -0800, Mike Leber wrote: > > We saw an increase in IPv6 traffic which correlated time wise with the > onset of this IPv4 incident. > > Happy eyeballs in action, automatically shifting what it could. > > Mike. > > On 11/8/11 2:56 AM, bmanning at vacation.karoshi.com wrote: > >how would a sidr-enabled routing infrastructure have fared in yesterdays > >routing circus? > > > >/bill > > From rdobbins at arbor.net Tue Nov 8 12:22:25 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 8 Nov 2011 18:22:25 +0000 Subject: where was my white knight.... In-Reply-To: <20111108181459.GA13752@vacation.karoshi.com.> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.> Message-ID: <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net> On Nov 9, 2011, at 1:14 AM, wrote: > that was/is kindof orthoginal to the question... would the sidr plan for routing security have been a help in this event? SIDR is intended to provide route-origination validation - it isn't intended to be nor can it possibly be a remedy for vendor-specific implementation problems. Validation storm-control is something which must be accounted for in SIDR/DANE architecture, implementation, and deployment. But at the end of the day, vendors are still responsible for their own code. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From rdobbins at arbor.net Tue Nov 8 12:25:36 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 8 Nov 2011 18:25:36 +0000 Subject: where was my white knight.... In-Reply-To: <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.> <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net> Message-ID: <3FF79D55-9167-4969-B612-A49666A98A1D@arbor.net> On Nov 9, 2011, at 1:22 AM, Dobbins, Roland wrote: > Validation storm-control is something which must be accounted for in SIDR/DANE architecture, implementation, and deployment. But at the end of the day, vendors are still responsible for their own code. To be clear, I was alluding to some discussion centering around DANE or a DANE-like mechanism to handle SIDR-type route validation. Recursive dependencies make this a non-starter, IMHO. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From nick at foobar.org Tue Nov 8 12:48:12 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 08 Nov 2011 18:48:12 +0000 Subject: where was my white knight.... In-Reply-To: <20111108181459.GA13752@vacation.karoshi.com.> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.> Message-ID: <4EB9796C.9080009@foobar.org> On 08/11/2011 18:14, bmanning at vacation.karoshi.com wrote: > the answer seems to be NO, it would not have helped and would have actually > contributed to network instability with large numbers of validation requests > sent to the sidr/ca nodes... i'm curious about sidr cold bootup, specifically when you are attempting to validate prefixes from an rpki CA or cache to which you do not necessarily have network connectivity because your igp is not yet fully up. The phrases "layering violation" and "chicken and egg" come to mind. Nick From bmanning at vacation.karoshi.com Tue Nov 8 12:54:02 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Nov 2011 18:54:02 +0000 Subject: where was my white knight.... In-Reply-To: <3FF79D55-9167-4969-B612-A49666A98A1D@arbor.net> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.> <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net> <3FF79D55-9167-4969-B612-A49666A98A1D@arbor.net> Message-ID: <20111108185402.GB13752@vacation.karoshi.com.> On Tue, Nov 08, 2011 at 06:25:36PM +0000, Dobbins, Roland wrote: > On Nov 9, 2011, at 1:22 AM, Dobbins, Roland wrote: > > > Validation storm-control is something which must be accounted for in SIDR/DANE architecture, implementation, and deployment. But at the end of the day, vendors are still responsible for their own code. > > To be clear, I was alluding to some discussion centering around DANE or a DANE-like mechanism to handle SIDR-type route validation. Recursive dependencies make this a non-starter, IMHO. > well... your still stuck w/ knowing where your CA is... /bill From bmanning at vacation.karoshi.com Tue Nov 8 12:55:09 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Nov 2011 18:55:09 +0000 Subject: where was my white knight.... In-Reply-To: <4EB9796C.9080009@foobar.org> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.> <4EB9796C.9080009@foobar.org> Message-ID: <20111108185509.GC13752@vacation.karoshi.com.> On Tue, Nov 08, 2011 at 06:48:12PM +0000, Nick Hilliard wrote: > On 08/11/2011 18:14, bmanning at vacation.karoshi.com wrote: > > the answer seems to be NO, it would not have helped and would have actually > > contributed to network instability with large numbers of validation requests > > sent to the sidr/ca nodes... > > i'm curious about sidr cold bootup, specifically when you are attempting to > validate prefixes from an rpki CA or cache to which you do not necessarily > have network connectivity because your igp is not yet fully up. The > phrases "layering violation" and "chicken and egg" come to mind. > > Nick yeah...there is that. /bill From jbates at brightok.net Tue Nov 8 13:03:24 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 08 Nov 2011 13:03:24 -0600 Subject: [outages] More notes In-Reply-To: <6995.1320775527@turing-police.cc.vt.edu> References: <12949593.1985.1320720112598.JavaMail.root@benjamin.baylink.com> <20111108082137.GA20928@nic.fr> <6995.1320775527@turing-police.cc.vt.edu> Message-ID: <4EB97CFC.3020508@brightok.net> On 11/8/2011 12:05 PM, Valdis.Kletnieks at vt.edu wrote: > > And if JunOS is anything like CIsco IOS, a lot of shops didn't upgrade because > the newer release has *other* issues in their environments. Nobody wants to > upgrade to fix a once-ever-few-months bug if it also buys them a daily crash in > something else. > > Juniper runs a quarterly (roughly major) 10.1, 10.2, 10.3, 10.4, .... R is patch revisions for the major release. They are usually good at fixing and not breaking things on the R release. My last upgrade a bit ago was R7.5 of 10.4 (which has more revisions than older 10 releases, probably due to the fact that it will be the long term support release and gets non-critical patches as well). Jack From randy at psg.com Tue Nov 8 13:16:10 2011 From: randy at psg.com (Randy Bush) Date: Tue, 08 Nov 2011 20:16:10 +0100 Subject: where was my white knight.... In-Reply-To: <20111108181459.GA13752@vacation.karoshi.com.> Message-ID: > the answer seems to be NO, it would not have helped and would have > actually contributed to network instability with large numbers of > validation requests sent to the sidr/ca nodes... utter bullshit. maybe you would benefit by actually reading the doccos and understanding the protocols. From randy at psg.com Tue Nov 8 13:19:14 2011 From: randy at psg.com (Randy Bush) Date: Tue, 08 Nov 2011 20:19:14 +0100 Subject: where was my white knight.... In-Reply-To: <4EB9796C.9080009@foobar.org> Message-ID: > i'm curious about sidr cold bootup, specifically when you are > attempting to validate prefixes from an rpki CA or cache to which you > do not necessarily have network connectivity because your igp is not > yet fully up. The phrases "layering violation" and "chicken and egg" > come to mind. what comes to my mind is that NotFound is the default and it is recommended to route on it. i know boys are not allowed to read the manual, but this is starting to get boring. randy From joshua.klubi at gmail.com Tue Nov 8 13:59:43 2011 From: joshua.klubi at gmail.com (joshua.klubi at gmail.com) Date: Tue, 8 Nov 2011 19:59:43 +0000 Subject: Logs Bank Message-ID: Hi, If I may ask, is there any OSS that can serve as a log bank or log server, where it aggregate logs from different sources , and the logs can be accessed using the web from any location on the network and can do graphical presentations based on.the frequency or content os the logs. Thank you Joshua -- Sent from my Nokia N9 From jna at retina.net Tue Nov 8 14:00:30 2011 From: jna at retina.net (John Adams) Date: Tue, 8 Nov 2011 12:00:30 -0800 Subject: Logs Bank In-Reply-To: References: Message-ID: <72D9A217-326A-4089-9289-A5D67285949E@retina.net> You probably want spunk, but if you want to do aggregation in an OSS fashion, scribe or flume is the way to go. -John Sent from my iPhone On Nov 8, 2011, at 11:59, joshua.klubi at gmail.com wrote: > Hi, > > If I may ask, is there any OSS that can serve as a log bank or log server, where it aggregate logs from different sources , and the logs can be accessed using the web from any location on the network and can do graphical presentations based on.the frequency or content os the logs. > > Thank you > > Joshua > > -- > Sent from my Nokia N9 From lstewart at superb.net Tue Nov 8 14:00:49 2011 From: lstewart at superb.net (Landon Stewart) Date: Tue, 8 Nov 2011 12:00:49 -0800 Subject: Logs Bank In-Reply-To: References: Message-ID: On 8 November 2011 11:59, wrote: > Hi, > > If I may ask, is there any OSS that can serve as a log bank or log server, > where it aggregate logs from different sources , and the logs can be > accessed using the web from any location on the network and can do > graphical presentations based on.the frequency or content os the logs. > Do you mean like Splunk? http://www.splunk.com -- Landon Stewart SuperbHosting.Net by Superb Internet Corp. Toll Free (US/Canada): 888-354-6128 x 4199 Direct: 206-438-5879 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From charles at knownelement.com Tue Nov 8 14:00:59 2011 From: charles at knownelement.com (Charles N Wyble) Date: Tue, 08 Nov 2011 14:00:59 -0600 Subject: Logs Bank In-Reply-To: References: Message-ID: Yes. Check out rsyslog and logstash. joshua.klubi at gmail.com wrote: >Hi, > >If I may ask, is there any OSS that can serve as a log bank or log >server, where it aggregate logs from different sources , and the logs >can be accessed using the web from any location on the network and can >do graphical presentations based on.the frequency or content os the >logs. > >Thank you > >Joshua > >-- >Sent from my Nokia N9 -- Charles N Wyble @charlesnw charles at knownelement.com Building a cost effective, open, secure bit moving platform for tomorrows default free zone. From dr at cluenet.de Tue Nov 8 14:05:34 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 8 Nov 2011 21:05:34 +0100 Subject: Juniper MX960 Mqchip packet lenght error In-Reply-To: <7F682CB8F5E45A4899F807AA4FEA854213DD9A3D@GRFMBX707RM001.griffon.local> References: <7F682CB8F5E45A4899F807AA4FEA854213DD9A3D@GRFMBX707RM001.griffon.local> Message-ID: <20111108200534.GA17751@srv03.cluenet.de> On Tue, Nov 08, 2011 at 03:34:36PM +0100, Ferretti Antonio wrote: > After upgrading Juniper MX960 from 4x10Gbe DPCE to 16x10Gbe MPC, I see strange log messages like this: > > Fpc10 MQCHIP(0) LI Packet length error, pt entry 22 > > Seems to be only a "cosmetic" message, PR/593386 "and others". Wenth thru that half a year ago. :) > but today my team found some traffic dropped on interface on this card > (before we only request check about log message). > Has anyone the same problem? Yes. We were told: cosmetic only, and we saw no impact. Trigger was a "then log" in the lo0.0 firewall filter. > My software release is Junos 10.3R3.7. Would match. Above PR is fixed in 10.3R4, 10.4R4, 11.1R2 and newer Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From subscribedlists at derekbodner.com Tue Nov 8 14:05:34 2011 From: subscribedlists at derekbodner.com (Derek Bodner) Date: Tue, 08 Nov 2011 15:05:34 -0500 Subject: Logs Bank In-Reply-To: <72D9A217-326A-4089-9289-A5D67285949E@retina.net> References: <72D9A217-326A-4089-9289-A5D67285949E@retina.net> Message-ID: <4EB98B8E.4060402@derekbodner.com> On 11/08/2011 03:00 PM, John Adams wrote: > You probably want spunk, but if you want to do aggregation in an OSS fashion, scribe or flume is the way to go. > > Agree with Splunk, while not open source, is the most functional of these products. Be warned, while they offer a free license, once you start using it you'll be hooked, and their pricing beyond the free license is borderline extortionist. From alter3d at alter3d.ca Tue Nov 8 14:06:19 2011 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 08 Nov 2011 15:06:19 -0500 Subject: Logs Bank In-Reply-To: References: Message-ID: <4EB98BBB.5000306@alter3d.ca> Octopussy (8pussy.org) is another option as well. Natively ties into various network monitoring packages (Nagios, Zabbix) for alerting capabilities. - Peter On 11/8/2011 3:00 PM, Charles N Wyble wrote: > Yes. Check out rsyslog and logstash. > > joshua.klubi at gmail.com wrote: > >> Hi, >> >> If I may ask, is there any OSS that can serve as a log bank or log >> server, where it aggregate logs from different sources , and the logs >> can be accessed using the web from any location on the network and can >> do graphical presentations based on.the frequency or content os the >> logs. >> >> Thank you >> >> Joshua >> >> -- >> Sent from my Nokia N9 From davidj at mckendrick.ca Tue Nov 8 14:06:52 2011 From: davidj at mckendrick.ca (David) Date: Tue, 08 Nov 2011 14:06:52 -0600 Subject: Logs Bank In-Reply-To: References: Message-ID: <1320782812.2807.38.camel@beast.deigratia.ca> http://www.8pussy.org/dokuwiki/doku.php -- free. open source. http://logstash.net/ -- free. open source. http://splunk.com (already mentioned, of course) -- pay to play. And expensive, too. There are far more out there. From davidj at mckendrick.ca Tue Nov 8 14:09:02 2011 From: davidj at mckendrick.ca (David) Date: Tue, 08 Nov 2011 14:09:02 -0600 Subject: Logs Bank In-Reply-To: <1320782812.2807.38.camel@beast.deigratia.ca> References: <1320782812.2807.38.camel@beast.deigratia.ca> Message-ID: <1320782942.2807.40.camel@beast.deigratia.ca> Oh! And http://graylog2.org/ -- free, open source. That's the last of the ones I can muster up. On Tue, 2011-11-08 at 14:06 -0600, David wrote: > http://www.8pussy.org/dokuwiki/doku.php -- free. open source. > http://logstash.net/ -- free. open source. > http://splunk.com (already mentioned, of course) -- pay to play. And > expensive, too. > > There are far more out there. > > From sylvie at newnog.org Tue Nov 8 14:08:45 2011 From: sylvie at newnog.org (Sylvie LaPerriere) Date: Tue, 8 Nov 2011 12:08:45 -0800 Subject: [NANOG-announce] Call for Communications Committee (CC) Volunteers Message-ID: NANOGers: The NANOG Communications Committee, as defined by the NANOG Bylaws, is a committee that is responsible for the NANOG mailing list, and other forms of electronic communication among the NANOG community as agreed with the Board of Directors. The Communications Committee is responsible for the administration and minimal moderation of the NANOG list, nanog at nanog.org, Also, the committee is responsible for the administration of other mailing lists and other forms of electronic communications among the NANOG community. The NANOG Board is seeking volunteers who are, or willing to become, members and are willing to serve on the Communications Committee. Please submit your name and interest statement to Board at nanog.org Thanks! 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 andy-nanog at bash.sh Tue Nov 8 14:44:45 2011 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Tue, 8 Nov 2011 20:44:45 +0000 Subject: Logs Bank In-Reply-To: References: Message-ID: To answer your question. "yes" However, with almost everything I can think of, there will be an element of development required in order to achieve the results you're after. - at a previous work place a few years ago we fed all event logs into hadoop, from where we produced reports, initially just into excel files, and then later created a webapp which produced near realtime stats/reports/graphs. I've not looked recently at LogStash, or 8pussy, but primary concern would be how well they deal with huge log volumes, how they scale when one server is not big enough to hold all the logs any more, how they deal with many users searching at the same time etc. If you want to actually just get on with crunching logs, and drawing graphs in a timely fashion, Splunk is proven, and works well up to big scale (we were feeding almost 1TB/day of logs into it at my last company)... Splunk is not cheap, but when considering the cost of development + suppport if you went down the route of task of rolling something equivalent in capabilities, its not bad value. thanks Andrew On Tue, Nov 8, 2011 at 7:59 PM, wrote: > Hi, > > If I may ask, is there any OSS that can serve as a log bank or log server, > where it aggregate logs from different sources , and the logs can be > accessed using the web from any location on the network and can do > graphical presentations based on.the frequency or content os the logs. > > Thank you > > Joshua > > -- > Sent from my Nokia N9 > From nick at foobar.org Tue Nov 8 14:51:00 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 08 Nov 2011 20:51:00 +0000 Subject: where was my white knight.... In-Reply-To: References: Message-ID: <4EB99634.7060803@foobar.org> On 08/11/2011 19:19, Randy Bush wrote: > what comes to my mind is that NotFound is the default and it is > recommended to route on it. I understand what the manual says (actually, i read it). I'm just curious as to how this is going to work in real life. Let's say you have a router cold boot with a bunch of ibgp peers, a transit or two and an rpki cache which is located on a non-connected network - e.g. small transit pop / AS boundary scenario. The cache is not necessarily going to be reachable until it sees an update for its connected network. Until this happens, there will be no connectivity from the router to the cache, and consequently prefixes received in from the transit may be subject to an incorrect and potentially inconsistent routing policy with respect to the rest of the network. Ok, they'll be revalidated once the cache comes on line, but what do you do with them in the interim? Route traffic to them, knowing that they might or might not be correct? Drop until the cache comes online from the point of view of the router? Forward potentially incorrect UPDATEs to your other ibgp peers, and forward validated updates when the cache comes on-line again? If so, then what if your incorrect new policy takes precedence over an existing path in your ibgp mesh? And what if your RP is low on memory from storing an unvalidated adj-rib-in? You could argue to have a local cache in every pop but may not be feasible either - a cache will require storage with a high write life-cycle (i.e. forget about using lots of types of flash), and you cannot be guaranteed that this is going to be available on a router. Look, i understand that you're designing rpki <-> interactivity such that things will at least work in some fashion when your routers lose sight of their rpki caches. The problem is that this approach weakens rpki's strengths - e.g. the ability to help stop youtube-like incidents from recurring by ignoring invalid prefix injection. Nick From leigh.porter at ukbroadband.com Tue Nov 8 15:08:26 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 8 Nov 2011 21:08:26 +0000 Subject: where was my white knight.... In-Reply-To: <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.>, <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net> Message-ID: <84EFCC3F-52DB-48DB-83B4-93CC16C3CB4C@ukbroadband.com> On 8 Nov 2011, at 18:24, "Dobbins, Roland" wrote: > > On Nov 9, 2011, at 1:14 AM, wrote: > >> that was/is kindof orthoginal to the question... would the sidr plan for routing security have been a help in this event? > > SIDR is intended to provide route-origination validation - it isn't intended to be nor can it possibly be a remedy for vendor-specific implementation problems. > > Validation storm-control is something which must be accounted for in SIDR/DANE architecture, implementation, and deployment. But at the end of the day, vendors are still responsible for their own code. > > Indeed, we can expect new and exciting ways to blow up networks with SIDR. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From morrowc.lists at gmail.com Tue Nov 8 15:22:48 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 8 Nov 2011 16:22:48 -0500 Subject: where was my white knight.... In-Reply-To: <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com> Message-ID: On Tue, Nov 8, 2011 at 1:14 PM, wrote: > > ?that was/is kindof orthoginal to the question... would the sidr plan > for routing security have been a help in this event? ?nice to know > unsecured IPv6 took some of the load when the unsecured IPv4 path > failed. > if all routing goes boom, would secure routing have saved you? no... all routing went boom. > ?the answer seems to be NO, it would not have helped and would have actually > contributed to network instability with large numbers of validation requests > sent to the sidr/ca nodes. I think actually it wouldn't have caused more validation requests, the routers have (in some form of the plan) a cache from their local cache, they use this for origin validation... there's not a requirement to refresh up the entire chain. (I think). -chris > > /bill > > On Tue, Nov 08, 2011 at 10:01:04AM -0800, Mike Leber wrote: >> >> We saw an increase in IPv6 traffic which correlated time wise with the >> onset of this IPv4 incident. >> >> Happy eyeballs in action, automatically shifting what it could. >> >> Mike. >> >> On 11/8/11 2:56 AM, bmanning at vacation.karoshi.com wrote: >> >how would a sidr-enabled routing infrastructure have fared in yesterdays >> >routing circus? >> > >> >/bill >> > > > From morrowc.lists at gmail.com Tue Nov 8 15:25:54 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 8 Nov 2011 16:25:54 -0500 Subject: where was my white knight.... In-Reply-To: <4EB9796C.9080009@foobar.org> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.> <4EB9796C.9080009@foobar.org> Message-ID: On Tue, Nov 8, 2011 at 1:48 PM, Nick Hilliard wrote: > On 08/11/2011 18:14, bmanning at vacation.karoshi.com wrote: >> ?the answer seems to be NO, it would not have helped and would have actually >> contributed to network instability with large numbers of validation requests >> sent to the sidr/ca nodes... > > i'm curious about sidr cold bootup, specifically when you are attempting to > validate prefixes from an rpki CA or cache to which you do not necessarily > have network connectivity because your igp is not yet fully up. ?The > phrases "layering violation" and "chicken and egg" come to mind. 'lazy validation' - prefer to get at least somewhat converged, then validate. > From morrowc.lists at gmail.com Tue Nov 8 15:30:38 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 8 Nov 2011 16:30:38 -0500 Subject: where was my white knight.... In-Reply-To: <84EFCC3F-52DB-48DB-83B4-93CC16C3CB4C@ukbroadband.com> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <20111108181459.GA13752@vacation.karoshi.com.> <46BAD2CA-614E-4F8F-A876-14160213BAD3@arbor.net> <84EFCC3F-52DB-48DB-83B4-93CC16C3CB4C@ukbroadband.com> Message-ID: On Tue, Nov 8, 2011 at 4:08 PM, Leigh Porter wrote: > > On 8 Nov 2011, at 18:24, "Dobbins, Roland" wrote: > >> Validation storm-control is something which must be accounted for in SIDR/DANE architecture, implementation, and deployment. ?But at the end of the day, vendors are still responsible for their own code. >> >> > > Indeed, we can expect new and exciting ways to blow up networks with SIDR. or, the same old ways... only with crypto! really, there was some care taken in the process to create this and NOT stomp all over how networks currently work. comments welcome though. From Valdis.Kletnieks at vt.edu Tue Nov 8 15:32:48 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 08 Nov 2011 16:32:48 -0500 Subject: where was my white knight.... In-Reply-To: Your message of "Tue, 08 Nov 2011 20:51:00 GMT." <4EB99634.7060803@foobar.org> References: <4EB99634.7060803@foobar.org> Message-ID: <77240.1320787968@turing-police.cc.vt.edu> On Tue, 08 Nov 2011 20:51:00 GMT, Nick Hilliard said: > I understand what the manual says (actually, i read it). I'm just curious > as to how this is going to work in real life. Let's say you have a router > cold boot with a bunch of ibgp peers, a transit or two and an rpki cache > which is located on a non-connected network Anybody who puts their rpki cache someplace that isn't accessible until they get the rpki initialized gets what they deserve. Once you realize this, the rest of the "what do we do for routing until it comes up" concern trolling in the rest of that paragraph becomes pretty easy to sort out... > You could argue to have a local cache in every pop but may not be feasible > either - a cache will require storage with a high write life-cycle (i.e. > forget about using lots of types of flash), and you cannot be guaranteed > that this is going to be available on a router. Caching just enough to validate the routes you need to get to a more capable rpki server shouldn't have a high write life-cycle. Heck, you could just manually configure a host route pointing to the rpki server... And it would hardly be the first time that people have been unable to deploy feature XYZ because it wouldn't fit in the flash on older boxes still in production. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bicknell at ufp.org Tue Nov 8 15:36:01 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 8 Nov 2011 13:36:01 -0800 Subject: where was my white knight.... In-Reply-To: References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com> Message-ID: <20111108213600.GA70357@ussenterprise.ufp.org> In a message written on Tue, Nov 08, 2011 at 04:22:48PM -0500, Christopher Morrow wrote: > I think actually it wouldn't have caused more validation requests, the > routers have (in some form of the plan) a cache from their local > cache, they use this for origin validation... there's not a > requirement to refresh up the entire chain. (I think). I kinda think everyone is wrong here, but Chris is closer to accurate. :P When a router goes boom, the rest of the routers recalculate around it. Generally speaking all of the routers will have already had a route with the same origin, and thus have hopefully cached a lookup of the origin. However, that lookup might have been done days/weeks/months ago, in a stable network. While I'm not familar with the nitty gritty details here, caches expire for various reasons. The mere act of the route changing paths, if it moved to a device with a stale cache, would trigger a new lookup, right? Basically I would expect any routing change to generate a set of new lookups proportial to the cache expiration rules. What am I missing? -- 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 jra at baylink.com Tue Nov 8 15:52:49 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 8 Nov 2011 16:52:49 -0500 (EST) Subject: OT: Ars: Cicso v Adekeye Message-ID: <14406628.2099.1320789169512.JavaMail.root@benjamin.baylink.com> http://arstechnica.com/tech-policy/news/2011/07/a-pound-of-flesh-how-ciscos-unmitigated-gall-derailed-one-mans-life.ars/1 -- 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 leigh.porter at ukbroadband.com Tue Nov 8 16:15:03 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 8 Nov 2011 22:15:03 +0000 Subject: where was my white knight.... In-Reply-To: <20111108213600.GA70357@ussenterprise.ufp.org> References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com> , <20111108213600.GA70357@ussenterprise.ufp.org> Message-ID: On 8 Nov 2011, at 21:37, "Leo Bicknell" wrote: > In a message written on Tue, Nov 08, 2011 at 04:22:48PM -0500, Christopher Morrow wrote: >> I think actually it wouldn't have caused more validation requests, the >> routers have (in some form of the plan) a cache from their local >> cache, they use this for origin validation... there's not a >> requirement to refresh up the entire chain. (I think). > > I kinda think everyone is wrong here, but Chris is closer to accurate. > :P > > When a router goes boom, the rest of the routers recalculate around > it. Generally speaking all of the routers will have already had a > route with the same origin, and thus have hopefully cached a lookup > of the origin. However, that lookup might have been done > days/weeks/months ago, in a stable network. > > While I'm not familar with the nitty gritty details here, caches > expire for various reasons. The mere act of the route changing > paths, if it moved to a device with a stale cache, would trigger a > new lookup, right? > > Basically I would expect any routing change to generate a set of > new lookups proportial to the cache expiration rules. Which may very well fail because all the routing is hosed. I'm not all that familiar with the potential implementation issues, but I would think that network-local caches would be in order. Even with local caches, I would expect a high incidence of change to trigger something sensible to mitigate this kind of craziness from happening. I am sure enough people have had incorrectly scaled RADIUS farms blow up when a load of DSLAMS vanish and come back again not to repeat such storms. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From nick at foobar.org Tue Nov 8 16:19:24 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 08 Nov 2011 22:19:24 +0000 Subject: where was my white knight.... In-Reply-To: <77240.1320787968@turing-police.cc.vt.edu> References: <4EB99634.7060803@foobar.org> <77240.1320787968@turing-police.cc.vt.edu> Message-ID: <4EB9AAEC.9000308@foobar.org> On 08/11/2011 21:32, Valdis.Kletnieks at vt.edu wrote: > Anybody who puts their rpki cache someplace that isn't accessible until they > get the rpki initialized gets what they deserve. One solution is to have directly-connected rpki caches available to all your bgp edge routers throughout your entire network. This may turn out to be expensive capex-wise, and will turn out to be yet another critical infrastructure item to maintain, increasing opex. Alternatively, you host rpki caches on all your AS-edge routers => upgrades - and lots of currently-sold kit will simply not handle this sort of thing properly. > Once you realize this, the rest of the "what do we do for routing until > it comes up" concern trolling in the rest of that paragraph becomes > pretty easy to sort out... I humbly apologise for expressing concern about the wisdom of imposing a hierarchical, higher-layer validation structure for forwarding-info management on a pre-existing lower layer fully distributed system which is already pretty damned complex... What's that principle called again? Was it "Keep It Complex, Stupid"? I can't seem to remember :-) > Caching just enough to validate the routes you need to get to a more capable > rpki server shouldn't have a high write life-cycle. Lots of older flash isn't going to like this => higher implementation cost due to upgrades. > Heck, you could just manually > configure a host route pointing to the rpki server... Yep, hard coding things - good idea, that. > And it would hardly be the first time that people have been unable to deploy > feature XYZ because it wouldn't fit in the flash on older boxes still in > production. This is one of several points I'm making: there is a cost factor here, and it's not clear how large it is. Nick From rdobbins at arbor.net Tue Nov 8 16:26:30 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 8 Nov 2011 22:26:30 +0000 Subject: where was my white knight.... In-Reply-To: References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com> Message-ID: On Nov 9, 2011, at 4:22 AM, Christopher Morrow wrote: > the routers have (in some form of the plan) a cache A cache that's persistent across reboots? ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From rdobbins at arbor.net Tue Nov 8 16:29:06 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 8 Nov 2011 22:29:06 +0000 Subject: where was my white knight.... In-Reply-To: <4EB9AAEC.9000308@foobar.org> References: <4EB99634.7060803@foobar.org> <77240.1320787968@turing-police.cc.vt.edu> <4EB9AAEC.9000308@foobar.org> Message-ID: On Nov 9, 2011, at 5:19 AM, Nick Hilliard wrote: > One solution is to have directly-connected rpki caches available to all your bgp edge routers throughout your entire network. They don't have to be directly-connected - they could be on the DCN, which ought to have at least some static 'hints' to critical resources. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From bicknell at ufp.org Tue Nov 8 16:32:09 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 8 Nov 2011 14:32:09 -0800 Subject: where was my white knight.... In-Reply-To: <4EB9AAEC.9000308@foobar.org> References: <4EB99634.7060803@foobar.org> <77240.1320787968@turing-police.cc.vt.edu> <4EB9AAEC.9000308@foobar.org> Message-ID: <20111108223209.GA72991@ussenterprise.ufp.org> In a message written on Tue, Nov 08, 2011 at 10:19:24PM +0000, Nick Hilliard wrote: > One solution is to have directly-connected rpki caches available to all > your bgp edge routers throughout your entire network. This may turn out to > be expensive capex-wise, and will turn out to be yet another critical > infrastructure item to maintain, increasing opex. Couldn't you just have a couple of these boxes on your network and route them in your IGP, removing any BGP dependancy? KISS. -- 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 bmanning at vacation.karoshi.com Tue Nov 8 16:32:25 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Nov 2011 22:32:25 +0000 Subject: where was my white knight.... In-Reply-To: References: <20111108181459.GA13752@vacation.karoshi.com.> Message-ID: <20111108223225.GA14045@vacation.karoshi.com.> On Tue, Nov 08, 2011 at 08:16:10PM +0100, Randy Bush wrote: > > the answer seems to be NO, it would not have helped and would have > > actually contributed to network instability with large numbers of > > validation requests sent to the sidr/ca nodes... > > utter bullshit. maybe you would benefit by actually reading the doccos > and understanding the protocols. are they actually coherent enough to be read & understood? /bill From waehlisch at ieee.org Tue Nov 8 16:38:12 2011 From: waehlisch at ieee.org (Matthias Waehlisch) Date: Tue, 8 Nov 2011 23:38:12 +0100 Subject: where was my white knight.... In-Reply-To: <20111108223225.GA14045@vacation.karoshi.com.> References: <20111108181459.GA13752@vacation.karoshi.com.> <20111108223225.GA14045@vacation.karoshi.com.> Message-ID: On Tue, 8 Nov 2011, bmanning at vacation.karoshi.com wrote: > On Tue, Nov 08, 2011 at 08:16:10PM +0100, Randy Bush wrote: > > > the answer seems to be NO, it would not have helped and would have > > > actually contributed to network instability with large numbers of > > > validation requests sent to the sidr/ca nodes... > > > > utter bullshit. maybe you would benefit by actually reading the doccos > > and understanding the protocols. > > are they actually coherent enough to be read & understood? > I think so: at least a Bachelor student of my got along with them for his thesis. Btw: There is also a very nice overview by Geoff published in Cisco IPJ: * http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-2/142_bgp.html Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch at ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From morrowc.lists at gmail.com Tue Nov 8 16:46:59 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 8 Nov 2011 17:46:59 -0500 Subject: where was my white knight.... In-Reply-To: References: <20111108105631.GB5979@vacation.karoshi.com.> <4EB96E60.9090707@he.net> <4eb971e6.11fc960a.4e29.3c18SMTPIN_ADDED@mx.google.com> Message-ID: On Tue, Nov 8, 2011 at 5:26 PM, Dobbins, Roland wrote: > > On Nov 9, 2011, at 4:22 AM, Christopher Morrow wrote: > >> ?the routers have (in some form of the plan) a cache > > A cache that's persistent across reboots? > not across reboots, but in this case routers didn't necessarily reboot (parts of them did though). in the case of a reboot, sure, pull from your local cache, no 'walk up the chian' is required here. From BEJones at semprautilities.com Tue Nov 8 17:06:39 2011 From: BEJones at semprautilities.com (Jones, Barry) Date: Tue, 8 Nov 2011 15:06:39 -0800 Subject: Firewalls - Ease of Use and Maintenance? Message-ID: Hello all. I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate. Feel free to ping me offline - and thank you for the assistance. ---------------------------------------- Barry Jones - CISSP GSNA Project Manager II Sempra Energy Utilities (760) 271-6822 P please don't print this e-mail unless you really need to. ---------------------------------------- From bhmccie at gmail.com Tue Nov 8 17:32:20 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 08 Nov 2011 17:32:20 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: References: Message-ID: <4EB9BC04.5010103@gmail.com> You've worked with all the big dogs. What are you looking for? Alternative options? -Hammer- "I was a normal American nerd" -Jack Herer On 11/08/2011 05:06 PM, Jones, Barry wrote: > Hello all. > I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate. > > Feel free to ping me offline - and thank you for the assistance. > > ---------------------------------------- > Barry Jones - CISSP GSNA > Project Manager II > Sempra Energy Utilities > (760) 271-6822 > > P please don't print this e-mail unless you really need to. > ---------------------------------------- > > From bmanning at vacation.karoshi.com Tue Nov 8 17:37:03 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Nov 2011 23:37:03 +0000 Subject: comments due 2dec2011 Message-ID: <20111108233703.GC14045@vacation.karoshi.com.> http://www.nist.gov/itl/cloud/index.cfm /bill From blake at pfankuch.me Tue Nov 8 19:53:20 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Wed, 9 Nov 2011 01:53:20 +0000 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: References: Message-ID: As Hammer stated, you hit all the big ones. ASA's are a classic fallback because of the stability implied by the cisco name. Complaints about them tend to be cost on getting all the shiny bits attached to them (IDS, IPS, Content filtering). This coming from a Cisco partner. I am not a Netscreen fan myself due to past experiences and sour tastes. Checkpoint's are OK, but I don't like the application need for configuring on SMB appliances. Add to the list Sonicwall. We use them primarily for our customers at work and are partners with them as well. They have appliances that go from 10 office size to Active/Active HA pairing that can do multi gbit of throughput. They support all the standard features you look for IPSEC VPN, SSLVPN, L2TP, VLAN Interfaces, Dynamic routing support (OSPF and RIP in small models, BGP in the larger) LDAP auth for all of the above, content filtering, IPS, IDS, Anti Spyware stateful blah blah and centralized management. Some of the newer things that are gaining popularity that you can license is the App Visualization (think netflow in a web UI with good filters), WAN Acceleration modules via a VMware Appliance, RBL Filtering (which can be applied to just about anything), DPI-SSL inspection for https traffic, Active/Active HA, Physical port redundancy per appliance, list goes on. Configuration logic is similar to a ASA, however takes a little to get used to. The nice thing is everything in the config is name based and searchable within the WebUI and you can talk non technical people through making changes in the config if you have to. The feature list is growing every day, and I almost prefer them anymore just because of the simplicity as well as the scalability. Ping me if you have more questions or want a few example setups. Blake -----Original Message----- From: Jones, Barry [mailto:BEJones at semprautilities.com] Sent: Tuesday, November 08, 2011 4:07 PM To: nanog at nanog.org Subject: Firewalls - Ease of Use and Maintenance? Hello all. I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate. Feel free to ping me offline - and thank you for the assistance. ---------------------------------------- Barry Jones - CISSP GSNA Project Manager II Sempra Energy Utilities (760) 271-6822 P please don't print this e-mail unless you really need to. ---------------------------------------- From Ben.Kessler at zenetra.com Tue Nov 8 20:09:09 2011 From: Ben.Kessler at zenetra.com (R. Benjamin Kessler) Date: Wed, 9 Nov 2011 02:09:09 +0000 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: References: Message-ID: <0CFF54003CD92945994CF0C0F90D81B6AF86DE@EXCH1-FWA1.zenetra.local> We work with many vendor's firewalls and our current "favorites" are Palo Alto Networks - they're very full-featured and easy to manage. www.paloaltonetworks.com I don't want to get all "sales-weasel" on you but we can help if you want more info as we are one of their premier partners. P.S. - we're also Juniper and Cisco partners too but we prefer the Palo Altos for firewalls these days. Let me know how I can help -Ben R. Benjamin Kessler CCIE #8762, CISSP, CCSE President / Chief Network Geek Zenetra Corporation Email: ben.kessler at zenetra.com http://www.zenetra.com Office: 260-271-4330 << Note: New Number Cell: 260-437-5774 Fax: 866-388-6652 -----Original Message----- From: Jones, Barry [mailto:BEJones at semprautilities.com] Sent: Tuesday, November 08, 2011 6:07 PM To: nanog at nanog.org Subject: Firewalls - Ease of Use and Maintenance? Hello all. I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate. Feel free to ping me offline - and thank you for the assistance. ---------------------------------------- Barry Jones - CISSP GSNA Project Manager II Sempra Energy Utilities (760) 271-6822 P please don't print this e-mail unless you really need to. ---------------------------------------- From randy at psg.com Tue Nov 8 21:14:35 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Nov 2011 04:14:35 +0100 Subject: where was my white knight.... In-Reply-To: <4EB99634.7060803@foobar.org> References: <4EB99634.7060803@foobar.org> Message-ID: > I understand what the manual says (actually, i read it). cheating!!!! > I'm just curious as to how this is going to work in real life. Let's > say you have a router cold boot with a bunch of ibgp peers, a transit > or two and an rpki cache which is located on a non-connected network - > e.g. small transit pop / AS boundary scenario. The cache is not > necessarily going to be reachable until it sees an update for its > connected network. once again, o when you have no connection to a cache or no covering roa for a a prefix, the result is specified as NotFound o we recommend you route on NotFound so the result is the same as today. > Until this happens, there will be no connectivity from the router to > the cache false > Look, i understand that you're designing rpki <-> interactivity such that > things will at least work in some fashion when your routers lose sight of > their rpki caches. The problem is that this approach weakens rpki's > strengths - e.g. the ability to help stop youtube-like incidents from > recurring by ignoring invalid prefix injection. you can't have you cake and eat it to. you can not detect invalid originations until you have the data to do so. randy From randy at psg.com Tue Nov 8 21:28:54 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Nov 2011 04:28:54 +0100 Subject: where was my white knight.... In-Reply-To: <20111108223225.GA14045@vacation.karoshi.com.> Message-ID: fwiw, we have not tested the scaling of rpki-rtr performance as much as we might have. we synthesized an rpki cache with roas for all the prefixes in a current table, 370k of them or whatever, and let routers load that cache from zip to full. for low-end routers and a mediocre cache server, either local or across noam, it took less than five seconds. this was small enough that we moved on to other stuff. randy From randy at psg.com Tue Nov 8 21:33:41 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Nov 2011 04:33:41 +0100 Subject: where was my white knight.... In-Reply-To: <84EFCC3F-52DB-48DB-83B4-93CC16C3CB4C@ukbroadband.com> Message-ID: > Indeed, we can expect new and exciting ways to blow up networks with > SIDR. the black helicopters spraying fud are especially vicious From owen at delong.com Tue Nov 8 21:54:00 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Nov 2011 19:54:00 -0800 Subject: where was my white knight.... In-Reply-To: References: Message-ID: On Nov 8, 2011, at 7:28 PM, Randy Bush wrote: > fwiw, we have not tested the scaling of rpki-rtr performance as much as > we might have. we synthesized an rpki cache with roas for all the > prefixes in a current table, 370k of them or whatever, and let routers > load that cache from zip to full. for low-end routers and a mediocre > cache server, either local or across noam, it took less than five > seconds. this was small enough that we moved on to other stuff. > > randy Did you do this on routers that already had fully converged tables, or, did you bootstrap the table load into the routers at the same time as would be the case in a power failure, post-crash reboot, software upgrade, etc.? If only the former, may I suggest that at least doing some level of the latter might prove a useful exercise? I apologize for this mildly operational question. Y'all can go back to Randy's fud-laiden black helicopters now. Owen From jof at thejof.com Tue Nov 8 22:47:48 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 8 Nov 2011 20:47:48 -0800 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: References: Message-ID: It really depends on what constraints you have. Do you care about: cost? performance? support? Personally, for cost-constrained applications of 1 Gbit/s or less (assuming modestly-sized packets, not all-DNS for example), I like OpenBSD/pf or Linux/netfilter and generic x86 64-bit servers. It's cheap, deeply customizable and since everything touches a CPU, it allows for deep traffic inspection. The tradeoff is that there's no support from major vendors, but there are many smaller but very experienced consulting shops that can integrate any patches and fix and issues that may arise. What kinds of things are you looking for? Cheers, jof On Tue, Nov 8, 2011 at 3:06 PM, Jones, Barry wrote: > Hello all. > I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate. > > Feel free to ping me offline - and thank you for the assistance. > > ---------------------------------------- > Barry Jones - CISSP GSNA > Project Manager II > Sempra Energy Utilities > (760) 271-6822 > > P please don't print this e-mail unless you really need to. > ---------------------------------------- > > From seth.mos at dds.nl Wed Nov 9 02:13:30 2011 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 09 Nov 2011 09:13:30 +0100 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: References: Message-ID: <4EBA362A.6050401@dds.nl> On 9-11-2011 0:06, Jones, Barry wrote: > Hello all. > I am potentially looking at firewall products and wanted suggestions as to the easiest firewalls to install, configure and maintain? I have a few small networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each have strong and not as strong features for ease of use. Like everyone, I'm resource challenged and need an easy solution to stand up and operate. I am biased because I am a pfSense developer. pfSense is a free open source FreeBSD based firewall with the pf packet filter. http://www.pfsense.org It supports various features and installable packages that might fill your needs. Commercial support is also available. One of the reasons I use it at work is because it is by far the cheapest solution to gigabit redundant (Active/Passive) firewalls. It runs on x86 machines from the low end PCengines.ch Alix 2D3 to something like a dual core Intel Atom for or the higher end on a "normal" server. It is administered entirely via the webUI, saves the config in a XML file you can backup and then restore on pretty much any other hardware you have around should it need to be replaced. The (readable) XML file was also really easy to provision things like hundreds of VPN tunnels instead of clicking through the UI. The PHP command interface allows you to perform scripting operations on the XML as well which comes in handy on mass mutations. Kind regards, Seth From tom at ninjabadger.net Wed Nov 9 04:07:17 2011 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 09 Nov 2011 10:07:17 +0000 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBA362A.6050401@dds.nl> References: <4EBA362A.6050401@dds.nl> Message-ID: <1320833243.1990.1.camel@teh-desktop> On Wed, 2011-11-09 at 09:13 +0100, Seth Mos wrote: > I am biased because I am a pfSense developer. > > pfSense is a free open source FreeBSD based firewall with the pf > packet filter. http://www.pfsense.org I'm a very happy user of m0n0wall and I know pfSense is often seen as the more 'grown up' variant. Still though, I hear bad things of the IPv6 support in pfSense. It's "available" but not stock-standard & supported. How does the pfSense developer attitude towards filtering the entire Internet, IPv6 included, currently stand? Tom From seth.mos at dds.nl Wed Nov 9 05:01:01 2011 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 09 Nov 2011 12:01:01 +0100 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <1320833243.1990.1.camel@teh-desktop> References: <4EBA362A.6050401@dds.nl> <1320833243.1990.1.camel@teh-desktop> Message-ID: <4EBA5D6D.6050408@dds.nl> On 9-11-2011 11:07, Tom Hill wrote: > On Wed, 2011-11-09 at 09:13 +0100, Seth Mos wrote: >> I am biased because I am a pfSense developer. >> >> pfSense is a free open source FreeBSD based firewall with the pf >> packet filter. http://www.pfsense.org > > I'm a very happy user of m0n0wall and I know pfSense is often seen as > the more 'grown up' variant. > > Still though, I hear bad things of the IPv6 support in pfSense. It's > "available" but not stock-standard & supported. That is correct, it is in the 2.1 branch. Our code has diverged a lot from m0n0wall where it came from so porting it was not easy. Instead I wrote the code from scratch. I wrote the IPv6 code in pfSense 2.1 for the last year and I've been using it in production for quite a while now. Since February this year to be precise. It is true that until 2.1 is released somewhere next year the latest official release is pfSense 2.0. The people running Commercial support do support 2.1 with IPv6 if you need it though. There are already a number of customers running it in production because they needed IPv6 support. The biggest holdup is lack of commercial VPN client support for dual-stack. Viscosity, TunnelBlick I am looking at you. We do ship a working Windows OpenVPN dual stack client solution in the Client exporter on 2.1. Working dual stack for your VPN solution is kind of important if you expect to be able to reach your corporate servers. Much grief/fun to be had here. If the corporate LAN advertises quad A records then it will confuse your VPN clients if they have a v4 VPN address but only a v6 internet address. > How does the pfSense developer attitude towards filtering the entire > Internet, IPv6 included, currently stand? I do not quite understand your question. If you are referring to a default deny policy on incoming traffic, then yes. The default rule is to deny incoming traffic over IPv6 as it did over IPv4. You will need to create rules to allow it through. Default LAN rule is allow both IPv4 and IPv6 out. Ofcourse you can alter the firewall rules as you see fit. If I misunderstood your question then please verify. Kind regards, Seth From nick at foobar.org Wed Nov 9 05:43:10 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 09 Nov 2011 11:43:10 +0000 Subject: where was my white knight.... In-Reply-To: References: <4EB99634.7060803@foobar.org> Message-ID: <4EBA674E.6030409@foobar.org> On 09/11/2011 03:14, Randy Bush wrote: > once again, > o when you have no connection to a cache or no covering roa for a > a prefix, the result is specified as NotFound > o we recommend you route on NotFound > > so the result is the same as today. Well no, not really because when the cache becomes reachable again, you need to revalidate everything which got a NotFound. This will cause extra bgp churn where revalidation caused a local policy change. Even if you have a local cache, this will still cause problems due to the problem you summarised in draft-ietf-sidr-origin-ops, section 6: "Like the DNS, the global RPKI presents only a loosely consistent view, depending on timing, updating, fetching, etc. Thus, one cache or router may have different data about a particular prefix than another cache or router. There is no 'fix' for this, it is the nature of distributed data with distributed caches." Local caches may miss updates due to interior unreachability. Routers will not revalidate after cache updates. So this loosely consistent view will propagate into your routers' bgp views. Do I really want this? Or, more to the point, is a perpetually inconsistent bgp network view better or worse than the occasional more serious reachability problem that rpki is attempting to solve? This isn't clear to me. >> Until this happens, there will be no connectivity from the router to >> the cache > > false Not false in the scenario I described. Please read what I said, not what your straw man whispers in your ear. :-) Nick From tom at ninjabadger.net Wed Nov 9 05:45:29 2011 From: tom at ninjabadger.net (Tom Hill) Date: Wed, 09 Nov 2011 11:45:29 +0000 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBA5D6D.6050408@dds.nl> References: <4EBA362A.6050401@dds.nl> <1320833243.1990.1.camel@teh-desktop> <4EBA5D6D.6050408@dds.nl> Message-ID: <1320839134.1990.8.camel@teh-desktop> On Wed, 2011-11-09 at 12:01 +0100, Seth Mos wrote: > That is correct, it is in the 2.1 branch. Our code has diverged a lot > from m0n0wall where it came from so porting it was not easy. Instead I > wrote the code from scratch. > > I wrote the IPv6 code in pfSense 2.1 for the last year and I've been > using it in production for quite a while now. Since February this year > to be precise. > > It is true that until 2.1 is released somewhere next year the latest > official release is pfSense 2.0. > > The people running Commercial support do support 2.1 with IPv6 if you > need it though. There are already a number of customers running it in > production because they needed IPv6 support. TH: This is good news. I look forward to the general availability of 2.1 in this case. An "official" release supporting v6 properly is long over-due for pfSense; users have been complaining about the lack of support for *years*. > The biggest holdup is lack of commercial VPN client support for > dual-stack. Viscosity, TunnelBlick I am looking at you. We do ship a > working Windows OpenVPN dual stack client solution in the Client > exporter on 2.1. > > Working dual stack for your VPN solution is kind of important if you > expect to be able to reach your corporate servers. Much grief/fun to be > had here. If the corporate LAN advertises quad A records then it will > confuse your VPN clients if they have a v4 VPN address but only a v6 > internet address. TH: Indeed, but the more you push on it the better it will become (hopefully). VPN clients/concentrators in the FOSS world is already a minefield of incompatibilities and other such problems. > > How does the pfSense developer attitude towards filtering the entire > > Internet, IPv6 included, currently stand? > > I do not quite understand your question. If you are referring to a > default deny policy on incoming traffic, then yes. > > The default rule is to deny incoming traffic over IPv6 as it did over > IPv4. You will need to create rules to allow it through. Default LAN > rule is allow both IPv4 and IPv6 out. Ofcourse you can alter the > firewall rules as you see fit. > > If I misunderstood your question then please verify. TH: In the past, the pfSense developer's attitude to IPv6 support has been pretty poor. I have mentioned above that customers have been asking for such support for years (i.e. since m0n0wall had it) and the response has been 'it's not important yet', which really wasn't true. But, despite that, it sounds like it's finally getting better. And that can only be good news. Tom From rsk at gsp.org Wed Nov 9 06:22:27 2011 From: rsk at gsp.org (Richard Kulawiec) Date: Wed, 9 Nov 2011 07:22:27 -0500 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: References: Message-ID: <20111109122227.GA5320@gsp.org> You will find it very difficult to beat pf on OpenBSD for efficiency, features, flexibility, robustness, and security. Maintenance is very easy: edit a configuration file, reload, done. ---rsk From nderitualex at gmail.com Wed Nov 9 06:32:45 2011 From: nderitualex at gmail.com (Alex Nderitu) Date: Wed, 09 Nov 2011 15:32:45 +0300 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <20111109122227.GA5320@gsp.org> References: <20111109122227.GA5320@gsp.org> Message-ID: <4EBA72ED.2010909@gmail.com> On 11/09/2011 03:22 PM, Richard Kulawiec wrote: > You will find it very difficult to beat pf on OpenBSD for efficiency, > features, flexibility, robustness, and security. Maintenance is very > easy: edit a configuration file, reload, done. > > ---rsk > > An important feature lacking for now as far as I know is content/web filtering especially for corporates wishing to block inappropriate/time wasting content like facebook. Addition of this would place it a par with the best like Sonicwall and Fortinet. Alex From jgreco at ns.sol.net Wed Nov 9 06:38:01 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 9 Nov 2011 06:38:01 -0600 (CST) Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBA72ED.2010909@gmail.com> Message-ID: <201111091238.pA9Cc1rN080840@aurora.sol.net> > On 11/09/2011 03:22 PM, Richard Kulawiec wrote: > > You will find it very difficult to beat pf on OpenBSD for efficiency, > > features, flexibility, robustness, and security. Maintenance is very > > easy: edit a configuration file, reload, done. > > An important feature lacking for now as far as I know is content/web > filtering especially for corporates wishing to block inappropriate/time > wasting content like facebook. Addition of this would place it a par > with the best like Sonicwall and Fortinet. I would probably disagree with Richard's statement; most organizations are looking for something that's a little more of a product/appliance and a little less of a one-off solution/generic UNIX box. That having been said, if you AREN'T put off by "edit a configuration file", then maybe you won't be put off by "install Squid, add squidGuard (IIRC), and configure transparent proxying" and you're pretty much all the way there. Oh, and you get caching acceleration for free. ... 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 rsk at gsp.org Wed Nov 9 07:11:45 2011 From: rsk at gsp.org (Richard Kulawiec) Date: Wed, 9 Nov 2011 08:11:45 -0500 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBA72ED.2010909@gmail.com> References: <20111109122227.GA5320@gsp.org> <4EBA72ED.2010909@gmail.com> Message-ID: <20111109131145.GA7981@gsp.org> On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote: > An important feature lacking for now as far as I know is content/web > filtering especially for corporates wishing to block > inappropriate/time wasting content like facebook. 1. That's not a firewall function. That's a censorship function. 2. You can of course easily do that via a variety of means, including BOGUS'ing the domains in DNS, blocking port 80 traffic to their network allocations, running an HTTP proxy that blocks them, etc. I presume that any minimally-competent censor could easily devise a first-order solution (using the software packages supplied with OpenBSD) in an afternoon. ---rsk From nick at foobar.org Wed Nov 9 07:24:20 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 09 Nov 2011 13:24:20 +0000 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <20111109122227.GA5320@gsp.org> References: <20111109122227.GA5320@gsp.org> Message-ID: <4EBA7F04.6000105@foobar.org> On 09/11/2011 12:22, Richard Kulawiec wrote: > You will find it very difficult to beat pf on OpenBSD for efficiency, > features, flexibility, robustness, and security. Maintenance is very > easy: edit a configuration file, reload, done. There are several areas where pf falls down. One is auto-synchronisation from primary to backup firewall (not really a pf problem, but it's important for production firewall systems). Another is ipv6 fragments, although this was mostly fixed in a commit on 20110329 (released in 5.0), which unfortunately has not yet made its way to freebsd yet. A third is openbsd's poor ethernet hardware interrupt handling. Again, this has improved recently, but it's still lags seriously behind linux / freebsd. Having said that, it's still my least disfavoured stateful packet filtering system. Nick From jgreco at ns.sol.net Wed Nov 9 08:00:01 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 9 Nov 2011 08:00:01 -0600 (CST) Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <20111109131145.GA7981@gsp.org> Message-ID: <201111091400.pA9E01lg081698@aurora.sol.net> > On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote: > > An important feature lacking for now as far as I know is content/web > > filtering especially for corporates wishing to block > > inappropriate/time wasting content like facebook. > > 1. That's not a firewall function. That's a censorship function. A "firewall" is pretty much a censorship function, you're using it to disallow certain types of traffic on your network. It's simply a matter of what layer you find most convenient to block things... a firewall is better closer to the bottom of the OSI layer model, a proxy is better closer to the top of the OSI layer model. Is it "censorship" not to want unwanted connection attempts to our gear, and block unsolicited TCP connections inbound? Is it "censorship" not to want unwanted exploit attempts to our gear, and run everything through ClamAV, and use blocklists to prevent users inadvertently pulling content from known malware sites? There's no functional differentiation between blocking content for one reason and blocking it for another. There's certainly a huge difference in the POLICY decisions that drive those blocking decisions, but the technology to do them is essentially identical. You can, after all, block facebook on your firewall at the IP level and I think we would both agree that that is "censorship" but also something a firewall is completely capable of. It's just neater and more practical to do at a higher level, for when facebook changes IP addresses (etc), so a higher level block is really more appropriate. > 2. You can of course easily do that via a variety of means, including > BOGUS'ing the domains in DNS, blocking port 80 traffic to their network > allocations, running an HTTP proxy that blocks them, etc. I presume > that any minimally-competent censor could easily devise a first-order > solution (using the software packages supplied with OpenBSD) in an afternoon. It's a little trickier to do in practice. I kind of wish pfSense included such functionality by default, it'd be so killer. :-) Last I checked, it was possible-but-a-fair-bit-of-messing-around. Still, vote++ for pfSense. ... 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 bhmccie at gmail.com Wed Nov 9 08:52:52 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 09 Nov 2011 08:52:52 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <201111091400.pA9E01lg081698@aurora.sol.net> References: <201111091400.pA9E01lg081698@aurora.sol.net> Message-ID: <4EBA93C4.8010809@gmail.com> I think that firewall/censorship is all semantics. The real question is the scale of the environment and the culture of your shop and areas of ownership. I work in a large enterprise. Combining "functions" such as L3 firewalling with content filtering with url filtering with XXX can be difficult. 1. Can the platform actually handle all the traffic? 2. Does one group own ALL the separate functions? If not, RBAC becomes an important (and sometimes political) issue. 3. How easy is it to troubleshoot? Although modern hardware is quickly catching up with all the glorious software features people want these days, in our environment we found it easier and saner to separate these functions. They were owned by different groups and the number of FWs we deploy vs the number of content filters didn't add up to make sense when aggregating functions was discussed. In a smaller operation a Fortinet or other product that consolidates these efforts may make sense. In a larger operation in depends on many outside factors. I've had the (dis)pleasure of working with PIX/FWSM/ASA since Vietnam. I've worked with Netscreen/Juniper, IPTables, PFsense, CheckPoint over Nokia, CheckPoint over Winblows, CheckPoint over UTM, Fortinet, Sonicwall (say Uncle!) and others. They all have their pros and cons and in the end it is specific to your shops needs. More of a UNIX guy? BSD FWs. No we aren't going to talk about how BSD isn't UNIX. That's a different mailing list. More of a Linux guy and need to make sure you have a vendor to yell at? CheckPoint. IPSO/SPLAT/GAEA is all Linux. Not a UNIX/Linux guy and you need a more reliable vendor? And a traditionally safer bet? "No one ever got fired for buying Cisco." Need to save money? Consolidate functions? Confident of the capabilities of the product? Fortinet. And the list goes on and on and on.... -Hammer- "I was a normal American nerd" -Jack Herer On 11/09/2011 08:00 AM, Joe Greco wrote: >> On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote: >> >>> An important feature lacking for now as far as I know is content/web >>> filtering especially for corporates wishing to block >>> inappropriate/time wasting content like facebook. >>> >> 1. That's not a firewall function. That's a censorship function. >> > A "firewall" is pretty much a censorship function, you're using it to > disallow certain types of traffic on your network. It's simply a matter > of what layer you find most convenient to block things... a firewall > is better closer to the bottom of the OSI layer model, a proxy is better > closer to the top of the OSI layer model. > > Is it "censorship" not to want unwanted connection attempts to our > gear, and block unsolicited TCP connections inbound? > > Is it "censorship" not to want unwanted exploit attempts to our > gear, and run everything through ClamAV, and use blocklists to > prevent users inadvertently pulling content from known malware sites? > > There's no functional differentiation between blocking content for > one reason and blocking it for another. There's certainly a huge > difference in the POLICY decisions that drive those blocking decisions, > but the technology to do them is essentially identical. You can, > after all, block facebook on your firewall at the IP level and I think > we would both agree that that is "censorship" but also something a > firewall is completely capable of. It's just neater and more practical > to do at a higher level, for when facebook changes IP addresses (etc), > so a higher level block is really more appropriate. > > >> 2. You can of course easily do that via a variety of means, including >> BOGUS'ing the domains in DNS, blocking port 80 traffic to their network >> allocations, running an HTTP proxy that blocks them, etc. I presume >> that any minimally-competent censor could easily devise a first-order >> solution (using the software packages supplied with OpenBSD) in an afternoon. >> > It's a little trickier to do in practice. I kind of wish pfSense > included such functionality by default, it'd be so killer. :-) > Last I checked, it was possible-but-a-fair-bit-of-messing-around. > > Still, vote++ for pfSense. > > ... JG > From bhmccie at gmail.com Wed Nov 9 09:00:50 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 09 Nov 2011 09:00:50 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBA93C4.8010809@gmail.com> References: <201111091400.pA9E01lg081698@aurora.sol.net> <4EBA93C4.8010809@gmail.com> Message-ID: <4EBA95A2.1060004@gmail.com> OH yeah! MANAGEMENT: If you have a few FWs and you manage them independently life is grand. But what if you have 20? 50? 100? and if 30-40 percent of the policy is the same? Cisco: NOTHING. Don't let them lie to you. CheckPoint: Provider 1 and SmartManager. Juniper: Not sure. BSD/PFSense: Nothing I know of Others: ??? Disclaimer: We are currently a CheckPoint/FWSM/PIX/ASA/Juniper shop. This is the byproduct of mergers/acquisitions/etc. We have standardized on CheckPoint and are phasing out the other vendors as they sunset. A major factor in the decision was management. In the end, if you separate the functions like we do, a FW is a FW is a FW. L3/4 isn't that complicated these days. It's L7 FWs that get the attention. So if the product is stable and has a good MTBF then it's not a huge difference to us as far as the capability of the FW to perform it's function. They all do it well. -Hammer- "I was a normal American nerd" -Jack Herer On 11/09/2011 08:52 AM, -Hammer- wrote: > I think that firewall/censorship is all semantics. The real question > is the scale of the environment and the culture of your shop and areas > of ownership. > > I work in a large enterprise. Combining "functions" such as L3 > firewalling with content filtering with url filtering with XXX can be > difficult. > > 1. Can the platform actually handle all the traffic? > 2. Does one group own ALL the separate functions? If not, RBAC becomes > an important (and sometimes political) issue. > 3. How easy is it to troubleshoot? > > Although modern hardware is quickly catching up with all the glorious > software features people want these days, in our environment we found > it easier and saner to separate these functions. They were owned by > different groups and the number of FWs we deploy vs the number of > content filters didn't add up to make sense when aggregating functions > was discussed. > > In a smaller operation a Fortinet or other product that consolidates > these efforts may make sense. In a larger operation in depends on many > outside factors. > > I've had the (dis)pleasure of working with PIX/FWSM/ASA since Vietnam. > I've worked with Netscreen/Juniper, IPTables, PFsense, CheckPoint over > Nokia, CheckPoint over Winblows, CheckPoint over UTM, Fortinet, > Sonicwall (say Uncle!) and others. They all have their pros and cons > and in the end it is specific to your shops needs. > > More of a UNIX guy? BSD FWs. No we aren't going to talk about how BSD > isn't UNIX. That's a different mailing list. > More of a Linux guy and need to make sure you have a vendor to yell > at? CheckPoint. IPSO/SPLAT/GAEA is all Linux. > Not a UNIX/Linux guy and you need a more reliable vendor? And a > traditionally safer bet? "No one ever got fired for buying Cisco." > Need to save money? Consolidate functions? Confident of the > capabilities of the product? Fortinet. > > And the list goes on and on and on.... > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 11/09/2011 08:00 AM, Joe Greco wrote: >>> On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote: >>> >>>> An important feature lacking for now as far as I know is content/web >>>> filtering especially for corporates wishing to block >>>> inappropriate/time wasting content like facebook. >>>> >>> 1. That's not a firewall function. That's a censorship function. >>> >> A "firewall" is pretty much a censorship function, you're using it to >> disallow certain types of traffic on your network. It's simply a matter >> of what layer you find most convenient to block things... a firewall >> is better closer to the bottom of the OSI layer model, a proxy is better >> closer to the top of the OSI layer model. >> >> Is it "censorship" not to want unwanted connection attempts to our >> gear, and block unsolicited TCP connections inbound? >> >> Is it "censorship" not to want unwanted exploit attempts to our >> gear, and run everything through ClamAV, and use blocklists to >> prevent users inadvertently pulling content from known malware sites? >> >> There's no functional differentiation between blocking content for >> one reason and blocking it for another. There's certainly a huge >> difference in the POLICY decisions that drive those blocking decisions, >> but the technology to do them is essentially identical. You can, >> after all, block facebook on your firewall at the IP level and I think >> we would both agree that that is "censorship" but also something a >> firewall is completely capable of. It's just neater and more practical >> to do at a higher level, for when facebook changes IP addresses (etc), >> so a higher level block is really more appropriate. >> >> >>> 2. You can of course easily do that via a variety of means, including >>> BOGUS'ing the domains in DNS, blocking port 80 traffic to their network >>> allocations, running an HTTP proxy that blocks them, etc. I presume >>> that any minimally-competent censor could easily devise a first-order >>> solution (using the software packages supplied with OpenBSD) in an afternoon. >>> >> It's a little trickier to do in practice. I kind of wish pfSense >> included such functionality by default, it'd be so killer. :-) >> Last I checked, it was possible-but-a-fair-bit-of-messing-around. >> >> Still, vote++ for pfSense. >> >> ... JG >> From gcroft at shoremortgage.com Wed Nov 9 09:04:06 2011 From: gcroft at shoremortgage.com (Gregory Croft) Date: Wed, 09 Nov 2011 10:04:06 -0500 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: Message-ID: Hi, I'm at a smaller company that wanted not only firewall capabilities but application level filtering. We went with the Palo Alto Networks. Story is the Palo Alto founder was formerly of Netscreen/Juniper. Anyhow. We've not had any issues with the PA500's that we use in our environment. They also just released a smaller unit (PA200) for small offices. Very easy to use/operate. My only complaint is the time it takes to commit changes. If you have any specific questions, shoot me an email. Hope that helps. Greg On 11/8/11 6:06 PM, "Jones, Barry" wrote: > Hello all. > I am potentially looking at firewall products and wanted suggestions as to the > easiest firewalls to install, configure and maintain? I have a few small > networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. I > have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and each > have strong and not as strong features for ease of use. Like everyone, I'm > resource challenged and need an easy solution to stand up and operate. > > Feel free to ping me offline - and thank you for the assistance. > > ---------------------------------------- > Barry Jones - CISSP GSNA > Project Manager II > Sempra Energy Utilities > (760) 271-6822 > > P please don't print this e-mail unless you really need to. > ---------------------------------------- > From jof at thejof.com Wed Nov 9 09:18:45 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Wed, 9 Nov 2011 07:18:45 -0800 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBA7F04.6000105@foobar.org> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> Message-ID: On Wed, Nov 9, 2011 at 5:24 AM, Nick Hilliard wrote: > On 09/11/2011 12:22, Richard Kulawiec wrote: >> You will find it very difficult to beat pf on OpenBSD for efficiency, >> features, flexibility, robustness, and security. ?Maintenance is very >> easy: edit a configuration file, reload, done. > > There are several areas where pf falls down. ?One is auto-synchronisation > from primary to backup firewall (not really a pf problem, but it's > important for production firewall systems). I've found that this works decently well, via pfsync. It sends out multicast IP packets with multi-valued elements describing the state of the flows it has in its table. If you're having pf inspect TCP sequence numbers, there's a bit of a race condition in failover with frequently or fast-moving TCP streams. As the window of acceptable sequence numbers moves on the active firewall, they're slightly delayed in getting replicated to the backup(s) and installed in their state tables. Consequently, on failover, it's possible for some flows to get blocked and which have to be re-created. I've hit this and dug into it recently, so if you're having a problem, I'd be happy to chat offlist. Cheers, jof From jcurran at arin.net Wed Nov 9 09:33:04 2011 From: jcurran at arin.net (John Curran) Date: Wed, 9 Nov 2011 15:33:04 +0000 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) References: <4E9F20FF.1070203@arin.net> Message-ID: <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> NANOG Community - There is an Draft Policy for Inter-RIR Transfers presently in extended "Last Call" in the ARIN Policy Development Process. The Last Call will run for one more week, and allows an opportunity for anyone in the Internet community to provide feedback regarding this proposed number resource policy. Feedback, including statements in support or opposition, may be sent to the ARIN Public Policy Mailing List "arin-ppml at arin.net" (http://lists.arin.net/mailman/listinfo/arin-ppml to join or view archives) A copy of the Last Call announcement, including the most recent changes and draft policy text, is attached to this email. Feel free to forward this email to anyone in the Internet community that you feel may wish to comment in support or opposition to this draft policy. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call Date: October 19, 2011 3:11:59 PM EDT To: arin-ppml at arin.net The ARIN Advisory Council (AC) met on 14 October 2011 and decided to send an amended version of the following draft policy to an extended last call: ARIN-2011-1: ARIN Inter-RIR Transfers The AC provided the following statement: ******** The Advisory Council reviewed the results of feedback from the ARIN XXVIII Public Policy Meeting concerning Draft Policy 2011-1 Inter-RIR Transfers. While there were concerns regarding the presented wording, there was significant continued support for a policy enabling Inter-Regional transfers of IPv4 number resources from organizations able to make them available to any organization with valid requirements. In addition to cumbersome wording, the presented text could not be cleanly inserted into the NRPM. The following is new language that directly modifies section 8.3 "Transfers to Specified Recipients" to allow such transfers to or from organizations in other regions. The first paragraph is a modified version of the current 8.3 policy language, envisioning resources being released to ARIN by the authorized resources holder or additionally by another RIR to be transferred to a specified recipient. The second sentence was reorganized to emphasize that it applies to an organization within the ARIN region that will receive such a specified transfer, and to eliminate the single aggregate language per 2011-10 which is also being sent to last call. The new second paragraph adds language enabling transfers to a specified recipient in another RIR's service region. This language specifies that such recipients justify their need to their RIR, following that RIR's policies. ARIN will verify that there is a compatible needs based policy that the other RIR will use to evaluate the need of the recipient and that both RIR's agree to the transfer. Implicit in the intent of the language presented and in conformance with statements made, the size of the block to be transferred is identified as /24 or larger, for obvious practical reasons. In accordance with concern for immediate adoption, the AC chose to forward this version to last call. Concerns expressed by some stakeholders for further controls were noted by the AC, and are being considered for future policy modification, assuaged in part by ARIN staff assurances that if any significant abuse of this policy were to occur, then the policy could easily be suspended. The AC thanks everyone in the community for their help in crafting this important policy and for your statements of support or other comments during Last Call. ******** Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for 2011-1 will expire on 16 November 2011. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-1 ARIN Inter-RIR Transfers Date/version: 14 October 2011 Policy statement: 8.3 Transfers to Specified Recipients In addition to transfers under section 8.2, IPv4 number resources may be released to ARIN by the authorized resource holder or another RIR, in whole or in part, for transfer to another specified organizational recipient. Organizations in the ARIN region may receive transferred number resources under RSA if they can demonstrate the need for such resources in the amount which they can justify under current ARIN policies. IPv4 address resources may be transferred to organizations in another RIR's service region if they demonstrate need to their region's RIR, according to that RIR's policies. Inter-regional transfers may take place only via RIRs who agree to the transfer and share compatible, needs-based policies. Such resources must be transferred in blocks of /24 or larger and will become part of the resource holdings of the recipient RIR. Timetable for implementation: immediate _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bicknell at ufp.org Wed Nov 9 09:56:33 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 9 Nov 2011 07:56:33 -0800 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> Message-ID: <20111109155633.GA21891@ussenterprise.ufp.org> In a message written on Wed, Nov 09, 2011 at 03:33:04PM +0000, John Curran wrote: > > There is an Draft Policy for Inter-RIR Transfers presently in extended > "Last Call" in the ARIN Policy Development Process. The Last Call > will run for one more week, and allows an opportunity for anyone in the > Internet community to provide feedback regarding this proposed > number resource policy. Feedback, including statements in support I went and read a fair number of PPML messages via the web interface as I no longer subscribe. I also read the policy proposal. I think the AC, and ARIN's policy process in general has come off the rails. There's a reason why I unsubscribed from PPML, and have not participated for 2+ years. I don't know exactly where things went wrong, but somewhere they went very, very wrong. But I don't have to summarize, Bill Sandiford (an AC Member) already did that for me: http://lists.arin.net/pipermail/arin-ppml/2011-November/023661.html Which leads me to my thoughts on the process, from two areas: 1) The concept of Inter-RIR transfers is a bad idea. Insuring "compatible" rules between RIR's will always be difficult at best. There are technical difficulties for the RIR's, such as how reverse DNS is handled. Most importantly, after going through all the pain of figuring out these details it's unlikely to help very many people at all. 2) The process followed to get here is totally broken. Bill hit the nail on the head, and it's archived on ARIN's web site: Text in Sep: http://lists.arin.net/pipermail/arin-ppml/2011-September/023170.html Text in Oct: http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html Near as I can tell the feedback in the October meeting made the AC want to do a _total rewrite of the entire policy_, which they turned around in under a week and shoved directly into the last call process. It's disgusting, and I'm glad I'm no longer involved. It's a mockery of the policy process ARIN has set up, and I'm baffled to this day why more folks aren't upset about it. -- 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 bill at herrin.us Wed Nov 9 10:19:28 2011 From: bill at herrin.us (William Herrin) Date: Wed, 9 Nov 2011 11:19:28 -0500 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> Message-ID: On Wed, Nov 9, 2011 at 10:33 AM, John Curran wrote: > The ARIN Advisory Council (AC) met on 14 October 2011 and decided to > send an amended version of the following draft policy to an extended last call: > > ?ARIN-2011-1: ARIN Inter-RIR Transfers Hi folks, There has been some contentious debate about this draft policy. In particular, it may provide a path for bleeding IPv4 addresses from North America to other world regions without requiring reciprocal access to other regions' IPv4 addresses for North American companies. If this concerns you, and I hope it does, I urge you to educate yourself on the matter and then voice your opinion on the ARIN public policy mailing list. Reference materials: The policy as presently drafted: http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html The proposed policy's draft history: https://www.arin.net/policy/proposals/2011_1.html How to subscribe to the ARIN public policy mailing list: http://lists.arin.net/mailman/listinfo/arin-ppml A brief selection of issues raised in the debate: http://lists.arin.net/pipermail/arin-ppml/2011-October/023441.html http://lists.arin.net/pipermail/arin-ppml/2011-October/023464.html http://lists.arin.net/pipermail/arin-ppml/2011-October/023467.html http://lists.arin.net/pipermail/arin-ppml/2011-October/023500.html http://lists.arin.net/pipermail/arin-ppml/2011-October/023511.html http://lists.arin.net/pipermail/arin-ppml/2011-October/023527.html http://lists.arin.net/pipermail/arin-ppml/2011-November/023661.html http://lists.arin.net/pipermail/arin-ppml/2011-November/023667.html 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 Wed Nov 9 10:28:56 2011 From: jcurran at arin.net (John Curran) Date: Wed, 9 Nov 2011 16:28:56 +0000 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <20111109155633.GA21891@ussenterprise.ufp.org> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: <4AA3446B-5311-4AFF-BEB0-75139468DF2B@corp.arin.net> On Nov 9, 2011, at 10:56 AM, Leo Bicknell wrote: > 2) The process followed to get here is totally broken. Bill hit > the nail on the head, and it's archived on ARIN's web site: > Text in Sep: http://lists.arin.net/pipermail/arin-ppml/2011-September/023170.html > Text in Oct: http://lists.arin.net/pipermail/arin-ppml/2011-October/023362.html > > Near as I can tell the feedback in the October meeting made the > AC want to do a _total rewrite of the entire policy_, which they > turned around in under a week and shoved directly into the last > call process. Leo - To be clear, the ARIN Advisory Council (ARIN AC) is definitely following the current ARIN policy development process. If they weren't, I would be obligated to directly intervene. It is true that the present Policy Development process allows the AC ample latitude in changing the policy proposals, with the requirement that if the Advisory Council sends a draft policy to last call that is different from the one presented at the public policy meeting, then the Advisory Council will provide an explanation for all changes made to the text. My message to NANOG was to encourage folks to speak out on the PPML mailing list regarding their thoughts on the draft policy, as that is the forum where the input will have the most impact. I will note that ARIN also just completed an open consultation on a revised Policy Development Process, and while it has closed, I will take directly any suggestions that you have for changes to that process that you feel are necessary. Thanks! /John John Curran President and CEO ARIN From John_Brzozowski at Cable.Comcast.com Wed Nov 9 10:32:39 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Wed, 9 Nov 2011 16:32:39 +0000 Subject: Comcast IPv6 Update Message-ID: Update from http://www.comcast6.net IPv6 Pilot Market Deployment Begins Wednesday, November 9, 2011 Comcast has started our first pilot market deployment of IPv6 in limited areas of California and Colorado. This first phase supports directly connected CPE, where a single computer is directly connected to a cable device. A subsequent phase will support home gateway devices. To learn more, check out FAQs on the pilot market deployment and the announcement and technical details on our blog. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From jeroen at unfix.org Wed Nov 9 10:40:40 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 09 Nov 2011 17:40:40 +0100 Subject: Comcast IPv6 Update In-Reply-To: References: Message-ID: <4EBAAD08.1010205@unfix.org> On 2011-11-09 17:32 , Brzozowski, John wrote: > Update from http://www.comcast6.net > IPv6 Pilot Market Deployment Begins > Wednesday, November 9, 2011 > > Comcast has started our first pilot market deployment of IPv6... Congrats! One step closer to full deployment! Greets, Jeroen From sclark at netwolves.com Wed Nov 9 10:47:31 2011 From: sclark at netwolves.com (Steve Clark) Date: Wed, 09 Nov 2011 11:47:31 -0500 Subject: Comcast IPv6 Update In-Reply-To: <4EBAAD08.1010205@unfix.org> References: <4EBAAD08.1010205@unfix.org> Message-ID: <4EBAAEA3.1090905@netwolves.com> On 11/09/2011 11:40 AM, Jeroen Massar wrote: > On 2011-11-09 17:32 , Brzozowski, John wrote: >> Update from http://www.comcast6.net >> IPv6 Pilot Market Deployment Begins >> Wednesday, November 9, 2011 >> >> Comcast has started our first pilot market deployment of IPv6... > Congrats! One step closer to full deployment! > > Greets, > Jeroen > Sort of interesting that you are only handing out a single address and not a prefix - which seems contradictory to all recommended practices. Will this be a continued effort for ISP's to charge for extra routable addresses? My $.02 -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com From cb.list6 at gmail.com Wed Nov 9 10:49:09 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 9 Nov 2011 08:49:09 -0800 Subject: Comcast IPv6 Update In-Reply-To: <4EBAAD08.1010205@unfix.org> References: <4EBAAD08.1010205@unfix.org> Message-ID: On Wed, Nov 9, 2011 at 8:40 AM, Jeroen Massar wrote: > On 2011-11-09 17:32 , Brzozowski, John wrote: >> Update from http://www.comcast6.net >> IPv6 Pilot Market Deployment Begins >> Wednesday, November 9, 2011 >> >> Comcast has started our first pilot market deployment of IPv6... > > Congrats! One step closer to full deployment! > +1 Glad to hear some good news about IPv6 deployment. Now, lets talk about deployment in Seattle :) From blake at pfankuch.me Wed Nov 9 10:54:32 2011 From: blake at pfankuch.me (Blake T. Pfankuch) Date: Wed, 9 Nov 2011 16:54:32 +0000 Subject: Comcast IPv6 Update In-Reply-To: References: Message-ID: This appears directed at the Home market. Any word on the Business Class market even as a /128? -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski at Cable.Comcast.com] Sent: Wednesday, November 09, 2011 9:33 AM To: NANOG Subject: Comcast IPv6 Update Update from http://www.comcast6.net IPv6 Pilot Market Deployment Begins Wednesday, November 9, 2011 Comcast has started our first pilot market deployment of IPv6 in limited areas of California and Colorado. This first phase supports directly connected CPE, where a single computer is directly connected to a cable device. A subsequent phase will support home gateway devices. To learn more, check out FAQs on the pilot market deployment and the announcement and technical details on our blog. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From John_Brzozowski at Cable.Comcast.com Wed Nov 9 10:54:45 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Wed, 9 Nov 2011 16:54:45 +0000 Subject: Comcast IPv6 Update In-Reply-To: <4EBAAEA3.1090905@netwolves.com> Message-ID: This is not all we are pursuing, it is part of our incremental enablement and deployment. We have a non-trivial population of users that are directly connected versus using a home router. If you notice we also mention that we will soon be sharing information about customer home gateway plans. Stay tuned. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 11/9/11 11:47 AM, "Steve Clark" wrote: > > > > On 11/09/2011 11:40 AM, Jeroen Massar wrote: > > On 2011-11-09 17:32 , Brzozowski, John wrote: > > > Update from http://www.comcast6.net >IPv6 Pilot Market Deployment Begins >Wednesday, November 9, 2011 > >Comcast has started our first pilot market deployment of IPv6... > > > > Congrats! One step closer to full deployment! > >Greets, > Jeroen > > > > > Sort of interesting that you are only > handing out a single address and not a prefix - which seems > contradictory > to all recommended practices. > > Will this be a continued effort for ISP's to charge for extra > routable addresses? > > My $.02 > > > > > -- > Stephen Clark > NetWolves > Sr. Software Engineer III > Phone: 813-579-3200 > Fax: 813-882-0209 > Email: steve.clark at netwolves.com > http://www.netwolves.com > > > From John_Brzozowski at Cable.Comcast.com Wed Nov 9 10:56:03 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Wed, 9 Nov 2011 16:56:03 +0000 Subject: Comcast IPv6 Update In-Reply-To: Message-ID: :) ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 11/9/11 11:49 AM, "Cameron Byrne" wrote: >On Wed, Nov 9, 2011 at 8:40 AM, Jeroen Massar wrote: >> On 2011-11-09 17:32 , Brzozowski, John wrote: >>> Update from http://www.comcast6.net >>> IPv6 Pilot Market Deployment Begins >>> Wednesday, November 9, 2011 >>> >>> Comcast has started our first pilot market deployment of IPv6... >> >> Congrats! One step closer to full deployment! >> > >+1 > >Glad to hear some good news about IPv6 deployment. Now, lets talk >about deployment in Seattle :) From Jason_Livingood at cable.comcast.com Wed Nov 9 10:58:03 2011 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 9 Nov 2011 16:58:03 +0000 Subject: Comcast IPv6 Update In-Reply-To: Message-ID: 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 matthew at walster.org Wed Nov 9 12:07:34 2011 From: matthew at walster.org (Matthew Walster) Date: Wed, 9 Nov 2011 18:07:34 +0000 Subject: Logs Bank In-Reply-To: References: Message-ID: On 8 November 2011 19:59, wrote: > > If I may ask, is there any OSS that can serve as a log bank or log server, Do you mean OSS, or do you mean free? M From nathan at atlasnetworks.us Wed Nov 9 12:10:19 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 9 Nov 2011 18:10:19 +0000 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBA72ED.2010909@gmail.com> References: <20111109122227.GA5320@gsp.org> <4EBA72ED.2010909@gmail.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5E2F71@ex-mb-1.corp.atlasnetworks.us> > An important feature lacking for now as far as I know is content/web > filtering especially for corporates wishing to block inappropriate/time > wasting content like facebook. Addition of this would place it a par > with the best like Sonicwall and Fortinet. At a previous employer, we utilized a Fortigate 200B to replace multiple boxen (two firewalls, barracuda, etc). I found it utterly underpowered for the featureset (even with much of it disabled), and its ability to utilize multiple WAN connections was extremely limited. I realize this is only a low-to-midline example of their lineup, but I was consistently surprised by how easy it was to overwhelm the device, especially given the price-point. The only thing I remember liking was the SSL-VPN functionality, but we couldn't use it because there was no Vista support at the time, so that was disabled too. Now, perhaps they've made progress, or their higher end devices perform better - just sharing my experience with the 200B. Nathan From dmburgess at linktechs.net Wed Nov 9 12:16:28 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Wed, 9 Nov 2011 12:16:28 -0600 Subject: Firewalls - Ease of Use and Maintenance? References: <4EB9BC04.5010103@gmail.com> Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50BA68A49@ltiserver.lti.local> Another alternative is RouterOS/MikroTik. Plenty of high end solutions and low end. ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > -----Original Message----- > From: -Hammer- [mailto:bhmccie at gmail.com] > Sent: Tuesday, November 08, 2011 5:32 PM > To: nanog at nanog.org > Subject: Re: Firewalls - Ease of Use and Maintenance? > > You've worked with all the big dogs. What are you looking for? > Alternative options? > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 11/08/2011 05:06 PM, Jones, Barry wrote: > > Hello all. > > I am potentially looking at firewall products and wanted suggestions as to > the easiest firewalls to install, configure and maintain? I have a few small > networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at another. > I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), and > each have strong and not as strong features for ease of use. Like everyone, > I'm resource challenged and need an easy solution to stand up and operate. > > > > Feel free to ping me offline - and thank you for the assistance. > > > > ---------------------------------------- > > Barry Jones - CISSP GSNA > > Project Manager II > > Sempra Energy Utilities > > (760) 271-6822 > > > > P please don't print this e-mail unless you really need to. > > ---------------------------------------- > > > > From Valdis.Kletnieks at vt.edu Wed Nov 9 12:29:43 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 09 Nov 2011 13:29:43 -0500 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: Your message of "Wed, 09 Nov 2011 08:00:01 CST." <201111091400.pA9E01lg081698@aurora.sol.net> References: <201111091400.pA9E01lg081698@aurora.sol.net> Message-ID: <9283.1320863383@turing-police.cc.vt.edu> On Wed, 09 Nov 2011 08:00:01 CST, Joe Greco said: > > On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote: > > > An important feature lacking for now as far as I know is content/web > > > filtering especially for corporates wishing to block > > > inappropriate/time wasting content like facebook. > > 1. That's not a firewall function. That's a censorship function. > Is it "censorship" not to want unwanted connection attempts to our > gear, and block unsolicited TCP connections inbound? > Is it "censorship" not to want unwanted exploit attempts to our > gear, and run everything through ClamAV, and use blocklists to > prevent users inadvertently pulling content from known malware sites? I do believe that Alex was saying "blocking outbound access to time wasters like Facebook" is a censorship function, not a firewall function. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From zeusdadog at gmail.com Wed Nov 9 12:47:37 2011 From: zeusdadog at gmail.com (Jay Nakamura) Date: Wed, 9 Nov 2011 13:47:37 -0500 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does Message-ID: We ran into a strange situation yesterday that I am still trying to figure out. We have many VoIP customers but yesterday suddenly select few of them couldn't reach the SIP provider's network from our network. I could traceroute to the SIP providers server from the affected clients' IP just fine. I confirmed that the SIP traffic was leaving our network out the interface to the upstream provider and the SIP provider says they couldn't see the SIP traffic come into their border router. SIP traffic coming from SIP provider to the affected customer came through fine. It's just Us -> SIP server was a problem. I thought there may be some strange BGP issue going on but we had other customers within the same /24 as the affected customers and they were connecting fine. The traffic at the time traversed Our network -> Qwest/century link -> Level 3 -> SIP provider I changed the routing around so it would go through our other upstream, AT&T, and it started working. With AT&T, the route was Our network -> AT&T -> Level 3 -> SIP provider So my questions is, is it possible there is some kind of filter at Qwest or Level 3 that is dropping traffic only for udp 5060 for select few IPs? That's the only explanation I can come up with other than the whole Juniper BGP issue 2 days ago left something in between in a strange state? I read the post about XO doing filtering on transit traffic, I haven't seen anyone say Level 3 or Qwest is doing the same. From nick at foobar.org Wed Nov 9 12:58:59 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 09 Nov 2011 18:58:59 +0000 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> Message-ID: <4EBACD73.60609@foobar.org> On 09/11/2011 15:18, Jonathan Lassoff wrote: > I've found that this works decently well, via pfsync. I meant config sync, not state sync. Nick From sean at seanharlow.info Wed Nov 9 12:59:56 2011 From: sean at seanharlow.info (Sean Harlow) Date: Wed, 9 Nov 2011 13:59:56 -0500 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: References: Message-ID: <1A009F7C-6D9C-4CD4-9206-3027D4ADEB70@seanharlow.info> I can't say I have a specific answer to your question, but yesterday I was seeing major packet loss on outbound audio from all my VoIP customers using Qwest and going in to servers on L3. It's entirely possible that SIP was also being lost, just the audio was the more notable and pressing issue. It seems to be resolved at this point, but we have not yet heard from Qwest what the actual problem was. This was with sites in Northeast Ohio and the Chicago area connecting to servers in New York and LA for what it's worth. ---------- Sean Harlow sean at seanharlow.info On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote: > We ran into a strange situation yesterday that I am still trying to > figure out. We have many VoIP customers but yesterday suddenly select > few of them couldn't reach the SIP provider's network from our > network. > > I could traceroute to the SIP providers server from the affected > clients' IP just fine. I confirmed that the SIP traffic was leaving > our network out the interface to the upstream provider and the SIP > provider says they couldn't see the SIP traffic come into their border > router. > > SIP traffic coming from SIP provider to the affected customer came > through fine. It's just Us -> SIP server was a problem. > > I thought there may be some strange BGP issue going on but we had > other customers within the same /24 as the affected customers and they > were connecting fine. > > The traffic at the time traversed > > Our network -> Qwest/century link -> Level 3 -> SIP provider > > I changed the routing around so it would go through our other > upstream, AT&T, and it started working. With AT&T, the route was > > Our network -> AT&T -> Level 3 -> SIP provider > > So my questions is, is it possible there is some kind of filter at > Qwest or Level 3 that is dropping traffic only for udp 5060 for select > few IPs? That's the only explanation I can come up with other than > the whole Juniper BGP issue 2 days ago left something in between in a > strange state? I read the post about XO doing filtering on transit > traffic, I haven't seen anyone say Level 3 or Qwest is doing the same. > From preston.parcell at viawest.com Wed Nov 9 13:04:01 2011 From: preston.parcell at viawest.com (Preston Parcell) Date: Wed, 9 Nov 2011 11:04:01 -0800 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: <1A009F7C-6D9C-4CD4-9206-3027D4ADEB70@seanharlow.info> References: <1A009F7C-6D9C-4CD4-9206-3027D4ADEB70@seanharlow.info> Message-ID: What was the timeframe for your issues? Just curious since we saw some strangeness last night. Preston -----Original Message----- From: Sean Harlow [mailto:sean at seanharlow.info] Sent: Wednesday, November 09, 2011 12:00 PM To: Jay Nakamura Cc: NANOG Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does I can't say I have a specific answer to your question, but yesterday I was seeing major packet loss on outbound audio from all my VoIP customers using Qwest and going in to servers on L3. It's entirely possible that SIP was also being lost, just the audio was the more notable and pressing issue. It seems to be resolved at this point, but we have not yet heard from Qwest what the actual problem was. This was with sites in Northeast Ohio and the Chicago area connecting to servers in New York and LA for what it's worth. ---------- Sean Harlow sean at seanharlow.info On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote: > We ran into a strange situation yesterday that I am still trying to > figure out. We have many VoIP customers but yesterday suddenly select > few of them couldn't reach the SIP provider's network from our > network. > > I could traceroute to the SIP providers server from the affected > clients' IP just fine. I confirmed that the SIP traffic was leaving > our network out the interface to the upstream provider and the SIP > provider says they couldn't see the SIP traffic come into their border > router. > > SIP traffic coming from SIP provider to the affected customer came > through fine. It's just Us -> SIP server was a problem. > > I thought there may be some strange BGP issue going on but we had > other customers within the same /24 as the affected customers and they > were connecting fine. > > The traffic at the time traversed > > Our network -> Qwest/century link -> Level 3 -> SIP provider > > I changed the routing around so it would go through our other > upstream, AT&T, and it started working. With AT&T, the route was > > Our network -> AT&T -> Level 3 -> SIP provider > > So my questions is, is it possible there is some kind of filter at > Qwest or Level 3 that is dropping traffic only for udp 5060 for select > few IPs? That's the only explanation I can come up with other than > the whole Juniper BGP issue 2 days ago left something in between in a > strange state? I read the post about XO doing filtering on transit > traffic, I haven't seen anyone say Level 3 or Qwest is doing the same. > From nathan at atlasnetworks.us Wed Nov 9 13:04:52 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 9 Nov 2011 19:04:52 +0000 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBACD73.60609@foobar.org> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5E3E52@ex-mb-1.corp.atlasnetworks.us> > I meant config sync, not state sync. I have multiple deployments of the config synchronization working just fine. :) From jlarsen at richweb.com Wed Nov 9 13:07:10 2011 From: jlarsen at richweb.com (C. Jon Larsen) Date: Wed, 9 Nov 2011 14:07:10 -0500 (EST) Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBACD73.60609@foobar.org> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> Message-ID: On Wed, 9 Nov 2011, Nick Hilliard wrote: > On 09/11/2011 15:18, Jonathan Lassoff wrote: >> I've found that this works decently well, via pfsync. > > I meant config sync, not state sync. put the main portion of the conf in subversion as an include file and factor out local differences in the configs with macros that are defined in pf.conf Easy. From zeusdadog at gmail.com Wed Nov 9 13:08:00 2011 From: zeusdadog at gmail.com (Jay Nakamura) Date: Wed, 9 Nov 2011 14:08:00 -0500 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: References: <1A009F7C-6D9C-4CD4-9206-3027D4ADEB70@seanharlow.info> Message-ID: It started sometime Tuesday morning. I have yet to set the route back to Qwest. I am going to do that tonight and test it. On Wed, Nov 9, 2011 at 2:04 PM, Preston Parcell wrote: > What was the timeframe for your issues? Just curious since we saw some strangeness last night. > > > Preston > > > > -----Original Message----- > From: Sean Harlow [mailto:sean at seanharlow.info] > Sent: Wednesday, November 09, 2011 12:00 PM > To: Jay Nakamura > Cc: NANOG > Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does > > I can't say I have a specific answer to your question, but yesterday I was seeing major packet loss on outbound audio from all my VoIP customers using Qwest and going in to servers on L3. ?It's entirely possible that SIP was also being lost, just the audio was the more notable and pressing issue. ?It seems to be resolved at this point, but we have not yet heard from Qwest what the actual problem was. > > This was with sites in Northeast Ohio and the Chicago area connecting to servers in New York and LA for what it's worth. > ---------- > Sean Harlow > sean at seanharlow.info > > On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote: > >> We ran into a strange situation yesterday that I am still trying to >> figure out. ?We have many VoIP customers but yesterday suddenly select >> few of them couldn't reach the SIP provider's network from our >> network. >> >> I could traceroute to the SIP providers server from the affected >> clients' IP just fine. ?I confirmed that the SIP traffic was leaving >> our network out the interface to the upstream provider and the SIP >> provider says they couldn't see the SIP traffic come into their border >> router. >> >> SIP traffic coming from SIP provider to the affected customer came >> through fine. ?It's just Us -> SIP server was a problem. >> >> I thought there may be some strange BGP issue going on but we had >> other customers within the same /24 as the affected customers and they >> were connecting fine. >> >> The traffic at the time traversed >> >> Our network -> Qwest/century link -> Level 3 -> SIP provider >> >> I changed the routing around so it would go through our other >> upstream, AT&T, and it started working. ?With AT&T, the route was >> >> Our network -> AT&T -> Level 3 -> SIP provider >> >> So my questions is, is it possible there is some kind of filter at >> Qwest or Level 3 that is dropping traffic only for udp 5060 for select >> few IPs? ?That's the only explanation I can come up with other than >> the whole Juniper BGP issue 2 days ago left something in between in a >> strange state? ?I read the post about XO doing filtering on transit >> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same. >> > > > From leo.vegoda at icann.org Wed Nov 9 13:08:44 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 9 Nov 2011 11:08:44 -0800 Subject: Performance Issues - PTR Records In-Reply-To: <20111108122731.DF12116E2475@drugs.dv.isc.org> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl> <20111108110512.72E8116E19F7@drugs.dv.isc.org> <4EB90EF2.3030100@unfix.org> <20111108122731.DF12116E2475@drugs.dv.isc.org> Message-ID: <41F6C547EA49EC46B4EE1EB2BC2F341849F82D4BE8@EXVPMBX100-1.exc.icann.org> Mark Andrew wrote: [...] > > That said though the PTR->forward->PTR check is a proper check and a > > really great way to figure out if the source SMTP host was actually set > > up with at least some admin doing it the right way. If they can't be > > bothered to set that up, why should you bother to accept that mail, or a > > better choice, just score it a bit negatively at least. > > Which only works as a filter because ISP's decided to prevent home > users from putting valid PTR records in the DNS for their own > machines. It has nothing to do with clue or knowlege. Some do but some don't. I seem to remember a very nice little web interface for setting reverse DNS when I used xs4all's service in the Netherlands. Regards, Leo From sean at seanharlow.info Wed Nov 9 13:13:49 2011 From: sean at seanharlow.info (Sean Harlow) Date: Wed, 9 Nov 2011 14:13:49 -0500 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: References: <1A009F7C-6D9C-4CD4-9206-3027D4ADEB70@seanharlow.info> Message-ID: I saw the problems starting around 09:30 Eastern and continuing past 17:00. Looking through ticket notes I had missed when writing my previous reply it seems that a fix was confirmed around 22:30 which involved a faulty piece of equipment being replaced. I do not have specifics on what went wrong and when it was actually fixed though. ---------- Sean Harlow sean at seanharlow.info On Nov 9, 2011, at 2:04 PM, Preston Parcell wrote: > What was the timeframe for your issues? Just curious since we saw some strangeness last night. > > > Preston > > > > -----Original Message----- > From: Sean Harlow [mailto:sean at seanharlow.info] > Sent: Wednesday, November 09, 2011 12:00 PM > To: Jay Nakamura > Cc: NANOG > Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does > > I can't say I have a specific answer to your question, but yesterday I was seeing major packet loss on outbound audio from all my VoIP customers using Qwest and going in to servers on L3. It's entirely possible that SIP was also being lost, just the audio was the more notable and pressing issue. It seems to be resolved at this point, but we have not yet heard from Qwest what the actual problem was. > > This was with sites in Northeast Ohio and the Chicago area connecting to servers in New York and LA for what it's worth. > ---------- > Sean Harlow > sean at seanharlow.info > > On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote: > >> We ran into a strange situation yesterday that I am still trying to >> figure out. We have many VoIP customers but yesterday suddenly select >> few of them couldn't reach the SIP provider's network from our >> network. >> >> I could traceroute to the SIP providers server from the affected >> clients' IP just fine. I confirmed that the SIP traffic was leaving >> our network out the interface to the upstream provider and the SIP >> provider says they couldn't see the SIP traffic come into their border >> router. >> >> SIP traffic coming from SIP provider to the affected customer came >> through fine. It's just Us -> SIP server was a problem. >> >> I thought there may be some strange BGP issue going on but we had >> other customers within the same /24 as the affected customers and they >> were connecting fine. >> >> The traffic at the time traversed >> >> Our network -> Qwest/century link -> Level 3 -> SIP provider >> >> I changed the routing around so it would go through our other >> upstream, AT&T, and it started working. With AT&T, the route was >> >> Our network -> AT&T -> Level 3 -> SIP provider >> >> So my questions is, is it possible there is some kind of filter at >> Qwest or Level 3 that is dropping traffic only for udp 5060 for select >> few IPs? That's the only explanation I can come up with other than >> the whole Juniper BGP issue 2 days ago left something in between in a >> strange state? I read the post about XO doing filtering on transit >> traffic, I haven't seen anyone say Level 3 or Qwest is doing the same. >> > > From listas at esds.com.br Wed Nov 9 13:18:12 2011 From: listas at esds.com.br (Eduardo Schoedler) Date: Wed, 9 Nov 2011 17:18:12 -0200 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <13175F96BDC3B34AB1425BAE905B3CE50BA68A49@ltiserver.lti.local> References: <4EB9BC04.5010103@gmail.com> <13175F96BDC3B34AB1425BAE905B3CE50BA68A49@ltiserver.lti.local> Message-ID: <8C123BAE-CAE5-457B-8838-4828AA1D7AF6@esds.com.br> How about Endian Firewalls ? -- Eduardo Schoedler Sent via iPhone Em 09/11/2011, ?s 16:16, "Dennis Burgess" escreveu: > Another alternative is RouterOS/MikroTik. Plenty of high end solutions > and low end. > > ----------------------------------------------------------- > Dennis Burgess, Mikrotik Certified Trainer > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270 Website: http://www.linktechs.net > LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > >> -----Original Message----- >> From: -Hammer- [mailto:bhmccie at gmail.com] >> Sent: Tuesday, November 08, 2011 5:32 PM >> To: nanog at nanog.org >> Subject: Re: Firewalls - Ease of Use and Maintenance? >> >> You've worked with all the big dogs. What are you looking for? >> Alternative options? >> >> -Hammer- >> >> "I was a normal American nerd" >> -Jack Herer >> >> >> >> On 11/08/2011 05:06 PM, Jones, Barry wrote: >>> Hello all. >>> I am potentially looking at firewall products and wanted suggestions > as to >> the easiest firewalls to install, configure and maintain? I have a few > small >> networks ( 50 nodes at one site, 50 odd at another, and maybe 20 at > another. >> I have worked with Cisco Pix, ASA, Netscreen, and Checkpoint (Nokia), > and >> each have strong and not as strong features for ease of use. Like > everyone, >> I'm resource challenged and need an easy solution to stand up and > operate. >>> >>> Feel free to ping me offline - and thank you for the assistance. >>> >>> ---------------------------------------- >>> Barry Jones - CISSP GSNA >>> Project Manager II >>> Sempra Energy Utilities >>> (760) 271-6822 >>> >>> P please don't print this e-mail unless you really need to. >>> ---------------------------------------- >>> >>> > From owen at impulse.net Wed Nov 9 13:21:09 2011 From: owen at impulse.net (Owen Roth) Date: Wed, 9 Nov 2011 11:21:09 -0800 (PST) Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: Message-ID: <1043806173.408651.1320866469574.JavaMail.root@lavender.impulse.net> Yes! Yesterday, from 9AM-10AM PST, I had a Qwest client transiting Level3 where traceroutes were working, but sip registrations were not. They were leaving fine, but not being received on the destination side. Then at 10AM-2PM PST, same client, registrations and invites were now working, but "180 RINGING" was being eaten. Things worked fully at 2PM. We only contacted Level3, and they didn't see any issues at around 1:45PM PST. Regards, Owen ----- Original Message ----- From: "Preston Parcell" To: "Sean Harlow" , "Jay Nakamura" Cc: "NANOG" Sent: Wednesday, November 9, 2011 11:04:01 AM Subject: RE: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does What was the timeframe for your issues? Just curious since we saw some strangeness last night. Preston -----Original Message----- From: Sean Harlow [mailto:sean at seanharlow.info] Sent: Wednesday, November 09, 2011 12:00 PM To: Jay Nakamura Cc: NANOG Subject: Re: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does I can't say I have a specific answer to your question, but yesterday I was seeing major packet loss on outbound audio from all my VoIP customers using Qwest and going in to servers on L3. It's entirely possible that SIP was also being lost, just the audio was the more notable and pressing issue. It seems to be resolved at this point, but we have not yet heard from Qwest what the actual problem was. This was with sites in Northeast Ohio and the Chicago area connecting to servers in New York and LA for what it's worth. ---------- Sean Harlow sean at seanharlow.info On Nov 9, 2011, at 1:47 PM, Jay Nakamura wrote: > We ran into a strange situation yesterday that I am still trying to > figure out. We have many VoIP customers but yesterday suddenly select > few of them couldn't reach the SIP provider's network from our > network. > > I could traceroute to the SIP providers server from the affected > clients' IP just fine. I confirmed that the SIP traffic was leaving > our network out the interface to the upstream provider and the SIP > provider says they couldn't see the SIP traffic come into their border > router. > > SIP traffic coming from SIP provider to the affected customer came > through fine. It's just Us -> SIP server was a problem. > > I thought there may be some strange BGP issue going on but we had > other customers within the same /24 as the affected customers and they > were connecting fine. > > The traffic at the time traversed > > Our network -> Qwest/century link -> Level 3 -> SIP provider > > I changed the routing around so it would go through our other > upstream, AT&T, and it started working. With AT&T, the route was > > Our network -> AT&T -> Level 3 -> SIP provider > > So my questions is, is it possible there is some kind of filter at > Qwest or Level 3 that is dropping traffic only for udp 5060 for select > few IPs? That's the only explanation I can come up with other than > the whole Juniper BGP issue 2 days ago left something in between in a > strange state? I read the post about XO doing filtering on transit > traffic, I haven't seen anyone say Level 3 or Qwest is doing the same. > From jgreco at ns.sol.net Wed Nov 9 13:36:02 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 9 Nov 2011 13:36:02 -0600 (CST) Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <9283.1320863383@turing-police.cc.vt.edu> Message-ID: <201111091936.pA9Ja2Di085657@aurora.sol.net> > On Wed, 09 Nov 2011 08:00:01 CST, Joe Greco said: > > > On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote: > > > > An important feature lacking for now as far as I know is content/web > > > > filtering especially for corporates wishing to block > > > > inappropriate/time wasting content like facebook. > > > > 1. That's not a firewall function. That's a censorship function. > > > Is it "censorship" not to want unwanted connection attempts to our > > gear, and block unsolicited TCP connections inbound? > > > Is it "censorship" not to want unwanted exploit attempts to our > > gear, and run everything through ClamAV, and use blocklists to > > prevent users inadvertently pulling content from known malware sites? > > I do believe that Alex was saying "blocking outbound access to time wasters > like Facebook" is a censorship function, not a firewall function. Of course he was. My point is that that's irrelevant. There are plenty of good policy reasons for wanting to block application layer stuff. The statement Alex made appeared to characterize blocking facebook as a "bad policy". As a result, one might infer that Alex's conclusion is that "firewalls shouldn't do this type of blocking." The merits of policies such as "blocking facebook" are largely beyond the scope of NANOG; I don't propose to debate that point. There are other forums to debate such censorship. However, the point I made should be easily understood: a firewall that offers tools to prevent users from visiting a certain website (via URL, let's say) is really not any different than a firewall that offers tools to prevent users from visiting a certain website (via packet firewall rules, let's say). Do you really want your users connecting to websites known to be operated by RBN, or virus infected stuff, or spyware? The difference between "we want to protect our gear against known harmful sites" and "we want to block our employees from visiting dating sites" is probably indistinguishable at a technical implementation level. So, in clearer response to Alex: who cares? That's not a NANOG issue. ... 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 jsw at inconcepts.biz Wed Nov 9 13:45:49 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 9 Nov 2011 14:45:49 -0500 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: References: Message-ID: On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura wrote: > So my questions is, is it possible there is some kind of filter at > Qwest or Level 3 that is dropping traffic only for udp 5060 for select > few IPs? ?That's the only explanation I can come up with other than I ran into exactly this problem last week with Rogers. All traffic from the client except udp/5060 could be received by us, and udp/5060 was blocked. We tested other IP addresses on our (provider) side and did not find any blocking there, so we assigned a new IP to the SIP gateway. I hardly think this can be an ordinary malfunction, but good luck getting a phone company to troubleshoot a problem with their subscribers using mobile data to connect to a third-party voice gateway... -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From nick at foobar.org Wed Nov 9 14:44:30 2011 From: nick at foobar.org (Nick Hilliard) Date: Wed, 09 Nov 2011 20:44:30 +0000 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> Message-ID: <4EBAE62E.5090706@foobar.org> On 09/11/2011 19:07, C. Jon Larsen wrote: > put the main portion of the conf in subversion as an include file and > factor out local differences in the configs with macros that are defined in > pf.conf > > Easy. As I said, it's not a pf problem. Commercial firewalls will do all this sort of thing off the shelf. It's a pain to have to write scripts to do this manually. Nick From jra at baylink.com Wed Nov 9 14:45:48 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 9 Nov 2011 15:45:48 -0500 (EST) Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: Message-ID: <7566167.2223.1320871548262.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeff Wheeler" > On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura > wrote: > > So my questions is, is it possible there is some kind of filter at > > Qwest or Level 3 that is dropping traffic only for udp 5060 for select > > few IPs? That's the only explanation I can come up with other than > > I ran into exactly this problem last week with Rogers. All traffic > from the client except udp/5060 could be received by us, and udp/5060 > was blocked. We tested other IP addresses on our (provider) side and > did not find any blocking there, so we assigned a new IP to the SIP > gateway. I hardly think this can be an ordinary malfunction, but good > luck getting a phone company to troubleshoot a problem with their > subscribers using mobile data to connect to a third-party voice > gateway... Well, just a couple of days ago, we discussed that XO does this kind of rifle-bullet filtering in certain circumstances; is any party getting their connectivity from 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 jared at puck.nether.net Wed Nov 9 15:39:08 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 9 Nov 2011 16:39:08 -0500 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: References: Message-ID: <12F5AF54-DD9E-414F-8142-A055C4E405CF@puck.nether.net> On Nov 9, 2011, at 2:45 PM, Jeff Wheeler wrote: > On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura wrote: >> So my questions is, is it possible there is some kind of filter at >> Qwest or Level 3 that is dropping traffic only for udp 5060 for select >> few IPs? That's the only explanation I can come up with other than > > I ran into exactly this problem last week with Rogers. All traffic > from the client except udp/5060 could be received by us, and udp/5060 > was blocked. We tested other IP addresses on our (provider) side and > did not find any blocking there, so we assigned a new IP to the SIP > gateway. I hardly think this can be an ordinary malfunction, but good > luck getting a phone company to troubleshoot a problem with their > subscribers using mobile data to connect to a third-party voice > gateway? I've seen UDP/5060 be intercepted or blocked by various providers. This is common in international markets. If you are doing VoIP over the public internet, it may be worthwhile to invest in software or hardware that can VPN either 'back' or 'out' to the internet. I have a PPTP VPN solution I use to escape various hotel networks. You can even do an install on a Linux box with the poptop/pptpd solution. (Having a ssh server on tcp/80 and tcp/443 also can help, and is part of 'being prepared'). - Jared From owen at delong.com Wed Nov 9 15:59:33 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Nov 2011 13:59:33 -0800 Subject: Comcast IPv6 Update In-Reply-To: References: Message-ID: <46051B98-2CD0-4DAD-9CD3-ABD6D6C97079@delong.com> This is excellent news, John and I encourage you and the folks at Comcast to keep up the good work. I wait with baited breath for the day I can move my business class connection to IPv6. Owen On Nov 9, 2011, at 8:54 AM, Brzozowski, John wrote: > This is not all we are pursuing, it is part of our incremental enablement > and deployment. We have a non-trivial population of users that are > directly connected versus using a home router. If you notice we also > mention that we will soon be sharing information about customer home > gateway plans. > > Stay tuned. > > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski at cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > > > > On 11/9/11 11:47 AM, "Steve Clark" wrote: > >> >> >> >> On 11/09/2011 11:40 AM, Jeroen Massar wrote: >> >> On 2011-11-09 17:32 , Brzozowski, John wrote: >> >> >> Update from http://www.comcast6.net >> IPv6 Pilot Market Deployment Begins >> Wednesday, November 9, 2011 >> >> Comcast has started our first pilot market deployment of IPv6... >> >> >> >> Congrats! One step closer to full deployment! >> >> Greets, >> Jeroen >> >> >> >> >> Sort of interesting that you are only >> handing out a single address and not a prefix - which seems >> contradictory >> to all recommended practices. >> >> Will this be a continued effort for ISP's to charge for extra >> routable addresses? >> >> My $.02 >> >> >> >> >> -- >> Stephen Clark >> NetWolves >> Sr. Software Engineer III >> Phone: 813-579-3200 >> Fax: 813-882-0209 >> Email: steve.clark at netwolves.com >> http://www.netwolves.com >> >> >> > From marka at isc.org Wed Nov 9 16:07:10 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Nov 2011 09:07:10 +1100 Subject: Performance Issues - PTR Records In-Reply-To: Your message of "Wed, 09 Nov 2011 11:08:44 -0800." <41F6C547EA49EC46B4EE1EB2BC2F341849F82D4BE8@EXVPMBX100-1.exc.icann.org> References: <20111107011021.5CEB316CD13E@drugs.dv.isc.org> <87ty6g1l4n.fsf@nemi.mork.no> <20111107.144648.74734213.sthaug@nethelp.no> <4EB8F028.8040607@dds.nl> <20111108110512.72E8116E19F7@drugs.dv.isc.org> <4EB90EF2.3030100@unfix.org> <20111108122731.DF12116E2475@drugs.dv.isc.org> <41F6C547EA49EC46B4EE1EB2BC2F341849F82D4BE8@EXVPMBX100-1.exc.icann.org> Message-ID: <20111109220710.79A4E16F9754@drugs.dv.isc.org> In message <41F6C547EA49EC46B4EE1EB2BC2F341849F82D4BE8 at EXVPMBX100-1.exc.icann.o rg>, Leo Vegoda writes: > Mark Andrew wrote: > > [...] > > > > That said though the PTR->forward->PTR check is a proper check and a > > > really great way to figure out if the source SMTP host was actually set > > > up with at least some admin doing it the right way. If they can't be > > > bothered to set that up, why should you bother to accept that mail, or = > a > > > better choice, just score it a bit negatively at least. > >=20 > > Which only works as a filter because ISP's decided to prevent home > > users from putting valid PTR records in the DNS for their own > > machines. It has nothing to do with clue or knowlege. =20 > > Some do but some don't. I seem to remember a very nice little web interface= > for setting reverse DNS when I used xs4all's service in the Netherlands.=20 > > Regards, > > Leo But many do. As I said the ability to set up PTR records has *nothing* to do with the clue level of the administrator. It has everything to do with what the ISP will let you do. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.nether.net Wed Nov 9 16:24:00 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 9 Nov 2011 17:24:00 -0500 Subject: Comcast IPv6 Update In-Reply-To: References: Message-ID: <000E444E-DD72-4DB8-AB1E-2EB8AF14B8A0@puck.nether.net> On Nov 9, 2011, at 11:58 AM, Livingood, Jason wrote: > 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. Thanks! I have been telling everyone to ask each time they phone in. I suspect there's a non-trivial number of people in this community alone that could call in for IPv6 on the business service, even if it is just a /64 for starters :) (That is all I would want myself). I'm grateful you are communicating with the community on your efforts. - Jared From blake at ispn.net Wed Nov 9 16:32:39 2011 From: blake at ispn.net (Blake Hudson) Date: Wed, 09 Nov 2011 16:32:39 -0600 Subject: Performance Issues - PTR Records In-Reply-To: <4EB2D3B4.7060700@merit.edu> References: <4EB2D3B4.7060700@merit.edu> Message-ID: <4EBAFF87.8080409@ispn.net> Larry Blunk wrote the following on 11/3/2011 12:47 PM: > On 11/02/2011 05:57 PM, Matt Chung wrote: >> I work for a regional ISP and very recently there has been an influx of >> calls reporting "slowness" when accessing certain websites (i.e >> google.com/voice/b) via HTTP. After performing a tcpdump and >> analyzing the >> session, I have been able to pinpoint the latency at the application >> layer. After the tcp session has been established, it takes up to 15-20 >> seconds before the application begins sending data. The root of the >> problem was that the PTR record for our customer(s) address does not >> exist. As soon as the record is created, latency from the >> application is >> eliminated. This is analogous to latency when accessing a server >> over SSH >> when no PTR is available. >> >> A seperate packet capture from another customer exhibiting similar >> performance behavior showed many TCP retransmissions. At first >> glance, I >> assumed this was network related however this correlates with the >> application not responding and inducing retransmissions at the TCP layer >> (different symptoms, same problem). >> >> Historically, there was no compelling reason to create PTR records >> for our >> CPE however more and more applications seem to be dependent on it. >> Although we will be assigning a record for each address, my question >> is why >> is the application (specifically HTTP) dependent on a reverse record ? >> What is the purpose? >> >> Hope this is helpful as well >> > > We recently encountered a similar issue with a customer. > The sites that had slowness issues were configured to > use the traditional Google Analytics javascript instead > of the newer asynchronous code. > The problem was not the lack of a PTR record, but rather > the in-addr delegation was pointing to lame servers that were > no longer responding (hence the long timeouts as the > Google servers attempted to perform reverse lookups > on the client IP's). As others have pointed out, as long > as there's a valid nameserver responding, a lack of PTR > record would not cause issues as an NXDOMAIN record would > be sent back immediately and the Google Analytics server > will move on. > > > -Larry Blunk > Merit Larry, you're absolutely correct. One has to wonder what the continued debate is about. The Op likely had a DNS loop, misconfiguration, or lame servers. Correcting that issue should resolve any "slowness". The issue then is whether the application requires a valid PTR (or subsequent matching forward record) such as SMTP. BTW, ARIN requires valid IN-ADDR.ARPA domain records. The specific record may be NXDOMAIN (non-existant), but the server cannot be lame - https://www.arin.net/policy/nrpm.html#seven1 I believe just about all of us on this list have agreed to this policy. However, my experience tells me that many people choose to ignore it. This thread is evidence of such. --Blake From blake at ispn.net Wed Nov 9 16:45:15 2011 From: blake at ispn.net (Blake Hudson) Date: Wed, 09 Nov 2011 16:45:15 -0600 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: References: Message-ID: <4EBB027B.8010306@ispn.net> Jay Nakamura wrote the following on 11/9/2011 12:47 PM: > We ran into a strange situation yesterday that I am still trying to > figure out. We have many VoIP customers but yesterday suddenly select > few of them couldn't reach the SIP provider's network from our > network. > > I could traceroute to the SIP providers server from the affected > clients' IP just fine. I confirmed that the SIP traffic was leaving > our network out the interface to the upstream provider and the SIP > provider says they couldn't see the SIP traffic come into their border > router. > > ... > So my questions is, is it possible there is some kind of filter at > Qwest or Level 3 that is dropping traffic only for udp 5060 for select > few IPs? That's the only explanation I can come up with other than > the whole Juniper BGP issue 2 days ago left something in between in a > strange state? I read the post about XO doing filtering on transit > traffic, I haven't seen anyone say Level 3 or Qwest is doing the same. > I've found tools like tcptraceroute (the name is deceiving, UDP is the default) and hping to be invaluable in tracking down issues like these that are obviously above the routing and into the transport layer. I'm not sure how an IP transit provider (who should be providing routing/switching) screws up transport layer connections - looks like they are arbitrarily "managing" client data. Just my $0.02. --Blake From paul at paulgraydon.co.uk Wed Nov 9 16:59:19 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Wed, 09 Nov 2011 12:59:19 -1000 Subject: Comcast IPv6 Update In-Reply-To: References: Message-ID: <4EBB05C7.2050201@paulgraydon.co.uk> On 11/09/2011 06:32 AM, Brzozowski, John wrote: > Update from http://www.comcast6.net > IPv6 Pilot Market Deployment Begins > Wednesday, November 9, 2011 > > Comcast has started our first pilot market deployment of IPv6 in limited areas of California and Colorado. This first phase supports directly connected CPE, where a single computer is directly connected to a cable device. A subsequent phase will support home gateway devices. To learn more, check out FAQs on the pilot market deployment and the announcement and technical details on our blog. > > John > Good to hear, thanks John. Hopefully Comcast's marketing/sales team can run productively with this. It might start to encourage some of the other major and minor ISPs to jump on board. Paul From mulitskiy at acedsl.com Wed Nov 9 17:20:29 2011 From: mulitskiy at acedsl.com (Michael Ulitskiy) Date: Wed, 9 Nov 2011 18:20:29 -0500 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: References: Message-ID: <201111091820.29199.mulitskiy@acedsl.com> It may also be related to QoS policy inside the carriers. Some time ago I've seen exactly the same symptoms with Verizon when sip signaling was sent marked as EF. Remarking it down to CS1 or CS3 (don't remember exactly) solved the problem. Michael On Wednesday 09 November 2011 13:47:37 Jay Nakamura wrote: > We ran into a strange situation yesterday that I am still trying to > figure out. We have many VoIP customers but yesterday suddenly select > few of them couldn't reach the SIP provider's network from our > network. > > I could traceroute to the SIP providers server from the affected > clients' IP just fine. I confirmed that the SIP traffic was leaving > our network out the interface to the upstream provider and the SIP > provider says they couldn't see the SIP traffic come into their border > router. > > SIP traffic coming from SIP provider to the affected customer came > through fine. It's just Us -> SIP server was a problem. > > I thought there may be some strange BGP issue going on but we had > other customers within the same /24 as the affected customers and they > were connecting fine. > > The traffic at the time traversed > > Our network -> Qwest/century link -> Level 3 -> SIP provider > > I changed the routing around so it would go through our other > upstream, AT&T, and it started working. With AT&T, the route was > > Our network -> AT&T -> Level 3 -> SIP provider > > So my questions is, is it possible there is some kind of filter at > Qwest or Level 3 that is dropping traffic only for udp 5060 for select > few IPs? That's the only explanation I can come up with other than > the whole Juniper BGP issue 2 days ago left something in between in a > strange state? I read the post about XO doing filtering on transit > traffic, I haven't seen anyone say Level 3 or Qwest is doing the same. > > From jimb at jsbc.cc Wed Nov 9 18:25:12 2011 From: jimb at jsbc.cc (Jim Burwell) Date: Wed, 09 Nov 2011 16:25:12 -0800 Subject: Comcast IPv6 Update In-Reply-To: References: Message-ID: <4EBB19E8.6080307@jsbc.cc> On 11/9/2011 08:58, Livingood, Jason wrote: > 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 > > Yeh. I've been waiting since before the trial started for biz class IPv6. I even read some article on one of the Comcast sites (IIRC) that one of their business class customers was doing NDS. I guess it was a one-off. :) From zeusdadog at gmail.com Wed Nov 9 21:33:44 2011 From: zeusdadog at gmail.com (Jay Nakamura) Date: Wed, 9 Nov 2011 22:33:44 -0500 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: References: Message-ID: I just removed the route to our other provider and traffic is going out Qwest again. The problem seems to be gone now. As others had similar problems during the same period using Qwest, it must have been some strange issue with Qwest. On Wed, Nov 9, 2011 at 1:47 PM, Jay Nakamura wrote: > We ran into a strange situation yesterday that I am still trying to > figure out. ?We have many VoIP customers but yesterday suddenly select > few of them couldn't reach the SIP provider's network from our > network. > > I could traceroute to the SIP providers server from the affected > clients' IP just fine. ?I confirmed that the SIP traffic was leaving > our network out the interface to the upstream provider and the SIP > provider says they couldn't see the SIP traffic come into their border > router. > > SIP traffic coming from SIP provider to the affected customer came > through fine. ?It's just Us -> SIP server was a problem. > > I thought there may be some strange BGP issue going on but we had > other customers within the same /24 as the affected customers and they > were connecting fine. > > The traffic at the time traversed > > Our network -> Qwest/century link -> Level 3 -> SIP provider > > I changed the routing around so it would go through our other > upstream, AT&T, and it started working. ?With AT&T, the route was > > Our network -> AT&T -> Level 3 -> SIP provider > > So my questions is, is it possible there is some kind of filter at > Qwest or Level 3 that is dropping traffic only for udp 5060 for select > few IPs? ?That's the only explanation I can come up with other than > the whole Juniper BGP issue 2 days ago left something in between in a > strange state? ?I read the post about XO doing filtering on transit > traffic, I haven't seen anyone say Level 3 or Qwest is doing the same. > From jbates at brightok.net Wed Nov 9 23:41:39 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Nov 2011 23:41:39 -0600 Subject: Anyone seen this kind of problem? SIP traffic not getting to destination but traceroute does In-Reply-To: <4EBB027B.8010306@ispn.net> References: <4EBB027B.8010306@ispn.net> Message-ID: <4EBB6413.9060509@brightok.net> On 11/9/2011 4:45 PM, Blake Hudson wrote: > I'm not sure how an IP transit provider (who should be providing > routing/switching) screws up transport layer connections - looks like > they are arbitrarily "managing" client data. Just my $0.02. With today's routers, all sorts of weird things can go wrong, especially if it's a hardware failure. I had an IO/FE go out on a 7200 (which is as software as you get) which attributed to a lot of weirdness. It started when the IGP updated state information on the IO card's FE, which shut down mpls switching on the router, but the LSP itself was still considered up. It then showed by freaking out the neighbor 7206 when we reboot the failing one (could no longer ping the loopback of the neighbor router with and without using the LSP, but all IGP was up and you could ping/telnet/ssh to any other IP ). Finally the reboot itself showed the true issue (required multiple power cycles and a reset of the ata card to even load IOS in an unstable state). I don't even want to think what happens when a high end router's linecard starts to fail. Jack From randy at psg.com Thu Nov 10 00:01:07 2011 From: randy at psg.com (Randy Bush) Date: Thu, 10 Nov 2011 07:01:07 +0100 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <20111109155633.GA21891@ussenterprise.ufp.org> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: > 1) The concept of Inter-RIR transfers is a bad idea. Insuring > "compatible" rules between RIR's will always be difficult at > best. no need to coordinate rules/policies at all. what we suggested in a/p three years back was simple. seller must abide by seller's local selling policy and buyer must abide by buyer's local receiving policy. randy From lasse at sdu.dk Thu Nov 10 02:56:51 2011 From: lasse at sdu.dk (Lasse Birnbaum Jensen) Date: Thu, 10 Nov 2011 09:56:51 +0100 Subject: Encrypted RPC and firewalling Message-ID: <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk> hi all I would like to know how you guys handle encypted rpc across firewalls. We utilize an ASA platform and the DCERPC inspection cant handle encrypted RPC (which is standard in most windows 2008 and default in all communication in exchange 2010). Ciscos says: disable encryption or create "allow any" rules. Do you limit the RPC port range on the windows systems and make "holes" in the firewall for these or do you disable RPC encryption ? Please share your knowledge in this area. Best regards Lasse Birnbaum Jensen Network administrator, IT-Service University of Southern Denmark Email: lasse at sdu.dk -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1927 bytes Desc: not available URL: From bill at herrin.us Thu Nov 10 06:39:15 2011 From: bill at herrin.us (William Herrin) Date: Thu, 10 Nov 2011 07:39:15 -0500 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: On Thu, Nov 10, 2011 at 1:01 AM, Randy Bush wrote: >> 1) The concept of Inter-RIR transfers is a bad idea. ?Insuring >> ? ?"compatible" rules between RIR's will always be difficult at >> ? ?best. > > no need to coordinate rules/policies at all. ?what we suggested in a/p > three years back was simple. ?seller must abide by seller's local > selling policy and buyer must abide by buyer's local receiving policy. Randy, Such a process creates a back-door requirement that participating registries race to the bottom eliminating eligibility requirements for address recipients. Failure to do so leaves their own registrants at an unfair disadvantage when trying to get addresses. The approach is, unfortunately, more simpleminded than it is simple. But really this discussion belongs on the ARIN PPML where your input would be most welcome. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Thu Nov 10 06:50:39 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Nov 2011 07:50:39 -0500 Subject: Encrypted RPC and firewalling In-Reply-To: Your message of "Thu, 10 Nov 2011 09:56:51 +0100." <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk> References: <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk> Message-ID: <42850.1320929439@turing-police.cc.vt.edu> On Thu, 10 Nov 2011 09:56:51 +0100, Lasse Birnbaum Jensen said: > I would like to know how you guys handle encypted rpc across firewalls. You can always just set the firewall to ban RPC in general, whether or not it's encrypted (while you're there, close off ports 137-139 and other chucklehead stuff like that), and just make the user who's outside the firewall VPN in. That's a nice, simple, well-understood configuration that almost all software and even most users can handle. (We don't actually do a big monolithic firewall box - but pretty much everything has an iptables ruleset loaded that says "if your source IP isn't inside our 2 /16s, your packets go bye bye". And there's a nice PPTP-based VPN solution in place that even a humanities professor emeritus can use ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Nov 10 06:50:39 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Nov 2011 07:50:39 -0500 Subject: Encrypted RPC and firewalling In-Reply-To: Your message of "Thu, 10 Nov 2011 09:56:51 +0100." <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk> References: <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk> Message-ID: <42850.1320929439@turing-police.cc.vt.edu> On Thu, 10 Nov 2011 09:56:51 +0100, Lasse Birnbaum Jensen said: > I would like to know how you guys handle encypted rpc across firewalls. You can always just set the firewall to ban RPC in general, whether or not it's encrypted (while you're there, close off ports 137-139 and other chucklehead stuff like that), and just make the user who's outside the firewall VPN in. That's a nice, simple, well-understood configuration that almost all software and even most users can handle. (We don't actually do a big monolithic firewall box - but pretty much everything has an iptables ruleset loaded that says "if your source IP isn't inside our 2 /16s, your packets go bye bye". And there's a nice PPTP-based VPN solution in place that even a humanities professor emeritus can use ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Thu Nov 10 06:51:17 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Nov 2011 07:51:17 -0500 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: Your message of "Thu, 10 Nov 2011 07:39:15 EST." References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: <42872.1320929477@turing-police.cc.vt.edu> On Thu, 10 Nov 2011 07:39:15 EST, William Herrin said: > Such a process creates a back-door requirement that participating > registries race to the bottom eliminating eligibility requirements for > address recipients. When was the last time this industry turned down a chance to have a race to the bottom? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From randy at psg.com Thu Nov 10 07:28:50 2011 From: randy at psg.com (Randy Bush) Date: Thu, 10 Nov 2011 14:28:50 +0100 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: >> no need to coordinate rules/policies at all. ?what we suggested in a/p >> three years back was simple. ?seller must abide by seller's local >> selling policy and buyer must abide by buyer's local receiving policy. > > Such a process creates a back-door requirement that participating > registries race to the bottom eliminating eligibility requirements for > address recipients. Failure to do so leaves their own registrants at > an unfair disadvantage when trying to get addresses. i am sure the americans who think all address space should righfully be theirs can dream up paranoid scenarios for anything. but dear canute, the tide is coming, get over it or get wet. they do not sell enough enough anti-nausea meds here for me to read the arin ppml list. randy From mysidia at gmail.com Thu Nov 10 07:36:58 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 10 Nov 2011 07:36:58 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBAE62E.5090706@foobar.org> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> Message-ID: On Wed, Nov 9, 2011 at 2:44 PM, Nick Hilliard wrote: > On 09/11/2011 19:07, C. Jon Larsen wrote: > As I said, it's not a pf problem. ?Commercial firewalls will do all this > sort of thing off the shelf. ?It's a pain to have to write scripts to do this manually. Ah... the high cost of 'free' products, you have to do some scripting, or pay another organization to support it / do scripting work for you. The advantage is... you _can_ do a small amount of scripting or programming to add minor additional required functionality. And a very large number commercial firewalls do not have config synchronization, except, perhaps between a failover pair, anyways. Anyways... I can see synchronizing blacklists on a firewall, or having a firewall configured to fetch certain 'drop' rules from a HTTPS URL. Otherwise: the thought of mass synchronization of lots of firewalls can be bad in that it creates a single point of system compromise; supposing the synchronization source machine were compromised, one dirty rule inserted by an intruder followed by a kick off of the sync mechanism, and then actions to break it/prevent further syncing, defeats the security of the entire deployment.... -- -JH From cja at daydream.com Thu Nov 10 07:38:16 2011 From: cja at daydream.com (CJ Aronson) Date: Thu, 10 Nov 2011 06:38:16 -0700 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: So Randy.. Are you in favor or opposed to 2011-1? Thanks! ----Cathy On Thu, Nov 10, 2011 at 6:28 AM, Randy Bush wrote: > >> no need to coordinate rules/policies at all. what we suggested in a/p > >> three years back was simple. seller must abide by seller's local > >> selling policy and buyer must abide by buyer's local receiving policy. > > > > Such a process creates a back-door requirement that participating > > registries race to the bottom eliminating eligibility requirements for > > address recipients. Failure to do so leaves their own registrants at > > an unfair disadvantage when trying to get addresses. > > i am sure the americans who think all address space should righfully be > theirs can dream up paranoid scenarios for anything. but dear canute, > the tide is coming, get over it or get wet. > > they do not sell enough enough anti-nausea meds here for me to read the > arin ppml list. > > randy > > From mhuff at ox.com Thu Nov 10 07:38:35 2011 From: mhuff at ox.com (Matthew Huff) Date: Thu, 10 Nov 2011 08:38:35 -0500 Subject: Encrypted RPC and firewalling In-Reply-To: <42850.1320929439@turing-police.cc.vt.edu> References: <2E350517-A6A8-4097-AE60-BAF2FA090877@sdu.dk> <42850.1320929439@turing-police.cc.vt.edu> Message-ID: <483E6B0272B0284BA86D7596C40D29F901212962120E@PUR-EXCH07.ox.com> Also, Most enterprises that support Exchange remote access use RPC over HTTPS which is encrypted and easy to allow on the firewall. ---- 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: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Thursday, November 10, 2011 7:51 AM > To: Lasse Birnbaum Jensen > Cc: nanog at nanog.org > Subject: Re: Encrypted RPC and firewalling > > On Thu, 10 Nov 2011 09:56:51 +0100, Lasse Birnbaum Jensen said: > > I would like to know how you guys handle encypted rpc across > firewalls. > > You can always just set the firewall to ban RPC in general, whether or > not it's encrypted (while you're there, close off ports 137-139 and > other chucklehead stuff like that), and just make the user who's > outside the firewall VPN in. That's a nice, simple, well-understood > configuration that almost all software and even most users can handle. > > (We don't actually do a big monolithic firewall box - but pretty much > everything has an iptables ruleset loaded that says "if your source IP > isn't inside our 2 /16s, your packets go bye bye". And there's a nice > PPTP-based VPN solution in place that even a humanities professor > emeritus can use ;) From randy at psg.com Thu Nov 10 07:44:12 2011 From: randy at psg.com (Randy Bush) Date: Thu, 10 Nov 2011 14:44:12 +0100 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: > So Randy.. Are you in favor or opposed to 2011-1? against From bill at herrin.us Thu Nov 10 07:48:04 2011 From: bill at herrin.us (William Herrin) Date: Thu, 10 Nov 2011 08:48:04 -0500 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: On Thu, Nov 10, 2011 at 8:28 AM, Randy Bush wrote: > i am sure the americans who think all address space should righfully be > theirs can dream up paranoid scenarios for anything. ?but dear canute, > the tide is coming, get over it or get wet. Randy, You're fortunate that you speak for a minority. If you didn't, we'd tell the bunch of you to go to hell instead of valiantly seeking to improve the situation in which APNIC finds itself. > they do not sell enough enough anti-nausea meds here for me to read the > arin ppml list. It's your privilege to make uneducated snipes from afar. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Thu Nov 10 07:51:02 2011 From: randy at psg.com (Randy Bush) Date: Thu, 10 Nov 2011 14:51:02 +0100 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: > You're fortunate that you speak for a minority. actually, that time has passed. you're the minority. there are more non-americans than american rir members, there are more legacy holders than arin junior vigilantes, ... observe how the american 'global' proposal flew. randy From bicknell at ufp.org Thu Nov 10 07:56:18 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 10 Nov 2011 05:56:18 -0800 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: <20111110135618.GA82609@ussenterprise.ufp.org> In a message written on Thu, Nov 10, 2011 at 02:28:50PM +0100, Randy Bush wrote: > i am sure the americans who think all address space should righfully be > theirs can dream up paranoid scenarios for anything. but dear canute, > the tide is coming, get over it or get wet. I believe you have made an incorrect assumption as to why some folks are against transfers. Quite frankly, if it made you (and the rest of the world) happier I would support a proposal to reclaim all unused legacy space in the ARIN region and divide 100% of it among the other RIR's. We'd be better off without it. The real problem is, if people spent even 10% of the time spent arguing over how to buy/sell/trade/swap IPv4 space deploying IPv6 space we wouldn't be havng this discussion, as no one would need any more IPv4 space at this point since we would all be removing it from our network. The tide is coming. The tide is wet. The tide is full of IPv6 water. Get over it. -- 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 randy at psg.com Thu Nov 10 08:04:50 2011 From: randy at psg.com (Randy Bush) Date: Thu, 10 Nov 2011 15:04:50 +0100 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <20111110135618.GA82609@ussenterprise.ufp.org> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> Message-ID: > The real problem is, if people spent even 10% of the time spent > arguing over how to buy/sell/trade/swap IPv4 space deploying IPv6 > space we wouldn't be havng this discussion, as no one would need > any more IPv4 space at this point since we would all be removing > it from our network. > > The tide is coming. The tide is wet. The tide is full of IPv6 water. > Get over it. i am a measurement type. it's a stretch to call things even slightly damp. not that i am happy with this. we deployed in the '90s. randy From bhmccie at gmail.com Thu Nov 10 08:52:22 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 10 Nov 2011 08:52:22 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> Message-ID: <4EBBE526.5090102@gmail.com> The other high cost of "free" that people sometimes overlook is liability. Many organizations want/need someone to hold the fire to in the event of an issue. I believe in open source and am an advocate of open source computing (this email is from my Debian (NOT UBUNTU) laptop and my BSD workstation is right beside it), but at an organizational level, if I had an open source FW and a vulnerability was allowed to get thru it and compromise customer or confidential data, my management would be looking to the vendor for answers. If I told them "it's open source, there is no "vendor"" it would not go over well. Why? Because the liability is now assumed by my company. So when the customer sues it's on me. Or (and we see these on a regular basis) when the patent troll contacts us about his patent that the open source product is violating and wants compensation the liability stops at my company. IF I am using a vendor supported platform, I can take that to my vendor and discuss options. Many (not all) large businesses have agreements with vendors that go well beyond NDAs. Agreements about liability. Healthcare/Financial/Defense all have these kinds of agreements. I'm not saying it's fair. It's just how the world works. For that reason there are some areas where open source is smart while there are other areas (a firewall you depend on to protect you) where open source may put you and your employer at risk. You have to consider that. Or... Some of us do. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 07:36 AM, Jimmy Hess wrote: > On Wed, Nov 9, 2011 at 2:44 PM, Nick Hilliard wrote: > >> On 09/11/2011 19:07, C. Jon Larsen wrote: >> As I said, it's not a pf problem. Commercial firewalls will do all this >> sort of thing off the shelf. It's a pain to have to write scripts to do this manually. >> > Ah... the high cost of 'free' products, you have to do some > scripting, or pay another organization to support it / do scripting > work for you. The advantage is... you _can_ do a small amount of > scripting or programming to add minor additional required > functionality. And a very large number commercial firewalls do not > have config synchronization, except, perhaps between a failover pair, > anyways. > > Anyways... I can see synchronizing blacklists on a firewall, or > having a firewall configured to fetch certain 'drop' rules from a > HTTPS URL. Otherwise: the thought of mass synchronization of > lots of firewalls can be bad in that it creates a single point of > system compromise; supposing the synchronization source machine > were compromised, one dirty rule inserted by an intruder followed by > a kick off of the sync mechanism, and then actions to break > it/prevent further syncing, defeats the security of the entire > deployment.... > > -- > -JH > > From rsk at gsp.org Thu Nov 10 09:14:26 2011 From: rsk at gsp.org (Richard Kulawiec) Date: Thu, 10 Nov 2011 10:14:26 -0500 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBBE526.5090102@gmail.com> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> Message-ID: <20111110151426.GA22050@gsp.org> On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote: > The other high cost of "free" that people sometimes overlook is > liability. Please point to an instance (case citation, please) where a commercial firewall vendor has been successfully litigated against -- that is, held responsible by a court of law for a failure of their product to provide the functionality that it's claimed to provide. ---rsk From bhmccie at gmail.com Thu Nov 10 09:39:29 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 10 Nov 2011 09:39:29 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <20111110151426.GA22050@gsp.org> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> Message-ID: <4EBBF031.4060200@gmail.com> OK. Right off the bat you know I can't and won't. But in some places it is common practice to make sure agreements are in place to make sure all parties are protected based on how a product is expected/designed to perform. I can't say more than that. Realize I'm speaking about things that are solely on the vendor. Not "Did you configure the ACL properly?" What you can Google is the names of companies who have settled out of court against various trolling lawsuits vs the names of companies that are still in litigation. There is a mix of both manufacturer/vendor and end customer. It all depends on the case. This shouldn't surprise you. If Toyota makes a defective brake and you slam into someone else, your insurance covers you. Eventually, if the issue scales out to the point that it is obvious that Toyota made a defective brake and it is not your fault, some insurance companies collectively will go to the government or directly to the manufacturer for compensation. This is no different. If you sell me a FW and it catches on fire thru no fault of my own and then the public finds out that FWs are catching on fire all over the place, it's a good bet that that FW vendor will be getting some lawsuits. If a FW vendor reports a product to work a certain way and instead thru a massive vulnerability or development oversight it does not the same applies. Software. Hardware. Physical (fire). Logical (vulnerability). I'm not saying that it happens all the time and I'm not even saying it's a general practice. What I'm saying is it happens. And depending on your business vertical it could be a very real consideration. COMPLETELY 100% MADE UP HYPOTHETICAL SCENARIO: I put a FW in. I put proper L3 ACLs in. I block 443 inbound. I didn't say I block HTTPS. I block 443. I test it by telnetting from the Internet to 1.1.1.1:443 and I am unable to connect. Looks good. A month later our CEO is surfing the Internet. Thru a development oversight in the product, when I NAT or PAT him to the Internet his source port is not pulled from the Ephemeral range but is instead sourced as port 443. He of course goes to sites riddled with Malware because that's what CEOs do. They click on links. So the Malware website initiates a new TCP session to destination port 443 with his NATted IP. The state table has an entry for that IP and 443 and even though this is a new TCP session the FW lets it thru. The malware site bad guys are able to retrieve confidential information about a merger and publish it. The other company that we were merging with sues us because the information is leaked to the public and adversely impacted their stock value. Everything in the above paragraph is able to be documented thru forensics and it is indisputable that the FW was properly configured and should have blocked it but didn't. The FW did NOT perform as advertised/designed. This is NOT the fault of me or my company. If a few thousand dollars is at stake nothing may come of this. If tens or hundreds of millions of dollars are at stake I promise you that our lawyers will be contacting the manufacturer whose product did not perform as advertised. They will compensate (in one way or another) us for our losses. It's a big ugly world full of lots of lawyers. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 09:14 AM, Richard Kulawiec wrote: > On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote: > >> The other high cost of "free" that people sometimes overlook is >> liability. >> > Please point to an instance (case citation, please) where a commercial > firewall vendor has been successfully litigated against -- that is, held > responsible by a court of law for a failure of their product to provide > the functionality that it's claimed to provide. > > ---rsk > > > From bicknell at ufp.org Thu Nov 10 09:53:17 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 10 Nov 2011 07:53:17 -0800 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <20111110151426.GA22050@gsp.org> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> Message-ID: <20111110155317.GA88837@ussenterprise.ufp.org> In a message written on Thu, Nov 10, 2011 at 10:14:26AM -0500, Richard Kulawiec wrote: > Please point to an instance (case citation, please) where a commercial > firewall vendor has been successfully litigated against -- that is, held > responsible by a court of law for a failure of their product to provide > the functionality that it's claimed to provide. Unsuccessful litigation has costs as well. Patent trolls have sued end-users in a number of cases for both commerical and open source software. In many cases they lose, but someone still has to shell out a pile of cash for the lawyers to defend. Just ask folks like AutoZone or DaimlerChrysler how much it cost to use Linux when they were sued by SCO and had to defend themselves. Sure, they prevailed, but I bet tens of thousands of dollars were spent on litigation. -- 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 jra at baylink.com Thu Nov 10 09:56:25 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 10 Nov 2011 10:56:25 -0500 (EST) Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <20111110155317.GA88837@ussenterprise.ufp.org> Message-ID: <3751311.2323.1320940585880.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Leo Bicknell" > Just ask folks like AutoZone or DaimlerChrysler how much it cost to use > Linux when they were sued by SCO and had to defend themselves. Sure, > they prevailed, but I bet tens of thousands of dollars were spent on > litigation. Sure. But compare that to the millions they would have spent using SCO... :-) Cheers, -- jra [1]Yes, I realize AutoZone may have been paying for their Linux distro... -- 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 alter3d at alter3d.ca Thu Nov 10 10:04:19 2011 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Thu, 10 Nov 2011 11:04:19 -0500 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBBF031.4060200@gmail.com> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> <4EBBF031.4060200@gmail.com> Message-ID: <4EBBF603.1000506@alter3d.ca> Your hypothetical scenario assumes you're the only organization compromised by the flaw (or one of very few), and not #3972 on the list, in which case the company could go bankrupt before a court can hear your case, and the "liability protection" they offered you is worth the electrons it's printed on. It's great if you're a Fortune 50 and have the legal, political and financial clout to be #1 on the lawsuit list, but nearly worthless for most organizations. - Peter On 11/10/2011 10:39 AM, -Hammer- wrote: > OK. Right off the bat you know I can't and won't. But in some places > it is common practice to make sure agreements are in place to make > sure all parties are protected based on how a product is > expected/designed to perform. I can't say more than that. Realize I'm > speaking about things that are solely on the vendor. Not "Did you > configure the ACL properly?" > > What you can Google is the names of companies who have settled out of > court against various trolling lawsuits vs the names of companies that > are still in litigation. There is a mix of both manufacturer/vendor > and end customer. It all depends on the case. > > This shouldn't surprise you. If Toyota makes a defective brake and you > slam into someone else, your insurance covers you. Eventually, if the > issue scales out to the point that it is obvious that Toyota made a > defective brake and it is not your fault, some insurance companies > collectively will go to the government or directly to the manufacturer > for compensation. This is no different. If you sell me a FW and it > catches on fire thru no fault of my own and then the public finds out > that FWs are catching on fire all over the place, it's a good bet that > that FW vendor will be getting some lawsuits. If a FW vendor reports a > product to work a certain way and instead thru a massive vulnerability > or development oversight it does not the same applies. Software. > Hardware. Physical (fire). Logical (vulnerability). I'm not saying > that it happens all the time and I'm not even saying it's a general > practice. What I'm saying is it happens. And depending on your > business vertical it could be a very real consideration. > > COMPLETELY 100% MADE UP HYPOTHETICAL SCENARIO: > > I put a FW in. I put proper L3 ACLs in. I block 443 inbound. I didn't > say I block HTTPS. I block 443. I test it by telnetting from the > Internet to 1.1.1.1:443 and I am unable to connect. Looks good. A > month later our CEO is surfing the Internet. Thru a development > oversight in the product, when I NAT or PAT him to the Internet his > source port is not pulled from the Ephemeral range but is instead > sourced as port 443. He of course goes to sites riddled with Malware > because that's what CEOs do. They click on links. So the Malware > website initiates a new TCP session to destination port 443 with his > NATted IP. The state table has an entry for that IP and 443 and even > though this is a new TCP session the FW lets it thru. The malware site > bad guys are able to retrieve confidential information about a merger > and publish it. The other company that we were merging with sues us > because the information is leaked to the public and adversely impacted > their stock value. Everything in the above paragraph is able to be > documented thru forensics and it is indisputable that the FW was > properly configured and should have blocked it but didn't. The FW did > NOT perform as advertised/designed. This is NOT the fault of me or my > company. If a few thousand dollars is at stake nothing may come of > this. If tens or hundreds of millions of dollars are at stake I > promise you that our lawyers will be contacting the manufacturer whose > product did not perform as advertised. They will compensate (in one > way or another) us for our losses. It's a big ugly world full of lots > of lawyers. > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 11/10/2011 09:14 AM, Richard Kulawiec wrote: >> On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote: >>> The other high cost of "free" that people sometimes overlook is >>> liability. >> Please point to an instance (case citation, please) where a commercial >> firewall vendor has been successfully litigated against -- that is, held >> responsible by a court of law for a failure of their product to provide >> the functionality that it's claimed to provide. >> >> ---rsk >> >> From bhmccie at gmail.com Thu Nov 10 10:06:32 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 10 Nov 2011 10:06:32 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBBF603.1000506@alter3d.ca> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> <4EBBF031.4060200@gmail.com> <4EBBF603.1000506@alter3d.ca> Message-ID: <4EBBF688.4060300@gmail.com> Look the thread was about considerations for various firewalls. Eventually it spun off to be considerations and issues with Open Source options. I was merely pointing out a consideration that some folks have to take into account. You don't have to like it, agree with it, or even believe it. But it does happen and it is out there. I was just pointing it out. Take it for what you want but arguing it is pointless. It's out there for some of us. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 10:04 AM, Peter Kristolaitis wrote: > Your hypothetical scenario assumes you're the only organization > compromised by the flaw (or one of very few), and not #3972 on the > list, in which case the company could go bankrupt before a court can > hear your case, and the "liability protection" they offered you is > worth the electrons it's printed on. It's great if you're a Fortune > 50 and have the legal, political and financial clout to be #1 on the > lawsuit list, but nearly worthless for most organizations. > > - Peter > > > On 11/10/2011 10:39 AM, -Hammer- wrote: >> OK. Right off the bat you know I can't and won't. But in some places >> it is common practice to make sure agreements are in place to make >> sure all parties are protected based on how a product is >> expected/designed to perform. I can't say more than that. Realize I'm >> speaking about things that are solely on the vendor. Not "Did you >> configure the ACL properly?" >> >> What you can Google is the names of companies who have settled out of >> court against various trolling lawsuits vs the names of companies >> that are still in litigation. There is a mix of both >> manufacturer/vendor and end customer. It all depends on the case. >> >> This shouldn't surprise you. If Toyota makes a defective brake and >> you slam into someone else, your insurance covers you. Eventually, if >> the issue scales out to the point that it is obvious that Toyota made >> a defective brake and it is not your fault, some insurance companies >> collectively will go to the government or directly to the >> manufacturer for compensation. This is no different. If you sell me a >> FW and it catches on fire thru no fault of my own and then the public >> finds out that FWs are catching on fire all over the place, it's a >> good bet that that FW vendor will be getting some lawsuits. If a FW >> vendor reports a product to work a certain way and instead thru a >> massive vulnerability or development oversight it does not the same >> applies. Software. Hardware. Physical (fire). Logical >> (vulnerability). I'm not saying that it happens all the time and I'm >> not even saying it's a general practice. What I'm saying is it >> happens. And depending on your business vertical it could be a very >> real consideration. >> >> COMPLETELY 100% MADE UP HYPOTHETICAL SCENARIO: >> >> I put a FW in. I put proper L3 ACLs in. I block 443 inbound. I didn't >> say I block HTTPS. I block 443. I test it by telnetting from the >> Internet to 1.1.1.1:443 and I am unable to connect. Looks good. A >> month later our CEO is surfing the Internet. Thru a development >> oversight in the product, when I NAT or PAT him to the Internet his >> source port is not pulled from the Ephemeral range but is instead >> sourced as port 443. He of course goes to sites riddled with Malware >> because that's what CEOs do. They click on links. So the Malware >> website initiates a new TCP session to destination port 443 with his >> NATted IP. The state table has an entry for that IP and 443 and even >> though this is a new TCP session the FW lets it thru. The malware >> site bad guys are able to retrieve confidential information about a >> merger and publish it. The other company that we were merging with >> sues us because the information is leaked to the public and adversely >> impacted their stock value. Everything in the above paragraph is able >> to be documented thru forensics and it is indisputable that the FW >> was properly configured and should have blocked it but didn't. The FW >> did NOT perform as advertised/designed. This is NOT the fault of me >> or my company. If a few thousand dollars is at stake nothing may come >> of this. If tens or hundreds of millions of dollars are at stake I >> promise you that our lawyers will be contacting the manufacturer >> whose product did not perform as advertised. They will compensate (in >> one way or another) us for our losses. It's a big ugly world full of >> lots of lawyers. >> >> -Hammer- >> >> "I was a normal American nerd" >> -Jack Herer >> >> >> >> On 11/10/2011 09:14 AM, Richard Kulawiec wrote: >>> On Thu, Nov 10, 2011 at 08:52:22AM -0600, -Hammer- wrote: >>>> The other high cost of "free" that people sometimes overlook is >>>> liability. >>> Please point to an instance (case citation, please) where a commercial >>> firewall vendor has been successfully litigated against -- that is, >>> held >>> responsible by a court of law for a failure of their product to provide >>> the functionality that it's claimed to provide. >>> >>> ---rsk >>> >>> > > From egermann at limanews.com Thu Nov 10 10:20:22 2011 From: egermann at limanews.com (Eric Germann) Date: Thu, 10 Nov 2011 08:20:22 -0800 Subject: TwTelecom engineer offlist Message-ID: <730AF3879A3A3844B3FB5A881A3DFBC8D60719AF08@VA3DIAXVS091.RED001.local> Anyone with twtelecom who can contact me off list about a possible congestion issue at one of your handoffs? Thanks EKG From jof at thejof.com Thu Nov 10 10:30:46 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Thu, 10 Nov 2011 08:30:46 -0800 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBAE62E.5090706@foobar.org> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> Message-ID: On Wed, Nov 9, 2011 at 12:44 PM, Nick Hilliard wrote: > On 09/11/2011 19:07, C. Jon Larsen wrote: >> >> put the main portion of the conf in subversion as an include file and >> factor out local differences in the configs with macros that are defined >> in >> pf.conf >> >> Easy. > > As I said, it's not a pf problem. ?Commercial firewalls will do all this > sort of thing off the shelf. ?It's a pain to have to write scripts to do > this manually. Agreed. This is rather a pain to have to do manually each time (either scp'ing or scripting). It's unfortunate that there's not a conventional script or mechanism for doing this. I have plenty of scripts from past commercial work that do this, but they're sadly tied up license-wise. I've had good luck, pf-wise, with creating a ruleset that is just identical between hosts. By keeping the interface naming/numbering scheme consistent across two hosts, the same configuration can just "work" on both. Cheers, jof From drc at virtualized.org Thu Nov 10 10:59:35 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 10 Nov 2011 08:59:35 -0800 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: Bill, On Nov 10, 2011, at 5:48 AM, William Herrin wrote: > On Thu, Nov 10, 2011 at 8:28 AM, Randy Bush wrote: >> i am sure the americans who think all address space should righfully be >> theirs can dream up paranoid scenarios for anything. but dear canute, >> the tide is coming, get over it or get wet. > You're fortunate that you speak for a minority. I don't think Randy speaks for anyone but himself. Some may, however, agree with him. > If you didn't, we'd > tell the bunch of you to go to hell instead of valiantly seeking to > improve the situation in which APNIC finds itself. Seriously? It is this sort of attitude that resulted in me giving up in disgust with the whole RIR circus. Well that and a curious note from ARIN counsel (at the direction of ARIN's board) to my then corporate counsel purportedly "expressing concern" about statements I made in a personal capacity on NANOG. Quite amusing, actually, but still disgusting. A tiny dose of reality: - The Internet (and world population as a whole) is growing most rapidly in the Asia/Pacific region. - There are companies who demand IPv4 addresses for which the combined yearly budgets of all the RIRs amounts to little more than a small fraction of what those companies spend on their lawyers alone. - APNIC no longer has IPv4 addresses to meet that demand. - There now at least 4 different organizations offering IPv4 addresses for sale (addrex.net, kalorama.com, tradeipv4.com, ipv4marketgroup.com) who are now participating in an estimated at $6 - $8 Billion market (and that's just legacy space). And you believe the couple of hundred folks who participate in ARIN are going to stand in the way of those business interests? I might gently suggest it would probably be more useful to figure out how the new market players and the "legacy" RIRs can coexist in a way that doesn't do severe damage to the Internet than it is to discuss how to rearrange the deck chairs in ever more intricate designs in order to try to maintain unjustifiable monopolies. I might suggest that but as I said, I gave up in disgust. Tell King Canute's advisors I said "hi". Regards, -drc From nick at foobar.org Thu Nov 10 11:29:40 2011 From: nick at foobar.org (Nick Hilliard) Date: Thu, 10 Nov 2011 17:29:40 +0000 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: <4EBC0A04.2010507@foobar.org> On 10/11/2011 16:59, David Conrad wrote: > Tell King Canute's advisors I said "hi". My OCD is screaming at me to point out that King Knut was attempting to show his advisers that even he couldn't control the tides. Nick From rsk at gsp.org Thu Nov 10 11:50:59 2011 From: rsk at gsp.org (Richard Kulawiec) Date: Thu, 10 Nov 2011 12:50:59 -0500 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> Message-ID: <20111110175059.GA14575@gsp.org> On Thu, Nov 10, 2011 at 08:30:46AM -0800, Jonathan Lassoff wrote: > > As I said, it's not a pf problem. ?Commercial firewalls will do all this > > sort of thing off the shelf. ?It's a pain to have to write scripts to do > > this manually. > > Agreed. This is rather a pain to have to do manually each time (either > scp'ing or scripting). It's unfortunate that there's not a > conventional script or mechanism for doing this. I don't see why this is a problem. I've been using tools like make, RCS (or CVS or subversion), perl, and rsync to maintain all kinds of unified and diverse configurations on small and large numbers of systems for many years. It's simple, it's scalable, it's easy to write, it's portable, it's robust (provided you pay attention to command exit codes), and it allows easy integration between disparate configuration files. (As an example of that last: I can cause changes in pf.conf to be synchronized with appropriately-matching changes in sendmail.cf or named.conf. Use of "make" ensures that they're kept in a consistent state. Of course, if I make a mistake, they're consistently wrong: but that's highly desirable.) Yes, you have to understand the interrelationships between all these moving parts to write the scripts/makefiles; but that's a good thing. And the payoff is that you get FAR more flexibility than any commercial product. And it's free (modulo your time investment...and you'd be investing time anyway, trying to make some vendor's setup do what you want). ---rsk From rsk at gsp.org Thu Nov 10 12:12:19 2011 From: rsk at gsp.org (Richard Kulawiec) Date: Thu, 10 Nov 2011 13:12:19 -0500 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBBF031.4060200@gmail.com> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> <4EBBF031.4060200@gmail.com> Message-ID: <20111110181219.GA26841@gsp.org> On Thu, Nov 10, 2011 at 09:39:29AM -0600, -Hammer- wrote: > OK. Right off the bat you know I can't and won't. Right. I know you can't and won't. I can't either. So we can summarily dismiss all the concerns about liability because they have no relationship to reality. You will not be suing BigFirewallCo, no matter how horribly their product fails, no matter how bad the damage is, no matter how obvious to all of us the failure is, no matter how culpable we might all agree they are, because (a) your pockets aren't as deep as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years and a lot of billable hours for everyone's attorneys. (s/you/I/ and everyone else, unless we happen to work for a Fortune 50 company...and probably not even then.) When it comes to security, I think it's better to rely on software engineering than litigation. ---rsk From bhmccie at gmail.com Thu Nov 10 12:12:21 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 10 Nov 2011 12:12:21 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <20111110181219.GA26841@gsp.org> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org> Message-ID: <4EBC1405.5010007@gmail.com> WOW. You really are naive.... -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 12:12 PM, Richard Kulawiec wrote: > On Thu, Nov 10, 2011 at 09:39:29AM -0600, -Hammer- wrote: > >> OK. Right off the bat you know I can't and won't. >> > Right. I know you can't and won't. I can't either. So we can > summarily dismiss all the concerns about liability because they > have no relationship to reality. You will not be suing BigFirewallCo, > no matter how horribly their product fails, no matter how bad the damage is, > no matter how obvious to all of us the failure is, no matter how culpable > we might all agree they are, because (a) your pockets aren't as deep > as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years > and a lot of billable hours for everyone's attorneys. (s/you/I/ and > everyone else, unless we happen to work for a Fortune 50 company...and > probably not even then.) > > When it comes to security, I think it's better to rely on software > engineering than litigation. > > ---rsk > > From jra at baylink.com Thu Nov 10 12:19:49 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 10 Nov 2011 13:19:49 -0500 (EST) Subject: Firewalls - Ease of Litigation and Subrogation In-Reply-To: <20111110181219.GA26841@gsp.org> Message-ID: <24317277.2351.1320949189583.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Richard Kulawiec" > Right. I know you can't and won't. I can't either. So we can > summarily dismiss all the concerns about liability because they > have no relationship to reality. You will not be suing BigFirewallCo, > no matter how horribly their product fails, no matter how bad the damage is, > no matter how obvious to all of us the failure is, no matter how culpable > we might all agree they are, because (a) your pockets aren't as deep > as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years > and a lot of billable hours for everyone's attorneys. (s/you/I/ and > everyone else, unless we happen to work for a Fortune 50 company...and > probably not even then.) Yeah, Rich, but come on: you and I -- and even his managers -- know that while that is true (that no one's actually going to sue anyone, and likely legally cannot anyway), that *still* won't keep Pointy Haired Bosses from making that *capability* a firm requirement. That's why their hair is pointy. 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 bhmccie at gmail.com Thu Nov 10 12:19:20 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 10 Nov 2011 12:19:20 -0600 Subject: Firewalls - Ease of Litigation and Subrogation In-Reply-To: <24317277.2351.1320949189583.JavaMail.root@benjamin.baylink.com> References: <24317277.2351.1320949189583.JavaMail.root@benjamin.baylink.com> Message-ID: <4EBC15A8.8010909@gmail.com> You guys are hilarious. OK. I give up. It never happens. I'll leave this thread alone. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 12:19 PM, Jay Ashworth wrote: > ----- Original Message ----- > >> From: "Richard Kulawiec" >> > >> Right. I know you can't and won't. I can't either. So we can >> summarily dismiss all the concerns about liability because they >> have no relationship to reality. You will not be suing BigFirewallCo, >> no matter how horribly their product fails, no matter how bad the damage is, >> no matter how obvious to all of us the failure is, no matter how culpable >> we might all agree they are, because (a) your pockets aren't as deep >> as BigFirewallCo's, and (b) you'd probably lose anyway (c) after 11 years >> and a lot of billable hours for everyone's attorneys. (s/you/I/ and >> everyone else, unless we happen to work for a Fortune 50 company...and >> probably not even then.) >> > Yeah, Rich, but come on: you and I -- and even his managers -- know that while > that is true (that no one's actually going to sue anyone, and likely legally > cannot anyway), that *still* won't keep Pointy Haired Bosses from making that > *capability* a firm requirement. > > That's why their hair is pointy. > > Cheers, > -- jra > From Valdis.Kletnieks at vt.edu Thu Nov 10 12:24:29 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 10 Nov 2011 13:24:29 -0500 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: Your message of "Thu, 10 Nov 2011 12:12:21 CST." <4EBC1405.5010007@gmail.com> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org> <4EBC1405.5010007@gmail.com> Message-ID: <8252.1320949469@turing-police.cc.vt.edu> On Thu, 10 Nov 2011 12:12:21 CST, -Hammer- said: > WOW. You really are naive.... I think Rich has been around long enough that he gets called a *lot* of things (many of them non-complimentary), but this is the first time this century anybody's called him *naive*... ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bhmccie at gmail.com Thu Nov 10 12:28:52 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 10 Nov 2011 12:28:52 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <8252.1320949469@turing-police.cc.vt.edu> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org> <4EBC1405.5010007@gmail.com> <8252.1320949469@turing-police.cc.vt.edu> Message-ID: <4EBC17E4.5060807@gmail.com> OK. Maybe I jumped to hard. But to tell me that what I'm referring to has never happened (even though I've participated) just because he hasn't heard of it is not the best way to approach an argument. When these things happen, there are agreements in place so it's not discussed. Especially when it's settled out of court. If you want some fun reading on the subject google Walker Digital or Leon Stambler. Again, I never said it happens to everyone. But it does happen and some of us have to consider it. I didn't realize it would come under such scrutiny just because it isn't widely published. Again, I'll try and leave this thread alone. -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 12:24 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 10 Nov 2011 12:12:21 CST, -Hammer- said: > >> WOW. You really are naive.... >> > I think Rich has been around long enough that he gets called a *lot* of things > (many of them non-complimentary), but this is the first time this century > anybody's called him *naive*... ;) > > From js.lists at gmail.com Thu Nov 10 12:51:14 2011 From: js.lists at gmail.com (Joe) Date: Thu, 10 Nov 2011 10:51:14 -0800 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBC17E4.5060807@gmail.com> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org> <4EBC1405.5010007@gmail.com> <8252.1320949469@turing-police.cc.vt.edu> <4EBC17E4.5060807@gmail.com> Message-ID: <3F46E049-1568-4402-A3A0-54A8D83F36E6@gmail.com> Litigation? Wow. To answer the OP: Any of the Cisco, Juniper, Sonic, Fortinet, etc can be easy to use to maintain. But I'd make sure you have a good understanding of what you intend to do, and what products will satisfy your needs. Demo's are a good idea. One person's definition of easy may not match someone else's. If you know what you're doing and want to roll your own, then go with what you're most comfortable with (linux, bad, etc). Your subject indicates you aren't comfortable with rolling your own, so there is no point to the side debate going on in this thread. Side point: For what it's worth, I use PF on OpenBSD because I like the clean and easy to read syntax. To me, that is *easier* to use, than trying to figure out some point-click GUI. The take away from this is, "what does ease of use mean to you"? Hope that helps. From bhmccie at gmail.com Thu Nov 10 12:54:48 2011 From: bhmccie at gmail.com (-Hammer-) Date: Thu, 10 Nov 2011 12:54:48 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <8252.1320949469@turing-police.cc.vt.edu> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org> <4EBC1405.5010007@gmail.com> <8252.1320949469@turing-police.cc.vt.edu> Message-ID: <4EBC1DF8.5070205@gmail.com> I changed my mind. I want to clear this up. Here is an example of where a patent troll skipped over the manufacturer and went straight for the end customer. There are dozens of these attacking all verticals and manufacturers alike for various reasons. http://dockets.justia.com/docket/texas/txedce/2:2008cv00471/113504/ So a customer buys a product that contains a technology. Then the customer is sued for possessing said technology. You don't think the customer (Merrill Lynch / BofA / Citigroup / etc) isn't gonna take that lawsuit and call the manufacturer up and tell them they are gonna eat it? You don't think a financial institution or a healthcare organization would attempt to recuperate the costs? You don't think that after the fact agreements are put in place so that frivolous lawsuits like this are appropriately handled between the manufacturer and the customer in the future? When millions of dollars are at stake? You don't have to like it. But you should be a little more objective. I am not speaking of specific cases I'm involved in. I just googled a few things and found some results.... -Hammer- "I was a normal American nerd" -Jack Herer On 11/10/2011 12:24 PM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 10 Nov 2011 12:12:21 CST, -Hammer- said: > >> WOW. You really are naive.... >> > I think Rich has been around long enough that he gets called a *lot* of things > (many of them non-complimentary), but this is the first time this century > anybody's called him *naive*... ;) > > From nathan at atlasnetworks.us Thu Nov 10 16:07:20 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 10 Nov 2011 22:07:20 +0000 Subject: Security Contact from k12.fl.us Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5E66A6@ex-mb-1.corp.atlasnetworks.us> Please contact me off-list. From nathan at atlasnetworks.us Thu Nov 10 16:14:43 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 10 Nov 2011 22:14:43 +0000 Subject: Security Contact from broward.k12.fl.us (was: Security Contact from k12.fl.us) In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B5E66A6@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C286B5E66A6@ex-mb-1.corp.atlasnetworks.us> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5E66F2@ex-mb-1.corp.atlasnetworks.us> It was pointed out to me that 'k12.fl.us' is not an organization, but rather a container. Clarification - I'm looking for a security contact from broward.k12.fl.us Nathan Eisenberg > -----Original Message----- > From: Nathan Eisenberg > Sent: Thursday, November 10, 2011 2:07 PM > To: NANOG list > Subject: Security Contact from k12.fl.us > > Please contact me off-list. From jbates at brightok.net Thu Nov 10 20:05:33 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Nov 2011 20:05:33 -0600 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <8252.1320949469@turing-police.cc.vt.edu> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org> <4EBC1405.5010007@gmail.com> <8252.1320949469@turing-police.cc.vt.edu> Message-ID: <4EBC82ED.6060603@brightok.net> On 11/10/2011 12:24 PM, Valdis.Kletnieks at vt.edu wrote: > I think Rich has been around long enough that he gets called a*lot* of things > (many of them non-complimentary), but this is the first time this century > anybody's called him*naive*...;) Given that all of humankind is naive, it would be redundant. The other things are much more entertaining. Jack From randy at psg.com Thu Nov 10 22:50:28 2011 From: randy at psg.com (Randy Bush) Date: Fri, 11 Nov 2011 13:50:28 +0900 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: > And you believe the couple of hundred folks who participate in ARIN > are going to stand in the way of those business interests? I might > gently suggest it would probably be more useful to figure out how the > new market players and the "legacy" RIRs can coexist in a way that > doesn't do severe damage to the Internet than it is to discuss how to > rearrange the deck chairs in ever more intricate designs in order to > try to maintain unjustifiable monopolies. arin control-freak vigilante insanity overwhelmed what's good for the internet long ago. randy From brett at the-watsons.org Fri Nov 11 01:15:46 2011 From: brett at the-watsons.org (Brett Watson) Date: Fri, 11 Nov 2011 00:15:46 -0700 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <20111110135618.GA82609@ussenterprise.ufp.org> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> Message-ID: On Nov 10, 2011, at 6:56 AM, Leo Bicknell wrote: > The tide is coming. The tide is wet. The tide is full of IPv6 water. > Get over it. Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three). -b From harris.hui at gmail.com Fri Nov 11 02:19:10 2011 From: harris.hui at gmail.com (Harris Hui) Date: Fri, 11 Nov 2011 16:19:10 +0800 Subject: Location of Akamai Edge servers in Hong Kong Message-ID: Hi, Does anybody know where is the Akamai Edge servers located in Hong Kong? Which ISPs they are using? Are they peering with HKIX? Please advise. Thanks Harris From chcheng at ieee.org Fri Nov 11 03:17:32 2011 From: chcheng at ieee.org (Che-Hoo CHENG) Date: Fri, 11 Nov 2011 17:17:32 +0800 Subject: Location of Akamai Edge servers in Hong Kong In-Reply-To: References: Message-ID: Yes, AS20940 is on HKIX. You can check HKIX's Looking Glass (of MLPA Route Servers) at http://www.hkix.net/hkix/hkixlg.htm or http://www.hkix.net/hkix/connected.htm . I'm sure they do BLPA over HKIX too. Regards, Che-Hoo On 11 Nov, 2011, at 4:19 PM, Harris Hui wrote: > Hi, > > Does anybody know where is the Akamai Edge servers located in Hong Kong? > Which ISPs they are using? Are they peering with HKIX? > > Please advise. > > Thanks > Harris From cdel at firsthand.net Fri Nov 11 03:34:27 2011 From: cdel at firsthand.net (Christian de Larrinaga) Date: Fri, 11 Nov 2011 09:34:27 +0000 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> Message-ID: <4D6F26F1-005B-4095-B65F-DEAF79006396@firsthand.net> Lucky rich you to have such capacious v4 connectivity to be worrying about such downstream stuff. The rest of the world is starring at abyss of zero connectivity unless it deploys v6. Solve that one. Christian On 11 Nov 2011, at 07:15, Brett Watson wrote: > On Nov 10, 2011, at 6:56 AM, Leo Bicknell wrote: > >> The tide is coming. The tide is wet. The tide is full of IPv6 water. >> Get over it. > > Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three). > > -b From jcurran at arin.net Fri Nov 11 04:47:50 2011 From: jcurran at arin.net (John Curran) Date: Fri, 11 Nov 2011 10:47:50 +0000 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> Message-ID: <9B8525E7-022F-478E-AA38-A92475C55F2D@arin.net> On Nov 10, 2011, at 11:59 AM, David Conrad wrote: > A tiny dose of reality: > - The Internet (and world population as a whole) is growing most rapidly in the Asia/Pacific region. > - There are companies who demand IPv4 addresses for which the combined yearly budgets of all the RIRs amounts to little more than a small fraction of what those companies spend on their lawyers alone. > - APNIC no longer has IPv4 addresses to meet that demand. > - There now at least 4 different organizations offering IPv4 addresses for sale (addrex.net, kalorama.com, tradeipv4.com, ipv4marketgroup.com) who are now participating in an estimated at $6 - $8 Billion market (and that's just legacy space). > > And you believe the couple of hundred folks who participate in ARIN are going to stand in the way of those business interests? I might gently suggest it would probably be more useful to figure out how the new market players and the "legacy" RIRs can coexist in a way that doesn't do severe damage to the Internet than it is to discuss how to rearrange the deck chairs in ever more intricate designs in order to try to maintain unjustifiable monopolies. David - We've got co-existence today for transfers within the ARIN region; it is now not uncommon to see ("Sale may be subject to compliance with policies of the American Registry of Internet Numbers") on various solicitations involving resources registered in the region. At present, there is no way to transfer resources in or out of the region, and whether that is desirable and under what constraints is precisely the question at hand with draft policy ARIN-2011-1. To the extent that folks have a view on this matter either in support or against, I suggest that you make that view known on the ARIN Public Policy Mailing List (ppml). As this policy will have some effect on many in the Internet community, it would be best for folks to take a moment to provide this important feedback. Thanks! /John John Curran President and CEO ARIN From bmanning at vacation.karoshi.com Fri Nov 11 04:51:38 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 11 Nov 2011 10:51:38 +0000 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <4D6F26F1-005B-4095-B65F-DEAF79006396@firsthand.net> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> <4D6F26F1-005B-4095-B65F-DEAF79006396@firsthand.net> Message-ID: <20111111105138.GA4384@vacation.karoshi.com.> actually - Paul Francis has done the community a massive favor by making the argument for NAT as a viable tool strong enough that NAT and NAT-like technologies are pervasive. NAT is even used to "glue" v4 and v6 enclaves together. So it is too early to tell if IPv6-only will be the inevitable end game (in our lifetimes), or if NAT-enabled infrastructures will continue to be pervasive, leaving v4 enclaves running for longer than our childrens live. This policy proposal is one means to track rights to use a given resource, and it is not clear to me that it has to fit in the sole provence of a single address family (although it is clearly targeted for one of them as currently written) I guess that puts me in the camp of favoring this work. For the rest of the zelots (in either camp) - put down the retoric and quit trying to teach the pigs to sing. Its a waste of your time and it annoys the pigs. /bill On Fri, Nov 11, 2011 at 09:34:27AM +0000, Christian de Larrinaga wrote: > > Lucky rich you to have such capacious v4 connectivity to be worrying about such downstream stuff. The rest of the world is starring at abyss of zero connectivity unless it deploys v6. > > Solve that one. > > > Christian > > On 11 Nov 2011, at 07:15, Brett Watson wrote: > > > On Nov 10, 2011, at 6:56 AM, Leo Bicknell wrote: > > > >> The tide is coming. The tide is wet. The tide is full of IPv6 water. > >> Get over it. > > > > Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three). > > > > -b > > From bicknell at ufp.org Fri Nov 11 08:55:03 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 11 Nov 2011 06:55:03 -0800 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> Message-ID: <20111111145503.GA48535@ussenterprise.ufp.org> In a message written on Fri, Nov 11, 2011 at 12:15:46AM -0700, Brett Watson wrote: > > The tide is coming. The tide is wet. The tide is full of IPv6 water. > > Get over it. > > Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 issues? (I'll just leave it at those three). Multi-homing in IPv6 works just like it does in IPv4. Folks may be working on better ways, but that's the reality of the moment, and it's a deployable reality. RA/DHCPv6 is being worked on, and progress is being made...although slower than I would like. But remember, IPv4 isn't done 30+ years on. The IETF has entertained proposals to improve/extend IPv4 every year. NAT wasn't in the original spec. MPLS was added much later, etc. If you expect IPv6 to have 100% feature parity day one and then never change, you have unrealistic expectations. It's deployable today. Heck Comcast is deploying to end-users as we speak. Maybe in a few scenarios it still has significant issues that there are deployment problems, but you find those by doing, not by waiting. The networks I run have been dual stacked for 5+ years. It works. -- 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 lorell at hathcock.org Fri Nov 11 09:09:46 2011 From: lorell at hathcock.org (Lorell Hathcock) Date: Fri, 11 Nov 2011 09:09:46 -0600 Subject: Savvis broken link / underperforming between DC and Atlanta? Message-ID: <004c01cca083$f36da1b0$da48e510$@hathcock.org> Any one else seeing this? This was done yesterday from Hawaii. tracert speedtest.saas.infor.com 3 5 ms 5 ms 4 ms ip64-75-240-210.aloha.net [64.75.240.210] 4 5 ms 5 ms 5 ms hnl-edge-02.inet.qwest.net [67.129.94.69] 5 * * * Request timed out. 6 56 ms 56 ms 56 ms 63-235-40-18.dia.static.qwest.net [63.235.40.18] 7 58 ms 58 ms 59 ms cr1-tenge-0-3-5-0.sanfrancisco.savvis.net [204.70.200.198] 8 138 ms 138 ms 138 ms cr1-bundle-pos2.Washington.savvis.net [204.70.200.90] 9 135 ms 136 ms 136 ms hr1-tengig-2-0-0.sterling2dc2.savvis.net [204.70.197.74] 10 139 ms 136 ms 137 ms 165.193.78.106 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. But from Houston it was fine yesterday. It took a different route. Today I have the same problem from Houston. tracert speedtest.saas.infor.com 4 2 ms 2 ms 2 ms te4-1.3509.ccr01.iah02.atlas.cogentco.com [66.28.6.21] 5 3 ms 2 ms 2 ms te0-2-0-4.ccr21.iah01.atlas.cogentco.com [154.54.3.149] 6 9 ms 10 ms 8 ms te0-1-0-5.ccr21.dfw01.atlas.cogentco.com [154.54.2.225] 7 8 ms 8 ms 8 ms te7-3.mpd01.dfw03.atlas.cogentco.com [154.54.6.66] 8 15 ms 8 ms 12 ms aer1-ge-4-2.dallasequinix.savvis.net [208.175.175.5] 9 17 ms 8 ms 15 ms 204.70.207.182 10 10 ms 9 ms 10 ms cr1-tengig0-7-5-0.Dallas.savvis.net [204.70.200.170] 11 37 ms 37 ms 37 ms cr1-tengig-0-7-0-0.Washington.savvis.net [204.70.196.105] 12 36 ms 36 ms 36 ms hr1-tengig-2-0-0.sterling2dc2.savvis.net [204.70.197.74] 13 37 ms 36 ms 37 ms 165.193.78.106 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. This the end IP address is in Rackspace in Atlanta I am told. Known issues out there? Any de-peering going on? Or is this just a firewall or private IP space that is not responding to traceroute information requests? Thanks for any help, Lorell Hathcock From BEJones at semprautilities.com Fri Nov 11 09:22:53 2011 From: BEJones at semprautilities.com (Jones, Barry) Date: Fri, 11 Nov 2011 07:22:53 -0800 Subject: Firewalls - Ease of Use and Maintenance? In-Reply-To: <4EBC82ED.6060603@brightok.net> References: <20111109122227.GA5320@gsp.org> <4EBA7F04.6000105@foobar.org> <4EBACD73.60609@foobar.org> <4EBAE62E.5090706@foobar.org> <4EBBE526.5090102@gmail.com> <20111110151426.GA22050@gsp.org> <4EBBF031.4060200@gmail.com> <20111110181219.GA26841@gsp.org> <4EBC1405.5010007@gmail.com> <8252.1320949469@turing-police.cc.vt.edu> <4EBC82ED.6060603@brightok.net> Message-ID: Hey all. I wanted to say thanks for all the advice. Barry -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Thursday, November 10, 2011 6:06 PM To: Valdis.Kletnieks at vt.edu Cc: nanog at nanog.org Subject: Re: Firewalls - Ease of Use and Maintenance? On 11/10/2011 12:24 PM, Valdis.Kletnieks at vt.edu wrote: > I think Rich has been around long enough that he gets called a*lot* > of things (many of them non-complimentary), but this is the first time > this century anybody's called him*naive*...;) Given that all of humankind is naive, it would be redundant. The other things are much more entertaining. Jack From Valdis.Kletnieks at vt.edu Fri Nov 11 09:56:18 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 11 Nov 2011 10:56:18 -0500 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: Your message of "Fri, 11 Nov 2011 00:15:46 MST." References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> Message-ID: <4387.1321026978@turing-police.cc.vt.edu> On Fri, 11 Nov 2011 00:15:46 MST, Brett Watson said: > Awesome, so you've solved the multi-homing issues with v6? The RA/DHCPv6 > issues? (I'll just leave it at those three). What multi-homing issues? We've been multihomed on the IPv6 side for... ages. And yes, there's some RA/DHCP issues - but the *practical* upshot is that it's hard to DHCP a v6-only host and get stuff like DNS and NTP servers to them. So since our users are all dual-stack, we just DCHPv4 the DNS and such to them, and it's not a major issue. If they're on our wireless, they get a globally routable IPv6 address and a NAT-ed IPv4, and DNS and such are available over the IPv4, and mostly everything Just Works (modulo the NAT dain bramage, of course). When we get a good DHCPv6, we'll roll it out. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nick at foobar.org Fri Nov 11 10:04:31 2011 From: nick at foobar.org (Nick Hilliard) Date: Fri, 11 Nov 2011 16:04:31 +0000 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <4387.1321026978@turing-police.cc.vt.edu> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> <4387.1321026978@turing-police.cc.vt.edu> Message-ID: <4EBD478F.4040703@foobar.org> On 11/11/2011 15:56, Valdis.Kletnieks at vt.edu wrote: > And yes, there's some RA/DHCP issues - but the *practical* upshot is that it's > hard to DHCP a v6-only host and get stuff like DNS and NTP servers to them. another practical upshot is that switch manufacturers now need to support both RA Guard and DHCPv6 snooping instead of just a single protocol like we have in ipv4. That is, unless you're ok with the idea of arbitrary priority RA packets floating around your network. e.g. pages 9-16 of: http://ripe63.ripe.net/presentations/220-ripe63_techteam.pdf Nick From bmanning at vacation.karoshi.com Fri Nov 11 10:02:33 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 11 Nov 2011 16:02:33 +0000 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <20111111145503.GA48535@ussenterprise.ufp.org> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> <20111111145503.GA48535@ussenterprise.ufp.org> Message-ID: <20111111160233.GA5760@vacation.karoshi.com.> On Fri, Nov 11, 2011 at 06:55:03AM -0800, Leo Bicknell wrote: > > The networks I run have been dual stacked for 5+ years. It works. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ and I've been running single-stack IPv6 networks for 4+ years. IVI is a wonderful thing. Dual stack kind of implies you still need IPv4 for -EVERY- node. :) whoops! Guess there is a need for NAT after all, eh? (now promises to stop meing snarky and STFU) /bill From owen at delong.com Fri Nov 11 12:44:36 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Nov 2011 10:44:36 -0800 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <20111111160233.GA5760@vacation.karoshi.com.> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> <20111111145503.GA48535@ussenterprise.ufp.org> <20111111160233.GA5760@vacation.karoshi.com.> Message-ID: On Nov 11, 2011, at 8:02 AM, bmanning at vacation.karoshi.com wrote: > On Fri, Nov 11, 2011 at 06:55:03AM -0800, Leo Bicknell wrote: >> >> The networks I run have been dual stacked for 5+ years. It works. >> >> -- >> Leo Bicknell - bicknell at ufp.org - CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ > > and I've been running single-stack IPv6 networks for 4+ years. > IVI is a wonderful thing. Dual stack kind of implies you still > need IPv4 for -EVERY- node. :) whoops! Guess there is a need for > NAT after all, eh? (now promises to stop meing snarky and STFU) > Dual stack implies that you have IPv4 for some subset of the nodes. It says nothing about need. It says nothing about percentage of the nodes that are dual stacked. Owen From Valdis.Kletnieks at vt.edu Fri Nov 11 13:11:20 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 11 Nov 2011 14:11:20 -0500 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: Your message of "Fri, 11 Nov 2011 16:04:31 GMT." <4EBD478F.4040703@foobar.org> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> <4387.1321026978@turing-police.cc.vt.edu> <4EBD478F.4040703@foobar.org> Message-ID: <4923.1321038680@turing-police.cc.vt.edu> On Fri, 11 Nov 2011 16:04:31 GMT, Nick Hilliard said: > another practical upshot is that switch manufacturers now need to support > both RA Guard and DHCPv6 snooping instead of just a single protocol like we > have in ipv4. That is, unless you're ok with the idea of arbitrary > priority RA packets floating around your network. When did I ever say I was "OK with the idea"? Our single biggest network security issue is the fact that every day, one or two dozen of our users manage to get phished or hit by a drive-by, have their credentials stolen, and then often get used to send through enough spam to land us on various block lists, at which point the NANOG lurker in the next cubicle has a Bad Day because he's part our e-mail team. Most of the time we catch it, and the user has a Bad Day because they have to deal with the fallout of getting compromised. But this stuff would happen if it was IPv4, IPv6, IPv5.437 or tin-can-and-string. RA Guard is so far down the list of *actual* day to day net operations issues it's not funny. I think the the last time we had to put the smackdown on somebody advertising 2002: was like a year ago. Yes, RA Guard is a consideration. But the subnets we *really* care about are more-or-less physically secure, and the hosts are secure, so we don't see many RA games on critical subnets unless we've *already* got a critical security event in progress. Dorms and the like are easier to RA-spoof - but our switches are all managed, the symptoms of an RA issue are known to our NOC, and when we have an issue, the offending port suddenly loses link. ;) Would it be *nice* to have RA Guard and DHCP6 snooping in place? Yes. Is it totally impossible to deploy IPv6 until they're fully baked? Not at all - just need to be aware of the issues and be prepared to mitigate. Sure it raises the risk level slightly - but we judge the risks of not being well-positioned for IPv6 to be *much* higher. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cscora at apnic.net Fri Nov 11 13:18:23 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Nov 2011 05:18:23 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201111111918.pABJINS6030367@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, 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 12 Nov, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 381658 Prefixes after maximum aggregation: 166539 Deaggregation factor: 2.29 Unique aggregates announced to Internet: 187635 Total ASes present in the Internet Routing Table: 39286 Prefixes per ASN: 9.71 Origin-only ASes present in the Internet Routing Table: 32382 Origin ASes announcing only one prefix: 15485 Transit ASes present in the Internet Routing Table: 5290 Transit-only ASes present in the Internet Routing Table: 133 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1677 Unregistered ASNs in the Routing Table: 881 Number of 32-bit ASNs allocated by the RIRs: 1940 Number of 32-bit ASNs visible in the Routing Table: 1614 Prefixes from 32-bit ASNs in the Routing Table: 3721 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 87 Number of addresses announced to Internet: 2490142976 Equivalent to 148 /8s, 108 /16s and 145 /24s Percentage of available address space announced: 67.2 Percentage of allocated address space announced: 67.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.6 Total number of prefixes smaller than registry allocations: 161365 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 95008 Total APNIC prefixes after maximum aggregation: 31143 APNIC Deaggregation factor: 3.05 Prefixes being announced from the APNIC address blocks: 91456 Unique aggregates announced from the APNIC address blocks: 38380 APNIC Region origin ASes present in the Internet Routing Table: 4602 APNIC Prefixes per ASN: 19.87 APNIC Region origin ASes announcing only one prefix: 1269 APNIC Region transit ASes present in the Internet Routing Table: 720 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 21 Number of APNIC region 32-bit ASNs visible in the Routing Table: 107 Number of APNIC addresses announced to Internet: 629934432 Equivalent to 37 /8s, 140 /16s and 9 /24s Percentage of available APNIC address space announced: 79.9 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-132095, 132096-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: 146101 Total ARIN prefixes after maximum aggregation: 74287 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 118152 Unique aggregates announced from the ARIN address blocks: 48520 ARIN Region origin ASes present in the Internet Routing Table: 14740 ARIN Prefixes per ASN: 8.02 ARIN Region origin ASes announcing only one prefix: 5637 ARIN Region transit ASes present in the Internet Routing Table: 1565 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 804207808 Equivalent to 47 /8s, 239 /16s and 60 /24s Percentage of available ARIN address space announced: 63.9 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: 92019 Total RIPE prefixes after maximum aggregation: 51066 RIPE Deaggregation factor: 1.80 Prefixes being announced from the RIPE address blocks: 84487 Unique aggregates announced from the RIPE address blocks: 54587 RIPE Region origin ASes present in the Internet Routing Table: 16107 RIPE Prefixes per ASN: 5.25 RIPE Region origin ASes announcing only one prefix: 7977 RIPE Region transit ASes present in the Internet Routing Table: 2539 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1119 Number of RIPE addresses announced to Internet: 491921856 Equivalent to 29 /8s, 82 /16s and 33 /24s Percentage of available RIPE address space announced: 79.2 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 196608-198655 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: 36135 Total LACNIC prefixes after maximum aggregation: 7921 LACNIC Deaggregation factor: 4.56 Prefixes being announced from the LACNIC address blocks: 35567 Unique aggregates announced from the LACNIC address blocks: 18567 LACNIC Region origin ASes present in the Internet Routing Table: 1549 LACNIC Prefixes per ASN: 22.96 LACNIC Region origin ASes announcing only one prefix: 446 LACNIC Region transit ASes present in the Internet Routing Table: 286 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 18 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 372 Number of LACNIC addresses announced to Internet: 92919936 Equivalent to 5 /8s, 137 /16s and 216 /24s Percentage of available LACNIC address space announced: 61.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: 8487 Total AfriNIC prefixes after maximum aggregation: 2043 AfriNIC Deaggregation factor: 4.15 Prefixes being announced from the AfriNIC address blocks: 6576 Unique aggregates announced from the AfriNIC address blocks: 2022 AfriNIC Region origin ASes present in the Internet Routing Table: 496 AfriNIC Prefixes per ASN: 13.26 AfriNIC Region origin ASes announcing only one prefix: 156 AfriNIC Region transit ASes present in the Internet Routing Table: 106 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: 4 Number of AfriNIC addresses announced to Internet: 27687168 Equivalent to 1 /8s, 166 /16s and 121 /24s Percentage of available AfriNIC address space announced: 41.3 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 2510 11108 968 Korea Telecom (KIX) 17974 1649 511 36 PT TELEKOMUNIKASI INDONESIA 7545 1625 303 88 TPG Internet Pty Ltd 4755 1544 377 172 TATA Communications formerly 7552 1394 1064 7 Vietel Corporation 9829 1166 989 28 BSNL National Internet Backbo 9583 1116 83 512 Sify Limited 4808 1093 2095 313 CNCGROUP IP network: China169 24560 964 343 218 Bharti Airtel Ltd., Telemedia 18101 953 119 149 Reliance Infocom Ltd Internet 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 3544 3814 219 bellsouth.net, inc. 7029 2918 1016 199 Windstream Communications Inc 18566 2093 383 177 Covad Communications 1785 1847 680 122 PaeTec Communications, Inc. 4323 1622 1077 387 Time Warner Telecom 20115 1595 1545 624 Charter Communications 22773 1495 2909 102 Cox Communications, Inc. 30036 1415 255 671 Mediacom Communications Corp 19262 1395 4728 400 Verizon Global Networks 7018 1314 7029 862 AT&T WorldNet Services 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 1519 416 14 Corbina telecom 6830 646 1927 411 UPC Distribution Services 34984 596 110 184 BILISIM TELEKOM 20940 551 182 433 Akamai Technologies European 3320 503 8168 388 Deutsche Telekom AG 3292 479 2074 407 TDC Tele Danmark 12479 479 596 9 Uni2 Autonomous System 8866 463 133 26 Bulgarian Telecommunication C 31148 408 22 114 FreeNet ISP 8551 402 354 43 Bezeq International 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 1706 316 157 TVCABLE BOGOTA 28573 1490 1043 79 NET Servicos de Comunicao S.A 8151 1446 2937 346 UniNet S.A. de C.V. 7303 1238 751 173 Telecom Argentina Stet-France 27947 591 72 84 Telconet S.A 22047 580 322 17 VTR PUNTO NET S.A. 6503 566 434 68 AVANTEL, S.A. 7738 553 1050 31 Telecomunicacoes da Bahia S.A 3816 539 234 96 Empresa Nacional de Telecomun 11172 525 85 95 Servicios Alestra S.A de C.V 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 24863 716 146 36 LINKdotNET AS number 8452 665 446 12 TEDATA 15475 444 74 8 Nile Online 36992 285 415 20 Etisalat MISR 3741 281 939 230 The Internet Solution 15706 240 32 6 Sudatel Internet Exchange Aut 33776 239 13 8 Starcomms Nigeria Limited 6713 235 519 14 Itissalat Al-MAGHRIB 29571 218 17 13 Ci Telecom Autonomous system 12258 196 28 57 Vodacom Internet Company 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 3544 3814 219 bellsouth.net, inc. 7029 2918 1016 199 Windstream Communications Inc 4766 2510 11108 968 Korea Telecom (KIX) 18566 2093 383 177 Covad Communications 1785 1847 680 122 PaeTec Communications, Inc. 10620 1706 316 157 TVCABLE BOGOTA 17974 1649 511 36 PT TELEKOMUNIKASI INDONESIA 7545 1625 303 88 TPG Internet Pty Ltd 4323 1622 1077 387 Time Warner Telecom 20115 1595 1545 624 Charter Communications 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 2918 2719 Windstream Communications Inc 18566 2093 1916 Covad Communications 1785 1847 1725 PaeTec Communications, Inc. 17974 1649 1613 PT TELEKOMUNIKASI INDONESIA 10620 1706 1549 TVCABLE BOGOTA 4766 2510 1542 Korea Telecom (KIX) 7545 1625 1537 TPG Internet Pty Ltd 8402 1519 1505 Corbina telecom 28573 1490 1411 NET Servicos de Comunicao S.A 22773 1495 1393 Cox Communications, Inc. 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 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 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 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.0.0/16 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 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 37345 MEDALLION Communications 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 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:12 /10:27 /11:81 /12:236 /13:465 /14:808 /15:1422 /16:12006 /17:6064 /18:10089 /19:19963 /20:27615 /21:27723 /22:37556 /23:35208 /24:198912 /25:1154 /26:1364 /27:759 /28:166 /29:4 /30:0 /31:0 /32:5 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2548 2918 Windstream Communications Inc 6389 2185 3544 bellsouth.net, inc. 18566 2042 2093 Covad Communications 10620 1601 1706 TVCABLE BOGOTA 8402 1495 1519 Corbina telecom 30036 1375 1415 Mediacom Communications Corp 11492 1117 1154 Cable One 1785 1057 1847 PaeTec Communications, Inc. 7011 1051 1168 Citizens Utilities 22773 958 1495 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:408 2:484 4:15 5:1 6:3 8:356 12:1966 13:1 14:547 15:11 16:3 17:7 20:9 23:63 24:1683 27:1031 31:675 32:65 33:2 34:2 36:4 38:756 39:1 40:110 41:2681 42:59 43:1 44:3 46:1050 47:3 49:298 50:449 52:13 55:8 56:2 57:47 58:920 59:496 60:362 61:1131 62:1094 63:1970 64:4065 65:2302 66:4319 67:2019 68:1174 69:3142 70:905 71:387 72:1820 74:2633 75:430 76:319 77:881 78:887 79:479 80:1133 81:836 82:516 83:518 84:621 85:1154 86:400 87:931 88:356 89:1591 90:235 91:4257 92:536 93:1553 94:1303 95:1089 96:427 97:286 98:943 99:37 101:233 103:459 106:7 107:91 108:76 109:1184 110:671 111:807 112:362 113:480 114:623 115:715 116:881 117:722 118:889 119:1266 120:345 121:681 122:1574 123:1019 124:1353 125:1355 128:246 129:184 130:164 131:616 132:151 133:21 134:221 135:54 136:213 137:142 138:287 139:121 140:494 141:253 142:389 143:401 144:495 145:64 146:470 147:219 148:638 149:270 150:164 151:194 152:449 153:172 154:7 155:387 156:208 157:361 158:155 159:489 160:331 161:214 162:374 163:173 164:506 165:368 166:544 167:443 168:820 169:145 170:881 171:87 172:4 173:1742 174:702 175:432 176:297 177:367 178:1100 180:1145 181:38 182:652 183:236 184:393 185:1 186:1401 187:774 188:963 189:1157 190:5188 192:5923 193:5050 194:3554 195:3109 196:1268 197:170 198:3617 199:4206 200:5475 201:1704 202:8553 203:8538 204:4311 205:2370 206:2668 207:2816 208:4025 209:3584 210:2711 211:1463 212:2074 213:1804 214:777 215:96 216:4930 217:1601 218:560 219:343 220:1257 221:515 222:324 223:272 End of report From jbates at brightok.net Fri Nov 11 14:10:32 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Nov 2011 14:10:32 -0600 Subject: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week) In-Reply-To: <4923.1321038680@turing-police.cc.vt.edu> References: <4E9F20FF.1070203@arin.net> <9F539F99-00A2-4478-9218-4E795C710C52@corp.arin.net> <20111109155633.GA21891@ussenterprise.ufp.org> <20111110135618.GA82609@ussenterprise.ufp.org> <4387.1321026978@turing-police.cc.vt.edu> <4EBD478F.4040703@foobar.org> <4923.1321038680@turing-police.cc.vt.edu> Message-ID: <4EBD8138.70408@brightok.net> On 11/11/2011 1:11 PM, Valdis.Kletnieks at vt.edu wrote: > Would it be*nice* to have RA Guard and DHCP6 snooping in place? Yes. Is it > totally impossible to deploy IPv6 until they're fully baked? Not at all - just > need to be aware of the issues and be prepared to mitigate. Sure it raises the > risk level slightly - but we judge the risks of not being well-positioned for > IPv6 to be*much* higher. From a DSLAM perspective, the security stuff was annoying and often just broke IPv6 all together. I am still a fan of 1 vlan per user and q-in-q. It does have issues in dorm type scenarios where you might not want to bring local traffic all the way back to l3 termination, though. Jack From cidr-report at potaroo.net Fri Nov 11 16:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Nov 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201111112200.pABM01Lo023491@wattle.apnic.net> BGP Update Report Interval: 03-Nov-11 -to- 09-Nov-11 (6 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 50212 2.8% 50.7 -- BSNL-NIB National Internet Backbone 2 - AS8402 26154 1.5% 22.0 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS6316 25706 1.5% 659.1 -- AS-PAETEC-NET - PaeTec Communications, Inc. 4 - AS32528 24976 1.4% 12488.0 -- ABBOTT Abbot Labs 5 - AS27738 24092 1.4% 70.9 -- Ecuadortelecom S.A. 6 - AS20632 19812 1.1% 1981.2 -- PETERSTAR-AS PeterStar 7 - AS24722 17705 1.0% 260.4 -- BABILON-AS Babilon-T 8 - AS9498 17067 1.0% 28.5 -- BBIL-AP BHARTI Airtel Ltd. 9 - AS7552 16942 1.0% 12.2 -- VIETEL-AS-AP Vietel Corporation 10 - AS4274 15310 0.9% 189.0 -- ERX-AU-NET Assumption University 11 - AS45595 13295 0.8% 49.6 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 12 - AS16916 12798 0.7% 752.8 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 13 - AS5800 12743 0.7% 49.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - AS8866 10934 0.6% 218.7 -- BTC-AS Bulgarian Telecommunication Company Plc. 15 - AS47331 10442 0.6% 4.6 -- TTNET TTNet A.S. 16 - AS4766 10388 0.6% 4.4 -- KIXS-AS-KR Korea Telecom 17 - AS28573 9590 0.5% 12.8 -- NET Servicos de Comunicao S.A. 18 - AS24560 9494 0.5% 12.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 19 - AS7029 8930 0.5% 3.6 -- WINDSTREAM - Windstream Communications Inc 20 - AS9649 8751 0.5% 182.3 -- MOPH-TH-AP Information Technology Office TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 24976 1.4% 12488.0 -- ABBOTT Abbot Labs 2 - AS17408 3281 0.2% 3281.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 3 - AS20632 19812 1.1% 1981.2 -- PETERSTAR-AS PeterStar 4 - AS8499 1192 0.1% 1192.0 -- Space Hellas S.A. 5 - AS9562 8166 0.5% 1166.6 -- MSU-TH-AP Mahasarakham University 6 - AS44075 1046 0.1% 1046.0 -- GCCNGN GCCNGN AS 7 - AS17425 4074 0.2% 1018.5 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 8 - AS16916 12798 0.7% 752.8 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 9 - AS10099 742 0.0% 742.0 -- HKUNICOM1-AP China Unicom (Hong Kong) Operations Limited 10 - AS6316 25706 1.5% 659.1 -- AS-PAETEC-NET - PaeTec Communications, Inc. 11 - AS47859 635 0.0% 635.0 -- CLEORON Cleoron Alliance LTD. 12 - AS46983 527 0.0% 527.0 -- SAML-ASN - Southpaw Asset Management LP 13 - AS50977 3656 0.2% 522.3 -- ESYCOR-AS ESYCOR S.A. 14 - AS18409 2598 0.1% 519.6 -- BOT-TH-AS Bank of Thailand, Bangkok, Thailand 15 - AS55696 1004 0.1% 502.0 -- SCOM-AS-ID Starcom Solusindo PT. 16 - AS16898 488 0.0% 488.0 -- LOG-NET - Global Technology Services, Ltd. 17 - AS48068 486 0.0% 486.0 -- VISONIC Visonic Ltd 18 - AS10445 1894 0.1% 473.5 -- HTG - Huntleigh Telcom 19 - AS16391 473 0.0% 473.0 -- CELITO-1 - Celito Communications Inc. 20 - AS3738 1379 0.1% 459.7 -- SSB-ASN - State Street Bank and Trust Company TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 84.204.132.0/24 19734 1.1% AS20632 -- PETERSTAR-AS PeterStar 2 - 206.80.93.0/24 12756 0.7% AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 3 - 202.92.235.0/24 12739 0.7% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 4 - 130.36.34.0/24 12488 0.7% AS32528 -- ABBOTT Abbot Labs 5 - 130.36.35.0/24 12488 0.7% AS32528 -- ABBOTT Abbot Labs 6 - 213.16.48.0/24 10728 0.6% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 7 - 66.248.104.0/21 8529 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 8 - 66.248.120.0/21 8523 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 9 - 66.248.96.0/21 8517 0.5% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 10 - 221.183.16.0/23 4245 0.2% AS65500 -- -Private Use AS- AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 11 - 202.153.174.0/24 3281 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 12 - 217.52.130.0/24 2525 0.1% AS15475 -- NOL AS36992 -- ETISALAT-MISR 13 - 110.164.24.0/24 2040 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 14 - 110.164.25.0/24 2040 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 15 - 110.164.27.0/24 2040 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 16 - 110.164.26.0/24 2040 0.1% AS9562 -- MSU-TH-AP Mahasarakham University 17 - 202.151.6.0/24 2036 0.1% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 18 - 202.151.7.0/24 2036 0.1% AS17425 -- EPA-AS-TH Provincial Electricity Authority of Thailand. 19 - 59.99.0.0/20 1780 0.1% AS9829 -- BSNL-NIB National Internet Backbone 20 - 117.228.0.0/20 1779 0.1% AS9829 -- BSNL-NIB National Internet Backbone 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 Nov 11 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Nov 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201111112200.pABM00uW023486@wattle.apnic.net> This report has been generated at Fri Nov 11 21:12:18 2011 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 04-11-11 382870 224714 05-11-11 383079 224693 06-11-11 382973 224818 07-11-11 383132 224645 08-11-11 383213 224878 09-11-11 383651 224771 10-11-11 383571 224523 11-11-11 383517 224623 AS Summary 39387 Number of ASes in routing system 16620 Number of ASes announcing only one prefix 3544 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108825600 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'). --- 11Nov11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 383910 224980 158930 41.4% All ASes AS6389 3544 222 3322 93.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2093 406 1687 80.6% COVAD - Covad Communications Co. AS4766 2514 993 1521 60.5% KIXS-AS-KR Korea Telecom AS7029 2959 1541 1418 47.9% WINDSTREAM - Windstream Communications Inc AS22773 1495 112 1383 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1539 230 1309 85.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1623 389 1234 76.0% TWTC - tw telecom holdings, inc. AS1785 1850 782 1068 57.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1485 425 1060 71.4% NET Servicos de Comunicao S.A. AS19262 1395 400 995 71.3% VZGNI-TRANSIT - Verizon Online LLC AS7552 1394 423 971 69.7% VIETEL-AS-AP Vietel Corporation AS10620 1706 757 949 55.6% Telmex Colombia S.A. AS7303 1238 333 905 73.1% Telecom Argentina S.A. AS18101 954 150 804 84.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1447 667 780 53.9% Uninet S.A. de C.V. AS4808 1093 344 749 68.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS30036 1415 676 739 52.2% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS7545 1625 947 678 41.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1107 457 650 58.7% LEVEL3 Level 3 Communications AS17974 1648 1014 634 38.5% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS24560 964 347 617 64.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS8402 1428 818 610 42.7% CORBINA-AS OJSC "Vimpelcom" AS20115 1595 996 599 37.6% CHARTER-NET-HKY-NC - Charter Communications AS4804 691 93 598 86.5% MPX-AS Microplex PTY LTD AS17676 664 70 594 89.5% GIGAINFRA Softbank BB Corp. AS3549 1027 454 573 55.8% GBLX Global Crossing Ltd. AS22561 933 373 560 60.0% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 580 33 547 94.3% VTR BANDA ANCHA S.A. AS17488 946 401 545 57.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS7011 1168 646 522 44.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 44120 15499 28621 64.9% Top 30 total Possible Bogus Routes 5.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 5.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 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- 41.222.79.0/24 AS37345 MEDALLION 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 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.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 185.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 185.24.0.0/24 AS12654 RIPE-NCC-RIS-AS RIPE Network Coordination Center 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 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 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 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.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 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.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 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 impulse.net Fri Nov 11 16:01:47 2011 From: owen at impulse.net (Owen Roth) Date: Fri, 11 Nov 2011 14:01:47 -0800 (PST) Subject: Edgecast network issues seen in combination with lowered MTU In-Reply-To: <41596952.419621.1321046344544.JavaMail.root@lavender.impulse.net> Message-ID: <1398278335.419780.1321048907409.JavaMail.root@lavender.impulse.net> Hello, I had an issue with lowered MTU through a portion of my network, and besides the expected impact, some clients were unable to access resources either directly hosted or indirectly served content by EdgeCast Networks (had to look at traceroutes and view source to determine). I also found nodes that weren't pingable, and didn't appear to have ICMP unreachables available but no directly impacted end-to-end lowered MTU was visible. It seems to be a PathMTU issue or a weird unidirectional MTU issue (?). I have fixed the lowered MTU, and so restored connectivity to affected users -- this is not a current problem but still an incipient one. I consulted with EdgeCast NOC in this matter, but it is hard to demonstrate a <1% problem when it isn't apparent from every other network. Or they may have contracted clue-immunity, it's hard to tell. I've used MTUroute/TCProute and "ping a.b.c.d df-bit size 1500". That did NOT show an issue, 1500 bytes were pingable from the customer end and edge router. Given that I know it was an MTU issue, as that's how I patched and then fixed it, is there another tool that would detect whatever this is? Has anyone else seen this compound problem with EdgeCast Networks? Is "ICMP unreachables" ON to NOT break PMTUD per RFC, still best practice or has that drifted? Regards, Owen From jlewis at packetnexus.com Sun Nov 13 09:36:43 2011 From: jlewis at packetnexus.com (Jason Lewis) Date: Sun, 13 Nov 2011 10:36:43 -0500 Subject: Arguing against using public IP space Message-ID: I don't want to start a flame war, but this article seems flawed to me. It seems an IP is an IP. http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html I think I could announce private IP space, so doesn't that make this argument invalid? I've always looked at private IP space as more of a resource and management choice and not a security feature. From bonomi at mail.r-bonomi.com Sun Nov 13 10:38:50 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 13 Nov 2011 10:38:50 -0600 (CST) Subject: Arguing against using public IP space In-Reply-To: Message-ID: <201111131638.pADGcoiu007448@mail.r-bonomi.com> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis wrote; > > I don't want to start a flame war, but this article seems flawed to > me. Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is DEFINITELY 'flawed'. > It seems an IP is an IP. True. *BUT*, "some IP's are more equal than others", as Orwell would say. > > http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html > > I think I could announce private IP space, so doesn't that make this > argument invalid? You likely would have a 'rude surprise' if you actually tried it. It is an express violation of RFCs to announce routing for RFC-1918 space -outside- of your own network. In addition, virtually _every_ ASN operator has ingress filters on their border routers to block almost all traffic to RFC-1918 destinations. "Good net neighbor" operators also run egress filters that block almost all outbound traffic with RFC-1918 _source_ addresses -- things like icmp 'un- reachables' are an exception. > I've always looked at private IP space as more of a > resource and management choice and not a security feature. > From rdobbins at arbor.net Sun Nov 13 10:42:16 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 13 Nov 2011 16:42:16 +0000 Subject: Arguing against using public IP space In-Reply-To: References: Message-ID: On Nov 13, 2011, at 10:36 PM, Jason Lewis wrote: > I don't want to start a flame war, but this article seems flawed to me. The real issue is interconnecting SCADA systems to publicly-routed networks, not the choice of potentially routable space vs. RFC1918 space for SCADA networks, per se. If I've an RFC1918-addressed SCADA network which is interconnected to a publicly-routed- and -accessible network, then an attacker can work to compromise a host on the publicly-accessible network and then jump from there to the RFC1918 SCADA network. > I think I could announce private IP space, so doesn't that make this argument invalid? Most networks, except those which haven't implemented the most basic BCPs, wouldn't accept your announcements of RFC1918 or otherwise-reserved space. It's likely that your peers/upstreams wouldn't accept them in the first place, much less propagate them. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From davidianwalker at gmail.com Sun Nov 13 11:21:38 2011 From: davidianwalker at gmail.com (David Walker) Date: Mon, 14 Nov 2011 03:51:38 +1030 Subject: Arguing against using public IP space In-Reply-To: References: Message-ID: On 14/11/2011, Jason Lewis wrote: > I don't want to start a flame war, If you didn't write it I wouldn't stress about that. > but this article seems flawed to > me. Me too. > It seems an IP is an IP. Yes but in IPv4 land there is a difference although probably not in the way the author "suggests". The non-routability of the private address space is dependent on the good sense of router manufacturers and although these days that's probably guaranteed the impression I get is some dumb SCADA network guy is expected to go "oh, private address, intrinsically secure" or "oh, public address, intrinsically insecure, hmm, all my edge devices are owned and beyond help". Hehe. > I think I could announce private IP space, Exactly but it would never get legs. > so doesn't that make this > argument invalid? I think there are much better reasons why the article is invalid and ultimately irrelevant and weird. I know this is contentious so I'll clarify it ... NAT is not a security feature. Any perceived benefit is from the state table ... which any packet filter can duplicate. NATting is not the issue but the allow/deny situation based on the state table. More importantly though, other than DOS (presuming less bandwidth inside than out) or attacks on a host's TCP/IP stack (maybe SCADA suffers here), what's important is services hanging on ports and any vulnerabilities they have - which, by design are passed whether you NAT or not (we want people to talk to our web server). Has any one ever been cracked on their web browser or email client or whatever by something that was preventable at the lower layers with a default deny all in rule ... Never. The only issue for clients in that respect is spoofing and so on ... which NAT passes as well as (or more openly than) any packet filter ... Any good packet filter can help there but that's strictly a packet filtering feature and nothing to do with NAT. By definition alone, NAT is useless here. Some of the finer points argue against NAT entirely. http://www.ietf.org/rfc/rfc4966.txt (security considerations) Extending that, there could be some filtering somewhere. On the host, on the edge. A packet filter (ipso facto more relevant than a network address translator) is the tool of choice. Regardless, all that matters is vulnerability in services. I could never imagine writing an article about NAT (or translation) in a security context other than to say "focus on the real issues". It's all kind of backward too. IPv6 anyone? Surely SCADA is the prima facie example of "everyone's light bulb connected to the internet". Where's Vint Cerf when you need him ... Besides ... ... who uses Classes any more? :] > I've always looked at private IP space as more of a > resource and management choice and not a security feature. > > Right on ... ... and those SCADA guys have got important issues to worry about. Best wishes. From mysidia at gmail.com Sun Nov 13 11:48:06 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 13 Nov 2011 11:48:06 -0600 Subject: Arguing against using public IP space In-Reply-To: <201111131638.pADGcoiu007448@mail.r-bonomi.com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> Message-ID: On Sun, Nov 13, 2011 at 10:38 AM, Robert Bonomi wrote: > On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis wrote; > In addition, virtually _every_ ASN operator has ingress filters on their > border routers to block almost all traffic to RFC-1918 destinations. Well, when we are talking about selection of IP addresses as a supposed security feature... the view that "your ASN operator probably has ingress filters" is an optimistic one. The relevant question if you expect "private IP" to be a security feature is: "Can you legitimately rely on your ASN operator having ingress filters on border routers to block your RFC1918 destinations from remote access" ? And the proper answer is NO, you cannot rely on that; if your network design relies on this assumption, then it is not secure. If your router is compromised, an intruder can announce your private RFC1918 IP address space through a tunnel. If an intruder is a conspirator with one of your peer networks, they can conspire with your peer to allow an RFC1918 announcement from your network. Or create a static route for a RFC1918 subnet on your network. In other words, your use of RFC1918 address space alone does not create security. Your RFC1918 network actually _does_ need isolation separate and apart from the address space, for you to have reliable security, you still need a firewall, proxy, or NAT device of some form, with the private network isolated from the public one, even when using private IPs. -- -JH From leigh.porter at ukbroadband.com Sun Nov 13 12:50:55 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Sun, 13 Nov 2011 18:50:55 +0000 Subject: Arguing against using public IP space In-Reply-To: References: Message-ID: <7814062A-B014-48D7-9D1A-37E7DD5C09EF@ukbroadband.com> I was involved in a security review of a SCADA system a couple of years ago. Their guy was very impressed with himself and his "Internet air-gap" but managed to leave all their ops consoles on both the SCADA network and their internal corp LAN. Their corp LAN was a mess with holes through their NAT gateway all over the place to let external support people rdesktop to the SCADA network machines. Of course it was all on private address space internally. So you see, when you put idiots in charge, your screwed whatever you do and private address space and NAT and whatever else will be no more then security by nice stickers and marketing. -- Leigh On 13 Nov 2011, at 15:38, "Jason Lewis" wrote: > I don't want to start a flame war, but this article seems flawed to > me. It seems an IP is an IP. > > http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html > > I think I could announce private IP space, so doesn't that make this > argument invalid? I've always looked at private IP space as more of a > resource and management choice and not a security feature. > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From bill at herrin.us Sun Nov 13 14:13:37 2011 From: bill at herrin.us (William Herrin) Date: Sun, 13 Nov 2011 15:13:37 -0500 Subject: Arguing against using public IP space In-Reply-To: <201111131638.pADGcoiu007448@mail.r-bonomi.com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> Message-ID: On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi wrote: > On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis wrote; >> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html > > Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is > DEFINITELY 'flawed'. Hi Robert, Give the chart a second look. 192.168.0.0/16 (one of the three RFC1918 spaces) is, in fact, a /16 of IPv4 address space and it is, in fact, found in the old "class C" range. Ditto 172.16.0.0/12. If there's a nitpick, the author should have labeled the column something like "classful area" instead of "classful description." On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis wrote: > I've always looked at private IP space as more of a > resource and management choice and not a security feature. Hi Jason, If your machine is addressed with a globally routable IP, a trivial failure of your security apparatus leaves your machine addressable from any other host in the entire world which wishes to send it packets. In the parlance, it tends to "fail open." Machines using RFC1918 or RFC4193 space often have the opposite property: a failure of the security apparatus is prone to leave them unable to interact with the rest of the world at all. They tend to "fail closed." Think of this way: Your firewall is a deadbolt and RFC1918 is the lock on the doorknob. The knob lock doesn't stop anyone from entering an unlatched window, opening the door from the inside and walking out with all your stuff. Yet when you forget to throw the deadbolt, it does stop an intruder from simply turning the knob and wandering in. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From davidianwalker at gmail.com Sun Nov 13 15:03:02 2011 From: davidianwalker at gmail.com (David Walker) Date: Mon, 14 Nov 2011 07:33:02 +1030 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> Message-ID: Hey. On 14/11/2011, Jimmy Hess wrote: > In other words, your use of RFC1918 address space alone does not > create security. I had this crazy idea that somewhere in the rfcs was a "should" that manufacturers block private address space (i.e. hard coded) but it's not (in fact the opposite). Obviously there's shoulds for nocs and isps. Regardless, you're exactly correct. > Your RFC1918 network actually _does_ need > isolation separate and apart from the address space, for you to have > reliable security, you still need a firewall, proxy, or NAT device > of some form, Pardon me but that's not axiomatic. This is where the flames come right? Between me and you there's X machines that route packets (and have layer four services - yes I'm a TCP/IP model guy). There's no separate firewall machines, no security postured proxies, no NATting. These routers pass packets happily and don't influence my security or the security of the other routers at all. Obviously there are plenty of other critical machines that don't have proxies or NATting (DNS). Pertinently, they are publicly addressable yet don't have security issues resulting from not having intermediate firewalls or proxies or NAT. The only issues they do have are what all endpoint machines face - poor application (protocol) design (lack of encryption and so on), poor administration, bugs. Of those three, the methodology most readily associated to security is firewalling (packet filtering). A packet addressed to an endpoint that doesn't serve anything or have a client listening will be ignered (whatever) as a matter of course. Firewall or no firewall. If I have a client application open on a port and get incoming from an unsolicited IP then again it will be ignored as a matter of course. Incoming to bogus ports are of course dropped (whatever). Firewall or no firewall. If I do have a port mapped to a service (serving not clienting) then I'm open for business. That's fundamental to TCP/IP and secure. All other security considerations are appropriately handled at layer four. The only reason we firewall (packet filter) is to provide access control (for whatever reason). Access control is a good enough reason to have something called a firewall but everything else is a failure in design. Again though, access control is a failure at protocol design (hence DNS and BGP issues). Firewalling here is a kludge. The only issue that depends on firewalling is ... DoS to preserve bandwidth and that's not an end in and of itself. I posit to you that in the current state of affairs, firewalling a host or network is incredibly useful but entirely superfluous to defending a machine. I think you'd be hard pressed to find any convincing reason to suggest that proxies are any more useful (given good layer four design) from a security perspective. NAT? No. Fundamentally, it's not required or every machine that was publicly addressable would have a NAT machine shoved in front of it and another one shoved in front of that ... Prima facie examples are every publicly addressable machine on the internet. If there was a reason other than address space management then our critical infrastructure would be NATted. The history of NAT tells me I'm right. > ... you still need ... > ... the private network isolated from the public one ... No. I apologize in advance if this is too pedestrian (you might know this but not agree with it) but I want to make a point: http://en.wikipedia.org/wiki/End-to-end_connectivity I've got homework to do (read some of that stuff and re-evaluate my position) but NAT has caused nothing but trouble for security practioners and allowed developers to get away with whatever they can ... NAT saved us ... or at least all the moms and dads who don't have good product or good administration. > ... you still need ... > ... the private network isolated from the public one ... If this were true then IPv6 was fail. Apart from any push to bring NAT along for the ride, we have a newer IP with the deliberate choice made to make every machine publicly addressable ... and to turn every NAT box into a router only ... and let them route packets (like every other intermediate router) freeing up hosts ... to do host security. To me that was a breath of very fresh air. The only reason to be concerned about this is vendors who make bad choices and for that there's always other vendors. :] > -- > -JH > > Best wishes. From regnauld at nsrc.org Sun Nov 13 15:27:56 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Sun, 13 Nov 2011 22:27:56 +0100 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> Message-ID: <20111113212756.GD73635@macbook.bluepipe.net> William Herrin (bill) writes: > If your machine is addressed with a globally routable IP, a trivial > failure of your security apparatus leaves your machine addressable > from any other host in the entire world which wishes to send it > packets. In the parlance, it tends to "fail open." Machines using > RFC1918 or RFC4193 space often have the opposite property: a failure > of the security apparatus is prone to leave them unable to interact > with the rest of the world at all. They tend to "fail closed." > > Think of this way: Your firewall is a deadbolt and RFC1918 is the lock > on the doorknob. The knob lock doesn't stop anyone from entering an > unlatched window, opening the door from the inside and walking out > with all your stuff. Yet when you forget to throw the deadbolt, it > does stop an intruder from simply turning the knob and wandering in. > That's not exactly correct. NAT doesn't imply firewalling/filtering. To illustrate this to customers, I've mounted attacks/scans on hosts behind NAT devices, from the interconnect network immediately outside: if you can point a route with the ext ip of the NAT device as the next hop, it usually just forwards the packets... Phil From dougb at dougbarton.us Sun Nov 13 15:48:32 2011 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 13 Nov 2011 13:48:32 -0800 Subject: Arguing against using public IP space In-Reply-To: <20111113212756.GD73635@macbook.bluepipe.net> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> Message-ID: <4EC03B30.2090007@dougbarton.us> On 11/13/2011 13:27, Phil Regnauld wrote: > That's not exactly correct. NAT doesn't imply firewalling/filtering. > To illustrate this to customers, I've mounted attacks/scans on > hosts behind NAT devices, from the interconnect network immediately > outside: if you can point a route with the ext ip of the NAT device > as the next hop, it usually just forwards the packets... Have you written this up anywhere? It would be absolutely awesome to be able to point the "NAT IS A SECURITY FEATURE!!!" crowd to an actual demonstration of why it isn't. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From cb.list6 at gmail.com Sun Nov 13 15:57:51 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 13 Nov 2011 13:57:51 -0800 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> Message-ID: On Sun, Nov 13, 2011 at 12:13 PM, William Herrin wrote: > On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi > wrote: >> On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis wrote; >>> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html >> >> Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is >> DEFINITELY 'flawed'. > > Hi Robert, > > Give the chart a second look. 192.168.0.0/16 (one of the three RFC1918 > spaces) is, in fact, a /16 of IPv4 address space and it is, in fact, > found in the old "class C" range. Ditto 172.16.0.0/12. If there's a > nitpick, the author should have labeled the column something like > "classful area" instead of "classful description." > > > On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis wrote: >> I've always looked at private IP space as more of a >> resource and management choice and not a security feature. > > Hi Jason, > > If your machine is addressed with a globally routable IP, a trivial > failure of your security apparatus leaves your machine addressable > from any other host in the entire world which wishes to send it > packets. In the parlance, it tends to "fail open." Machines using > RFC1918 or RFC4193 space often have the opposite property: a failure > of the security apparatus is prone to leave them unable to interact > with the rest of the world at all. They tend to "fail closed." > This "fail open" vs "fail closed" is a very good characterization of the situation. While many IPv4 situations requires RFC1918 addresses due to scarcity, so it is a moot point, this fail open vs closed argument applies very well to why one should consider IPv6 ULA addresses in certain specific scenarios. If the system does not need to speak to the outside world, a ULA is frequently the right choice to leverage this "fail closed" benefits, which IMHO outstrip any advantages due to "not having to renumber when requirements change" or whatever else the religiously anti-ULA folks have to say. CB > Think of this way: Your firewall is a deadbolt and RFC1918 is the lock > on the doorknob. The knob lock doesn't stop anyone from entering an > unlatched window, opening the door from the inside and walking out > with all your stuff. Yet when you forget to throw the deadbolt, it > does stop an intruder from simply turning the knob and wandering in. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From chuckchurch at gmail.com Sun Nov 13 16:43:46 2011 From: chuckchurch at gmail.com (Chuck Church) Date: Sun, 13 Nov 2011 17:43:46 -0500 Subject: Arguing against using public IP space In-Reply-To: <4EC03B30.2090007@dougbarton.us> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> Message-ID: <001001cca255$b4a45450$1decfcf0$@com> When you all say NAT, are you implying PAT as well? 1 to 1 NAT really provides no security. But with PAT, different story. Are there poor implementations of PAT that don't enforce an exact port/address match for the translation table? If the translation table isn't at fault, are the 'helpers' that allow ftp to work passively to blame? Chuck -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Sunday, November 13, 2011 4:49 PM To: Phil Regnauld Cc: nanog at nanog.org Subject: Re: Arguing against using public IP space On 11/13/2011 13:27, Phil Regnauld wrote: > That's not exactly correct. NAT doesn't imply firewalling/filtering. > To illustrate this to customers, I've mounted attacks/scans on > hosts behind NAT devices, from the interconnect network immediately > outside: if you can point a route with the ext ip of the NAT device > as the next hop, it usually just forwards the packets... Have you written this up anywhere? It would be absolutely awesome to be able to point the "NAT IS A SECURITY FEATURE!!!" crowd to an actual demonstration of why it isn't. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From regnauld at nsrc.org Sun Nov 13 16:46:31 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Sun, 13 Nov 2011 23:46:31 +0100 Subject: Arguing against using public IP space In-Reply-To: <4EC03B30.2090007@dougbarton.us> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> Message-ID: <20111113224631.GE73635@macbook.bluepipe.net> Doug Barton (dougb) writes: > On 11/13/2011 13:27, Phil Regnauld wrote: > > That's not exactly correct. NAT doesn't imply firewalling/filtering. > > To illustrate this to customers, I've mounted attacks/scans on > > hosts behind NAT devices, from the interconnect network immediately > > outside: if you can point a route with the ext ip of the NAT device > > as the next hop, it usually just forwards the packets... > > Have you written this up anywhere? It would be absolutely awesome to be > able to point the "NAT IS A SECURITY FEATURE!!!" crowd to an actual > demonstration of why it isn't. Nope, but I could do a quick tut on how to do this against a natd/pf/ iptables or IOS with IP overload. Arguably in *most* cases your CPE or whatever is NATing is behind some upstream device doing ingress filtering, so you still need to be compromising a device fairly close to the target network. P. From regnauld at nsrc.org Sun Nov 13 16:59:24 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Sun, 13 Nov 2011 23:59:24 +0100 Subject: Arguing against using public IP space In-Reply-To: <001001cca255$b4a45450$1decfcf0$@com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> Message-ID: <20111113225924.GF73635@macbook.bluepipe.net> Chuck Church (chuckchurch) writes: > When you all say NAT, are you implying PAT as well? 1 to 1 NAT really > provides no security. But with PAT, different story. Are there poor > implementations of PAT that don't enforce an exact port/address match for > the translation table? If the translation table isn't at fault, are the > 'helpers' that allow ftp to work passively to blame? PAT (overload) will have ports open listening for return traffic, on the external IP that's being "overloaded". What happens if you initiate traffic directed at the RFC1918 network itself, and send that to the MAC address of the NAT device ? In many cases, it just works. That's how IP forwarding works, after all :) inside net ----------[NAT]-----------{ext net}----[attacker] 192.168.0.0/24 .254 1.2.3.4 1.2.3.5 S:1.2.3.5 D:192.168.0.1 next hop: 1.2.3.4 Now, on the way back *out* from the inside net, traffic from 192.168.0.1 back to 1.2.3.4 might get translated - it depends if what the NAT is programmed to do if it sees, say, a S/A packet with no corresponding SYN, on its way out. It might just get dropped. UDP would in some cases get natted, but since you know your destination port on 1.2.3.5, you know what to expect, and you can build an asymmetric connection since you control the attacking host. Either way, you've still injected traffic into the inside net. Etc... From Gabriel.McCall at thyssenkrupp.com Sun Nov 13 17:12:19 2011 From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel) Date: Sun, 13 Nov 2011 18:12:19 -0500 Subject: Arguing against using public IP space In-Reply-To: References: Message-ID: Google for "NAT is not a security feature" and review all the discussions and unnecessary panic over a lack of NAT support in IPv6. If your SCADA network can reach the public internet then your security is only as good as your firewall, whether you NAT or not. If your SCADA network is completely isolated then it doesn't make a bit of difference what addresses you use. -----Original message----- From: Jason Lewis To: "nanog at nanog.org" Sent: Sun, Nov 13, 2011 15:36:43 GMT+00:00 Subject: Arguing against using public IP space I don't want to start a flame war, but this article seems flawed to me. It seems an IP is an IP. http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html I think I could announce private IP space, so doesn't that make this argument invalid? I've always looked at private IP space as more of a resource and management choice and not a security feature. From jra at baylink.com Sun Nov 13 17:29:39 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 13 Nov 2011 18:29:39 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: Message-ID: <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Roland Dobbins" > The real issue is interconnecting SCADA systems to publicly-routed > networks, not the choice of potentially routable space vs. RFC1918 > space for SCADA networks, per se. If I've an RFC1918-addressed SCADA > network which is interconnected to a publicly-routed- and -accessible > network, then an attacker can work to compromise a host on the > publicly-accessible network and then jump from there to the RFC1918 > SCADA network. SCADA networks should be hard air-gapped from any other network. In case you're in charge of one, and you didn't hear that, let me say it again: *SCADA networks should he hard air-gapped from any other network.* If you're in administrative control of one, and it's attacked because you didn't follow this rule, and someone dies because of it, I heartily, and perfectly seriously, encourage that you be charged with homicide. We do it with Professional Engineers; I see no reason we shouldn't expect the same level of responsibility from other types. 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 Sun Nov 13 17:36:31 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 13 Nov 2011 18:36:31 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: <4EC03B30.2090007@dougbarton.us> Message-ID: <8319275.2593.1321227391110.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Doug Barton" > On 11/13/2011 13:27, Phil Regnauld wrote: > > That's not exactly correct. NAT doesn't imply > > firewalling/filtering. > > To illustrate this to customers, I've mounted attacks/scans on > > hosts behind NAT devices, from the interconnect network immediately > > outside: if you can point a route with the ext ip of the NAT device > > as the next hop, it usually just forwards the packets... > > Have you written this up anywhere? It would be absolutely awesome to > be able to point the "NAT IS A SECURITY FEATURE!!!" crowd to an actual > demonstration of why it isn't. Accepting strict source routing from a public interface is certainly in the top 10 Worst Common Practices, is it not? (IE: I would be surprised if *any* current router actually let you do that.) 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 jay at west.net Sun Nov 13 17:51:13 2011 From: jay at west.net (Jay Hennigan) Date: Sun, 13 Nov 2011 15:51:13 -0800 Subject: Arguing against using public IP space In-Reply-To: References: Message-ID: <4EC057F1.6030105@west.net> On 11/13/11 7:36 AM, Jason Lewis wrote: > I don't want to start a flame war, but this article seems flawed to > me. It seems an IP is an IP. > > http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html > > I think I could announce private IP space, so doesn't that make this > argument invalid? You could announce it. I wouldn't expect anyone else to listen to those announcements other than for the purpose of ridiculing you. > I've always looked at private IP space as more of a > resource and management choice and not a security feature. It depends. Case 1: If the SCADA vendors are configuring units with non-RFC1918 IP space in live customer installations, and these installations aren't ever in any way connected to the public Internet, then there isn't any real operational problem. It smacks of carelessness/cluelessness on the part of both the vendor and the IT staff of the customer who accepted the configuration, but nothing is operationally broken. Case 2: Same as above, but the SCADA network is connected to the Internet behind a NAT at the customer location. Again careless and clueless. And should anything on that network need to access resources on the Internet within the space configured on the SCADA system it won't work. The vendor/customer have broken reachability to some part of the public Internet for that system. Whether there is a security risk depends on the configuration of the NAT firewall and whether and how how the SCADA system opens connections outbound and what vulnerabilities exist in its systems if it does. No more security risk than the same situation using RFC1918 space. Case 3: Same as case 2 but without the NAT. Pretty much the same result. The SCADA system won't be reachable from the outside because the customer's provider won't route those addresses to the customer. Packets sourced to the Internet from the SCADA aren't likely to get very far. Even more broken/stupid than the other scenarios but not likely to be much of a security risk in terms of exposure to the Internet. Case 4: SCADA vendor asks customer for a subnet of public IP space allocated to the customer and installs the SCADA system directly on the Internet. From an RFC standpoint, nothing is broken. From a security standpoint, without appropriate firewalls, a very bad idea. So, yes, it's a dumb idea. The degree of dumbness depends. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From chuckchurch at gmail.com Sun Nov 13 17:53:19 2011 From: chuckchurch at gmail.com (Chuck Church) Date: Sun, 13 Nov 2011 18:53:19 -0500 Subject: Arguing against using public IP space In-Reply-To: <20111113225924.GF73635@macbook.bluepipe.net> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> Message-ID: <002201cca25f$6c5340d0$44f9c270$@com> -----Original Message----- From: Phil Regnauld [mailto:regnauld at nsrc.org] > PAT (overload) will have ports open listening for return traffic, > on the external IP that's being "overloaded". > What happens if you initiate traffic directed at the RFC1918 > network itself, and send that to the MAC address of the NAT device ? > In many cases, it just works. That's how IP forwarding works, after > all :) > > inside net ----------[NAT]-----------{ext net}----[attacker] > 192.168.0.0/24 .254 1.2.3.4 1.2.3.5 > S:1.2.3.5 D:192.168.0.1 next hop: 1.2.3.4 > > Now, on the way back *out* from the inside net, traffic from > 192.168.0.1 back to 1.2.3.4 might get translated - it depends if > what the NAT is programmed to do if it sees, say, a S/A packet > with no corresponding SYN, on its way out. It might just get > dropped. UDP would in some cases get natted, but since you > know your destination port on 1.2.3.5, you know what to expect, > and you can build an asymmetric connection since you control the > attacking host. > > Either way, you've still injected traffic into the inside net. > That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host. Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue. Chuck From jlewis at packetnexus.com Sun Nov 13 17:58:36 2011 From: jlewis at packetnexus.com (Jason Lewis) Date: Sun, 13 Nov 2011 18:58:36 -0500 Subject: Arguing against using public IP space In-Reply-To: <4EC057F1.6030105@west.net> References: <4EC057F1.6030105@west.net> Message-ID: >> I think I could announce private IP space, so doesn't that make this >> argument invalid? > > You could announce it. ?I wouldn't expect anyone else to listen to those > announcements other than for the purpose of ridiculing you. > People keep pointing to this as unlikely. I argue that spammers are currently doing this all over the world, maybe not as widespread wiith 1918 space. If I can announce 1918 space to an ISP where my target is...it doesn't matter if everyone else ignores or drops it. The ISP allowed it, so all their customers will route the traffic. I still think it's a valid attack vector, discounting it because people would laugh at me, seems like a poor security posture. jas From bonomi at mail.r-bonomi.com Sun Nov 13 18:16:46 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 13 Nov 2011 18:16:46 -0600 (CST) Subject: Arguing against using public IP space In-Reply-To: Message-ID: <201111140016.pAE0GkZP009815@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sun Nov 13 14:15:38 2011 > From: William Herrin > Date: Sun, 13 Nov 2011 15:13:37 -0500 > Subject: Re: Arguing against using public IP space > To: nanog at nanog.org > > On Sun, Nov 13, 2011 at 11:38 AM, Robert Bonomi > wrote: > > On Sun, 13 Nov 2011 10:36:43 -0500, Jason Lewis wrote; > >> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html > > > > Any article that claims a /12 is a 'class B', and a /16 is a 'Class C', is > > DEFINITELY 'flawed'. > > Hi Robert, > > Give the chart a second look. 192.168.0.0/16 (one of the three RFC1918 > spaces) is, in fact, a /16 of IPv4 address space and it is, in fact, > found in the old "class C" range. Ditto 172.16.0.0/12. If there's a > nitpick, the author should have labeled the column something like > "classful area" instead of "classful description." In the 'classful' world, neither the /12 or the /16 spaces were referencble as a single object. Correct 'classful descriptions' would have been: "16 contiguous Class 'B's" "256 contiguous Class 'C's" From jra at baylink.com Sun Nov 13 18:21:36 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 13 Nov 2011 19:21:36 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: <201111140016.pAE0GkZP009815@mail.r-bonomi.com> Message-ID: <3481047.2631.1321230096029.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert Bonomi" > In the 'classful' world, neither the /12 or the /16 spaces were referencible > as a single object. Correct 'classful descriptions' would have been: > "16 contiguous Class 'B's" "256 contiguous Class 'C's" Fine. But I think you're going to fine that synechdoche triumphs here, and a Class-C *Sized* network is going to be called that, even if it's first octet is 191 or lower, Robert. 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 Sun Nov 13 19:13:21 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 14 Nov 2011 01:13:21 +0000 Subject: Arguing against using public IP space In-Reply-To: <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com> References: <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com> Message-ID: On Nov 14, 2011, at 6:29 AM, Jay Ashworth wrote: > SCADA networks should be hard air-gapped from any other network. Concur, GMTA. My point is that without an airgap, the attacker can jump from a production network to the SCADA network, so we're in violent agreement. ;> ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From rbf+nanog at panix.com Sun Nov 13 19:14:59 2011 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 13 Nov 2011 19:14:59 -0600 Subject: Arguing against using public IP space In-Reply-To: <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com> References: <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com> Message-ID: <20111114011458.GA19365@panix.com> On Sun, Nov 13, 2011 at 06:29:39PM -0500, Jay Ashworth wrote: > > SCADA networks should be hard air-gapped from any other network. > > In case you're in charge of one, and you didn't hear that, let me say > it again: > > *SCADA networks should he hard air-gapped from any other network.* > > If you're in administrative control of one, and it's attacked because you > didn't follow this rule, and someone dies because of it, I heartily, and > perfectly seriously, encourage that you be charged with homicide. > > We do it with Professional Engineers; I see no reason we shouldn't expect > the same level of responsibility from other types. What if you air-gap the SCADA network of which you are in administrative control, and then there's a failure on it, and the people responsible for troubleshooting it can't do it remotely (because of the air gap), so the trouble continues for an extra hour while they drive to the office, and that extra hour of failure causes someone to die. Should that result in a homicide charge? What if you air-gap the SCADA network of which you are in administrative control, but, having done so, you can't afford the level of redundancy you could when it wasn't air-gapped, and a transport failure leaves you without remote control of a system at a time when it's needed to prevent a cascading failure, and that leads to someone dieing. Should that result in a homicide charge? Air-gap means you have to build your own facilities for the entire SCADA network. No MPLS-VPN service from providers. Can't even use point-to-point TDM circuits (T1, for example) from providers, since those are typically mixed in with other circuits in the carrier's DACS, so it's only logical separation. And even if you want to redefine "air-gap" to be "air-gap, or at least no co-mingling in any packet switching equipment", you've ruled out any use of commercial wireless service (i.e. cellular) for backup paths. A good engineer weighs all the tradeoffs and makes a judgement. In some systems, there's might be a safety component of availability that justifies accepting some very small increase in the risk of outside compromise. You can argue that safety is paramount -- that the system needs to be designed to never get into an unsafe condition because of a communications failure (which, in fact is a good argument) -- that there must always be sufficient local control to keep the system in a safe state. Then you can implement the air-gap policy, knowing that while it might make remote control less reliable, there's no chance of, say, the plant blowing up because of loss of remote control. (Except, of course, that that's only true if you have complete faith in the local control system. Sometimes remote monitoring can allow a human to see and correct a developing unsafe condition that the control system was never programmed to deal with.) But even if the local control is completely safe in the loss-of-comm failure case, it's still not as cut and dried as it sounds. The plant might not blow up. But it might trip offline with there being no way to restart it because of a comm failure. Ok, fine, you say, it's still in a safe condition. Except, of course, that power outages, especially widespread ones, can kill people. Remote control of the power grid might not be necessarily to keep plants from blowing up, but it's certainly necessary in certain cases to keep it online. (And in this paragraph, I'm using the power grid as an example. But the point I'm making in this post is more general case.) Sure, anytime there's an attack or failure on a SCADA network that wouldn't have occurred had it been air-gapped, it's easy for people to knee-jerk a "SCADA networks should be airgapped" response. But that's not really intelligent commentary unless you carefully consider what risks are associated with air-gapping the network. Practically speaking, non-trivial SCADA networks are almost never completely air-gapped. Have you talked to people who run them? -- Brett From jra at baylink.com Sun Nov 13 19:31:15 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 13 Nov 2011 20:31:15 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: <20111114011458.GA19365@panix.com> Message-ID: <3922450.2637.1321234275543.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brett Frankenberger" > What if you air-gap the SCADA network of which you are in > administrative control, and then there's a failure on it, and the > people responsible for troubleshooting it can't do it remotely (because of > the air gap), so the trouble continues for an extra hour while they drive > to the office, and that extra hour of failure causes someone to die. > Should that result in a homicide charge? I should think it would be your responsibility, as the chief engineer, to make sure *you have filled all such possible holes in your operations plan*. > What if you air-gap the SCADA network of which you are in > administrative control, but, having done so, you can't afford the > level of redundancy you could when it wasn't air-gapped, and a transport > failure leaves you without remote control of a system at a time when > it's needed to prevent a cascading failure, and that leads to someone > dieing. Should that result in a homicide charge? If it costs more to run, then it *costs more to run*. > Air-gap means you have to build your own facilities for the entire > SCADA network. No MPLS-VPN service from providers. Can't even use > point-to-point TDM circuits (T1, for example) from providers, since > those are typically mixed in with other circuits in the carrier's > DACS, so it's only logical separation. And even if you want to redefine > "air-gap" to be "air-gap, or at least no co-mingling in any packet > switching equipment", you've ruled out any use of commercial wireless > service (i.e. cellular) for backup paths. *I* define "air gap" as "no way to move packets from the outside world into the network. I didn't say "100% dedicated facilities", though your implication that that still leaves an attacker a way to reconfigure things such that they could get in is absolutely correct. > A good engineer weighs all the tradeoffs and makes a judgement. In > some systems, there's might be a safety component of availability that > justifies accepting some very small increase in the risk of outside > compromise. The line is pretty bright, I think, but you're correct in asserting that the price difference goes up as the square of the number of nines. But that's not important now; we're talking about cases that aren't even *99%*, much less 4 or 5 nines of unlikelihood that an outsider can find a way to break in. > You can argue that safety is paramount -- that the system needs to be > designed to never get into an unsafe condition because of a > communications failure (which, in fact is a good argument) -- that > there must always be sufficient local control to keep the system in a > safe state. Then you can implement the air-gap policy, knowing that > while it might make remote control less reliable, there's no chance > of, say, the plant blowing up because of loss of remote control. (Except, > of course, that that's only true if you have complete faith in the > local control system. Sometimes remote monitoring can allow a human to see > and correct a developing unsafe condition that the control system was > never programmed to deal with.) Yes, but that's enablement for loss of locally staffed control, all by itself. Even power utilities have a pretty good real rate of return these days; I have no problem with them spending a little more of their revenue on safety, instead of profit. If that takes regulators pointing guns at them, I'm fine with that. > But even if the local control is completely safe in the loss-of-comm > failure case, it's still not as cut and dried as it sounds. The plant > might not blow up. But it might trip offline with there being no way > to restart it because of a comm failure. Ok, fine, you say, it's still > in a safe condition. Except, of course, that power outages, especially > widespread ones, can kill people. Remote control of the power grid > might not be necessarily to keep plants from blowing up, but it's > certainly necessary in certain cases to keep it online. (And in this > paragraph, I'm using the power grid as an example. But the point I'm > making in this post is more general case.) And I just read the Cracked piece talking about the 77 NYC blackout, which is sort of weird, actually. :-) But the general case point *I* was making was not that I expected a conviction. It was that I expected a charge, and a trial. If a bridge collapses, are we going to charge the Professional Engineer who signed off on it? > Sure, anytime there's an attack or failure on a SCADA network that > wouldn't have occurred had it been air-gapped, it's easy for people to > knee-jerk a "SCADA networks should be airgapped" response. But that's > not really intelligent commentary unless you carefully consider what > risks are associated with air-gapping the network. > > Practically speaking, non-trivial SCADA networks are almost never > completely air-gapped. Have you talked to people who run them? No, and yes my knee was jerking. But based on the industry stuff I have seen from out here, security isn't anywhere in the same *county* with where it needs to be, and -- just as with RMS and the GPL -- maybe if some extremists knees jerk, the end result, while more moderate, will be more salutary. If you were that chief, and you knew the result of you screwing up might be the loss of your liberty, not just your job... you don't think you'd fight budget battles with your utility harder? (That's often the reason for such regulations: to give middle to upper management more bullets to fire at the (greedy) owners.) Thanks for doing some of my math for me, though, Brett. :-) 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 jeff-kell at utc.edu Sun Nov 13 19:36:18 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 13 Nov 2011 20:36:18 -0500 Subject: Arguing against using public IP space In-Reply-To: <20111113212756.GD73635@macbook.bluepipe.net> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> Message-ID: <4EC07092.9070101@utc.edu> On 11/13/2011 4:27 PM, Phil Regnauld wrote: > That's not exactly correct. NAT doesn't imply firewalling/filtering. > To illustrate this to customers, I've mounted attacks/scans on hosts > behind NAT devices, from the interconnect network immediately outside: > if you can point a route with the ext ip of the NAT device as the next > hop, it usually just forwards the packets... Phil "It depends" on your NAT model. If you take a default Cisco PIX or ASA device... (a) There is an option to "permit non-NAT traffic through the firewall". If not selected (nat-control) then there must be a covering NAT rule for any inside host to communicate with the outside interface, let alone outside-to-inside. (b) By default all inbound traffic is default-deny, only "return" traffic for inside-initiated connections is allowed. Yes, it's stateful (which is another argument altogether for placing a stateful device in the chain) but by all means, it does not allow outside traffic into the inside, regardless of the addressing scheme on the inside. Beyond that, using 1918 space decreases the possibility that a "new, unexpected" path to the inside network will result in exposure. If you are using public space on the inside, and some path develops that bypasses the firewall, the routing information is already in place, you only need to affect the last hop. You can then get end-to-end routing of inside hosts to an outside party. Using 1918 space, with even nominal BCP adherence of the intermediate transit providers, you can't leak routing naturally. (Yes, it's certainly possible, but it raises the bar). If the added protection were trivial, I would think the PCI requirement 1.3.8 requiring it would have been rejected long ago. Jeff From jay at west.net Sun Nov 13 19:39:03 2011 From: jay at west.net (Jay Hennigan) Date: Sun, 13 Nov 2011 17:39:03 -0800 Subject: Arguing against using public IP space In-Reply-To: <4EC06106.2020303@west.net> References: <4EC06106.2020303@west.net> Message-ID: <4EC07137.7030706@west.net> On 11/13/11 3:58 PM, Jason Lewis wrote: > People keep pointing to this as unlikely. I argue that spammers are > currently doing this all over the world, maybe not as widespread wiith > 1918 space. If I can announce 1918 space to an ISP where my target > is...it doesn't matter if everyone else ignores or drops it. The ISP > allowed it, so all their customers will route the traffic. I still > think it's a valid attack vector, discounting it because people would > laugh at me, seems like a poor security posture. It would be your target announcing the RFC1918 space, so the security risk would be if his ISP, your ISP and all of the intermediate peering/transit links were to honor those announcements and route the traffic to the target. Possible, and it has probably happened at some point, but not likely. The closer your logically to your target the more likely such an attack would succeed. I certainly don't recommend announcing RFC1918 space to the public Internet. Doing so is a bad thing. If you do so there is indeed a non-zero chance that someone close enough to you could connect to your network and do damage. Announcing RFC1918 space is less likely to route very far than announcing public space that isn't allocated to you, however. That's what the spammers all over the world are doing. In terms of security, most every SCADA system, as others have pointed out, should not be connected to the public Internet AT ALL. In this case it really doesn't matter what addressing scheme is used. Use Novell IPX or Appletalk if you want. Or MODBUS. If, however, it is using IPv4, RFC1918 space in a different subnet than anything used internally within the organization is a better choice than any public space or subnets of RFC1918 space in use within the organization. This offers a degree of protection against mis-cabling and other accidental or malicious vectors that could allow other networks to communicate with the SCADA network. It would probably be best if the SCADA hardware vendors were to ship their gear with no IP addresses pre-programmed at all, as well as preventing them from being configured until any default passwords are changed. Similarly, they should educate their installation contractors about such things. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jgreco at ns.sol.net Sun Nov 13 20:24:29 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 13 Nov 2011 20:24:29 -0600 (CST) Subject: Arguing against using public IP space In-Reply-To: <20111114011458.GA19365@panix.com> Message-ID: <201111140224.pAE2OTjX061150@aurora.sol.net> > Sure, anytime there's an attack or failure on a SCADA network that > wouldn't have occurred had it been air-gapped, it's easy for people to > knee-jerk a "SCADA networks should be airgapped" response. But that's > not really intelligent commentary unless you carefully consider what > risks are associated with air-gapping the network. Not to mention that it's not the only way for these things to get infected. Getting fixated on air-gapping is unrealistically ignoring the other threats out there. There needs to be a whole lot more security work done on SCADA nets. ... 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 Valdis.Kletnieks at vt.edu Sun Nov 13 20:43:32 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 13 Nov 2011 21:43:32 -0500 Subject: Arguing against using public IP space In-Reply-To: Your message of "Sun, 13 Nov 2011 19:14:59 CST." <20111114011458.GA19365@panix.com> References: <30721173.2585.1321226978998.JavaMail.root@benjamin.baylink.com> <20111114011458.GA19365@panix.com> Message-ID: <81357.1321238612@turing-police.cc.vt.edu> On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said: > What if you air-gap the SCADA network of which you are in > administrative control, and then there's a failure on it, and the people > responsible for troubleshooting it can't do it remotely (because of the > air gap), so the trouble continues for an extra hour while they drive > to the office, and that extra hour of failure causes someone to die. > Should that result in a homicide charge? If you designed a life-critical airgapped network that didn't have a trained warm body at the NOC 24/7 with an airgapped management console, and hot (or at least warm) spares for both console and console monkey, yes, you *do* deserve that negligent homicide charge. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joelja at bogus.com Sun Nov 13 20:59:45 2011 From: joelja at bogus.com (Joel jaeggli) Date: Mon, 14 Nov 2011 10:59:45 +0800 Subject: Arguing against using public IP space In-Reply-To: <201111140224.pAE2OTjX061150@aurora.sol.net> References: <201111140224.pAE2OTjX061150@aurora.sol.net> Message-ID: <4EC08421.80708@bogus.com> On 11/14/11 10:24 , Joe Greco wrote: >> Sure, anytime there's an attack or failure on a SCADA network that >> wouldn't have occurred had it been air-gapped, it's easy for people to >> knee-jerk a "SCADA networks should be airgapped" response. But that's >> not really intelligent commentary unless you carefully consider what >> risks are associated with air-gapping the network. > > Not to mention that it's not the only way for these things to get > infected. Getting fixated on air-gapping is unrealistically ignoring > the other threats out there. > > There needs to be a whole lot more security work done on SCADA nets. Stuxnet should provide a fairly illustrative example. It doesn't really matter how well isolated from direct access it is if it has a soft gooey center and a willing attacker. > ... JG From mysidia at gmail.com Sun Nov 13 21:48:01 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 13 Nov 2011 21:48:01 -0600 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> Message-ID: On Sun, Nov 13, 2011 at 3:03 PM, David Walker wrote: > On 14/11/2011, Jimmy Hess wrote: > A packet addressed to an endpoint that doesn't serve anything or have > a client listening will be ignered (whatever) as a matter of course. > Firewall or no firewall. It will not go to a listening application, neither will it be completely ignored -- the receiving machine's TCP stack will have a look at the packet. On common operating systems there are frequently unsafe applications listening on ports; on certain OSes, there will be no way to turn off system applications, or human error will leave them in place. > That's fundamental to TCP/IP and secure. It's fundamental to TCP/IP, but not fundamentally secure. TCP/IP implementations have flaws. If a host is meant solely as an endpoint, then it is exposed to undue risk, if arbitrary packets can be addressed to its TCP/IP stack that might have remotely exploitable bugs. > The only reason we firewall (packet filter) is to provide access > control (for whatever reason). No, we also firewall to block access entirely to applications attempting to establish a service on unapproved ports. We also use firewalls in certain forms to ensure that communications over a TCP/IP socket comply with a protocol, for example, that a session terminated on port 25 is actually a SMTP session. The firewall might restrict the set of allowed SMTP commands, validate the syntax of certain commands, hide server version information, prevent use of ESMTP pipelining from outside, etc. > I apologize in advance if this is too pedestrian (you might know this > but not agree with it) but I want to make a point: > http://en.wikipedia.org/wiki/End-to-end_connectivity End to end connectivity principal's purpose is not to provide security. It is to facilitate communications with other hosts and networks. When a private system _really_ has to be secure, end to end connectivity is inherently incompatible with security objectives. There is always a tradeoff involving sacrificing a level of security against remote attack when connecting a computer to a network, and then again, when connecting the network to the internet. A computer that is not connected to a network is perfectly secure against network-based attacks. A computer that is connected to LAN is at risk of potential network-based attack from that LAN. If that LAN is then connected through a firewall through many to 1 NAT, there is another layer of risk added. If the NAT'ing firewall is then replaced with a simple many to 1 NAT router, there is another layer of risk added; there are new attacks possible that still succeed in a NAT environment, that the firewall would have stopped. Finally, if that that same computer is then given end to end connectivity with no firewall, there is a much less encumbered communications path available to that computer for launching network-based attack; the attack surface is greatly increased in such a design. If we are talking about nodes that interface with a SCADA network; the concept of unfirewalled end-to-end connectivity approaches the level of insanity. Those are not systems where end-to-end public connectivity should be a priority over security. -- -JH From owen at delong.com Sun Nov 13 21:51:24 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 13 Nov 2011 19:51:24 -0800 Subject: Arguing against using public IP space In-Reply-To: References: Message-ID: <2DE5DF4F-059C-4F39-81D4-363E49966282@delong.com> On Nov 13, 2011, at 7:36 AM, Jason Lewis wrote: > I don't want to start a flame war, but this article seems flawed to > me. It seems an IP is an IP. > > http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html > > I think I could announce private IP space, so doesn't that make this > argument invalid? I've always looked at private IP space as more of a > resource and management choice and not a security feature. Yes, the author of this article is sadly mistaken and woefully void of clue on the issues he attempts to address. You are completely correct. Owen From rdobbins at arbor.net Mon Nov 14 00:21:47 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 14 Nov 2011 06:21:47 +0000 Subject: Arguing against using public IP space In-Reply-To: <201111140224.pAE2OTjX061150@aurora.sol.net> References: <201111140224.pAE2OTjX061150@aurora.sol.net> Message-ID: On Nov 14, 2011, at 9:24 AM, Joe Greco wrote: > Getting fixated on air-gapping is unrealistically ignoring the other threats out there. I don't think anyone in this thread is 'fixated' on the idea of airgapping; but it's generally a good idea whenever possible, and as restrictive a communications policy as is possible is definitely called for, amongst all the other things one ought to be doing. It's also important to note that it's often impossible to *completely* airgap things, these days, due to various interdependencies, admin requirements (mentioned before), and so forth; perhaps bastioning is a more apt term. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From gaileywg at MANSFIELDCT.ORG Mon Nov 14 08:42:32 2011 From: gaileywg at MANSFIELDCT.ORG (Sam (Walter) Gailey) Date: Mon, 14 Nov 2011 14:42:32 +0000 Subject: Cable standards question Message-ID: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> Hello, newbie question of the morning time, but hopefully not too off-topic... I run a small town network. A new building is being built that the town wants fiber access to. I have to specify for vendors what it is that the town expects in the cabling. I am (obviously) not a fiber expert, and I'm having trouble phrasing the language of the RFP so that we are assured a quality installation. My question is this; Is there an appropriate standard to specify for fiber-optic cabling that if it is followed the fiber will be installed correctly? Would specifying TIA/EIA 568-C.3, for example, be correct? I'm envisioning something like; "The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling." Any suggestions or examples of language would be very appreciated. Offlist contact is probably best. Many thanks, ---Sam From dseagrav at humancapitaldev.com Mon Nov 14 08:57:31 2011 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Mon, 14 Nov 2011 08:57:31 -0600 Subject: Cable standards question In-Reply-To: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> Message-ID: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE@humancapitaldev.com> On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote: > "The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling." > > Any suggestions or examples of language would be very appreciated. Offlist contact is probably best. Is it appropriate to just say "When installing fiber-optic cable the vendor will ensure the resulting installation does not suck."? That would seem to me to be the most direct solution to the problem. I mean, standards are all well and good, but what if the standard sucks? Then you'd be up a creek. Maybe there should be a legal definition of the concept of suck, so that suckage could be contractually minimized. From jgreco at ns.sol.net Mon Nov 14 08:58:37 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 14 Nov 2011 08:58:37 -0600 (CST) Subject: Arguing against using public IP space In-Reply-To: <4EC08421.80708@bogus.com> Message-ID: <201111141458.pAEEwcS6072727@aurora.sol.net> > On 11/14/11 10:24 , Joe Greco wrote: > >> Sure, anytime there's an attack or failure on a SCADA network that > >> wouldn't have occurred had it been air-gapped, it's easy for people to > >> knee-jerk a "SCADA networks should be airgapped" response. But that's > >> not really intelligent commentary unless you carefully consider what > >> risks are associated with air-gapping the network. > > > > Not to mention that it's not the only way for these things to get > > infected. Getting fixated on air-gapping is unrealistically ignoring > > the other threats out there. > > > > There needs to be a whole lot more security work done on SCADA nets. > > Stuxnet should provide a fairly illustrative example. > > It doesn't really matter how well isolated from direct access it is if > it has a soft gooey center and a willing attacker. That's basically the case for so many things. I was reading, recently, two articles on Ars Technica ("Die, VPN" and "Live, VPN") which made it exceedingly clear that these sorts of designs are still the rule for most companies. I mean, I already knew that, but it was *depressing* to read. We've been very successful for many years designing things as though they were going to be deployed on the public Internet, even if we do still put them behind a firewall. That's just belt-and-suspenders common sense. We do run a VPN service, which I use heavily, but it really has little to do with granting magical access to resources - the VPN endpoint is actually outside any firewall. I've so frequently found, over the years, that some "free" Internet connection offering is crippled in some stupid manner (transparent proxying with ad injection!), that the value added is mostly just that of getting an Internet connection with no interference by third parties. The fact that third parties cannot do any meaningful snooping is nice too. I also recall a fairly surreal discussion with a NANOG'er who was absolutely convinced that SSH key based access to other servers was more secure than password based access along with some ACL's and something like sshguard; my point was that compromise of the magic host with the magic key would tend to be worse (because you've suddenly got access to all the other servers) while having different secure passwords for each host, along with some ACL's and sshguard, allow you to retain some isolation within the network from an infected node. It's dependent on design and forethought, of course... Basically, getting access to some point in the network shouldn't really allow you to go on a rampage through the rest of the network. ... 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 rps at maine.edu Mon Nov 14 09:00:36 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 14 Nov 2011 10:00:36 -0500 Subject: Arguing against using public IP space In-Reply-To: References: Message-ID: As far as I can see Red Tiger Security is Jonathan Pollet; and even though they list Houston, Dubai, Milan, and Sydney as offices it looks like Houston is the only one.? Is that right?? Seems a little misleading. It actually reminds me of a 16 year old kid I know who runs a web hosting "company" that you'd think was a Fortune 500 by the way the website reads, and he's more than happy to take your credit card information and store it without being PCI compliant. Credibility of the company aside, At first I wanted to cut Jonathan some slack.? If he was going to point to the use of public IPs as evidence that a firewall may not be in use and then went on to discuss the potential risks of not having any security, then that would have been appropriate.? But instead he goes on about explaining what a public vs. private address is (poorly) and proceeds to associate the security of the system with the use of private IPs. I just don't see him as credible in the security field after reading it. Then again, he does have that interview on Fox News posted on his website where he talks about terrorist plots to compromise the integrity of nuclear power plants... Honestly, people post stuff like this time and time again. It's been debunked so many times that a quick Google will probably give you what you need to figure it out on your own. On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis wrote: > I don't want to start a flame war, but this article seems flawed to > me. ?It seems an IP is an IP. > > http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html > > I think I could announce private IP space, so doesn't that make this > argument invalid? ?I've always looked at private IP space as more of a > resource and management choice and not a security feature. > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From jgreco at ns.sol.net Mon Nov 14 09:05:01 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 14 Nov 2011 09:05:01 -0600 (CST) Subject: Arguing against using public IP space In-Reply-To: Message-ID: <201111141505.pAEF51jX072831@aurora.sol.net> > On Nov 14, 2011, at 9:24 AM, Joe Greco wrote: > > Getting fixated on air-gapping is unrealistically ignoring the other thre= > ats out there. > > I don't think anyone in this thread is 'fixated' on the idea of airgapping;= No, but it's clear that there are many designers out there who feel this is the way to go. That's why it's a good idea to cover the ground anyways. > but it's generally a good idea whenever possible, and as restrictive a com= > munications policy as is possible is definitely called for, amongst all the= > other things one ought to be doing. I think the part people forget about is that last part, "amongst all the other things one ought to be doing." > It's also important to note that it's often impossible to *completely* airg= > ap things, these days, due to various interdependencies, admin requirements= > (mentioned before), and so forth; perhaps bastioning is a more apt term. If it didn't turn into a situation where everyone's bastardizing^Wbastioning your network in insecure ways. ... 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 Mon Nov 14 09:12:35 2011 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 14 Nov 2011 10:12:35 -0500 (EST) Subject: Cable standards question In-Reply-To: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> Message-ID: On Mon, 14 Nov 2011, Sam (Walter) Gailey wrote: > My question is this; Is there an appropriate standard to specify for fiber-optic cabling that if it is followed the fiber will be installed correctly? Would specifying TIA/EIA 568-C.3, for example, be correct? > > I'm envisioning something like; > > "The vendor will provide fiber connectivity between (building A) and > (building B). Vendor will be responsible for all building penetrations > and terminations. When installing the fiber-optic cable the vendor will > follow the appropriate TIA/EIA 568 standards for fiber-optic cabling." At minimum, I think you should probably specify the type and number of fibers you want. i.e. Based on the distance and gear you'll be using, do you need single-mode, or will multi-mode do (as well as the core/cladding diameter)? Generally, but not always, fiber uses one strand for transmit and another for receive, so a typical fiber run is done using duplex fiber. Some optics can transmit and receive over one strand using different wavelengths. You might even specify how you want the fiber terminated (SC, LC, cables hanging from the wall, fiber patch panel, etc.). ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mike at cmkconsulting.com Mon Nov 14 09:25:12 2011 From: mike at cmkconsulting.com (Mickey Fox) Date: Mon, 14 Nov 2011 09:25:12 -0600 Subject: airgap / negligent homicide charge Message-ID: The determination of whether a failure rises to the level of negligent homicide will require a review of industry standards, company standards and sometimes straight common-sence. If the industry standard is airgap re security you are probably okay so long as you review and address the very concerns and questions you are raising in a responsible fashion that does not rely solely on expediency, cost, etc., but looks to real-world scenarios and emergency / backup procedures, equipment, testing and training. Mickey Fox CMK Consulting Services On Nov 14, 2011 9:00 AM, 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: Arguing against using public IP space > (Valdis.Kletnieks at vt.edu) > 2. Re: Arguing against using public IP space (Joel jaeggli) > 3. Re: Arguing against using public IP space (Jimmy Hess) > 4. Re: Arguing against using public IP space (Owen DeLong) > 5. Re: Arguing against using public IP space (Dobbins, Roland) > 6. Cable standards question (Sam (Walter) Gailey) > 7. Re: Cable standards question (Daniel Seagraves) > 8. Re: Arguing against using public IP space (Joe Greco) > 9. Re: Arguing against using public IP space (Ray Soucy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 13 Nov 2011 21:43:32 -0500 > From: Valdis.Kletnieks at vt.edu > To: Brett Frankenberger > Cc: NANOG > Subject: Re: Arguing against using public IP space > Message-ID: <81357.1321238612 at turing-police.cc.vt.edu> > Content-Type: text/plain; charset="us-ascii" > > On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said: > > > What if you air-gap the SCADA network of which you are in > > administrative control, and then there's a failure on it, and the people > > responsible for troubleshooting it can't do it remotely (because of the > > air gap), so the trouble continues for an extra hour while they drive > > to the office, and that extra hour of failure causes someone to die. > > Should that result in a homicide charge? > > If you designed a life-critical airgapped network that didn't have a > trained > warm body at the NOC 24/7 with an airgapped management console, and hot > (or at > least warm) spares for both console and console monkey, yes, you *do* > deserve > that negligent homicide charge. > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 227 bytes > Desc: not available > URL: < > http://mailman.nanog.org/pipermail/nanog/attachments/20111113/247b47fe/attachment-0001.bin > > > > ------------------------------ > > Message: 2 > Date: Mon, 14 Nov 2011 10:59:45 +0800 > From: Joel jaeggli > To: Joe Greco > Cc: NANOG > Subject: Re: Arguing against using public IP space > Message-ID: <4EC08421.80708 at bogus.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/14/11 10:24 , Joe Greco wrote: > >> Sure, anytime there's an attack or failure on a SCADA network that > >> wouldn't have occurred had it been air-gapped, it's easy for people to > >> knee-jerk a "SCADA networks should be airgapped" response. But that's > >> not really intelligent commentary unless you carefully consider what > >> risks are associated with air-gapping the network. > > > > Not to mention that it's not the only way for these things to get > > infected. Getting fixated on air-gapping is unrealistically ignoring > > the other threats out there. > > > > There needs to be a whole lot more security work done on SCADA nets. > > Stuxnet should provide a fairly illustrative example. > > It doesn't really matter how well isolated from direct access it is if > it has a soft gooey center and a willing attacker. > > > ... JG > > > > > ------------------------------ > > Message: 3 > Date: Sun, 13 Nov 2011 21:48:01 -0600 > From: Jimmy Hess > To: David Walker > Cc: nanog at nanog.org > Subject: Re: Arguing against using public IP space > Message-ID: > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Sun, Nov 13, 2011 at 3:03 PM, David Walker > wrote: > > On 14/11/2011, Jimmy Hess wrote: > > A packet addressed to an endpoint that doesn't serve anything or have > > a client listening will be ignered (whatever) as a matter of course. > > Firewall or no firewall. > It will not go to a listening application, neither will it be > completely ignored -- > the receiving machine's TCP stack will have a look at the packet. > On common operating systems there are frequently unsafe applications > listening on ports; on certain OSes, there will be no way to turn off > system applications, or human error will leave them in place. > > > That's fundamental to TCP/IP and secure. > It's fundamental to TCP/IP, but not fundamentally secure. TCP/IP > implementations have flaws. > If a host is meant solely as an endpoint, then it is exposed to undue > risk, if arbitrary packets can be addressed to its TCP/IP stack that > might have remotely exploitable bugs. > > > The only reason we firewall (packet filter) is to provide access > > control (for whatever reason). > No, we also firewall to block access entirely to applications > attempting to establish a service on unapproved ports. We also use > firewalls in certain forms to ensure that communications over a TCP/IP > socket comply with a protocol, for example, that a session > terminated on port 25 is actually a SMTP session. > > The firewall might restrict the set of allowed SMTP commands, validate > the syntax of certain commands, hide server version information, > prevent use of ESMTP pipelining from outside, etc. > > > I apologize in advance if this is too pedestrian (you might know this > > but not agree with it) but I want to make a point: > > http://en.wikipedia.org/wiki/End-to-end_connectivity > > End to end connectivity principal's purpose is not to provide > security. It is to facilitate communications with other hosts and > networks. When a private system _really_ has to be secure, end to > end connectivity is inherently incompatible with security objectives. > > There is always a tradeoff involving sacrificing a level of security > against remote attack > when connecting a computer to a network, and then again, when > connecting the network to the internet. > > A computer that is not connected to a network is perfectly secure > against network-based attacks. > A computer that is connected to LAN is at risk of potential > network-based attack from that LAN. > > If that LAN is then connected through a firewall through many to 1 > NAT, there is another layer of risk added. > > If the NAT'ing firewall is then replaced with a simple many to 1 NAT > router, there is another layer of risk added; there are new attacks > possible that still succeed in a NAT environment, that the firewall > would have stopped. > > Finally, if that that same computer is then given end to end > connectivity with no firewall, there is a much less encumbered > communications path available to that computer for launching > network-based attack; the attack surface is greatly increased in such > a design. > > If we are talking about nodes that interface with a SCADA network; > the concept of unfirewalled end-to-end connectivity approaches the > level of insanity. > > Those are not systems where end-to-end public connectivity should be a > priority over security. > > -- > -JH > > > > ------------------------------ > > Message: 4 > Date: Sun, 13 Nov 2011 19:51:24 -0800 > From: Owen DeLong > To: Jason Lewis > Cc: nanog at nanog.org > Subject: Re: Arguing against using public IP space > Message-ID: <2DE5DF4F-059C-4F39-81D4-363E49966282 at delong.com> > Content-Type: text/plain; charset=us-ascii > > > On Nov 13, 2011, at 7:36 AM, Jason Lewis wrote: > > > I don't want to start a flame war, but this article seems flawed to > > me. It seems an IP is an IP. > > > > > http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html > > > > I think I could announce private IP space, so doesn't that make this > > argument invalid? I've always looked at private IP space as more of a > > resource and management choice and not a security feature. > > Yes, the author of this article is sadly mistaken and woefully void > of clue on the issues he attempts to address. > > You are completely correct. > > Owen > > > > > ------------------------------ > > Message: 5 > Date: Mon, 14 Nov 2011 06:21:47 +0000 > From: "Dobbins, Roland" > To: NANOG Operators' Group > Subject: Re: Arguing against using public IP space > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On Nov 14, 2011, at 9:24 AM, Joe Greco wrote: > > > Getting fixated on air-gapping is unrealistically ignoring the other > threats out there. > > I don't think anyone in this thread is 'fixated' on the idea of > airgapping; but it's generally a good idea whenever possible, and as > restrictive a communications policy as is possible is definitely called > for, amongst all the other things one ought to be doing. > > It's also important to note that it's often impossible to *completely* > airgap things, these days, due to various interdependencies, admin > requirements (mentioned before), and so forth; perhaps bastioning is a more > apt term. > > ----------------------------------------------------------------------- > Roland Dobbins // > > The basis of optimism is sheer terror. > > -- Oscar Wilde > > > > > ------------------------------ > > Message: 6 > Date: Mon, 14 Nov 2011 14:42:32 +0000 > From: "Sam (Walter) Gailey" > To: "nanog at nanog.org" > Subject: Cable standards question > Message-ID: > <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2 at TN-Mail-1.mansfieldct.net > > > Content-Type: text/plain; charset="us-ascii" > > Hello, newbie question of the morning time, but hopefully not too > off-topic... > > I run a small town network. A new building is being built that the town > wants fiber access to. I have to specify for vendors what it is that the > town expects in the cabling. I am (obviously) not a fiber expert, and I'm > having trouble phrasing the language of the RFP so that we are assured a > quality installation. > > My question is this; Is there an appropriate standard to specify for > fiber-optic cabling that if it is followed the fiber will be installed > correctly? Would specifying TIA/EIA 568-C.3, for example, be correct? > > I'm envisioning something like; > > "The vendor will provide fiber connectivity between (building A) and > (building B). Vendor will be responsible for all building penetrations and > terminations. When installing the fiber-optic cable the vendor will follow > the appropriate TIA/EIA 568 standards for fiber-optic cabling." > > Any suggestions or examples of language would be very appreciated. Offlist > contact is probably best. > > Many thanks, > > ---Sam > > > ------------------------------ > > Message: 7 > Date: Mon, 14 Nov 2011 08:57:31 -0600 > From: Daniel Seagraves > To: nanog at nanog.org > Subject: Re: Cable standards question > Message-ID: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE at humancapitaldev.com> > Content-Type: text/plain; charset=us-ascii > > > On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote: > > > "The vendor will provide fiber connectivity between (building A) and > (building B). Vendor will be responsible for all building penetrations and > terminations. When installing the fiber-optic cable the vendor will follow > the appropriate TIA/EIA 568 standards for fiber-optic cabling." > > > > Any suggestions or examples of language would be very appreciated. > Offlist contact is probably best. > > Is it appropriate to just say "When installing fiber-optic cable the > vendor will ensure the resulting installation does not suck."? > That would seem to me to be the most direct solution to the problem. I > mean, standards are all well and good, but what if the standard sucks? > Then you'd be up a creek. > > Maybe there should be a legal definition of the concept of suck, so that > suckage could be contractually minimized. > > > > > ------------------------------ > > Message: 8 > Date: Mon, 14 Nov 2011 08:58:37 -0600 (CST) > From: Joe Greco > To: joelja at bogus.com (Joel jaeggli) > Cc: NANOG > Subject: Re: Arguing against using public IP space > Message-ID: <201111141458.pAEEwcS6072727 at aurora.sol.net> > Content-Type: text/plain; charset=us-ascii > > > On 11/14/11 10:24 , Joe Greco wrote: > > >> Sure, anytime there's an attack or failure on a SCADA network that > > >> wouldn't have occurred had it been air-gapped, it's easy for people to > > >> knee-jerk a "SCADA networks should be airgapped" response. But that's > > >> not really intelligent commentary unless you carefully consider what > > >> risks are associated with air-gapping the network. > > > > > > Not to mention that it's not the only way for these things to get > > > infected. Getting fixated on air-gapping is unrealistically ignoring > > > the other threats out there. > > > > > > There needs to be a whole lot more security work done on SCADA nets. > > > > Stuxnet should provide a fairly illustrative example. > > > > It doesn't really matter how well isolated from direct access it is if > > it has a soft gooey center and a willing attacker. > > That's basically the case for so many things. > > I was reading, recently, two articles on Ars Technica ("Die, VPN" and > "Live, VPN") which made it exceedingly clear that these sorts of designs > are still the rule for most companies. I mean, I already knew that, but > it was *depressing* to read. > > We've been very successful for many years designing things as though they > were going to be deployed on the public Internet, even if we do still put > them behind a firewall. That's just belt-and-suspenders common sense. > > We do run a VPN service, which I use heavily, but it really has little > to do with granting magical access to resources - the VPN endpoint is > actually outside any firewall. I've so frequently found, over the years, > that some "free" Internet connection offering is crippled in some stupid > manner (transparent proxying with ad injection!), that the value added > is mostly just that of getting an Internet connection with no interference > by third parties. The fact that third parties cannot do any meaningful > snooping is nice too. > > I also recall a fairly surreal discussion with a NANOG'er who was > absolutely convinced that SSH key based access to other servers was > more secure than password based access along with some ACL's and > something like sshguard; my point was that compromise of the magic > host with the magic key would tend to be worse (because you've suddenly > got access to all the other servers) while having different secure > passwords for each host, along with some ACL's and sshguard, allow you > to retain some isolation within the network from an infected node. It's > dependent on design and forethought, of course... > > Basically, getting access to some point in the network shouldn't really > allow you to go on a rampage through the rest of the network. > > ... 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. > > > > ------------------------------ > > Message: 9 > Date: Mon, 14 Nov 2011 10:00:36 -0500 > From: Ray Soucy > To: Jason Lewis > Cc: nanog at nanog.org > Subject: Re: Arguing against using public IP space > Message-ID: > > > Content-Type: text/plain; charset=ISO-8859-1 > > As far as I can see Red Tiger Security is Jonathan Pollet; and even > though they list Houston, Dubai, Milan, and Sydney as offices it looks > like Houston is the only one.? Is that right?? Seems a little > misleading. > > It actually reminds me of a 16 year old kid I know who runs a web > hosting "company" that you'd think was a Fortune 500 by the way the > website reads, and he's more than happy to take your credit card > information and store it without being PCI compliant. > > Credibility of the company aside, > > At first I wanted to cut Jonathan some slack.? If he was going to > point to the use of public IPs as evidence that a firewall may not be > in use and then went on to discuss the potential risks of not having > any security, then that would have been appropriate.? But instead he > goes on about explaining what a public vs. private address is (poorly) > and proceeds to associate the security of the system with the use of > private IPs. > > I just don't see him as credible in the security field after reading it. > > Then again, he does have that interview on Fox News posted on his > website where he talks about terrorist plots to compromise the > integrity of nuclear power plants... > > Honestly, people post stuff like this time and time again. It's been > debunked so many times that a quick Google will probably give you what > you need to figure it out on your own. > > On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis > wrote: > > I don't want to start a flame war, but this article seems flawed to > > me. ?It seems an IP is an IP. > > > > > http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html > > > > I think I could announce private IP space, so doesn't that make this > > argument invalid? ?I've always looked at private IP space as more of a > > resource and management choice and not a security feature. > > > > > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > > > > End of NANOG Digest, Vol 46, Issue 43 > ************************************* > From jof at thejof.com Mon Nov 14 09:38:38 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Mon, 14 Nov 2011 07:38:38 -0800 Subject: Cable standards question In-Reply-To: References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> Message-ID: On Mon, Nov 14, 2011 at 7:12 AM, Jon Lewis wrote: > On Mon, 14 Nov 2011, Sam (Walter) Gailey wrote: > > My question is this; Is there an appropriate standard to specify for >> fiber-optic cabling that if it is followed the fiber will be installed >> correctly? Would specifying TIA/EIA 568-C.3, for example, be correct? >> >> I'm envisioning something like; >> >> "The vendor will provide fiber connectivity between (building A) and >> (building B). Vendor will be responsible for all building penetrations and >> terminations. When installing the fiber-optic cable the vendor will follow >> the appropriate TIA/EIA 568 standards for fiber-optic cabling." >> > > At minimum, I think you should probably specify the type and number of > fibers you want. i.e. Based on the distance and gear you'll be using, do > you need single-mode, or will multi-mode do (as well as the core/cladding > diameter)? Generally, but not always, fiber uses one strand for transmit > and another for receive, so a typical fiber run is done using duplex fiber. > Some optics can transmit and receive over one strand using different > wavelengths. You might even specify how you want the fiber terminated (SC, > LC, cables hanging from the wall, fiber patch panel, etc.). > I'd agree with this. I wouldn't worry about the standard so much as the practical aspects of a run. Once you have an idea of the approximate distance of the run, you can figure out which optics you plan on using. This will determine what physical connectors you'll need and what your approximate link budget will be. Based on that information, you can figure out which type to ask for (9um/125um single-mode, most likely), a range of path loss that you're comfortable with, and the physical termination you'd like at either end. Cheers, jof From jra at baylink.com Mon Nov 14 09:59:37 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 14 Nov 2011 10:59:37 -0500 (EST) Subject: Cable standards question In-Reply-To: Message-ID: <30391048.2725.1321286377294.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jonathan Lassoff" > I'd agree with this. I wouldn't worry about the standard so much as the > practical aspects of a run. Once you have an idea of the approximate > distance of the run, you can figure out which optics you plan on > using. This will determine what physical connectors you'll need and what your > approximate link budget will be. > > Based on that information, you can figure out which type to ask for > (9um/125um single-mode, most likely), a range of path loss that you're > comfortable with, and the physical termination you'd like at either > end. You Jon people[1] are, as near as I can tell, answering a question the OP didn't actually ask. It may in fact be that he didn't realize he should spec the design down to that level, but it sounded to me like what he was looking for was "what language should I put in there to constrain the quality of the implementation?" Cheers, -- jra [1] :-) -- 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 chipps at chipps.com Mon Nov 14 10:05:52 2011 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Mon, 14 Nov 2011 10:05:52 -0600 Subject: Cable standards question In-Reply-To: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> Message-ID: <003901cca2e7$49361d10$dba25730$@chipps.com> BICSI has a sample RFQ for this purpose. You can use the whole thing or just pull out the cabling phrase. You will need to update the standard names to the current ones. https://www.bicsi.org/single.aspx?l=1866 Kenneth M. Chipps Ph.D. -----Original Message----- From: Sam (Walter) Gailey [mailto:gaileywg at MANSFIELDCT.ORG] Sent: Monday, November 14, 2011 8:43 AM To: nanog at nanog.org Subject: Cable standards question Hello, newbie question of the morning time, but hopefully not too off-topic... I run a small town network. A new building is being built that the town wants fiber access to. I have to specify for vendors what it is that the town expects in the cabling. I am (obviously) not a fiber expert, and I'm having trouble phrasing the language of the RFP so that we are assured a quality installation. My question is this; Is there an appropriate standard to specify for fiber-optic cabling that if it is followed the fiber will be installed correctly? Would specifying TIA/EIA 568-C.3, for example, be correct? I'm envisioning something like; "The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling." Any suggestions or examples of language would be very appreciated. Offlist contact is probably best. Many thanks, ---Sam From streiner at cluebyfour.org Mon Nov 14 10:07:40 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 14 Nov 2011 11:07:40 -0500 (EST) Subject: Cable standards question In-Reply-To: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> Message-ID: On Mon, 14 Nov 2011, Sam (Walter) Gailey wrote: > My question is this; Is there an appropriate standard to specify for > fiber-optic cabling that if it is followed the fiber will be installed > correctly? Would specifying TIA/EIA 568-C.3, for example, be correct? > > I'm envisioning something like; > > "The vendor will provide fiber connectivity between (building A) and > (building B). Vendor will be responsible for all building penetrations > and terminations. When installing the fiber-optic cable the vendor will > follow the appropriate TIA/EIA 568 standards for fiber-optic cabling." How you phrase the requirements depends on what you want the end result to be. Sorry to start this off with a wishy-washy statement, but when dealing with contractors, you have to be very specific with what you want, and stay involved during the project, to be sure the results are what you want. It's a good idea to define very clearly what is "in scope" and "out of scope" for the contractor up front. This can include things like the contractor being responsible for submitting any one-call requests per your localities' guidelines for any work that requires digging, or restoring any items that have to be removed (landscaping, sidewalks, paved roadways, etc) to facilitate digging. For example, do the buildings in question already have usable entrance facilities for communications (aerial/underground entrances, suitable demarc locations in each building, cable pathways from the exterior penetrations to the demarc point)? If not, you will generally need to spell out exactly what the fiber contractor (or a sub-contractor) is expected to provide (conduits from comms manhole/utility vault/pole/etc). Typically you will need to define a place in each building where the fiber will land, which will either be in a rack or on a wall. Also, at a minimum, the contractor should 1. test all strands at the appropriate wavelengths, 2. provide you with documentation of the test results, and 3. general fit-and-finish/workmanship items such as making sure all connectors have dust caps and any required labeling of the termination bays. Where I work, we have detailed construction / installation standards that get added to the bid package of any new construction or major renovation on our campus. If you want, I can send you a copy (off-list) of the relevant pieces of our Division 27 specs that go out to contractors as part of our construction bid packages. jms From jasongurtz at npumail.com Mon Nov 14 10:56:52 2011 From: jasongurtz at npumail.com (Jason Gurtz) Date: Mon, 14 Nov 2011 11:56:52 -0500 Subject: Cable standards question In-Reply-To: References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> Message-ID: > How you phrase the requirements depends on what you want the end result > to be. Sorry to start this off with a wishy-washy statement, but when > dealing with contractors, you have to be very specific with what you > want, and stay involved during the project, to be sure the results are > what you want. This is *really* great advice. Standards are good, but it pays to have due-diligence done about specific products and methods. To the OP: I witnessed a municipal fiber build-out, managed by someone in another department who had essentially zero networking experience. His consultants' all seemed experienced in conceptual layout, but not so much the specific physical details. While this project was basically a success, 99% of the difficulties had to do with physical access details, site remediation (power, racks, site-local cabling), and the specific fiber related equipment such as splice boxes and patch panels. For instance, we ended up with a 23" telco rack filled with 19" equipment and 23" to 19" converter panels. General tidiness; a contractor left a large splice-box laying on the floor in the midst of a slack-spool instead of wall or rack mounting. Another contractor developed a spider's nest of wiring in our server room instead of structured cabling. Specifying exact rack sizes, specific cable management, mounting locations, etc... would have helped a lot. Photos of the specific areas would have helped immensely. Some of the delivered patch panels were of low quality (many of the connectors were faulty, requiring extra labor to clean and re-polish). Caveat emptor! Find what the good brands are and specify (maybe others can comment here). Go take a look at vendor websites like Middle Atlantic and see what options are out there. Some things are just easier and more convenient to use. The devil is in the details. A building-to-building connection is clearly easier than lighting up a city but you will still be stuck with what you get. You can never plan enough. ~JasonG From dholmes at mwdh2o.com Mon Nov 14 11:31:50 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 14 Nov 2011 09:31:50 -0800 Subject: Cable standards question In-Reply-To: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> Message-ID: <922ACC42D498884AA02B3565688AF99534019DB3E0@USEXMBS01.mwd.h2o> Formal construction contract bids use the Construction Specification Institute (CSI) format. There are 2 versions, I am familiar with and use the 1998 version. The 1998 CSI format is broken up into 16 divisions (mechanical, civil, electrical, architectural, etc.). Electrical, where network cabling specs reside in the CSI 1998 version, are located in Division 16. The standard fiber optic spec is Division 16 16745. A web search on "fiber optic 16745 spec" will turn up various examples from real fiber optic construction bids, usually government contracts for large-scale construction projects such as highways, University campuses, municipal fiber builds, etc. My suggestion is to look at existing 16745 specs, and modify them to your requirements. -----Original Message----- From: Sam (Walter) Gailey [mailto:gaileywg at MANSFIELDCT.ORG] Sent: Monday, November 14, 2011 6:43 AM To: nanog at nanog.org Subject: Cable standards question Hello, newbie question of the morning time, but hopefully not too off-topic... I run a small town network. A new building is being built that the town wants fiber access to. I have to specify for vendors what it is that the town expects in the cabling. I am (obviously) not a fiber expert, and I'm having trouble phrasing the language of the RFP so that we are assured a quality installation. My question is this; Is there an appropriate standard to specify for fiber-optic cabling that if it is followed the fiber will be installed correctly? Would specifying TIA/EIA 568-C.3, for example, be correct? I'm envisioning something like; "The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling." Any suggestions or examples of language would be very appreciated. Offlist contact is probably best. Many thanks, ---Sam This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From network.ipdog at gmail.com Mon Nov 14 12:31:30 2011 From: network.ipdog at gmail.com (Network IP Dog) Date: Mon, 14 Nov 2011 10:31:30 -0800 Subject: Copper not dead for super-fast broadband, says BT | Networking | ZDNet UK Message-ID: <4ec15e90.b39c440a.60a9.03a0@mx.google.com> http://www.zdnet.co.uk/news/networking/2011/11/11/copper-not-dead-for-super- fast-broadband-says-bt-40094401/?ps=twitter From Gabriel.McCall at thyssenkrupp.com Mon Nov 14 12:50:20 2011 From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel) Date: Mon, 14 Nov 2011 13:50:20 -0500 Subject: Arguing against using public IP space In-Reply-To: <002201cca25f$6c5340d0$44f9c270$@com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> Message-ID: <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. The fact that consumer cpe's typically do both nat and stateful firewalling does not mean that those functions are inseparable. -----Original message----- From: Chuck Church To: 'Phil Regnauld' Cc: "nanog at nanog.org" Sent: Sun, Nov 13, 2011 23:53:19 GMT+00:00 Subject: RE: Arguing against using public IP space -----Original Message----- From: Phil Regnauld [mailto:regnauld at nsrc.org] > PAT (overload) will have ports open listening for return traffic, > on the external IP that's being "overloaded". > What happens if you initiate traffic directed at the RFC1918 > network itself, and send that to the MAC address of the NAT device ? > In many cases, it just works. That's how IP forwarding works, after > all :) > > inside net ----------[NAT]-----------{ext net}----[attacker] > 192.168.0.0/24 .254 1.2.3.4 1.2.3.5 > S:1.2.3.5 D:192.168.0.1 next hop: 1.2.3.4 > > Now, on the way back *out* from the inside net, traffic from > 192.168.0.1 back to 1.2.3.4 might get translated - it depends if > what the NAT is programmed to do if it sees, say, a S/A packet > with no corresponding SYN, on its way out. It might just get > dropped. UDP would in some cases get natted, but since you > know your destination port on 1.2.3.5, you know what to expect, > and you can build an asymmetric connection since you control the > attacking host. > > Either way, you've still injected traffic into the inside net. > That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host. Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue. Chuck From charlesg at unixrealm.com Mon Nov 14 13:11:08 2011 From: charlesg at unixrealm.com (Charles Gagnon) Date: Mon, 14 Nov 2011 14:11:08 -0500 Subject: packet loss out of Texas on Cogent and GlobalCrossing Message-ID: I need the Nanog intellect, We are seeing packet loss in certain scenarios only on traffic to and from Austin, TX. The local provider is Time Warner and they are not having (obvious) problems. We ran tests from NY and NJ over Internap and AboveNet connections.We only see problems when the traffic goes over gblx or cogent. Has anyone heard of problem with these carriers out of Texas? -- Charles Gagnon charlesg at unixrealm.com From bill at herrin.us Mon Nov 14 13:32:24 2011 From: bill at herrin.us (William Herrin) Date: Mon, 14 Nov 2011 14:32:24 -0500 Subject: Arguing against using public IP space In-Reply-To: <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> Message-ID: On Mon, Nov 14, 2011 at 1:50 PM, McCall, Gabriel wrote: > Chuck, you're right that this should not happen- but > the reason it should not happen is because you have > a properly functioning stateful firewall, not because > you're using NAT. If your firewall is working properly, > then having public addresses behind it is no less secure > than private. And if your firewall is not working properly, > then having private addresses behind it is no > more secure than public. In either case, NAT gains > you nothing over what you'd have with a firewalled > public-address subnet. > > The fact that consumer cpe's typically do both nat > and stateful firewalling does not mean that those > functions are inseparable. Gabriel, This is not accurate. First, many:1 NAT (sometimes also called PAT) is not separable from a stateful firewall. You can build a stateful firewall without many-to-one NAT but the reverse is not possible. Second, while a security benefit from RFC 1918 addressing combined with 1:1 NAT is dubious at best, the same is not true for the much more commonly implemented many:1 NAT. With RFC1918 plus many:1 NAT, most if not all functions of the interior of the network are not addressable from far locations outside the network, regardless of the correct or incorrect operation of the security apparatus. This is an additional boundary which must be bypassed in order to gain access to the network interior. While there are a variety of techniques for circumventing this boundary no combination of them guarantees successful breach. Hence it provides a security benefit all on its own. You would not rely on NAT+RFC1918 alone to secure a network and neither would I. However, that's far from meaning that the use of RFC1918 is never (or even rarely) operative in a network's security process. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Mon Nov 14 13:46:21 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 14 Nov 2011 14:46:21 -0500 (EST) Subject: Cable standards question In-Reply-To: Message-ID: <29777640.2763.1321299981428.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jason Gurtz" > For instance, we ended up with a 23" telco rack filled with 19" equipment > and 23" to 19" converter panels. General tidiness; a contractor left a > large splice-box laying on the floor in the midst of a slack-spool instead > of wall or rack mounting. Another contractor developed a spider's nest of > wiring in our server room instead of structured cabling. Specifying exact > rack sizes, specific cable management, mounting locations, etc... would > have helped a lot. Photos of the specific areas would have helped > immensely. This seems like an altogether excellent time for me to remind people about http://bestpractices.wikia.com and volunteer it[1] as a place in which to capture these sorts of, among other things, pictures of installs, both good and bad -- along with notes as to *why* they are specifically good and/or bad. Cheers, -- jra [1]Yes, it's gotten a bit spammed up; I'll clean it out if you'll use it. ;-) -- 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 charlesg at unixrealm.com Mon Nov 14 14:52:27 2011 From: charlesg at unixrealm.com (Charles Gagnon) Date: Mon, 14 Nov 2011 15:52:27 -0500 Subject: packet loss out of Texas on Cogent and GlobalCrossing In-Reply-To: <03af01cca302$dae14440$90a3ccc0$@truenet.com> References: <03af01cca302$dae14440$90a3ccc0$@truenet.com> Message-ID: Good point, I can't seem to reproduce with the looking glass interfaces out there. They either don't use enough packets in sequence or don't through the problem hops. On this path: Send ICMP echos to 24.227.216.194, timeout is 2 seconds, ?maximum hops are 32,1 ? ? ? 0ms ? ? 1ms ? ? 0ms ? ? 74.201.153.2212 ? ? ? 143ms 10ms ? ?0ms ? ? 216.52.95.893 ? ? ? 1ms ? ? 1ms ? ? 1ms 77.67.70.974 ? ? ? 1ms ? ? 1ms ? ? 1ms ? ? 213.200.66.2105 ? ? ? 3ms ? 1ms ? ? 2ms ? ? 66.198.111.976 ? ? ? 19ms ? ?7ms ? ? 7ms 216.6.87.97 ? ? ? 7ms ? ? 7ms ? ? 7ms ? ? 216.6.87.28 ? ? ? 6ms 7ms ? ? 7ms ? ? 66.198.154.149 ? ? ? 6ms ? ? 7ms ? ? 6ms 107.14.19.13210 ? ? ?107ms ? 108ms ? 113ms ? 66.109.10.1111 ? ? ?118ms ? 144ms ? 120ms ? 107.14.17.13912 ? ? ?119ms ? 120ms ? 120ms 72.179.205.5913 ? ? ?115ms ? 115ms ? 114ms ? 24.73.240.19514 115ms ? 115ms ? 115ms ? 24.73.240.252 I re-tested and using 100 msg counts, I get 3-6% packet loss on anything after 10. On hops 1-10, I'm all clean. That 66.109.10.11 address is inside TimeWarner/RR so I'll keep trying to contact them. On Mon, Nov 14, 2011 at 2:23 PM, Eric Tykwinski wrote: > Have you check the relevant looking glass sites? > > http://www.cogentco.com/en/network/looking-glass > http://www.globalcrossing.com/network/network_looking_glass.aspx > > We are connected to both providers, so everything is looking clean for us. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > F: 610-429-3222 > > -----Original Message----- > From: Charles Gagnon [mailto:charlesg at unixrealm.com] > Sent: Monday, November 14, 2011 2:11 PM > To: nanog at nanog.org > Subject: packet loss out of Texas on Cogent and GlobalCrossing > > I need the Nanog intellect, > > We are seeing packet loss in certain scenarios only on traffic to and from > Austin, TX. The local provider is Time Warner and they are not having > (obvious) problems. We ran tests from NY and NJ over Internap and AboveNet > connections.We only see problems when the traffic goes over gblx or cogent. > Has anyone heard of problem with these carriers out of Texas? > -- > Charles Gagnon > charlesg at unixrealm.com > > > -- Charles Gagnon charlesg at unixrealm.com From jra at baylink.com Mon Nov 14 14:55:14 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 14 Nov 2011 15:55:14 -0500 (EST) Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: <29935980.2769.1321304092428.JavaMail.root@benjamin.baylink.com> Message-ID: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> Kill this subject if you're sick of it. ----- Original Message ----- > From: "Gabriel McCall" > If your firewall is working > properly, then having public addresses behind it is no less secure > than private. And if your firewall is not working properly, then > having private addresses behind it is no more secure than public. This assertion is frequently made -- it was made a couple other times this morning -- but I continue to think that it doesn't hold much water, primarly because it doesn't take into account *the probability of various potential failure modes in a firewall*. The basic assertion made by proponents of this theory, when analyzed, amounts to "the probability that a firewall between a publicly routable internal network and the internet will fail in such a fashion as to pass packets addressed to internal machines is of the same close order as the probability that a DNAT router will fail in such a fashion as to allow people outside it to address packets to *arbitrary* internal machine IP addresses (assuming they have any way to determine what those are)." Hopefully, my rephrasing makes it clearer why those of us who believe that there is, in fact, *some* extra security contributed by RFC 1918 and DNAT in the over all stack tend not to buy the arguments of those who say that in fact, it contributes none: they never show their work, so we cannot evaluate their assertions. But in fact, as someone pointed out this morning in the original thread: even if you happen to *know* the internal 1918 IP of the NATted target, the default failure mode of the NAT box is "stop forwarding packets into private network at all". Certainly, individual NAT boxes can have other failure modes, but each of those extra layers adds at least another 0 to the probability p-number, in my not-a-mathematician estimation. On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of "NAT contributes no security" can't, either. > That makes sense, but I'm wondering if that should be considered correct > behavior. Obviously a non-consumer grade router can have rules defining > what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect > everything coming from the outside in to either a) match up with > something in the translation table, b) be a service the router itself is hosting > (http, etc), or c) be a port it explicitly forwards to the same inside > host. > Anything not matching one of those 3 categories you'd think could be > dropped. Routing without translating ports and addresses seems like > the root of the issue. It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue. And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports. 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 Mon Nov 14 15:10:32 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 14 Nov 2011 16:10:32 -0500 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: Your message of "Mon, 14 Nov 2011 15:55:14 EST." <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> Message-ID: <141376.1321305032@turing-police.cc.vt.edu> On Mon, 14 Nov 2011 15:55:14 EST, Jay Ashworth said: > On the other hand, since a firewall's job is to stop packets you don't want, One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating badness". A firewall's job isn't to stop unwanted packets, it's to pass only wanted packets. > if it stops doing it's just as a firewall, it's likely to keep on doing it's > other job: passing packets. As a result, a firewall that fails open rather than closed is mis-designed. And if you're deploying a firewall and don't know if the failure mode is open or closed, you probably get what you deserve when it fails. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rubensk at gmail.com Mon Nov 14 15:21:29 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 14 Nov 2011 19:21:29 -0200 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> References: <29935980.2769.1321304092428.JavaMail.root@benjamin.baylink.com> <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> Message-ID: For the common good it doesn't matter if the "NAT is good" guys are right or the "NAT is useless" guys are right, as they both fail to decrease the numbers of their opposing parts. We must get IPv6 done for both of them. It seems that application reverse-proxies can make "NAT is good" guys happy, so let's get it or some other solution on the market (both commercial and open-source) and move on with what really matters, getting v6 done. Rubens On Mon, Nov 14, 2011 at 6:55 PM, Jay Ashworth wrote: > Kill this subject if you're sick of it. > > ----- Original Message ----- >> From: "Gabriel McCall" > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?If your firewall is working >> properly, then having public addresses behind it is no less secure >> than private. And if your firewall is not working properly, then >> having private addresses behind it is no more secure than public. > > This assertion is frequently made -- it was made a couple other times > this morning -- but I continue to think that it doesn't hold much water, > primarly because it doesn't take into account *the probability of various > potential failure modes in a firewall*. > > The basic assertion made by proponents of this theory, when analyzed, > amounts to "the probability that a firewall between a publicly routable > internal network and the internet will fail in such a fashion as to pass > packets addressed to internal machines is of the same close order as the > probability that a DNAT router will fail in such a fashion as to allow > people outside it to address packets to *arbitrary* internal machine IP > addresses (assuming they have any way to determine what those are)." > > Hopefully, my rephrasing makes it clearer why those of us who believe that > there is, in fact, *some* extra security contributed by RFC 1918 and DNAT > in the over all stack tend not to buy the arguments of those who say that > in fact, it contributes none: they never show their work, so we cannot > evaluate their assertions. > > But in fact, as someone pointed out this morning in the original thread: > even if you happen to *know* the internal 1918 IP of the NATted target, > the default failure mode of the NAT box is "stop forwarding packets into > private network at all". > > Certainly, individual NAT boxes can have other failure modes, but each of > those extra layers adds at least another 0 to the probability p-number, > in my not-a-mathematician estimation. > > On the other hand, since a firewall's job is to stop packets you don't want, > if it stops doing it's just as a firewall, it's likely to keep on doing it's > other job: passing packets. ?It certainly depends on the fundamental design > of the firewall, which I can't speak to generally... but you proponents of > "NAT contributes no security" can't, either. > >> That makes sense, but I'm wondering if that should be considered correct >> behavior. Obviously a non-consumer grade router can have rules defining >> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect >> everything coming from the outside in to either a) match up with >> something in the translation table, b) be a service the router itself is hosting >> (http, etc), or c) be a port it explicitly forwards to the same inside >> host. > >> Anything not matching one of those 3 categories you'd think could be >> dropped. Routing without translating ports and addresses seems like >> the root of the issue. > > It is. ?And IME, the people who think NAT provides no security rarely if > ever seem to address that aspect of the issue. > > And, for what it's worth, I'm discussing the common case: 1-to-many incoming > DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on > other ports. > > 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 bhmccie at gmail.com Mon Nov 14 15:43:26 2011 From: bhmccie at gmail.com (-Hammer-) Date: Mon, 14 Nov 2011 15:43:26 -0600 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> Message-ID: <4EC18B7E.8080607@gmail.com> There really is no winner or "right way" on this thread. In IPv4 as a security guy we have often implemented NAT as an extra layer of obfuscation. In IPv6, that option really isn't there. So it's a cultural change for me. I'm not shedding any tears. We've talked to our FW vendors about various 6to6 and 4to6/6to4 options and we may consider it but given the push in the IPv6 community for native addressing I really am hesitant to add NAT functionality given that no one really knows what the IPv6 future holds. -Hammer- "I was a normal American nerd" -Jack Herer On 11/14/2011 02:55 PM, Jay Ashworth wrote: > Kill this subject if you're sick of it. > > ----- Original Message ----- > >> From: "Gabriel McCall" >> > >> If your firewall is working >> properly, then having public addresses behind it is no less secure >> than private. And if your firewall is not working properly, then >> having private addresses behind it is no more secure than public. >> > This assertion is frequently made -- it was made a couple other times > this morning -- but I continue to think that it doesn't hold much water, > primarly because it doesn't take into account *the probability of various > potential failure modes in a firewall*. > > The basic assertion made by proponents of this theory, when analyzed, > amounts to "the probability that a firewall between a publicly routable > internal network and the internet will fail in such a fashion as to pass > packets addressed to internal machines is of the same close order as the > probability that a DNAT router will fail in such a fashion as to allow > people outside it to address packets to *arbitrary* internal machine IP > addresses (assuming they have any way to determine what those are)." > > Hopefully, my rephrasing makes it clearer why those of us who believe that > there is, in fact, *some* extra security contributed by RFC 1918 and DNAT > in the over all stack tend not to buy the arguments of those who say that > in fact, it contributes none: they never show their work, so we cannot > evaluate their assertions. > > But in fact, as someone pointed out this morning in the original thread: > even if you happen to *know* the internal 1918 IP of the NATted target, > the default failure mode of the NAT box is "stop forwarding packets into > private network at all". > > Certainly, individual NAT boxes can have other failure modes, but each of > those extra layers adds at least another 0 to the probability p-number, > in my not-a-mathematician estimation. > > On the other hand, since a firewall's job is to stop packets you don't want, > if it stops doing it's just as a firewall, it's likely to keep on doing it's > other job: passing packets. It certainly depends on the fundamental design > of the firewall, which I can't speak to generally... but you proponents of > "NAT contributes no security" can't, either. > > >> That makes sense, but I'm wondering if that should be considered correct >> behavior. Obviously a non-consumer grade router can have rules defining >> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect >> everything coming from the outside in to either a) match up with >> something in the translation table, b) be a service the router itself is hosting >> (http, etc), or c) be a port it explicitly forwards to the same inside >> host. >> > >> Anything not matching one of those 3 categories you'd think could be >> dropped. Routing without translating ports and addresses seems like >> the root of the issue. >> > It is. And IME, the people who think NAT provides no security rarely if > ever seem to address that aspect of the issue. > > And, for what it's worth, I'm discussing the common case: 1-to-many incoming > DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on > other ports. > > Cheers, > -- jra > From jra at baylink.com Mon Nov 14 15:53:16 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 14 Nov 2011 16:53:16 -0500 (EST) Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: <141376.1321305032@turing-police.cc.vt.edu> Message-ID: <31204866.2781.1321307596881.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > > On the other hand, since a firewall's job is to stop packets you > > don't want, > > One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating > badness". > A firewall's job isn't to stop unwanted packets, it's to pass only > wanted packets. >From 30,000ft those are equivalent. When you get down below 5000ft, it starts to matter which approach you take to it. There are lots and lots of people, though, whose exposure to firewalls is "a set of rules you drop over a router" -- in consequence of which there are a lot of *firewalls* that are designed that way. You're correct in implying that that's strategically bad, but both components of that paragraph impact the issue. > > if it stops doing it's just as a firewall, it's likely to keep on > > doing it's other job: passing packets. > > As a result, a firewall that fails open rather than closed is > mis-designed. > > And if you're deploying a firewall and don't know if the failure mode > is open or closed, you probably get what you deserve when it fails. Can't argue with that at all. 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 m.hallgren at free.fr Mon Nov 14 15:54:47 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 14 Nov 2011 22:54:47 +0100 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: <4EC18B7E.8080607@gmail.com> References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> <4EC18B7E.8080607@gmail.com> Message-ID: <1321307687.2817.8.camel@home> Le lundi 14 novembre 2011 ? 15:43 -0600, -Hammer- a ?crit : > There really is no winner or "right way" on this thread. In IPv4 as a > security guy we have often implemented NAT as an extra layer of > obfuscation. In IPv6, that option really isn't there. So it's a cultural > change for me. I'm not shedding any tears. We've talked to our FW > vendors about various 6to6 and 4to6/6to4 options and we may consider it > but given the push in the IPv6 community for native addressing I really > am hesitant to add NAT functionality given that no one really knows what > the IPv6 future holds. I consider that a good way of looking a things. ;) Cheers, mh > > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > On 11/14/2011 02:55 PM, Jay Ashworth wrote: > > Kill this subject if you're sick of it. > > > > ----- Original Message ----- > > > >> From: "Gabriel McCall" > >> > > > >> If your firewall is working > >> properly, then having public addresses behind it is no less secure > >> than private. And if your firewall is not working properly, then > >> having private addresses behind it is no more secure than public. > >> > > This assertion is frequently made -- it was made a couple other times > > this morning -- but I continue to think that it doesn't hold much water, > > primarly because it doesn't take into account *the probability of various > > potential failure modes in a firewall*. > > > > The basic assertion made by proponents of this theory, when analyzed, > > amounts to "the probability that a firewall between a publicly routable > > internal network and the internet will fail in such a fashion as to pass > > packets addressed to internal machines is of the same close order as the > > probability that a DNAT router will fail in such a fashion as to allow > > people outside it to address packets to *arbitrary* internal machine IP > > addresses (assuming they have any way to determine what those are)." > > > > Hopefully, my rephrasing makes it clearer why those of us who believe that > > there is, in fact, *some* extra security contributed by RFC 1918 and DNAT > > in the over all stack tend not to buy the arguments of those who say that > > in fact, it contributes none: they never show their work, so we cannot > > evaluate their assertions. > > > > But in fact, as someone pointed out this morning in the original thread: > > even if you happen to *know* the internal 1918 IP of the NATted target, > > the default failure mode of the NAT box is "stop forwarding packets into > > private network at all". > > > > Certainly, individual NAT boxes can have other failure modes, but each of > > those extra layers adds at least another 0 to the probability p-number, > > in my not-a-mathematician estimation. > > > > On the other hand, since a firewall's job is to stop packets you don't want, > > if it stops doing it's just as a firewall, it's likely to keep on doing it's > > other job: passing packets. It certainly depends on the fundamental design > > of the firewall, which I can't speak to generally... but you proponents of > > "NAT contributes no security" can't, either. > > > > > >> That makes sense, but I'm wondering if that should be considered correct > >> behavior. Obviously a non-consumer grade router can have rules defining > >> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect > >> everything coming from the outside in to either a) match up with > >> something in the translation table, b) be a service the router itself is hosting > >> (http, etc), or c) be a port it explicitly forwards to the same inside > >> host. > >> > > > >> Anything not matching one of those 3 categories you'd think could be > >> dropped. Routing without translating ports and addresses seems like > >> the root of the issue. > >> > > It is. And IME, the people who think NAT provides no security rarely if > > ever seem to address that aspect of the issue. > > > > And, for what it's worth, I'm discussing the common case: 1-to-many incoming > > DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on > > other ports. > > > > Cheers, > > -- jra > > From marka at isc.org Mon Nov 14 16:04:08 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 15 Nov 2011 09:04:08 +1100 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: Your message of "Mon, 14 Nov 2011 15:43:26 MDT." <4EC18B7E.8080607@gmail.com> References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> <4EC18B7E.8080607@gmail.com> Message-ID: <20111114220408.0AAC7171AAD9@drugs.dv.isc.org> Firewalls and NATs are "warm fuzzy feeling" devices. The best way to keep secure is to run up to date software and to only provide services you need. Firewalls and NAT both inhibit inventions. Both really do very little with modern operating systems that have been designed to be connected without a firewall in front of them to the Internet. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gaileywg at MANSFIELDCT.ORG Mon Nov 14 16:07:17 2011 From: gaileywg at MANSFIELDCT.ORG (Sam (Walter) Gailey) Date: Mon, 14 Nov 2011 22:07:17 +0000 Subject: Cable standards question In-Reply-To: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE@humancapitaldev.com> References: <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2@TN-Mail-1.mansfieldct.net> <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE@humancapitaldev.com> Message-ID: <64BA4A04F13A7A43B289BAE7F07961F50AC94EB3@TN-Mail-1.mansfieldct.net> First off, thanks to everyone who has replied, both on and off list, I've gotten some very good information on this, raising things I hadn't considered, particularly involving testing and warranties. Daniel Seagraves wrote: Getting an installation that doesn't suck is indeed the core of the matter. However, "doesn't suck" is a rather vague concept as a point of law in case you have to sue your vendor for having installed something that sucks. That's why I was looking for a set of standards that I can point to and say (as an example) "your installation sucks, and it sucks because you didn't follow X standard, and ran unshielded fiber at a 90 degree angle over a knife edge." < Maybe there should be a legal definition of the concept of suck, so that suckage could be contractually minimized.> Unfortunately vendors install suckage all the time. Our own particular horror story was one of our schools where half the school was experiencing intermittent issues of crosstalk, lag, unexplained packet loss, etc. Some days it was fine, others it wasn't and it took us some time to find out that the cabling vendor had connected the two network closets via plain old cat 5 cable, a run that was considerably longer than 300 feet. You wouldn't normally expect to have to specify to telecommunications vendors that you don't exceed the maximum cable length, but there it was. We replaced that link with multimode, and the problems immediately vanished. I'm sure others have similar stories. A number of people have asked for more details on the project and I deliberately didn't put those in because I was looking more for a standard that, if followed, produces acceptable link no matter what the project details are. For the curious, it's a simple point-to-point link involving an existing building and new construction that are about a mile apart . It will be singlemode, we will provide the racks on both ends, and we're specifying SC terminations. Whether we own or lease the fiber, lit or dark, depends on the economics of the quotes that come back to us. It's not a complicated project, but I shouldn't have to re-write a cabling spec as part of the RFP just to keep the vendors honest. A number of good references have been sent to me so I think I'm all set. Thanks, NANOG! :) ---Sam -----Original Message----- From: Daniel Seagraves [mailto:dseagrav at humancapitaldev.com] Sent: Monday, November 14, 2011 9:58 AM To: nanog at nanog.org Subject: Re: Cable standards question On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote: > "The vendor will provide fiber connectivity between (building A) and (building B). Vendor will be responsible for all building penetrations and terminations. When installing the fiber-optic cable the vendor will follow the appropriate TIA/EIA 568 standards for fiber-optic cabling." > > Any suggestions or examples of language would be very appreciated. Offlist contact is probably best. Is it appropriate to just say "When installing fiber-optic cable the vendor will ensure the resulting installation does not suck."? That would seem to me to be the most direct solution to the problem. I mean, standards are all well and good, but what if the standard sucks? Then you'd be up a creek. Maybe there should be a legal definition of the concept of suck, so that suckage could be contractually minimized. From lyndon at orthanc.ca Mon Nov 14 17:01:30 2011 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Mon, 14 Nov 2011 15:01:30 -0800 (PST) Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: <4EC18B7E.8080607@gmail.com> References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> <4EC18B7E.8080607@gmail.com> Message-ID: > There really is no winner or "right way" on this thread. In IPv4 as a > security guy we have often implemented NAT as an extra layer of obfuscation. It's worse than just obfuscation. The 'security' side effect of NAT can typically be implemented by four or five rules in a traditional firewall. But a NAT implementation adds thousands of lines of code to the path the packets take, and any time you introduce complexity you decrease the overall security of the system. And the complexity extends beyond the NAT box. Hacking on IPsec, SIP, and lord knows what else to work around address rewriting adds even more opportunities for something to screw up. If you want security, you have to DEcrease the number of lines of code in the switching path, not add to it. Complexity is evil. It's a shame this is no longer taught in computing courses. And I mean taught as a philosophy, not as a function of line count or any other bean-counter metrics. --lyndon From tvhawaii at shaka.com Mon Nov 14 18:05:42 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Mon, 14 Nov 2011 14:05:42 -1000 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... References: <31204866.2781.1321307596881.JavaMail.root@benjamin.baylink.com> Message-ID: <3F3E6DC1F01848F9BCB6C9CC2F6CDD71@owner59e1f1502> Jay Ashworth wrote: > ----- Original Message ----- >> From: "Valdis Kletnieks" > >>> On the other hand, since a firewall's job is to stop packets you >>> don't want, >> >> One of Marcus Ranum's "5 Stupidest Security Blunders" - "enumerating >> badness". >> A firewall's job isn't to stop unwanted packets, it's to pass only >> wanted packets. > > From 30,000ft those are equivalent. Speaking of 30,000 ft., saw this on Dave Farber's IP list: https://plus.google.com/u/0/110897184785831382163/posts/5qsNxFEaiML From bill at herrin.us Mon Nov 14 18:06:13 2011 From: bill at herrin.us (William Herrin) Date: Mon, 14 Nov 2011 19:06:13 -0500 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> <4EC18B7E.8080607@gmail.com> Message-ID: On Mon, Nov 14, 2011 at 6:01 PM, Lyndon Nerenberg wrote: > But a NAT implementation adds thousands of lines of code to the path the > packets take, and any time you introduce complexity you decrease the overall > security of the system. ?And the complexity extends beyond the NAT box. > ?Hacking on IPsec, SIP, and lord knows what else to work around address > rewriting adds even more opportunities for something to screw up. > > If you want security, you have to DEcrease the number of lines of code in > the switching path, not add to it. Hi Lyndon, Counterpoint: Using two firewalls in serial from two different vendors doubles the complexity. Yet it almost always improves security: fat fingers on one firewall rarely repeat the same way on the second and a rogue packet must pass both. The same two firewalls in parallel surely reduces security. Is complexity the enemy of security? In general principle yes, but as with many things IT DEPENDS. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mcdonald.richards at gmail.com Mon Nov 14 18:09:30 2011 From: mcdonald.richards at gmail.com (McDonald Richards) Date: Tue, 15 Nov 2011 11:09:30 +1100 Subject: packet loss out of Texas on Cogent and GlobalCrossing In-Reply-To: References: <03af01cca302$dae14440$90a3ccc0$@truenet.com> Message-ID: I take multiple services from Global Crossing in San Jose and have had reports of packet loss from Cogent users in Chicago and London (and been able to reproduce). In all cases it appears to be after wherever Cogents' "mci01" location is. 10.|-- te0-3-0-3.mpd21.mci01.atl 0.0% 100 205.7 205.2 204.5 207.7 0.7 11.|-- te0-5-0-4.mpd21.ord01.atl 7.0% 100 238.4 235.6 230.4 239.1 2.0 12.|-- te0-0-0-5.ccr21.bos01.atl 4.0% 100 315.1 315.0 314.6 316.7 0.3 13.|-- te0-0-0-2.mpd21.lon13.atl 10.0% 100 323.7 323.7 321.6 325.7 0.7 14.|-- te2-1.ccr01.lon01.atlas.c 6.0% 100 324.6 332.8 314.9 523.0 38.5 15.|-- te1-2.mpd01.lon01.atlas.c 9.0% 100 326.3 339.3 324.9 506.0 39.5 10.|-- te0-4-0-3.mpd21.mci01.atl 0.0% 100 206.1 208.9 204.6 225.8 5.3 11.|-- te0-4-0-3.mpd21.ord01.atl 3.0% 100 239.2 237.0 228.7 239.5 1.9 12.|-- te0-0-0-1.ccr21.ord03.atl 4.0% 100 239.1 237.4 228.3 240.9 2.0 13.|-- te2-1.mpd02.ord03.atlas.c 4.0% 100 228.0 235.2 227.0 350.2 23.9 McDonald On Tue, Nov 15, 2011 at 7:52 AM, Charles Gagnon wrote: > Good point, I can't seem to reproduce with the looking glass > interfaces out there. They either don't use enough packets in sequence > or don't through the problem hops. On this path: > > Send ICMP echos to 24.227.216.194, timeout is 2 seconds, maximum hops > are 32,1 0ms 1ms 0ms 74.201.153.2212 143ms > 10ms 0ms 216.52.95.893 1ms 1ms 1ms > 77.67.70.974 1ms 1ms 1ms 213.200.66.2105 3ms > 1ms 2ms 66.198.111.976 19ms 7ms 7ms > 216.6.87.97 7ms 7ms 7ms 216.6.87.28 6ms > 7ms 7ms 66.198.154.149 6ms 7ms 6ms > 107.14.19.13210 107ms 108ms 113ms 66.109.10.1111 118ms > 144ms 120ms 107.14.17.13912 119ms 120ms 120ms > 72.179.205.5913 115ms 115ms 114ms 24.73.240.19514 > 115ms 115ms 115ms 24.73.240.252 > I re-tested and using 100 msg counts, I get 3-6% packet loss on > anything after 10. On hops 1-10, I'm all clean. That 66.109.10.11 > address is inside TimeWarner/RR so I'll keep trying to contact them. > > > On Mon, Nov 14, 2011 at 2:23 PM, Eric Tykwinski > wrote: > > Have you check the relevant looking glass sites? > > > > http://www.cogentco.com/en/network/looking-glass > > http://www.globalcrossing.com/network/network_looking_glass.aspx > > > > We are connected to both providers, so everything is looking clean for > us. > > > > Sincerely, > > > > Eric Tykwinski > > TrueNet, Inc. > > P: 610-429-8300 > > F: 610-429-3222 > > > > -----Original Message----- > > From: Charles Gagnon [mailto:charlesg at unixrealm.com] > > Sent: Monday, November 14, 2011 2:11 PM > > To: nanog at nanog.org > > Subject: packet loss out of Texas on Cogent and GlobalCrossing > > > > I need the Nanog intellect, > > > > We are seeing packet loss in certain scenarios only on traffic to and > from > > Austin, TX. The local provider is Time Warner and they are not having > > (obvious) problems. We ran tests from NY and NJ over Internap and > AboveNet > > connections.We only see problems when the traffic goes over gblx or > cogent. > > Has anyone heard of problem with these carriers out of Texas? > > -- > > Charles Gagnon > > charlesg at unixrealm.com > > > > > > > > > > -- > Charles Gagnon > charlesg at unixrealm.com > > From jeff-kell at utc.edu Mon Nov 14 18:12:54 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 14 Nov 2011 19:12:54 -0500 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: References: <29935980.2769.1321304092428.JavaMail.root@benjamin.baylink.com> <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> Message-ID: <4EC1AE86.8060700@utc.edu> On 11/14/2011 4:21 PM, Rubens Kuhl wrote: > For the common good it doesn't matter if the "NAT is good" guys are > right or the "NAT is useless" guys are right, as they both fail to > decrease the numbers of their opposing parts. We must get IPv6 done > for both of them. Hehehe... depending on your ISPs / transit providers / border technology level, putting critical infrastructure on IPv6[only] might be the safest most unreachable network of all :) Jeff From jeroen at mompl.net Mon Nov 14 18:35:30 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 14 Nov 2011 16:35:30 -0800 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> Message-ID: <4EC1B3D2.5060007@mompl.net> William Herrin wrote: > If your machine is addressed with a globally routable IP, a trivial > failure of your security apparatus leaves your machine addressable > from any other host in the entire world which wishes to send it Isn't that the case with IPv6? That the IP is addressable from any host in the entire (IPv6) world? And isn't that considered a good thing? I don't think that being addressable from anywhere is a security hole in and of itself. It's how you implement and (mis)configure your firewall and related things that is the (potential) security hole. Whether the IP is world addressable or not > with all your stuff. Yet when you forget to throw the deadbolt, it > does stop an intruder from simply turning the knob and wandering in. Personally I prefer car analogies when it comes to explaining (complex) computer matters. ;-) Greetings, Jeroen -- Earthquake Magnitude: 5.2 Date: Monday, November 14, 2011 22:08:15 UTC Location: eastern Turkey Latitude: 38.6644; Longitude: 43.0993 Depth: 10.00 km From jon at smugmug.com Mon Nov 14 19:06:59 2011 From: jon at smugmug.com (Jon Heise) Date: Mon, 14 Nov 2011 17:06:59 -0800 Subject: equinix sv3 provider recommendations Message-ID: I'm setting up internet connectivity in the equinix SV3 datacenter, we are already a level3 customer what other providers have been reliable from sv3. From smb at cs.columbia.edu Mon Nov 14 19:15:22 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 14 Nov 2011 20:15:22 -0500 Subject: airgap / negligent homicide charge In-Reply-To: References: Message-ID: <3EFCE3CB-1D61-463E-8C3E-32425D1ECA29@cs.columbia.edu> Here's a quote from a famous court case (T.J. Hooper) on liability and industry standards: Indeed in most cases reasonable prudence is in face common prudence; but strictly it is never its measure; a whole calling may have unduly lagged in the adoption of new and available devices. It may never set its own tests, however persuasive be its usages. Courts must in the end say what is required; there are precautions so imperative that even their universal disregard will not excuse their omission. And here's a quote from a legal textbook: The standard of conduct imposed by the law is an external one, based upon what society demands generally of its members, rather than upon the actors personal morality or individual sense of right and wrong. A failure to conform to the standard is negligence, therefore, even if it is due to clumsiness, stupidity, forgetfulness, an excitable temperament, or even sheer ignorance. An honest blunder, or a mistaken belief that no damage will result, may absolve the actor from moral blame, but the harm to others is still as great, and the actors individual standards must give way in this area of the law to those of the public. In other words, society may require of a person not to be awkward or a fool. In other words, get real legal advice on the standard of care you should observe. On Nov 14, 2011, at 10:25 AM, Mickey Fox wrote: > The determination of whether a failure rises to the level of negligent > homicide will require a review of industry standards, company standards and > sometimes straight common-sence. > > If the industry standard is airgap re security you are probably okay so > long as you review and address the very concerns and questions you are > raising in a responsible fashion that does not rely solely on expediency, > cost, etc., but looks to real-world scenarios and emergency / backup > procedures, equipment, testing and training. > > Mickey Fox > CMK Consulting Services > On Nov 14, 2011 9:00 AM, 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: Arguing against using public IP space >> (Valdis.Kletnieks at vt.edu) >> 2. Re: Arguing against using public IP space (Joel jaeggli) >> 3. Re: Arguing against using public IP space (Jimmy Hess) >> 4. Re: Arguing against using public IP space (Owen DeLong) >> 5. Re: Arguing against using public IP space (Dobbins, Roland) >> 6. Cable standards question (Sam (Walter) Gailey) >> 7. Re: Cable standards question (Daniel Seagraves) >> 8. Re: Arguing against using public IP space (Joe Greco) >> 9. Re: Arguing against using public IP space (Ray Soucy) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sun, 13 Nov 2011 21:43:32 -0500 >> From: Valdis.Kletnieks at vt.edu >> To: Brett Frankenberger >> Cc: NANOG >> Subject: Re: Arguing against using public IP space >> Message-ID: <81357.1321238612 at turing-police.cc.vt.edu> >> Content-Type: text/plain; charset="us-ascii" >> >> On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said: >> >>> What if you air-gap the SCADA network of which you are in >>> administrative control, and then there's a failure on it, and the people >>> responsible for troubleshooting it can't do it remotely (because of the >>> air gap), so the trouble continues for an extra hour while they drive >>> to the office, and that extra hour of failure causes someone to die. >>> Should that result in a homicide charge? >> >> If you designed a life-critical airgapped network that didn't have a >> trained >> warm body at the NOC 24/7 with an airgapped management console, and hot >> (or at >> least warm) spares for both console and console monkey, yes, you *do* >> deserve >> that negligent homicide charge. >> >> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: not available >> Type: application/pgp-signature >> Size: 227 bytes >> Desc: not available >> URL: < >> http://mailman.nanog.org/pipermail/nanog/attachments/20111113/247b47fe/attachment-0001.bin >>> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 14 Nov 2011 10:59:45 +0800 >> From: Joel jaeggli >> To: Joe Greco >> Cc: NANOG >> Subject: Re: Arguing against using public IP space >> Message-ID: <4EC08421.80708 at bogus.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On 11/14/11 10:24 , Joe Greco wrote: >>>> Sure, anytime there's an attack or failure on a SCADA network that >>>> wouldn't have occurred had it been air-gapped, it's easy for people to >>>> knee-jerk a "SCADA networks should be airgapped" response. But that's >>>> not really intelligent commentary unless you carefully consider what >>>> risks are associated with air-gapping the network. >>> >>> Not to mention that it's not the only way for these things to get >>> infected. Getting fixated on air-gapping is unrealistically ignoring >>> the other threats out there. >>> >>> There needs to be a whole lot more security work done on SCADA nets. >> >> Stuxnet should provide a fairly illustrative example. >> >> It doesn't really matter how well isolated from direct access it is if >> it has a soft gooey center and a willing attacker. >> >>> ... JG >> >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Sun, 13 Nov 2011 21:48:01 -0600 >> From: Jimmy Hess >> To: David Walker >> Cc: nanog at nanog.org >> Subject: Re: Arguing against using public IP space >> Message-ID: >> >> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On Sun, Nov 13, 2011 at 3:03 PM, David Walker >> wrote: >>> On 14/11/2011, Jimmy Hess wrote: >>> A packet addressed to an endpoint that doesn't serve anything or have >>> a client listening will be ignered (whatever) as a matter of course. >>> Firewall or no firewall. >> It will not go to a listening application, neither will it be >> completely ignored -- >> the receiving machine's TCP stack will have a look at the packet. >> On common operating systems there are frequently unsafe applications >> listening on ports; on certain OSes, there will be no way to turn off >> system applications, or human error will leave them in place. >> >>> That's fundamental to TCP/IP and secure. >> It's fundamental to TCP/IP, but not fundamentally secure. TCP/IP >> implementations have flaws. >> If a host is meant solely as an endpoint, then it is exposed to undue >> risk, if arbitrary packets can be addressed to its TCP/IP stack that >> might have remotely exploitable bugs. >> >>> The only reason we firewall (packet filter) is to provide access >>> control (for whatever reason). >> No, we also firewall to block access entirely to applications >> attempting to establish a service on unapproved ports. We also use >> firewalls in certain forms to ensure that communications over a TCP/IP >> socket comply with a protocol, for example, that a session >> terminated on port 25 is actually a SMTP session. >> >> The firewall might restrict the set of allowed SMTP commands, validate >> the syntax of certain commands, hide server version information, >> prevent use of ESMTP pipelining from outside, etc. >> >>> I apologize in advance if this is too pedestrian (you might know this >>> but not agree with it) but I want to make a point: >>> http://en.wikipedia.org/wiki/End-to-end_connectivity >> >> End to end connectivity principal's purpose is not to provide >> security. It is to facilitate communications with other hosts and >> networks. When a private system _really_ has to be secure, end to >> end connectivity is inherently incompatible with security objectives. >> >> There is always a tradeoff involving sacrificing a level of security >> against remote attack >> when connecting a computer to a network, and then again, when >> connecting the network to the internet. >> >> A computer that is not connected to a network is perfectly secure >> against network-based attacks. >> A computer that is connected to LAN is at risk of potential >> network-based attack from that LAN. >> >> If that LAN is then connected through a firewall through many to 1 >> NAT, there is another layer of risk added. >> >> If the NAT'ing firewall is then replaced with a simple many to 1 NAT >> router, there is another layer of risk added; there are new attacks >> possible that still succeed in a NAT environment, that the firewall >> would have stopped. >> >> Finally, if that that same computer is then given end to end >> connectivity with no firewall, there is a much less encumbered >> communications path available to that computer for launching >> network-based attack; the attack surface is greatly increased in such >> a design. >> >> If we are talking about nodes that interface with a SCADA network; >> the concept of unfirewalled end-to-end connectivity approaches the >> level of insanity. >> >> Those are not systems where end-to-end public connectivity should be a >> priority over security. >> >> -- >> -JH >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Sun, 13 Nov 2011 19:51:24 -0800 >> From: Owen DeLong >> To: Jason Lewis >> Cc: nanog at nanog.org >> Subject: Re: Arguing against using public IP space >> Message-ID: <2DE5DF4F-059C-4F39-81D4-363E49966282 at delong.com> >> Content-Type: text/plain; charset=us-ascii >> >> >> On Nov 13, 2011, at 7:36 AM, Jason Lewis wrote: >> >>> I don't want to start a flame war, but this article seems flawed to >>> me. It seems an IP is an IP. >>> >>> >> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html >>> >>> I think I could announce private IP space, so doesn't that make this >>> argument invalid? I've always looked at private IP space as more of a >>> resource and management choice and not a security feature. >> >> Yes, the author of this article is sadly mistaken and woefully void >> of clue on the issues he attempts to address. >> >> You are completely correct. >> >> Owen >> >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Mon, 14 Nov 2011 06:21:47 +0000 >> From: "Dobbins, Roland" >> To: NANOG Operators' Group >> Subject: Re: Arguing against using public IP space >> Message-ID: >> Content-Type: text/plain; charset="us-ascii" >> >> On Nov 14, 2011, at 9:24 AM, Joe Greco wrote: >> >>> Getting fixated on air-gapping is unrealistically ignoring the other >> threats out there. >> >> I don't think anyone in this thread is 'fixated' on the idea of >> airgapping; but it's generally a good idea whenever possible, and as >> restrictive a communications policy as is possible is definitely called >> for, amongst all the other things one ought to be doing. >> >> It's also important to note that it's often impossible to *completely* >> airgap things, these days, due to various interdependencies, admin >> requirements (mentioned before), and so forth; perhaps bastioning is a more >> apt term. >> >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> The basis of optimism is sheer terror. >> >> -- Oscar Wilde >> >> >> >> >> ------------------------------ >> >> Message: 6 >> Date: Mon, 14 Nov 2011 14:42:32 +0000 >> From: "Sam (Walter) Gailey" >> To: "nanog at nanog.org" >> Subject: Cable standards question >> Message-ID: >> <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2 at TN-Mail-1.mansfieldct.net >>> >> Content-Type: text/plain; charset="us-ascii" >> >> Hello, newbie question of the morning time, but hopefully not too >> off-topic... >> >> I run a small town network. A new building is being built that the town >> wants fiber access to. I have to specify for vendors what it is that the >> town expects in the cabling. I am (obviously) not a fiber expert, and I'm >> having trouble phrasing the language of the RFP so that we are assured a >> quality installation. >> >> My question is this; Is there an appropriate standard to specify for >> fiber-optic cabling that if it is followed the fiber will be installed >> correctly? Would specifying TIA/EIA 568-C.3, for example, be correct? >> >> I'm envisioning something like; >> >> "The vendor will provide fiber connectivity between (building A) and >> (building B). Vendor will be responsible for all building penetrations and >> terminations. When installing the fiber-optic cable the vendor will follow >> the appropriate TIA/EIA 568 standards for fiber-optic cabling." >> >> Any suggestions or examples of language would be very appreciated. Offlist >> contact is probably best. >> >> Many thanks, >> >> ---Sam >> >> >> ------------------------------ >> >> Message: 7 >> Date: Mon, 14 Nov 2011 08:57:31 -0600 >> From: Daniel Seagraves >> To: nanog at nanog.org >> Subject: Re: Cable standards question >> Message-ID: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE at humancapitaldev.com> >> Content-Type: text/plain; charset=us-ascii >> >> >> On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote: >> >>> "The vendor will provide fiber connectivity between (building A) and >> (building B). Vendor will be responsible for all building penetrations and >> terminations. When installing the fiber-optic cable the vendor will follow >> the appropriate TIA/EIA 568 standards for fiber-optic cabling." >>> >>> Any suggestions or examples of language would be very appreciated. >> Offlist contact is probably best. >> >> Is it appropriate to just say "When installing fiber-optic cable the >> vendor will ensure the resulting installation does not suck."? >> That would seem to me to be the most direct solution to the problem. I >> mean, standards are all well and good, but what if the standard sucks? >> Then you'd be up a creek. >> >> Maybe there should be a legal definition of the concept of suck, so that >> suckage could be contractually minimized. >> >> >> >> >> ------------------------------ >> >> Message: 8 >> Date: Mon, 14 Nov 2011 08:58:37 -0600 (CST) >> From: Joe Greco >> To: joelja at bogus.com (Joel jaeggli) >> Cc: NANOG >> Subject: Re: Arguing against using public IP space >> Message-ID: <201111141458.pAEEwcS6072727 at aurora.sol.net> >> Content-Type: text/plain; charset=us-ascii >> >>> On 11/14/11 10:24 , Joe Greco wrote: >>>>> Sure, anytime there's an attack or failure on a SCADA network that >>>>> wouldn't have occurred had it been air-gapped, it's easy for people to >>>>> knee-jerk a "SCADA networks should be airgapped" response. But that's >>>>> not really intelligent commentary unless you carefully consider what >>>>> risks are associated with air-gapping the network. >>>> >>>> Not to mention that it's not the only way for these things to get >>>> infected. Getting fixated on air-gapping is unrealistically ignoring >>>> the other threats out there. >>>> >>>> There needs to be a whole lot more security work done on SCADA nets. >>> >>> Stuxnet should provide a fairly illustrative example. >>> >>> It doesn't really matter how well isolated from direct access it is if >>> it has a soft gooey center and a willing attacker. >> >> That's basically the case for so many things. >> >> I was reading, recently, two articles on Ars Technica ("Die, VPN" and >> "Live, VPN") which made it exceedingly clear that these sorts of designs >> are still the rule for most companies. I mean, I already knew that, but >> it was *depressing* to read. >> >> We've been very successful for many years designing things as though they >> were going to be deployed on the public Internet, even if we do still put >> them behind a firewall. That's just belt-and-suspenders common sense. >> >> We do run a VPN service, which I use heavily, but it really has little >> to do with granting magical access to resources - the VPN endpoint is >> actually outside any firewall. I've so frequently found, over the years, >> that some "free" Internet connection offering is crippled in some stupid >> manner (transparent proxying with ad injection!), that the value added >> is mostly just that of getting an Internet connection with no interference >> by third parties. The fact that third parties cannot do any meaningful >> snooping is nice too. >> >> I also recall a fairly surreal discussion with a NANOG'er who was >> absolutely convinced that SSH key based access to other servers was >> more secure than password based access along with some ACL's and >> something like sshguard; my point was that compromise of the magic >> host with the magic key would tend to be worse (because you've suddenly >> got access to all the other servers) while having different secure >> passwords for each host, along with some ACL's and sshguard, allow you >> to retain some isolation within the network from an infected node. It's >> dependent on design and forethought, of course... >> >> Basically, getting access to some point in the network shouldn't really >> allow you to go on a rampage through the rest of the network. >> >> ... 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. >> >> >> >> ------------------------------ >> >> Message: 9 >> Date: Mon, 14 Nov 2011 10:00:36 -0500 >> From: Ray Soucy >> To: Jason Lewis >> Cc: nanog at nanog.org >> Subject: Re: Arguing against using public IP space >> Message-ID: >> >> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> As far as I can see Red Tiger Security is Jonathan Pollet; and even >> though they list Houston, Dubai, Milan, and Sydney as offices it looks >> like Houston is the only one.? Is that right?? Seems a little >> misleading. >> >> It actually reminds me of a 16 year old kid I know who runs a web >> hosting "company" that you'd think was a Fortune 500 by the way the >> website reads, and he's more than happy to take your credit card >> information and store it without being PCI compliant. >> >> Credibility of the company aside, >> >> At first I wanted to cut Jonathan some slack.? If he was going to >> point to the use of public IPs as evidence that a firewall may not be >> in use and then went on to discuss the potential risks of not having >> any security, then that would have been appropriate.? But instead he >> goes on about explaining what a public vs. private address is (poorly) >> and proceeds to associate the security of the system with the use of >> private IPs. >> >> I just don't see him as credible in the security field after reading it. >> >> Then again, he does have that interview on Fox News posted on his >> website where he talks about terrorist plots to compromise the >> integrity of nuclear power plants... >> >> Honestly, people post stuff like this time and time again. It's been >> debunked so many times that a quick Google will probably give you what >> you need to figure it out on your own. >> >> On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis >> wrote: >>> I don't want to start a flame war, but this article seems flawed to >>> me. ?It seems an IP is an IP. >>> >>> >> http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html >>> >>> I think I could announce private IP space, so doesn't that make this >>> argument invalid? ?I've always looked at private IP space as more of a >>> resource and management choice and not a security feature. >>> >>> >> >> >> >> -- >> Ray Soucy >> >> Epic Communications Specialist >> >> Phone: +1 (207) 561-3526 >> >> Networkmaine, a Unit of the University of Maine System >> http://www.networkmaine.net/ >> >> >> >> End of NANOG Digest, Vol 46, Issue 43 >> ************************************* >> > --Steve Bellovin, https://www.cs.columbia.edu/~smb From egon at egon.cc Mon Nov 14 19:29:46 2011 From: egon at egon.cc (James Downs) Date: Mon, 14 Nov 2011 17:29:46 -0800 Subject: airgap / negligent homicide charge In-Reply-To: <3EFCE3CB-1D61-463E-8C3E-32425D1ECA29@cs.columbia.edu> References: <3EFCE3CB-1D61-463E-8C3E-32425D1ECA29@cs.columbia.edu> Message-ID: On Nov 14, 2011, at 5:15 PM, Steven Bellovin wrote: > And here's a quote from a legal textbook: > in this area of the law to those of the public. In other > words, society may require of a person not to be awkward If only that were more generally true. -j From mysidia at gmail.com Mon Nov 14 20:58:36 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 14 Nov 2011 20:58:36 -0600 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> References: <29935980.2769.1321304092428.JavaMail.root@benjamin.baylink.com> <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, Nov 14, 2011 at 2:55 PM, Jay Ashworth wrote: > The basic assertion made by proponents of this theory, when analyzed, > amounts to "the probability that a firewall between a publicly routable > internal network and the internet will fail in such a fashion as to pass > packets addressed to internal machines is of the same close order as the > probability that a DNAT router will fail in such a fashion as to allow > people outside it to address packets to *arbitrary* internal machine IP > addresses (assuming they have any way to determine what those are)." [snip] There is really no sound argument made that the probability is inherently any different. When we are referring to security devices failing to do what they are supposed to do, by definition, the correct level of protection has been lost, and you have a serious problem if this happens, regardless of whether your firewall is a NAT device or not. What will be most important is you have solid layers of defense behind the firewall, such as host security, IDS units, monitoring, and scanning regimes to detect the failure of the firewall function. The security appliance has failed, and all bets may be off. It should be noted, that "detecting" a failed simple firewall with a straight port scan is a much simpler more easily automatable process than detecting a failed 1:many NAT firewall. The ease of detecting the problem lowers the chance that you have a problem. The potential security failure modes of a 1:many NAT firewall are much more complicated than "simply pass packets it's not supposed to pass"; the quirks of the flaw mean that with a NAT firewall, it is likely the failure of the firewall function will go undetected by the security admin, resulting in a situation where you have an insidious problem... that is, a problem that is not obvious, but definitely exploitable to a determined attacker. Failure modes such as a "an intruder compromised the firewall" and injected a trojanned firmware result in equal risks regardless of whether NAT is implemented or not. -- -JH From Valdis.Kletnieks at vt.edu Mon Nov 14 23:21:25 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 15 Nov 2011 00:21:25 -0500 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: Your message of "Mon, 14 Nov 2011 19:06:13 EST." References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> <4EC18B7E.8080607@gmail.com> Message-ID: <155340.1321334485@turing-police.cc.vt.edu> On Mon, 14 Nov 2011 19:06:13 EST, William Herrin said: > Using two firewalls in serial from two different vendors doubles the > complexity. Yet it almost always improves security: fat fingers on one > firewall rarely repeat the same way on the second and a rogue packet > must pass both. Fat fingers are actually not the biggest issue - a far bigger problem are brain failures. If you thought opening port 197 was a good idea, you will have done it on both firewalls. And it doesn't even help to run automated config checkers - because you'll have marked port 197 as "good" in there as well. ;) And it doesn't even help with fat-finger issues anyhow, because you *know* that if your firewall admin is any good, they'll just write a script that loads both firewalls from a master config file - and then proceed to fat-finger said config file. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From cb.list6 at gmail.com Mon Nov 14 23:41:25 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Mon, 14 Nov 2011 21:41:25 -0800 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: <155340.1321334485@turing-police.cc.vt.edu> References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> <4EC18B7E.8080607@gmail.com> <155340.1321334485@turing-police.cc.vt.edu> Message-ID: On Nov 14, 2011 9:22 PM, wrote: > > On Mon, 14 Nov 2011 19:06:13 EST, William Herrin said: > > > Using two firewalls in serial from two different vendors doubles the > > complexity. Yet it almost always improves security: fat fingers on one > > firewall rarely repeat the same way on the second and a rogue packet > > must pass both. > Complexity equals downtime. I know at least one definition of security includes availability . > Fat fingers are actually not the biggest issue - a far bigger problem are brain > failures. If you thought opening port 197 was a good idea, you will have done > it on both firewalls. And it doesn't even help to run automated config > checkers - because you'll have marked port 197 as "good" in there as well. ;) > > And it doesn't even help with fat-finger issues anyhow, because you *know* that > if your firewall admin is any good, they'll just write a script that loads both > firewalls from a master config file - and then proceed to fat-finger said > config file. And, stateful firewalls are a very common dos vector. Attacking firewall sessions per second capacity and blowing up a session table can bring a service down real quick. Furthermore, firewalls are frequently installed at a choke point ... Which makes them a topological single point of failure.... So, they are deployed in pairs .... And therefore have a nice cascading failure behavior when hit with a dos. Cb From vton at integra.fr Tue Nov 15 03:30:41 2011 From: vton at integra.fr (Viet-Hung Ton) Date: Tue, 15 Nov 2011 10:30:41 +0100 (CET) Subject: Foundry MRP cohabit with STP In-Reply-To: <22933488.86198.1321348355390.JavaMail.root@FRM001P08ASU.itc.integra.fr> Message-ID: <8538341.86454.1321349440970.JavaMail.root@FRM001P08ASU.itc.integra.fr> Hi, We are deploying a network using MRP of Foundry (Metro Ring Protocol of Brocade now) and STP (in this case Rapid Spanning Tree Protocol-802.1W). The problem is that in some networking segment, we must enable both of protocols in the same interfaces and vlans for the correct function of our network. By the way, as MRP and STP are 2 protocols of loop prevention, the devices of Brocade force us choosing and activating just one among them that not our intention. Anybody has the same situation of some experiences in this case: how to make coexist these two protocols. (MRP and STP). Best thanks, Viet Ton. From fdelmotte1 at mac.com Tue Nov 15 04:03:05 2011 From: fdelmotte1 at mac.com (Fabien Delmotte) Date: Tue, 15 Nov 2011 11:03:05 +0100 Subject: Foundry MRP cohabit with STP In-Reply-To: <8538341.86454.1321349440970.JavaMail.root@FRM001P08ASU.itc.integra.fr> References: <8538341.86454.1321349440970.JavaMail.root@FRM001P08ASU.itc.integra.fr> Message-ID: <2A56D0E2-DFA3-4BF9-9A61-2634593165B4@mac.com> Hi, You cannot enable MRP and STP on the same physical interface, but you can enable MRP on a specific interface and STP on another, the only issue is MRP and STP are using the CPU, so if you loose a hello packet you may have some network instability. Regards Fabien P.S je suis en France si tu as besoin. Le 15 nov. 2011 ? 10:30, Viet-Hung Ton a ?crit : > Hi, > > > We are deploying a network using MRP of Foundry (Metro Ring Protocol of Brocade now) and STP (in this case Rapid Spanning Tree Protocol-802.1W). The problem is that in some networking segment, we must enable both of protocols in the same interfaces and vlans for the correct function of our network. By the way, as MRP and STP are 2 protocols of loop prevention, the devices of Brocade force us choosing and activating just one among them that not our intention. > > > Anybody has the same situation of some experiences in this case: how to make coexist these two protocols. (MRP and STP). > > Best thanks, > > > Viet Ton. > > > > From leigh.porter at ukbroadband.com Tue Nov 15 04:57:32 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 15 Nov 2011 10:57:32 +0000 Subject: Arguing against using public IP space In-Reply-To: <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> Message-ID: <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> On 14 Nov 2011, at 18:52, "McCall, Gabriel" wrote: > Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure! As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From rcheung at rochester.rr.com Tue Nov 15 05:34:15 2011 From: rcheung at rochester.rr.com (rcheung at rochester.rr.com) Date: Tue, 15 Nov 2011 6:34:15 -0500 Subject: Cell-based OOB management devices In-Reply-To: Message-ID: <20111115113416.HO6GH.49151.root@hrndva-web09-z01> David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC ---- David Hubbard wrote: > Hi all, I am looking at cellular-based devices as a higher > speed alternative to dial-up backup access methods for > out of band management during emergencies. I was > wondering if anyone had experiences with such devices > they could share? > > Devices I've found include Sierra Wireless AirLink Raven X, > Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I > have no experience with any but they all appear to support > the Sprint network which I assume would be ideal due to > not having usage caps on data (currently). The Opengear > device runs linux and has four serial ports, a usb port > for additional storage and ethernet, so it seems to have > some small advantages over the others since it could double > as an emergency self-contained management station you can > SSH into and run diagnostics from. All appear to have > VPN/gateway support. > > What none of them are clear on is how you would connect > to it over cellular since I assume you're just paying for > a typical data plan and it will randomly obtain IP > addresses. Maybe some type of dynamic dns service so you > can easily figure out your device's current IP? How > stable is the access to the device? Any idea if any of > them can do ipv6? > > Thanks! > > David > > From rcheung at rochester.rr.com Tue Nov 15 05:40:38 2011 From: rcheung at rochester.rr.com (rcheung at rochester.rr.com) Date: Tue, 15 Nov 2011 6:40:38 -0500 Subject: Cell-based OOB management devices Message-ID: <20111115114038.FVF0E.49163.root@hrndva-web09-z01> David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC ---- David Hubbard wrote: > Hi all, I am looking at cellular-based devices as a higher > speed alternative to dial-up backup access methods for > out of band management during emergencies. I was > wondering if anyone had experiences with such devices > they could share? > > Devices I've found include Sierra Wireless AirLink Raven X, > Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I > have no experience with any but they all appear to support > the Sprint network which I assume would be ideal due to > not having usage caps on data (currently). The Opengear > device runs linux and has four serial ports, a usb port > for additional storage and ethernet, so it seems to have > some small advantages over the others since it could double > as an emergency self-contained management station you can > SSH into and run diagnostics from. All appear to have > VPN/gateway support. > > What none of them are clear on is how you would connect > to it over cellular since I assume you're just paying for > a typical data plan and it will randomly obtain IP > addresses. Maybe some type of dynamic dns service so you > can easily figure out your device's current IP? How > stable is the access to the device? Any idea if any of > them can do ipv6? > > Thanks! > > David > > From faisal at snappydsl.net Tue Nov 15 07:49:17 2011 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 15 Nov 2011 08:49:17 -0500 Subject: Cell-based OOB management devices In-Reply-To: <20111115113416.HO6GH.49151.root@hrndva-web09-z01> References: <20111115113416.HO6GH.49151.root@hrndva-web09-z01> Message-ID: <9335C522-96E2-4E1D-AED8-A89406CBE0EF@snappydsl.net> A very flexible solution can be done with the Mikrotik family of routers....see this as an example for more details.. http://mum.mikrotik.com/presentations/BR09/3G_Applications.pdf Faisal On Nov 15, 2011, at 6:34 AM, wrote: > David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. > > > -RC > > > ---- David Hubbard wrote: >> Hi all, I am looking at cellular-based devices as a higher >> speed alternative to dial-up backup access methods for >> out of band management during emergencies. I was >> wondering if anyone had experiences with such devices >> they could share? >> >> Devices I've found include Sierra Wireless AirLink Raven X, >> Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I >> have no experience with any but they all appear to support >> the Sprint network which I assume would be ideal due to >> not having usage caps on data (currently). The Opengear >> device runs linux and has four serial ports, a usb port >> for additional storage and ethernet, so it seems to have >> some small advantages over the others since it could double >> as an emergency self-contained management station you can >> SSH into and run diagnostics from. All appear to have >> VPN/gateway support. >> >> What none of them are clear on is how you would connect >> to it over cellular since I assume you're just paying for >> a typical data plan and it will randomly obtain IP >> addresses. Maybe some type of dynamic dns service so you >> can easily figure out your device's current IP? How >> stable is the access to the device? Any idea if any of >> them can do ipv6? >> >> Thanks! >> >> David >> >> > > > From Valdis.Kletnieks at vt.edu Tue Nov 15 08:17:20 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 15 Nov 2011 09:17:20 -0500 Subject: Arguing against using public IP space In-Reply-To: Your message of "Tue, 15 Nov 2011 10:57:32 GMT." <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> Message-ID: <175192.1321366640@turing-police.cc.vt.edu> On Tue, 15 Nov 2011 10:57:32 GMT, Leigh Porter said: > Well this is not quite true, is it.. If your firewall is not working and you > have private space internally then you are a lot better off then if you have > public space internally! So if your firewall is not working then having private > space on one side is a hell of a lot more secure! By the same token, if your firewall fails closed rather than fails open, you're more secure. And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Think about it - if a NAT'ed firewall provides any real protection against real attacks, why are there still so many zombied systems out there? I mean, Windows Firewall has been shipping with inbound "default deny" since XP SP2 or so. How many years ago was that? And what *real* security over and above that host-based firewall are you getting from that appliance? Or as Dr Phil would say "FIrewalls - how is that working out for you?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From chuckchurch at gmail.com Tue Nov 15 08:46:32 2011 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 15 Nov 2011 09:46:32 -0500 Subject: Arguing against using public IP space In-Reply-To: <175192.1321366640@turing-police.cc.vt.edu> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> <175192.1321366640@turing-police.cc.vt.edu> Message-ID: <001a01cca3a5$5efa1200$1cee3600$@com> -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, November 15, 2011 9:17 AM To: Leigh Porter Cc: nanog at nanog.org; McCall, Gabriel Subject: Re: Arguing against using public IP space > And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys > and similar things that most firewalls are configured to pass through. Think about it - if a NAT'ed firewall provides > any real protection against real attacks, why are there still so many zombied systems out there? I mean, Windows > Firewall has been shipping with inbound "default deny" since XP SP2 or so. How many years ago was that? Simple explanation is that most firewall rules are written to trust traffic initiated by 'inside' (your users), and the return traffic gets trusted as well. This applies to both Window's own FW, and most hardware based firewalls. And NAT/PAT devices too. There's nothing more dangerous than a user with a web browser. Honestly, FWs will keep out attacks initiated from outside. But for traffic permitted or initiated by the inside, IPS is only way to go. Chuck From owen at delong.com Tue Nov 15 08:52:19 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Nov 2011 06:52:19 -0800 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> Message-ID: On Nov 14, 2011, at 11:32 AM, William Herrin wrote: > On Mon, Nov 14, 2011 at 1:50 PM, McCall, Gabriel > wrote: >> Chuck, you're right that this should not happen- but >> the reason it should not happen is because you have >> a properly functioning stateful firewall, not because >> you're using NAT. If your firewall is working properly, >> then having public addresses behind it is no less secure >> than private. And if your firewall is not working properly, >> then having private addresses behind it is no >> more secure than public. In either case, NAT gains >> you nothing over what you'd have with a firewalled >> public-address subnet. >> >> The fact that consumer cpe's typically do both nat >> and stateful firewalling does not mean that those >> functions are inseparable. > > Gabriel, > > This is not accurate. > > First, many:1 NAT (sometimes also called PAT) is not separable from a > stateful firewall. You can build a stateful firewall without > many-to-one NAT but the reverse is not possible. > Actually, you can. You need a state machine, but, several recent incidents have proven that the state machine in many of the lower-end consumer appliances is not, in fact, a firewall. This has been explained earlier in the thread, so I won't repeat it here. > Second, while a security benefit from RFC 1918 addressing combined > with 1:1 NAT is dubious at best, the same is not true for the much > more commonly implemented many:1 NAT. > Repeating this fallacy still doesn't make it true. > With RFC1918 plus many:1 NAT, most if not all functions of the > interior of the network are not addressable from far locations outside > the network, regardless of the correct or incorrect operation of the > security apparatus. This is an additional boundary which must be > bypassed in order to gain access to the network interior. While there > are a variety of techniques for circumventing this boundary no > combination of them guarantees successful breach. Hence it provides a > security benefit all on its own. If the security apparatus malfunctions, nothing prevents it from malfunctioning in a way that passes packets to the RFC-1918 addressed hosts. > > You would not rely on NAT+RFC1918 alone to secure a network and > neither would I. However, that's far from meaning that the use of > RFC1918 is never (or even rarely) operative in a network's security > process. RFC-1918 and NAT as a security measure is, at best, a locking screen door deployed in front of a vault door. If you take away the vault door, the screen door really doesn't do much. If the vault door is still there, the presence or absence of the screen door is largely irrelevant. Owen From kuenzler at init7.net Tue Nov 15 08:56:55 2011 From: kuenzler at init7.net (Fredy Kuenzler) Date: Tue, 15 Nov 2011 15:56:55 +0100 Subject: Minimum Allocation Size by RIRs (IPv4) Message-ID: <4EC27DB7.4000800@init7.net> I'm trying to compile a comprehensive and up-to-date list of Minimum Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so far: ARIN: https://www.arin.net/knowledge/ip_blocks.html APNIC: http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations (seems that they have recently changed from /22 to /24, which is not too helpful...) RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5 Nothing found for AFRINIC and LACNIC yet, and legacy space, too. -- Fredy K?nzler Init Seven AG AS13030 Elias-Canetti-Strasse 7 CH-8050 Z?rich Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 http://www.init7.net/ From bill at herrin.us Tue Nov 15 08:56:38 2011 From: bill at herrin.us (William Herrin) Date: Tue, 15 Nov 2011 09:56:38 -0500 Subject: Arguing against using public IP space In-Reply-To: <175192.1321366640@turing-police.cc.vt.edu> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> <175192.1321366640@turing-police.cc.vt.edu> Message-ID: On Tue, Nov 15, 2011 at 9:17 AM, wrote: > And this is totally overlooking the fact that the vast majority of *actual* > attacks these days are web-based drive-bys and similar things that most > firewalls are configured to pass through. Valdis, A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jlewis at lewis.org Tue Nov 15 08:59:39 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 15 Nov 2011 09:59:39 -0500 (EST) Subject: Minimum Allocation Size by RIRs (IPv4) In-Reply-To: <4EC27DB7.4000800@init7.net> References: <4EC27DB7.4000800@init7.net> Message-ID: On Tue, 15 Nov 2011, Fredy Kuenzler wrote: > I'm trying to compile a comprehensive and up-to-date list of Minimum > Allocation Sizes by the various RIRs. Any hint would be appreciated. I have > so far: > > ARIN: https://www.arin.net/knowledge/ip_blocks.html > > APNIC: > http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations > (seems that they have recently changed from /22 to /24, which is not too > helpful...) > > RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5 > > Nothing found for AFRINIC and LACNIC yet, and legacy space, too. I have some helpful links and at least a starting point for data (a couple of years old now) in this blog entry: http://jonsblog.lewis.org/2008/01/19#bgp ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owen at delong.com Tue Nov 15 09:00:25 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Nov 2011 07:00:25 -0800 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> Message-ID: > > On the other hand, since a firewall's job is to stop packets you don't want, > if it stops doing it's just as a firewall, it's likely to keep on doing it's > other job: passing packets. It certainly depends on the fundamental design > of the firewall, which I can't speak to generally... but you proponents of > "NAT contributes no security" can't, either. > Perhaps this misunderstanding of the job of a firewall explains your errant conclusions about their failure modes better than anything else in the thread. I would say that your description above does not fit a stateful firewall, but, instead describes a packet-filtering router. A stateful firewall's job is to forward only those packets you have permitted. If ti stops doing it's job, it's default failure mode is to stop forwarding packets. Please explain to me how mutilating the packet header makes any difference in this. >> That makes sense, but I'm wondering if that should be considered correct >> behavior. Obviously a non-consumer grade router can have rules defining >> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect >> everything coming from the outside in to either a) match up with >> something in the translation table, b) be a service the router itself is hosting >> (http, etc), or c) be a port it explicitly forwards to the same inside >> host. > >> Anything not matching one of those 3 categories you'd think could be >> dropped. Routing without translating ports and addresses seems like >> the root of the issue. > > It is. And IME, the people who think NAT provides no security rarely if > ever seem to address that aspect of the issue. > It's a lovely hypothetical description of how those devices should work. IME, and, as has been explained earlier in the thread, it is not necessarily how they ACTUALLY work. Since security depends not on the theoretical ideal of how the devices should work, but, rather on how they actually work, perhaps it is worth considering that our addressing reality instead of theory is actually a feature rather than a bug. > And, for what it's worth, I'm discussing the common case: 1-to-many incoming > DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on > other ports. I think that is what the discussion has been about all along. Owen From bhmccie at gmail.com Tue Nov 15 09:06:50 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 15 Nov 2011 09:06:50 -0600 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> <175192.1321366640@turing-police.cc.vt.edu> Message-ID: <4EC2800A.5090506@gmail.com> Guys, Everyone is complaining about whether a FW serves its purpose or not. Take a step back. Security is about layers. Router ACLs to filter whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP payload. Patch management at the OS and Application layer on the server. Heuristics analyzing strategically placed SPAN feeds. The list goes on depending upon the size of your enterprise. I don't think in a large environment you can avoid "complexity" these days. What you have to succeed at is managing that complexity. And L3 FWs have a very important purpose. They filter garbage. You focus your IDS/IPS on what the FW is allowing. It's more than a screen door. But yes, it's LESS than a true vault door. It's all about mitigating the risk. You'll never be 100% full proof. -Hammer- "I was a normal American nerd" -Jack Herer On 11/15/2011 08:56 AM, William Herrin wrote: > On Tue, Nov 15, 2011 at 9:17 AM, wrote: > >> And this is totally overlooking the fact that the vast majority of *actual* >> attacks these days are web-based drive-bys and similar things that most >> firewalls are configured to pass through. >> > Valdis, > > A firewall's job is to prevent the success of ACTIVE attack vectors > against your network. If your firewall successfully restricts > attackers to passive attack vectors (drive-by downloads) and social > engineering vectors then it has done everything reasonably expected of > it. Those other parts of the overall network security picture are > dealt with elsewhere in system security apparatus. So it's no mistake > than in a discussion of firewalls those two attack vectors do not > feature prominently. > > Regards, > Bill Herrin > > > > From bhmccie at gmail.com Tue Nov 15 09:13:26 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 15 Nov 2011 09:13:26 -0600 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> Message-ID: <4EC28196.5010206@gmail.com> There are some methods of security that NAT has a good use for. We use NAT to prevent reachibility. In other words, not only does an ACL have to allow traffic thru the FW, but a complimenting NAT rule has to allow the actual layer 3 reachibility. If not, even with the ACL, the routing path won't be available. It is a great "safety" check when we implement FW rules because it forces almost every manual entry to have two specific steps. In our layered environments, we also use local routing in some of our DMZs. In other words, a server on a subnet will only be aware of it's local broadcast domain. Even with a default GW, if it doesn't have a NAT in the FW, it can't route thru it. So even if a server gets compromised, the bad guy doesn't have a method to reach beyond the local DMZ without also making adjustments on the FW. I don't think this complicates our design to much and definitely keeps us in check from human errors. -Hammer- "I was a normal American nerd" -Jack Herer On 11/15/2011 09:00 AM, Owen DeLong wrote: >> On the other hand, since a firewall's job is to stop packets you don't want, >> if it stops doing it's just as a firewall, it's likely to keep on doing it's >> other job: passing packets. It certainly depends on the fundamental design >> of the firewall, which I can't speak to generally... but you proponents of >> "NAT contributes no security" can't, either. >> >> > Perhaps this misunderstanding of the job of a firewall explains your > errant conclusions about their failure modes better than anything else > in the thread. > > I would say that your description above does not fit a stateful firewall, but, > instead describes a packet-filtering router. > > A stateful firewall's job is to forward only those packets you have permitted. > If ti stops doing it's job, it's default failure mode is to stop forwarding > packets. Please explain to me how mutilating the packet header makes > any difference in this. > > >>> That makes sense, but I'm wondering if that should be considered correct >>> behavior. Obviously a non-consumer grade router can have rules defining >>> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect >>> everything coming from the outside in to either a) match up with >>> something in the translation table, b) be a service the router itself is hosting >>> (http, etc), or c) be a port it explicitly forwards to the same inside >>> host. >>> >> >>> Anything not matching one of those 3 categories you'd think could be >>> dropped. Routing without translating ports and addresses seems like >>> the root of the issue. >>> >> It is. And IME, the people who think NAT provides no security rarely if >> ever seem to address that aspect of the issue. >> >> > It's a lovely hypothetical description of how those devices should work. > IME, and, as has been explained earlier in the thread, it is not necessarily > how they ACTUALLY work. Since security depends not on the theoretical > ideal of how the devices should work, but, rather on how they actually > work, perhaps it is worth considering that our addressing reality instead > of theory is actually a feature rather than a bug. > > >> And, for what it's worth, I'm discussing the common case: 1-to-many incoming >> DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on >> other ports. >> > I think that is what the discussion has been about all along. > > Owen > > > From cb.list6 at gmail.com Tue Nov 15 09:20:50 2011 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 15 Nov 2011 07:20:50 -0800 Subject: Arguing against using public IP space In-Reply-To: <4EC2800A.5090506@gmail.com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> <175192.1321366640@turing-police.cc.vt.edu> <4EC2800A.5090506@gmail.com> Message-ID: On Nov 15, 2011 7:09 AM, "-Hammer-" wrote: > > Guys, > Everyone is complaining about whether a FW serves its purpose or not. Take a step back. Security is about layers. Router ACLs to filter whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP payload. Patch management at the OS and Application layer on the server. Heuristics analyzing strategically placed SPAN feeds. The list goes on depending upon the size of your enterprise. > I would say security is about stopping threats , not layering in technology and tools. Granted, layer is a good idea, throwing everything including the kitchen sink at a problem will result in just a larger problem. > I don't think in a large environment you can avoid "complexity" these days. What you have to succeed at is managing that complexity. And L3 FWs have a very important purpose. They filter garbage. You focus your IDS/IPS on what the FW is allowing. It's more than a screen door. But yes, it's LESS than a true vault door. It's all about mitigating the risk. You'll never be 100% full proof. > Large environments have to force simplicity to combat the natural ebb of complexity. The largest operators live by one rule , KISS. L3 network fw are an attack vector and single point of failure. But, I think this thread is not changing anyone's mind at this point. > -Hammer- > > "I was a normal American nerd" > -Jack Herer > > > > > On 11/15/2011 08:56 AM, William Herrin wrote: >> >> On Tue, Nov 15, 2011 at 9:17 AM, wrote: >> >>> >>> And this is totally overlooking the fact that the vast majority of *actual* >>> attacks these days are web-based drive-bys and similar things that most >>> firewalls are configured to pass through. >>> >> >> Valdis, >> >> A firewall's job is to prevent the success of ACTIVE attack vectors >> against your network. If your firewall successfully restricts >> attackers to passive attack vectors (drive-by downloads) and social >> engineering vectors then it has done everything reasonably expected of >> it. Those other parts of the overall network security picture are >> dealt with elsewhere in system security apparatus. So it's no mistake >> than in a discussion of firewalls those two attack vectors do not >> feature prominently. >> >> Regards, >> Bill Herrin >> >> >> >> From bhmccie at gmail.com Tue Nov 15 09:19:59 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 15 Nov 2011 09:19:59 -0600 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> <175192.1321366640@turing-police.cc.vt.edu> <4EC2800A.5090506@gmail.com> Message-ID: <4EC2831F.3030009@gmail.com> I see your side Cameron. -Hammer- "I was a normal American nerd" -Jack Herer On 11/15/2011 09:20 AM, Cameron Byrne wrote: > > > On Nov 15, 2011 7:09 AM, "-Hammer-" > wrote: > > > > Guys, > > Everyone is complaining about whether a FW serves its purpose or > not. Take a step back. Security is about layers. Router ACLs to filter > whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect > HTTP payload. Patch management at the OS and Application layer on the > server. Heuristics analyzing strategically placed SPAN feeds. The list > goes on depending upon the size of your enterprise. > > > > I would say security is about stopping threats , not layering in > technology and tools. Granted, layer is a good idea, throwing > everything including the kitchen sink at a problem will result in just > a larger problem. > > > I don't think in a large environment you can avoid "complexity" > these days. What you have to succeed at is managing that complexity. > And L3 FWs have a very important purpose. They filter garbage. You > focus your IDS/IPS on what the FW is allowing. It's more than a screen > door. But yes, it's LESS than a true vault door. It's all about > mitigating the risk. You'll never be 100% full proof. > > > > Large environments have to force simplicity to combat the natural ebb > of complexity. The largest operators live by one rule , KISS. > > L3 network fw are an attack vector and single point of failure. > > But, I think this thread is not changing anyone's mind at this point. > > > -Hammer- > > > > "I was a normal American nerd" > > -Jack Herer > > > > > > > > > > On 11/15/2011 08:56 AM, William Herrin wrote: > >> > >> On Tue, Nov 15, 2011 at 9:17 AM, > wrote: > >> > >>> > >>> And this is totally overlooking the fact that the vast majority of > *actual* > >>> attacks these days are web-based drive-bys and similar things that > most > >>> firewalls are configured to pass through. > >>> > >> > >> Valdis, > >> > >> A firewall's job is to prevent the success of ACTIVE attack vectors > >> against your network. If your firewall successfully restricts > >> attackers to passive attack vectors (drive-by downloads) and social > >> engineering vectors then it has done everything reasonably expected of > >> it. Those other parts of the overall network security picture are > >> dealt with elsewhere in system security apparatus. So it's no mistake > >> than in a discussion of firewalls those two attack vectors do not > >> feature prominently. > >> > >> Regards, > >> Bill Herrin > >> > >> > >> > >> > From owen at delong.com Tue Nov 15 09:32:37 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Nov 2011 07:32:37 -0800 Subject: Arguing against using public IP space In-Reply-To: <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> Message-ID: On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote: > > > On 14 Nov 2011, at 18:52, "McCall, Gabriel" wrote: > >> Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. > > > Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure! > This is not true. If your firewall is not working, it should not be passing packets. If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a failure of the network implementor and the address space will not have any impact whatsoever on your lack of security. > As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. > So does a firewall. Owen From cmorris at cs.odu.edu Tue Nov 15 09:44:51 2011 From: cmorris at cs.odu.edu (Charles Morris) Date: Tue, 15 Nov 2011 10:44:51 -0500 Subject: Ok; let's have the "Does DNAT contribute to Security" argument one more time... In-Reply-To: References: <3696694.2771.1321304114757.JavaMail.root@benjamin.baylink.com> Message-ID: Against my better judgment to get in the middle of this classic discussion, two points... One, many firewalls have fail-safe capabilities, in addition to fail-secure; even if they didn't it could be trivially programmed, or configured to do so in series, and as configuration is fairly arbitrary the comments about "how firewalls work" aren't really valid. My firewall most certainly works differently than yours ... There are also issues with stateful failover versus stateless failover. The two schools of thought on this issue are, as far as I know: a) Fail as little as possible and as compartmentalized as possible, attempting to keep service online at the expense of security (perhaps) (fail-safe) or b) Fail with the intent to keep the network as secure as possible, even if it means causing total service failure. (fail-secure) I find both to be valid and each network should be individually evaluated for application of A or B. If you have a secretless, isolated, read-only environment there is no reason to be concerned about people mucking about. in theory. Two, I would almost guarantee the combination of NAT+firewall is better than only firewall, however the fact that NAT is inherently stateful and really quite vulnerable to DoS makes for an interesting situation. At least with only firewall you could revert to stateless mode during a translation attack (if you chose 'A'). For a NAT to have a similar approach you would need a dark address pool for static translation... that doesn't seem likely or practical, saving a situation where you paid for address time. On the negative case, not having a NAT implies that you won't have any NAT failures or NAT hardware costs :) Perhaps unnecessary NAT is trading a theoretical protection (routing isolation) for a real vulnerability (trans table overflow). On Tue, Nov 15, 2011 at 10:00 AM, Owen DeLong wrote: >> >> On the other hand, since a firewall's job is to stop packets you don't want, >> if it stops doing it's just as a firewall, it's likely to keep on doing it's >> other job: passing packets. ?It certainly depends on the fundamental design >> of the firewall, which I can't speak to generally... but you proponents of >> "NAT contributes no security" can't, either. >> > > Perhaps this misunderstanding of the job of a firewall explains your > errant conclusions about their failure modes better than anything else > in the thread. > > I would say that your description above does not fit a stateful firewall, but, > instead describes a packet-filtering router. > > A stateful firewall's job is to forward only those packets you have permitted. > If ti stops doing it's job, it's default failure mode is to stop forwarding > packets. Please explain to me how mutilating the packet header makes > any difference in this. > >>> That makes sense, but I'm wondering if that should be considered correct >>> behavior. Obviously a non-consumer grade router can have rules defining >>> what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect >>> everything coming from the outside in to either a) match up with >>> something in the translation table, b) be a service the router itself is hosting >>> (http, etc), or c) be a port it explicitly forwards to the same inside >>> host. >> >>> Anything not matching one of those 3 categories you'd think could be >>> dropped. Routing without translating ports and addresses seems like >>> the root of the issue. >> >> It is. ?And IME, the people who think NAT provides no security rarely if >> ever seem to address that aspect of the issue. >> > > It's a lovely hypothetical description of how those devices should work. > IME, and, as has been explained earlier in the thread, it is not necessarily > how they ACTUALLY work. Since security depends not on the theoretical > ideal of how the devices should work, but, rather on how they actually > work, perhaps it is worth considering that our addressing reality instead > of theory is actually a feature rather than a bug. > >> And, for what it's worth, I'm discussing the common case: 1-to-many incoming >> DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on >> other ports. > > I think that is what the discussion has been about all along. > > Owen > > > From jgreco at ns.sol.net Tue Nov 15 09:54:50 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 15 Nov 2011 09:54:50 -0600 (CST) Subject: Arguing against using public IP space In-Reply-To: Message-ID: <201111151554.pAFFsoWL092906@aurora.sol.net> > If you put a router where you needed a firewall, then, this is not a = > failure of the firewall, but, a > failure of the network implementor and the address space will not have = > any impact whatsoever > on your lack of security. And the difference between a router and a firewall is ...? Apparently, one bit. ... 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 seitz at strato-rz.de Tue Nov 15 10:22:09 2011 From: seitz at strato-rz.de (Christian Seitz) Date: Tue, 15 Nov 2011 17:22:09 +0100 Subject: Minimum Allocation Size by RIRs (IPv4) In-Reply-To: <4EC27DB7.4000800@init7.net> References: <4EC27DB7.4000800@init7.net> Message-ID: <4EC291B1.3080908@strato-rz.de> Hello Fredy, Am 15.11.2011 15:56, schrieb Fredy Kuenzler: > I'm trying to compile a comprehensive and up-to-date list of Minimum > Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so > far: > > ARIN: https://www.arin.net/knowledge/ip_blocks.html > > APNIC: > http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations > (seems that they have recently changed from /22 to /24, which is not too > helpful...) > > RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5 > > Nothing found for AFRINIC and LACNIC yet, and legacy space, too. I made such a list some month ago and also found those links: LACNIC: http://lacnic.net/en/registro/index.html AfriNIC: http://www.afrinic.net/Registration/resources.htm ARIN Micro Allocations: https://www.arin.net/knowledge/micro_allocations.html Regards, Christian Seitz Network Operations -- --------------------------------------------------------------------------- Telefon: +49 (0)30 - 398 02 205 Mobil : +49 (0)172 - 389 8714 Telefax: +49 (0)30 - 398 02 222 E-Mail : seitz at strato-rz.de Website: http://www.strato.de/ --------------------------------------------------------------------------- STRATO AG Pascalstr. 10 10587 Berlin --------------------------------------------------------------------------- Vorsitzender des Aufsichtsrates: Dirk Backofen Vorstand: Damian Schmidt (Vorsitz), Julien Ardisson, Christian Mueller, Christoph Steffens, Rene Wienholtz Amtsgericht Berlin-Charlottenburg HRB 79450 From bill at herrin.us Tue Nov 15 10:25:16 2011 From: bill at herrin.us (William Herrin) Date: Tue, 15 Nov 2011 11:25:16 -0500 Subject: Minimum Allocation Size by RIRs (IPv4) In-Reply-To: <4EC27DB7.4000800@init7.net> References: <4EC27DB7.4000800@init7.net> Message-ID: On Tue, Nov 15, 2011 at 9:56 AM, Fredy Kuenzler wrote: > I'm trying to compile a comprehensive and up-to-date list of Minimum > Allocation Sizes by the various RIRs. Any hint would be appreciated. I have > so far: Hi Fredy, Due to the transfer processes which will sustain IPv4 as the regional free pools exhaust, the minimum allocation size can be expected to drop to /24 in essentially all /8's within the next 24 months. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rubensk at gmail.com Tue Nov 15 10:30:55 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Tue, 15 Nov 2011 14:30:55 -0200 Subject: Minimum Allocation Size by RIRs (IPv4) In-Reply-To: <4EC27DB7.4000800@init7.net> References: <4EC27DB7.4000800@init7.net> Message-ID: On Tue, Nov 15, 2011 at 12:56 PM, Fredy Kuenzler wrote: > I'm trying to compile a comprehensive and up-to-date list of Minimum > Allocation Sizes by the various RIRs. Any hint would be appreciated. I have > so far: NIRs (National Internet Registries) in the APNIC and LACNIC area need to be mapped as well as their policies sometimes differ from the RIRs (although they are converging due to IPv4 exhaustion). LACNIC: /24 - http://lacnic.net/en/politicas/manual3.html NIC.br: /24 - http://registro.br/provedor/numeracao/regras.html NIC.mx: /24 - http://www.iar.mx/jsf/static_content/services/resources_request/portable_ip_asn_wish/eligibilityCheck.jsf Rubens From rfinnesey at gmail.com Tue Nov 15 11:05:41 2011 From: rfinnesey at gmail.com (Ryan Finnesey) Date: Tue, 15 Nov 2011 12:05:41 -0500 Subject: Cell-based OOB management devices In-Reply-To: <20111115114038.FVF0E.49163.root@hrndva-web09-z01> References: <20111115114038.FVF0E.49163.root@hrndva-web09-z01> Message-ID: <002501cca3b9$1b877080$52965180$@gmail.com> We do this with at&t with a custom APN works great no need to VPN. If you want to use Sprint take a look at Sprint Data Link. You can use your IPs on the data cards. Cheers Ryan -----Original Message----- From: rcheung at rochester.rr.com [mailto:rcheung at rochester.rr.com] Sent: Tuesday, November 15, 2011 6:41 AM To: nanog at nanog.org; David Hubbard Subject: Re: Cell-based OOB management devices David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC ---- David Hubbard wrote: > Hi all, I am looking at cellular-based devices as a higher speed > alternative to dial-up backup access methods for out of band > management during emergencies. I was wondering if anyone had > experiences with such devices they could share? > > Devices I've found include Sierra Wireless AirLink Raven X, Digi's > ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience > with any but they all appear to support the Sprint network which I > assume would be ideal due to not having usage caps on data > (currently). The Opengear device runs linux and has four serial > ports, a usb port for additional storage and ethernet, so it seems to > have some small advantages over the others since it could double as an > emergency self-contained management station you can SSH into and run > diagnostics from. All appear to have VPN/gateway support. > > What none of them are clear on is how you would connect to it over > cellular since I assume you're just paying for a typical data plan and > it will randomly obtain IP addresses. Maybe some type of dynamic dns > service so you can easily figure out your device's current IP? How > stable is the access to the device? Any idea if any of them can do > ipv6? > > Thanks! > > David > > From owen at delong.com Tue Nov 15 11:08:07 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Nov 2011 09:08:07 -0800 Subject: Arguing against using public IP space In-Reply-To: <201111151554.pAFFsoWL092906@aurora.sol.net> References: <201111151554.pAFFsoWL092906@aurora.sol.net> Message-ID: <5CBF6B7A-D16E-487B-B70D-1F36B1CDBECB@delong.com> On Nov 15, 2011, at 7:54 AM, Joe Greco wrote: >> If you put a router where you needed a firewall, then, this is not a = >> failure of the firewall, but, a >> failure of the network implementor and the address space will not have = >> any impact whatsoever >> on your lack of security. > > And the difference between a router and a firewall is ...? > > Apparently, one bit. IMHO, a firewall does not route packets by default, but, rather only forwards those packets which match configured policies. A router, OTOH, routes packets by default, but, may be configured with some policy about which packets to forward. The difference functionally is what happens when the configuration is lost or corrupted. Essentially fail open vs. fail closed. Owen From leigh.porter at ukbroadband.com Tue Nov 15 11:14:44 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 15 Nov 2011 17:14:44 +0000 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> Message-ID: <8B492826-660E-466A-A31D-11616E5805A4@ukbroadband.com> On 15 Nov 2011, at 15:36, "Owen DeLong" wrote: > > On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote: > >> >> >> On 14 Nov 2011, at 18:52, "McCall, Gabriel" wrote: >> >>> Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. >> >> >> Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure! >> > This is not true. > > If your firewall is not working, it should not be passing packets. And of course, things always fail just the way we want them to. > > If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a > failure of the network implementor and the address space will not have any impact whatsoever > on your lack of security. This is not really a well made point, sorry. It's about a firewall failing, perhaps due to software error or hardware issue or because somebody failed to correctly configure a firewall rule. The point about private space is that is forces security in a way in which public space and a firewall does not. With private space, you are forces to explicitly configure NAT holes or VPN connections whereas with public space your boxes by default are accessible by the whole Internet. By default, on a private space network, nothing can get to it. > >> As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. >> > > So does a firewall. If it fails just how you want it to. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From leigh.porter at ukbroadband.com Tue Nov 15 11:16:23 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 15 Nov 2011 17:16:23 +0000 Subject: Arguing against using public IP space In-Reply-To: <001a01cca3a5$5efa1200$1cee3600$@com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> <175192.1321366640@turing-police.cc.vt.edu> <001a01cca3a5$5efa1200$1cee3600$@com> Message-ID: <56433BFF-2BDF-4C12-928F-B0C576047F24@ukbroadband.com> Quite right.. I bet all Iran's nuclear facilities have air gaps but they let people in with laptops and USB sticks. -- Leigh On 15 Nov 2011, at 14:48, "Chuck Church" wrote: > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Tuesday, November 15, 2011 9:17 AM > To: Leigh Porter > Cc: nanog at nanog.org; McCall, Gabriel > Subject: Re: Arguing against using public IP space > >> And this is totally overlooking the fact that the vast majority of > *actual* attacks these days are web-based drive-bys > and similar things > that most firewalls are configured to pass through. Think about it - if a > NAT'ed firewall provides > any real protection against real attacks, why are > there still so many zombied systems out there? I mean, Windows > > Firewall has been shipping with inbound "default deny" since XP SP2 or so. > How many years ago was that? > > Simple explanation is that most firewall rules are written to trust traffic > initiated by 'inside' (your users), and the return traffic gets trusted as > well. This applies to both Window's own FW, and most hardware based > firewalls. And NAT/PAT devices too. There's nothing more dangerous than a > user with a web browser. Honestly, FWs will keep out attacks initiated from > outside. But for traffic permitted or initiated by the inside, IPS is only > way to go. > > Chuck > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From paul4004 at gmail.com Tue Nov 15 11:15:06 2011 From: paul4004 at gmail.com (PC) Date: Tue, 15 Nov 2011 10:15:06 -0700 Subject: Cell-based OOB management devices In-Reply-To: <002501cca3b9$1b877080$52965180$@gmail.com> References: <20111115114038.FVF0E.49163.root@hrndva-web09-z01> <002501cca3b9$1b877080$52965180$@gmail.com> Message-ID: Second this. Custom APN to AT&T with ipsec lan2lan VPN built to the provider. Works great for this. Once you get rid of the vpn need, you can use any cheap console server. I've seen solutions ranging from little opengear boxes (which are great to ship to a remote site to help a tech set something up, BTW), to home-brew solutions involving anything that can run OpenWRT, has a usb port, and can run screen or ser2net. Prices for low volume (10mb/month) data plans typically are less than analog lines, too. On Tue, Nov 15, 2011 at 10:05 AM, Ryan Finnesey wrote: > We do this with at&t with a custom APN works great no need to VPN. If you > want to use Sprint take a look at Sprint Data Link. You can use your IPs > on the data cards. > > Cheers > Ryan > > > -----Original Message----- > From: rcheung at rochester.rr.com [mailto:rcheung at rochester.rr.com] > Sent: Tuesday, November 15, 2011 6:41 AM > To: nanog at nanog.org; David Hubbard > Subject: Re: Cell-based OOB management devices > > David, a Sprint aircard can be had with a static-ip, so that should ease > remote connectivity requirements. Or, you can opt for the Datalink (private > VPN) service, which separates your aircard traffic from other customers > within a VRF, obviating the need to run a separate VPN client. > > > -RC > > > ---- David Hubbard wrote: > > Hi all, I am looking at cellular-based devices as a higher speed > > alternative to dial-up backup access methods for out of band > > management during emergencies. I was wondering if anyone had > > experiences with such devices they could share? > > > > Devices I've found include Sierra Wireless AirLink Raven X, Digi's > > ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience > > with any but they all appear to support the Sprint network which I > > assume would be ideal due to not having usage caps on data > > (currently). The Opengear device runs linux and has four serial > > ports, a usb port for additional storage and ethernet, so it seems to > > have some small advantages over the others since it could double as an > > emergency self-contained management station you can SSH into and run > > diagnostics from. All appear to have VPN/gateway support. > > > > What none of them are clear on is how you would connect to it over > > cellular since I assume you're just paying for a typical data plan and > > it will randomly obtain IP addresses. Maybe some type of dynamic dns > > service so you can easily figure out your device's current IP? How > > stable is the access to the device? Any idea if any of them can do > > ipv6? > > > > Thanks! > > > > David > > > > > > > > > From bill at herrin.us Tue Nov 15 11:15:06 2011 From: bill at herrin.us (William Herrin) Date: Tue, 15 Nov 2011 12:15:06 -0500 Subject: Arguing against using public IP space In-Reply-To: <4EC1B3D2.5060007@mompl.net> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <4EC1B3D2.5060007@mompl.net> Message-ID: On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart wrote: > William Herrin wrote: >> If your machine is addressed with a globally routable IP, a trivial >> failure of your security apparatus leaves your machine addressable >> from any other host in the entire world which wishes to send it > > Isn't that the case with IPv6? That the IP is addressable from any host in > the entire (IPv6) world? And isn't that considered a good thing? Hi Jeroen, Yes, according to almost every application developer asked it's a good thing. Me? I'm not so sure. Historically, enterprises moved away from global addressability even when IP addresses were free, *before* address scarcity became an issue. There's a lesson in there somewhere and I'm not convinced it's that "they were dumb." > I don't think that being addressable from anywhere is a security hole in and > of itself. It's how you implement and (mis)configure your firewall and > related things that is the (potential) security hole. Whether the IP is > world addressable or not I agree. That your computer is globally addressable is NOT a security hole. It does not directly or indirectly make you vulnerable to attack. But the inverse doesn't follow. That your computer is not globally addressable ADDS one layer of security in a process you hope has enough layers to prevent an attack from penetrating. And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From rfinnesey at gmail.com Tue Nov 15 11:24:20 2011 From: rfinnesey at gmail.com (Ryan Finnesey) Date: Tue, 15 Nov 2011 12:24:20 -0500 Subject: Cell-based OOB management devices In-Reply-To: References: <20111115114038.FVF0E.49163.root@hrndva-web09-z01> <002501cca3b9$1b877080$52965180$@gmail.com> Message-ID: <033901cca3bb$6ab4d6f0$401e84d0$@gmail.com> We pay $4 per SIM with at&t then about $2.50 per MB. Cheers Ryan From: PC [mailto:paul4004 at gmail.com] Sent: Tuesday, November 15, 2011 12:15 PM To: Ryan Finnesey Cc: rcheung at rochester.rr.com; nanog at nanog.org; David Hubbard Subject: Re: Cell-based OOB management devices Second this. Custom APN to AT&T with ipsec lan2lan VPN built to the provider. Works great for this. Once you get rid of the vpn need, you can use any cheap console server. I've seen solutions ranging from little opengear boxes (which are great to ship to a remote site to help a tech set something up, BTW), to home-brew solutions involving anything that can run OpenWRT, has a usb port, and can run screen or ser2net. Prices for low volume (10mb/month) data plans typically are less than analog lines, too. On Tue, Nov 15, 2011 at 10:05 AM, Ryan Finnesey wrote: We do this with at&t with a custom APN works great no need to VPN. If you want to use Sprint take a look at Sprint Data Link. You can use your IPs on the data cards. Cheers Ryan -----Original Message----- From: rcheung at rochester.rr.com [mailto:rcheung at rochester.rr.com] Sent: Tuesday, November 15, 2011 6:41 AM To: nanog at nanog.org; David Hubbard Subject: Re: Cell-based OOB management devices David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC ---- David Hubbard wrote: > Hi all, I am looking at cellular-based devices as a higher speed > alternative to dial-up backup access methods for out of band > management during emergencies. I was wondering if anyone had > experiences with such devices they could share? > > Devices I've found include Sierra Wireless AirLink Raven X, Digi's > ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience > with any but they all appear to support the Sprint network which I > assume would be ideal due to not having usage caps on data > (currently). The Opengear device runs linux and has four serial > ports, a usb port for additional storage and ethernet, so it seems to > have some small advantages over the others since it could double as an > emergency self-contained management station you can SSH into and run > diagnostics from. All appear to have VPN/gateway support. > > What none of them are clear on is how you would connect to it over > cellular since I assume you're just paying for a typical data plan and > it will randomly obtain IP addresses. Maybe some type of dynamic dns > service so you can easily figure out your device's current IP? How > stable is the access to the device? Any idea if any of them can do > ipv6? > > Thanks! > > David > > From Valdis.Kletnieks at vt.edu Tue Nov 15 11:31:26 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 15 Nov 2011 12:31:26 -0500 Subject: Arguing against using public IP space In-Reply-To: Your message of "Tue, 15 Nov 2011 09:56:38 EST." References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> <175192.1321366640@turing-police.cc.vt.edu> Message-ID: <7408.1321378286@turing-police.cc.vt.edu> On Tue, 15 Nov 2011 09:56:38 EST, William Herrin said: > A firewall's job is to prevent the success of ACTIVE attack vectors > against your network. If your firewall successfully restricts > attackers to passive attack vectors (drive-by downloads) and social > engineering vectors then it has done everything reasonably expected of > it. Those other parts of the overall network security picture are > dealt with elsewhere in system security apparatus. So it's no mistake > than in a discussion of firewalls those two attack vectors do not > feature prominently. You missed the point - in the greater scheme of things, the threat model has moved on, so the entire "ZOMG We can't deploy IPv6 because there's no NAT for security" is a total crock of bovine manure. There are *so many* lower-hanging fruit these days that if you're trying to *actually* improve your site's security, you'd just punt worrying about the NAT stuff and focus on doing a better job defending against the threats that are actually succeeding in breaking into systems. In another year or two, lack of IPv6 deployment is going to start impacting the "availability" part of the security triad. I'd worry about *that* more than "how many NATs can dance on the head of a pin". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From theckman at linode.com Tue Nov 15 11:50:26 2011 From: theckman at linode.com (Tim Heckman) Date: Tue, 15 Nov 2011 12:50:26 -0500 Subject: Packets dropped passing from Qwest to Verizon Message-ID: <48A01A9F-7E07-4CC3-B57D-F4D6E8E53E26@linode.com> Hello, I'm looking looking for a POC at Qwest (AS209) or Verizon (AS701) to help diagnose what looks like a stale bogon filter. The packets drop where Qwest (63.146.26.210) peers with Verizon (152.63.2.130). Thanks in advance! Regards, Tim H. From jgreco at ns.sol.net Tue Nov 15 11:54:45 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 15 Nov 2011 11:54:45 -0600 (CST) Subject: Arguing against using public IP space In-Reply-To: <5CBF6B7A-D16E-487B-B70D-1F36B1CDBECB@delong.com> Message-ID: <201111151754.pAFHsk4t094745@aurora.sol.net> > On Nov 15, 2011, at 7:54 AM, Joe Greco wrote: > >> If you put a router where you needed a firewall, then, this is not a = > >> failure of the firewall, but, a > >> failure of the network implementor and the address space will not have = > >> any impact whatsoever > >> on your lack of security. > > > > And the difference between a router and a firewall is ...? > > > > Apparently, one bit. > > IMHO, a firewall does not route packets by default, but, rather only forwards > those packets which match configured policies. > > A router, OTOH, routes packets by default, but, may be configured with some > policy about which packets to forward. > > The difference functionally is what happens when the configuration is > lost or corrupted. Essentially fail open vs. fail closed. 1 vs 0. As I said... one bit. Understanding this fundamental truth is helpful in understanding why people use "routers" as "firewalls" and "firewalls" as "routers". Because they're basically the same thing, with a one bit difference. And some products, say like FreeBSD (which forms the heart of things like pfSense, so let's not even begin to argue that it "isn't a firewall") can actually be configured to default either way. So basically, while we would all prefer that firewalls default to deny, it probably isn't as important a distinction as this thread is making it out to be, because even a "default to deny" firewall fails when a naive admin makes a typo and allows all traffic from 0/0 inadvertently. It's just a matter of statistical likelihood. Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already. ... 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 drais at icantclick.org Tue Nov 15 12:02:28 2011 From: drais at icantclick.org (david raistrick) Date: Tue, 15 Nov 2011 13:02:28 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: <201111151754.pAFHsk4t094745@aurora.sol.net> References: <201111151754.pAFHsk4t094745@aurora.sol.net> Message-ID: On Tue, 15 Nov 2011, Joe Greco wrote: > Or perhaps a better argument would be that routers really ought to > default to deny. :-) I'd be fine with that, but I can hear the > screaming already. er. you've forgotten "en; conf t; ip routing" to turn off the default "no ip routing" (or "no ip forwarding" is my memory, but my config archive says otherwise) so we had default to deny in routers for a long time.... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From rps at maine.edu Tue Nov 15 12:32:48 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 15 Nov 2011 13:32:48 -0500 Subject: Arguing against using public IP space In-Reply-To: <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> Message-ID: On Tue, Nov 15, 2011 at 5:57 AM, Leigh Porter wrote: > As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. This is a myth; just like NAT provides security is a myth. It doesn't matter if your firewall performs NAT or not; if it fails, traffic will more than likely stop flowing. The conditions for a non-NAT firewall to fail open are very specific. You often need to engineer it to have that functionality. Either type of firewall system can be designed to fail open or fail closed. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From Valdis.Kletnieks at vt.edu Tue Nov 15 12:38:52 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 15 Nov 2011 13:38:52 -0500 Subject: Arguing against using public IP space In-Reply-To: Your message of "Tue, 15 Nov 2011 17:16:23 GMT." <56433BFF-2BDF-4C12-928F-B0C576047F24@ukbroadband.com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> <175192.1321366640@turing-police.cc.vt.edu> <001a01cca3a5$5efa1200$1cee3600$@com> <56433BFF-2BDF-4C12-928F-B0C576047F24@ukbroadband.com> Message-ID: <9649.1321382332@turing-police.cc.vt.edu> On Tue, 15 Nov 2011 17:16:23 GMT, Leigh Porter said: > Quite right.. I bet all Iran's nuclear facilities have air gaps but they let > people in with laptops and USB sticks. And that's the point - *most* networks have so many bigger issues that the whole "NAT makes us secure" mantra is dangerous self-delusion. If you have machines in the NAT area where you're actually concerned that "ZOMG the firewall might fail and expose them", why aren't they airgapped? As the Iranians discovered, if the attacker gets a foothold inside the NAT you're screwed anyhow, and *that* is probably a lot more likely scenario than a fail-open firewall.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jgreco at ns.sol.net Tue Nov 15 12:56:10 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 15 Nov 2011 12:56:10 -0600 (CST) Subject: Arguing against using public IP space In-Reply-To: Message-ID: <201111151856.pAFIuBFI095432@aurora.sol.net> > On Tue, 15 Nov 2011, Joe Greco wrote: > > Or perhaps a better argument would be that routers really ought to > > default to deny. :-) I'd be fine with that, but I can hear the > > screaming already. > > er. you've forgotten "en; conf t; ip routing" to turn off the default "no > ip routing" (or "no ip forwarding" is my memory, but my config archive > says otherwise) > > so we had default to deny in routers for a long time.... My bad. But seriously, now, I'm going to wander a bit far to make a point that I hope people get. In the '90's, during the rapid ISP growth era, one of the local policies here was that all boxes should be protected by a competent on-box firewall. The problem with this was that it was tough to implement in practice, since for the most part, boxes varied in interface configuration, etc., etc. Writing a custom ruleset for each box was nearly prohibitive. I also had clients where I saw similar problems. You'd see all sorts of pseudo-strange rulesets being written, and wildly differing policies about things like ssh, etc., which made administration a challenge too. But a large percentage seemed to go firewall-free. Bleh. So as part of the standard build, I designed an automatic firewall script that basically looked at the system IP configuration, derived reasonable defaults, and then allowed an abstract policy to be specified, such as TCP_ALLOW="80 443" and the rest was automatic. This may seem trivial to many of you, and I will even concede that it *should* be, but the point is that by having this installed by default, it made it MORE annoying to disable the firewall than it was to create a simple configuration for it. So suddenly all servers built through the build scripts reliably had firewall rules in place. I know some readers here may still be using variations on those scripts, and they've served us well over the years too. Now I want to stress the point here: It wasn't that there was this magic firewall script, because to be sure some engs still rolled their own for various reasons. The point is that SOME firewall was going to be running. And that's the desired result. In any case, to bring the discussion home, I suspect that part of the problem with routers and fw rules is that there's a lack of a "default to being firewalled". Because it's hard to do that and do it right without also being so painful that an admin just installs a "pass all" rule to get things working, and then forgets about it all. Those of you who work for large service providers or enterprises and have this all worked out - well, I'm not talking about you, of course. You have incentive and motivation to get this kind of thing working on your fleets of a thousand routers. Great. But it's still a problem for many others. ... 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 michael at rancid.berkeley.edu Tue Nov 15 13:22:06 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 15 Nov 2011 11:22:06 -0800 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <4EC1B3D2.5060007@mompl.net> Message-ID: <4EC2BBDE.1050508@rancid.berkeley.edu> On 11/15/11 09:15, William Herrin wrote: > On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart wrote: >> William Herrin wrote: >>> If your machine is addressed with a globally routable IP, a trivial >>> failure of your security apparatus leaves your machine addressable >>> from any other host in the entire world which wishes to send it >> >> Isn't that the case with IPv6? That the IP is addressable from any host in >> the entire (IPv6) world? And isn't that considered a good thing? > > Hi Jeroen, > > Yes, according to almost every application developer asked it's a good thing. > > Me? I'm not so sure. Historically, enterprises moved away from global > addressability even when IP addresses were free, *before* address > scarcity became an issue. There's a lesson in there somewhere and I'm > not convinced it's that "they were dumb." > And make no mistake: successful security is about layers, about DEPTH. > You can seek layers from other sources but a shallow security process > will tend to be easily breached. Hi Bill: I am not sure if the enterprises were dumb for doing private address space, but I have a few hints that they might have been. (E.g. there's a *lot* of RFC1918 space out there. Why does the overwhelming majority use 192.168.0.0/24 or 192.168.1.0/24 or 10.0.0.0/24?) But what definitely *is* dumb is are the following two axioms, at least one of which is expressed in the article: 1. You need NAT/private ip address space to have security. 2. Once you have NAT/private ip address space, you have security. On the surface those axioms clearly violate your notion of security layers and they clearly violate common sense. Yet we find them lurking just beneath the surface, including in the debate about the utility of IPv6 ULAs, as well as in the article. michael From michael at rancid.berkeley.edu Tue Nov 15 13:27:58 2011 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 15 Nov 2011 11:27:58 -0800 Subject: Arguing against using public IP space In-Reply-To: References: Message-ID: <4EC2BD3E.9000505@rancid.berkeley.edu> On 11/13/11 07:36, Jason Lewis wrote: > I don't want to start a flame war, but this article seems flawed to > me. It seems an IP is an IP. > > http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html > > I think I could announce private IP space, so doesn't that make this > argument invalid? I've always looked at private IP space as more of a > resource and management choice and not a security feature. Really, the article doesn't make much sense. The claim is that SCADA systems come with "public IP addresses by default" and that SCADA engineers are too ignorant of Internet security practices to know to re-configure them. First, the ignorance factor goes right back to the two axioms I mentioned in my reply to Bill. If you aren't paying attention, then you don't have security, regardless of which IP address space you use. Second, there's the point that the SCADA systems come with public IP addresses by default. So what? The article incorrectly confuses "public" IP addresses with "routable" IP addresses. As an example, when I worked in the College of Chemistry at UC Berkeley, there was a lab with NMR machines that all came with public IP addresses by default--those of the manufacturer. Of course, since the manufacturer was in Germany, and we were in the US those IP addresses weren't routable in our network. Are SCADA systems similarly configured? The article doesn't say if the manufacturers pre-configure addresses within the client's IP blocks or their own, or even 1.2.3.0/24. If the manufacturer went to the trouble of configuring the system on routable IP addresses, then the SCADA engineer can easily specify which set of addresses. If the manufacturer really does configure "public" IP addresses "by default" then it's unlikely that those "public" IP addresses are actually _routable_ on the network which is using the SCADA system. Oh, and the article treats RFC1918 and RFC4193 is equivalent, which is WRONG WRONG WRONG! michael From owen at delong.com Tue Nov 15 14:16:08 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Nov 2011 12:16:08 -0800 Subject: Arguing against using public IP space In-Reply-To: References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <4EC1B3D2.5060007@mompl.net> Message-ID: <971B1F8E-0B72-42E9-A9FD-FCD8DC4F7850@delong.com> On Nov 15, 2011, at 9:15 AM, William Herrin wrote: > On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart wrote: >> William Herrin wrote: >>> If your machine is addressed with a globally routable IP, a trivial >>> failure of your security apparatus leaves your machine addressable >>> from any other host in the entire world which wishes to send it >> >> Isn't that the case with IPv6? That the IP is addressable from any host in >> the entire (IPv6) world? And isn't that considered a good thing? > > Hi Jeroen, > > Yes, according to almost every application developer asked it's a good thing. > > Me? I'm not so sure. Historically, enterprises moved away from global > addressability even when IP addresses were free, *before* address > scarcity became an issue. There's a lesson in there somewhere and I'm > not convinced it's that "they were dumb." I'm not sure how you can make that case since RFC-1918 and it's predecessors RFC-1597 and RFC-1627 came after address scarcity was already a known problem. The oldest of these three (RFC 1597 is dated March, 1994. IPv6 development (spurred by the fact that IPv4 addresses were becoming scarce) started in earnest somewhere between 1990-1992 depending on who you ask). If your initial assertion were true, then, there might be some sort of lesson from your follow-on statement. In this case, however, since the assertion is false, the follow-on lesson is likely just that some enterprises jumped on the NAT bandwagon sooner than others in pursuit of certain coolness or other convenience factors unrelated to delivering a good internet experience to their end users. Also, since the internet was such a radically different thing back then as compared to what it is now, I'm not sure that any such lesson would inherently be useful in the modern age. > > >> I don't think that being addressable from anywhere is a security hole in and >> of itself. It's how you implement and (mis)configure your firewall and >> related things that is the (potential) security hole. Whether the IP is >> world addressable or not > > I agree. That your computer is globally addressable is NOT a security > hole. It does not directly or indirectly make you vulnerable to > attack. But the inverse doesn't follow. > > That your computer is not globally addressable ADDS one layer of > security in a process you hope has enough layers to prevent an attack > from penetrating. > This statement is absurd. I can have a globally unique address on a system that does not have any external connectivity. The fact that the address is global in scope does not in any way make that system any less secure than a system which uses an address that is not globally unique. Addressability is not reachability. Addressability has nothing to do with security. Reachability has a little bit to do with security, but, in any sane modern implementation, not a lot. > And make no mistake: successful security is about layers, about DEPTH. > You can seek layers from other sources but a shallow security process > will tend to be easily breached. > This is the only thing you've said here that I can actually agree with. Given the penalties associated with non-global addressing and the rewards available from global addressing combined with the absolutely minimal protection afforded by non-global addressing, I find it hard to imagine a scenario in which the benefits would ever outweigh the costs. Owen From owen at delong.com Tue Nov 15 14:23:26 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Nov 2011 12:23:26 -0800 Subject: Arguing against using public IP space In-Reply-To: <8B492826-660E-466A-A31D-11616E5805A4@ukbroadband.com> References: <201111131638.pADGcoiu007448@mail.r-bonomi.com> <20111113212756.GD73635@macbook.bluepipe.net> <4EC03B30.2090007@dougbarton.us> <001001cca255$b4a45450$1decfcf0$@com> <20111113225924.GF73635@macbook.bluepipe.net> <002201cca25f$6c5340d0$44f9c270$@com> <28059c8f-d60b-49ce-a0a8-63544eea2e05@blur> <6B29C0B1-6852-46CB-B3EB-1F91AF18A7B8@ukbroadband.com> <8B492826-660E-466A-A31D-11616E5805A4@ukbroadband.com> Message-ID: <69ACE97A-D95A-4FE1-99DF-A4D88EFA016B@delong.com> On Nov 15, 2011, at 9:14 AM, Leigh Porter wrote: > > On 15 Nov 2011, at 15:36, "Owen DeLong" wrote: > >> >> On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote: >> >>> >>> >>> On 14 Nov 2011, at 18:52, "McCall, Gabriel" wrote: >>> >>>> Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. >>> >>> >>> Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure! >>> >> This is not true. >> >> If your firewall is not working, it should not be passing packets. > > And of course, things always fail just the way we want them to. > Your stateful firewall is no more likely to fail open than your header-mutilating device. >> >> If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a >> failure of the network implementor and the address space will not have any impact whatsoever >> on your lack of security. > > This is not really a well made point, sorry. It's about a firewall failing, perhaps due to software error or hardware issue or because somebody failed to correctly configure a firewall rule. > The assertion I was countering is that a header-mangling device is inherently more secure than a stateful firewall that does not mangle headers. I believe that the above paragraph addresses the fact that both are equally likely to fail in an open manner. The problem I was primarily attempting to convey is that many people confuse packet filtering routers for firewalls. Routers have many ways in which they tend to fail open. Their default unconfigured mode is to pass all traffic. This is not the case with a properly designed stateful firewall. > The point about private space is that is forces security in a way in which public space and a firewall does not. > And my point is that it does not actually do so. If your header-mutilating device breaks or is badly designed or misconfigured, it is just as likely to pass traffic to your private-addressed internal hosts as a badly designed or misconfigured firewall. The only difference is the trivial difference in what it takes to get said traffic to the appliance in question. > With private space, you are forces to explicitly configure NAT holes or VPN connections whereas with public space your boxes by default are accessible by the whole Internet. By default, on a private space network, nothing can get to it. > Or deliver packets already addressed to the internal host to the external mac address of the header-mutilating device, or own the internal host through other means and have it create a tunnel which the header-mutilating device happily mistakes for a permitted stateful outbound flow, or... I realize you like to live in this fantasy land where private space makes things more secure because it allows you to be lazy about your security posture in other areas. This is a common fallacy that is well liked by many an IT department in the world. It's still a fallacy, and, arguably one that has systematically reduced security overall. > > >> >>> As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. >>> >> >> So does a firewall. > > If it fails just how you want it to. > If the firewall's default state is don't forward anything, the likelihood of it failing closed is just as high as the theoretical likelihood that a header-mutilating device will do so. In fact, arguably more so. Owen From jra at baylink.com Tue Nov 15 14:55:42 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 15 Nov 2011 15:55:42 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: <175192.1321366640@turing-police.cc.vt.edu> Message-ID: <4025227.2911.1321390542053.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > And this is totally overlooking the fact that the vast majority of *actual* > attacks these days are web-based drive-bys and similar things that most > firewalls are configured to pass through. Think about it - if a NAT'ed > firewall provides any real protection against real attacks, why are there still > so many zombied systems out there? I mean, Windows Firewall has been shipping > with inbound "default deny" since XP SP2 or so. How many years ago was that? > And what *real* security over and above that host-based firewall are you > getting from that appliance? > > Or as Dr Phil would say "FIrewalls - how is that working out for you?" Do you have actual honest-to-ghod numbers, Valdis? And aren't you making here the same assumption for which we chastise people who run DNS resolvers that wildcard to advertising pages for NXDOMAIN: That all the world's a workstation? 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 Tue Nov 15 15:10:32 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 15 Nov 2011 16:10:32 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: Message-ID: <30335127.2913.1321391432299.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > If your firewall is not working, it should not be passing packets. Yes; your arguments all seem to depend on that property being true. But we call it a *failure* for a reason, Owen. What the probability is of a firewall failing in such a fashion as to *stop filtering, but still pass packets* depends -- as you have pointed out -- entirely on its design. As *I* have pointed out, not all firewalls are created equal, and there are a helluva a lot of them out there for which this desirable property *simply is not true*. Sticking your head in the sand on this point is not especially productive. 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 Tue Nov 15 15:16:12 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 15 Nov 2011 16:16:12 -0500 (EST) Subject: Have they stopped teaching Defense in Depth? In-Reply-To: Message-ID: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Herrin" > That your computer is not globally addressable ADDS one layer of > security in a process you hope has enough layers to prevent an attack > from penetrating. > > And make no mistake: successful security is about layers, about DEPTH. > You can seek layers from other sources but a shallow security process > will tend to be easily breached. This is precisely the point I've been trying to make, and it ties in to my observations in response in the SCADA thread: not only does the number of layers matter, so does their "thickness". Certainly, if you're trying to "air-gap" a SCADA network to protect it from attack, then you are admitting a certain degree of vulnerability if your circuit passes through any sort of transport multiplexer, like a DACS, as that's a place an attacker could reconfigure to take control of your traffic. But mounting *that* attack requires insider knowledge of 4 or 5 layers of extra information which will be necessary to exploit such an attack. My estimation is that that makes that layer of your defense in depth "thicker" than some other layers might be. Those who think NAT provides no security seem still to be mounting the strawman that we think it *provides* security, rather than merely contributing some bits thereto... 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 Tue Nov 15 15:19:29 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 15 Nov 2011 16:19:29 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: <201111151754.pAFHsk4t094745@aurora.sol.net> Message-ID: <3759251.2917.1321391969507.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Greco" > And some products, say like FreeBSD (which forms the heart of things > like pfSense, so let's not even begin to argue that it "isn't a > firewall") can actually be configured to default either way. By Owen's definition, it's not. > So basically, while we would all prefer that firewalls default to deny, > it probably isn't as important a distinction as this thread is making > it out to be, because even a "default to deny" firewall fails when a > naive admin makes a typo and allows all traffic from 0/0 > inadvertently. It's just a matter of statistical likelihood. > > Or perhaps a better argument would be that routers really ought to > default to deny. :-) I'd be fine with that, but I can hear the > screaming already. But you're missing an important point here, Joe: we're not talking about default configuration... we're talking about *failure modes*, which are by definition unpredictable. All you can really do there is figure the probabilities... and the probability is that a *router-based* firewall (which as you and I agree, is a helluva lot of firewalls) will *be more likely* to fail into pass traffic mode than into don't pass traffic mode. 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 Tue Nov 15 15:23:04 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 15 Nov 2011 16:23:04 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: <69ACE97A-D95A-4FE1-99DF-A4D88EFA016B@delong.com> Message-ID: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > >> If your firewall is not working, it should not be passing packets. > > > > And of course, things always fail just the way we want them to. > > Your stateful firewall is no more likely to fail open than your > header-mutilating device. Please show your 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 owen at delong.com Tue Nov 15 15:45:11 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Nov 2011 16:45:11 -0500 Subject: Arguing against using public IP space In-Reply-To: <30335127.2913.1321391432299.JavaMail.root@benjamin.baylink.com> References: <30335127.2913.1321391432299.JavaMail.root@benjamin.baylink.com> Message-ID: Sent from my iPad On Nov 15, 2011, at 4:10 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> If your firewall is not working, it should not be passing packets. > > Yes; your arguments all seem to depend on that property being true. > > But we call it a *failure* for a reason, Owen. If your firewall has failed to such an extent, all bets are off about what it does or does not pas regardless of whether or not it mutilates the headers. > > What the probability is of a firewall failing in such a fashion as to *stop > filtering, but still pass packets* depends -- as you have pointed out -- > entirely on its design. > > As *I* have pointed out, not all firewalls are created equal, and there are > a helluva a lot of them out there for which this desirable property *simply > is not true*. Then I would, by definition call them routers, not firewalls. > > Sticking your head in the sand on this point is not especially productive. I'm not sticking my head in the sand about anything. I am pointing out that mutilating the packet header only reduces security. It does not improve it. Owen From marka at isc.org Tue Nov 15 15:50:55 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 16 Nov 2011 08:50:55 +1100 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: Your message of "Tue, 15 Nov 2011 16:16:12 CDT." <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> References: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> Message-ID: <20111115215055.72C851737568@drugs.dv.isc.org> In message <33284158.2915.1321391772464.JavaMail.root at benjamin.baylink.com>, Jay Ashworth write s: > ----- Original Message ----- > > From: "William Herrin" > > > That your computer is not globally addressable ADDS one layer of > > security in a process you hope has enough layers to prevent an attack > > from penetrating. > > > > And make no mistake: successful security is about layers, about DEPTH. > > You can seek layers from other sources but a shallow security process > > will tend to be easily breached. > > This is precisely the point I've been trying to make, and it ties in to my > observations in response in the SCADA thread: not only does the number of > layers matter, so does their "thickness". Certainly, if you're trying to > "air-gap" a SCADA network to protect it from attack, then you are admitting > a certain degree of vulnerability if your circuit passes through any sort of > transport multiplexer, like a DACS, as that's a place an attacker could > reconfigure to take control of your traffic. > > But mounting *that* attack requires insider knowledge of 4 or 5 layers of > extra information which will be necessary to exploit such an attack. > > My estimation is that that makes that layer of your defense in depth "thicker" > than some other layers might be. > > Those who think NAT provides no security seem still to be mounting the strawman > that we think it *provides* security, rather than merely contributing some bits > thereto... Most of us actually think that what ever benefit it adds over a firewall is miniscule compared to its negative consequences and once the cost benefit analysis is done that it is not worth it. Remember the cost of NAT is not solely borne by the entity deploying the NAT. If it was there would be little debate here. The cost of you deploying NAT is borne by everyone of us. It add a little bit to the cost of every router. If you want to use unroutable addresses then use a bastion host / proxy. Don't expect to be able to open a TCP socket and have it connect to something on the outside. Do it right or don't do it at all. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bill at herrin.us Tue Nov 15 16:01:09 2011 From: bill at herrin.us (William Herrin) Date: Tue, 15 Nov 2011 17:01:09 -0500 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: <20111115215055.72C851737568@drugs.dv.isc.org> References: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> <20111115215055.72C851737568@drugs.dv.isc.org> Message-ID: On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews wrote: > If you want to use unroutable addresses then use a bastion host / > proxy. ?Don't expect to be able to open a TCP socket and have it > connect to something on the outside. ?Do it right or don't do it > at all. Mark, What is a modern NAT but a bastion host proxy for which application compatibility has been maximized? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jgreco at ns.sol.net Tue Nov 15 16:13:32 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 15 Nov 2011 16:13:32 -0600 (CST) Subject: Arguing against using public IP space In-Reply-To: <3759251.2917.1321391969507.JavaMail.root@benjamin.baylink.com> Message-ID: <201111152213.pAFMDWZh097519@aurora.sol.net> > ----- Original Message ----- > > From: "Joe Greco" > > > And some products, say like FreeBSD (which forms the heart of things > > like pfSense, so let's not even begin to argue that it "isn't a > > firewall") can actually be configured to default either way. > > By Owen's definition, it's not. Then Owen's definition is wrong, because the vast majority of "firewall" devices out there are software-based devices. > > So basically, while we would all prefer that firewalls default to deny, > > it probably isn't as important a distinction as this thread is making > > it out to be, because even a "default to deny" firewall fails when a > > naive admin makes a typo and allows all traffic from 0/0 > > inadvertently. It's just a matter of statistical likelihood. > > > > Or perhaps a better argument would be that routers really ought to > > default to deny. :-) I'd be fine with that, but I can hear the > > screaming already. > > But you're missing an important point here, Joe: we're not talking about > default configuration... we're talking about *failure modes*, which are by > definition unpredictable. But I'm *not* missing the point. You missed mine. The fact of the matter is that routers don't come with firewall-by-default, we've failed to find ways to make it easier for people to firewall things properly than it is to open the gates. Or even notice that their gates are wide open. That's a problem. > All you can really do there is figure the probabilities... and the probability > is that a *router-based* firewall (which as you and I agree, is a helluva lot > of firewalls) will *be more likely* to fail into pass traffic mode than into > don't pass traffic mode. That depends on too many factors to really be able to make that call. On the equally cutting side for NAT proponents, there are some attacks against NAT devices that often succeed that shouldn't. I'm not trying to defend the firewall thing. That discussion is boring and dull, it's about the state of one bit, as I pointed out, which is the NANOG equivalent of how many angels can dance on the head of a pin. I was merely taking what seemed to be a good opportunity to point out that there's a more abstract failing here, which is that we have failed to make it easy to firewall by default. I don't mean "default to blocking packets." I mean that we've failed to make it easy for router owners to do abstract things like say "this network's a bunch of clients, and should be statefully firewalled for outbound connections only" and make it as easy (or easier) to do that than it is to open the connection wide open. Failing to put roadblocks in place where you could have roadblocks makes a network easier to penetrate. But I think I've made my point. The obvious, real, clear problem with many SCADA networks is that they're built out of garbage, with garbage software stacks, with no apparent thought given to security. On the Internet, we've typically dealt with that sort of stuff by beating it senseless (open SMTP relay, etc) and then replacing it. Adding layers to protect the "soft gooey center", as someone put it, helps, of course, but is only a band-aid solution. Who here would go passwordless on their OOB management network? ... 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 tayeb.meftah at gmail.com Mon Nov 14 14:51:07 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Mon, 14 Nov 2011 22:51:07 +0200 Subject: OpenSource IPTV and VoD Solution Message-ID: Hello Guys i'm looking for a solution to stream diferent DVB transponders through RTSP VLC look like complicated a bit i use MumuDVB for Multicasting but i didn't found anything for RTSP any help Would by welcome thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (20111115) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From galu at packetdam.com Tue Nov 15 17:28:42 2011 From: galu at packetdam.com (Vlad Galu) Date: Tue, 15 Nov 2011 23:28:42 +0000 Subject: OpenSource IPTV and VoD Solution In-Reply-To: References: Message-ID: <5435AB89-62D4-425B-BAB2-BC0FAE7604BB@packetdam.com> Have a look at RTMPD [1]. Although it is mainly RTMP, it supports RTSP. [1] http://www.rtmpd.com On Nov 14, 2011, at 8:51 PM, Meftah Tayeb wrote: > Hello Guys > i'm looking for a solution to stream diferent DVB transponders through RTSP > VLC look like complicated a bit > i use MumuDVB for Multicasting > but i didn't found anything for RTSP > any help Would by welcome > thank you > Meftah Tayeb > IT Consulting > http://www.tmvoip.com/ > phone: +21321656139 > Mobile: +213660347746 > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (20111115) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com From tayeb.meftah at gmail.com Mon Nov 14 16:25:18 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Tue, 15 Nov 2011 00:25:18 +0200 Subject: OpenSource IPTV and VoD Solution References: <5435AB89-62D4-425B-BAB2-BC0FAE7604BB@packetdam.com> Message-ID: <7D02F35711B04FE8AEE7FEAB3B127C08@work> thank you for that is a rtsp server no problem but how do i stream Live DVB traffic through it ? Thank you ----- Original Message ----- From: "Vlad Galu" To: "Meftah Tayeb" Cc: Sent: Wednesday, November 16, 2011 1:28 AM Subject: Re: OpenSource IPTV and VoD Solution Have a look at RTMPD [1]. Although it is mainly RTMP, it supports RTSP. [1] http://www.rtmpd.com On Nov 14, 2011, at 8:51 PM, Meftah Tayeb wrote: > Hello Guys > i'm looking for a solution to stream diferent DVB transponders through > RTSP > VLC look like complicated a bit > i use MumuDVB for Multicasting > but i didn't found anything for RTSP > any help Would by welcome > thank you > Meftah Tayeb > IT Consulting > http://www.tmvoip.com/ > phone: +21321656139 > Mobile: +213660347746 > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6633 (20111115) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (20111115) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (20111115) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From marka at isc.org Tue Nov 15 19:20:29 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 16 Nov 2011 12:20:29 +1100 Subject: Arguing against using public IP space In-Reply-To: Your message of "Tue, 15 Nov 2011 16:23:04 CDT." <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com> References: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com> Message-ID: <20111116012029.66D99173B09C@drugs.dv.isc.org> In message <29838609.2919.1321392184239.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > > >> If your firewall is not working, it should not be passing packets. > > > > > > And of course, things always fail just the way we want them to. > > > > Your stateful firewall is no more likely to fail open than your > > header-mutilating device. > > Please show your work. Prove to me that all NAT won't pass packets not addressed directly to it. Show your work. You are making assumptions about how the NAT is designed. Many NATs only take packets addressed to particular address ranges and process them though the state tables. All the rest of the packets are treated as normal traffic which may or may not be forwarded depending apon the way the base platform is configured which is usually as a router. Many NAT's will honour LSR. Unless you know the internals of a NAT you cannot say whether it fails open or closed. Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit but if it is a targeted attack then yes you can expect to see LSR based attacks which depending apon how the NAT is built may pass through it without even being noticed. Now can we put to bed that NAT provides any real security. If you want security add and configure a firewall. That firewall can be in the same box as the NAT. It can use the same state tables as the NAT but it is the firewall, not the NAT functionality, that provides the protection. Mark > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI > I > St Petersburg FL USA http://photo.imageinc.us +1 727 647 127 > 4 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From kauer at biplane.com.au Tue Nov 15 20:07:56 2011 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 16 Nov 2011 13:07:56 +1100 Subject: Arguing against using public IP space In-Reply-To: <20111116012029.66D99173B09C@drugs.dv.isc.org> References: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com> <20111116012029.66D99173B09C@drugs.dv.isc.org> Message-ID: <1321409276.2514.251.camel@karl> On Wed, 2011-11-16 at 12:20 +1100, Mark Andrews wrote: > You are making assumptions about how the NAT is designed. > [...] > Unless you know the internals of a NAT you cannot say whether it > fails open or closed. Indeed not! From 2010, during an identical discussion: http://seclists.org/nanog/2010/Apr/1166 To me, "fail" means that a system stops doing what it was designed to do. The results are by definition undefined. Others seem to think that "fail" means a kind of default. > it is actually feasible to probe through a NAT using LSR. What's LSR in this context? Loose source routing, I'm guessing. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- 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 bill at herrin.us Tue Nov 15 20:44:20 2011 From: bill at herrin.us (William Herrin) Date: Tue, 15 Nov 2011 21:44:20 -0500 Subject: Arguing against using public IP space In-Reply-To: <20111116012029.66D99173B09C@drugs.dv.isc.org> References: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com> <20111116012029.66D99173B09C@drugs.dv.isc.org> Message-ID: On Tue, Nov 15, 2011 at 8:20 PM, Mark Andrews wrote: > Given that most NATs only use a small set of address on the inside > it is actually feasible to probe through a NAT using LSR. > Most attacks don't do this as there are lots of lower hanging fruit Mark, My car can be slim-jimmed. Yet the lock is sufficiently operative in the security process that the two times the vehicle has been broken in to the vagrant put a rock through the window instead of jimmying the lock. That's what it MEANS when you say that there's lower hanging fruit to be found elsewhere. It means that the feature you're describing is operative in the process of obstructing an attacker. As an aside to the debate, I boldly suggest that any firewall vendor which actually implements LSR or any of the IP source route functionality anywhere in their code deserves to be tarred and feathered. The security implications of source routing have been long understood. Code which implements source routing has no business existing in a commercial firewall product where it could accidentally be called. Please, by all means, take this opportunity to out any such errors which you can document. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From marka at isc.org Tue Nov 15 21:07:19 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 16 Nov 2011 14:07:19 +1100 Subject: Arguing against using public IP space In-Reply-To: Your message of "Tue, 15 Nov 2011 21:44:20 CDT." References: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com> <20111116012029.66D99173B09C@drugs.dv.isc.org> Message-ID: <20111116030719.93485173BD2E@drugs.dv.isc.org> In message , William Herrin writes: > On Tue, Nov 15, 2011 at 8:20 PM, Mark Andrews wrote: > > Given that most NATs only use a small set of address on the inside > > it is actually feasible to probe through a NAT using LSR. > > Most attacks don't do this as there are lots of lower hanging fruit > > Mark, > > My car can be slim-jimmed. Yet the lock is sufficiently operative in > the security process that the two times the vehicle has been broken in > to the vagrant put a rock through the window instead of jimmying the > lock. > > That's what it MEANS when you say that there's lower hanging fruit to > be found elsewhere. It means that the feature you're describing is > operative in the process of obstructing an attacker. > > As an aside to the debate, I boldly suggest that any firewall vendor > which actually implements LSR or any of the IP source route > functionality anywhere in their code deserves to be tarred and > feathered. The security implications of source routing have been long > understood. Code which implements source routing has no business > existing in a commercial firewall product where it could accidentally > be called. Please, by all means, take this opportunity to out any such > errors which you can document. Indeed. A NAT mangles packets. A firewall provides protection. You can combine the two but expecting one to do the job of the other is just wrong and doesn't work. > Regards, > Bill Herrin > > > --=20 > William D. Herrin ................ herrin at dirtside.com=A0 bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Tue Nov 15 21:08:29 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 15 Nov 2011 22:08:29 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: <20111116012029.66D99173B09C@drugs.dv.isc.org> Message-ID: <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" > In message > <29838609.2919.1321392184239.JavaMail.root at benjamin.baylink.com>, Ja > y Ashworth writes: > > > >> If your firewall is not working, it should not be passing > > > >> packets. > > > > > > > > And of course, things always fail just the way we want them to. > > > > > > Your stateful firewall is no more likely to fail open than your > > > header-mutilating device. > > > > Please show your work. > > Prove to me that all NAT won't pass packets not addressed directly > to it. Show your work. I did not *assert* that. So I don't have to prove that. What I *asserted* was that inbound 1:N DNAT *reduces the probability of an attacker being able to target a specific inbound attack to a specific computer*. QED. > You are making assumptions about how the NAT is designed. Many > NATs only take packets addressed to particular address ranges and > process them though the state tables. All the rest of the packets > are treated as normal traffic which may or may not be forwarded > depending apon the way the base platform is configured which is > usually as a router. Many NAT's will honour LSR. As someone pointed out elsewhere, that's bad, but it's bad whether the box does NAT or not; even if the internal network is unrouted public space, that would be troublesome. > Unless you know the internals of a NAT you cannot say whether it > fails open or closed. It's probably impossible to determine whether any box's response to any failure will be pass or drop, with any reliability. All you can figure is probabilities. > Given that most NATs only use a small set of address on the inside > it is actually feasible to probe through a NAT using LSR. Most > attacks don't do this as there are lots of lower hanging fruit but > if it is a targeted attack then yes you can expect to see LSR based > attacks which depending apon how the NAT is built may pass through > it without even being noticed. Someone else has already addressed "low-hanging fruit", so I won't. I do concur, though: if you have specific examples of boxes which, as you allege, respect LSR to 1918 internal addresses, please, name and shame. > Now can we put to bed that NAT provides any real security. If you > want security add and configure a firewall. That firewall can be > in the same box as the NAT. It can use the same state tables as > the NAT but it is the firewall, not the NAT functionality, that > provides the protection. Nope; I'm afraid we still can't. As long as you continue to strawman that I/we are even *alleging* that NAT "provides" security (rather than "contributing" to it, we're just going to keep talking past each other, Mark. As long as you keep defining protection as "one thing in one place", I'll keep assuming you're flapping your jaws to dry your teeth. ("provides *the* protection") 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 marka at isc.org Tue Nov 15 22:54:15 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 16 Nov 2011 15:54:15 +1100 Subject: Arguing against using public IP space In-Reply-To: Your message of "Tue, 15 Nov 2011 22:08:29 CDT." <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com> References: <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com> Message-ID: <20111116045415.960C4173C5E3@drugs.dv.isc.org> In message <28327223.2951.1321412909463.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Mark Andrews" > > > In message > > <29838609.2919.1321392184239.JavaMail.root at benjamin.baylink.com>, Ja > > y Ashworth writes: > > > > >> If your firewall is not working, it should not be passing > > > > >> packets. > > > > > > > > > > And of course, things always fail just the way we want them to. > > > > > > > > Your stateful firewall is no more likely to fail open than your > > > > header-mutilating device. > > > > > > Please show your work. > > > > Prove to me that all NAT won't pass packets not addressed directly > > to it. Show your work. > > I did not *assert* that. So I don't have to prove that. > > What I *asserted* was that inbound 1:N DNAT *reduces the probability of > an attacker being able to target a specific inbound attack to a specific > computer*. QED. > > > You are making assumptions about how the NAT is designed. Many > > NATs only take packets addressed to particular address ranges and > > process them though the state tables. All the rest of the packets > > are treated as normal traffic which may or may not be forwarded > > depending apon the way the base platform is configured which is > > usually as a router. Many NAT's will honour LSR. > > As someone pointed out elsewhere, that's bad, but it's bad whether the box > does NAT or not; even if the internal network is unrouted public space, > that would be troublesome. Actually LSR is not bad in and of itself. The actual problem was badly designed firewall code that failed properly examine the LSR option. Rather than fix the firewall code people choose to drop packets with LSR options. > > Unless you know the internals of a NAT you cannot say whether it > > fails open or closed. > > It's probably impossible to determine whether any box's response to > any failure will be pass or drop, with any reliability. All you can > figure is probabilities. > > > Given that most NATs only use a small set of address on the inside > > it is actually feasible to probe through a NAT using LSR. Most > > attacks don't do this as there are lots of lower hanging fruit but > > if it is a targeted attack then yes you can expect to see LSR based > > attacks which depending apon how the NAT is built may pass through > > it without even being noticed. > > Someone else has already addressed "low-hanging fruit", so I won't. I do > concur, though: if you have specific examples of boxes which, as you allege, > respect LSR to 1918 internal addresses, please, name and shame. Why do they need to be "named and shamed"? They are NOT firewalls. It is not their job to block LSR traffic. The fact that you think NATs should be doing this is yet another indication that you don't understand the difference between a NAT and a firewall. > > Now can we put to bed that NAT provides any real security. If you > > want security add and configure a firewall. That firewall can be > > in the same box as the NAT. It can use the same state tables as > > the NAT but it is the firewall, not the NAT functionality, that > > provides the protection. > > Nope; I'm afraid we still can't. As long as you continue to strawman that > I/we are even *alleging* that NAT "provides" security (rather than > "contributing" to it, we're just going to keep talking past each other, Mark. > > As long as you keep defining protection as "one thing in one place", I'll > keep assuming you're flapping your jaws to dry your teeth. ("provides *the* > protection") > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI > I > St Petersburg FL USA http://photo.imageinc.us +1 727 647 127 > 4 > -- 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 Nov 15 23:18:04 2011 From: galu at packetdam.com (Vlad Galu) Date: Wed, 16 Nov 2011 05:18:04 +0000 Subject: OpenSource IPTV and VoD Solution In-Reply-To: <7D02F35711B04FE8AEE7FEAB3B127C08@work> References: <5435AB89-62D4-425B-BAB2-BC0FAE7604BB@packetdam.com> <7D02F35711B04FE8AEE7FEAB3B127C08@work> Message-ID: <524AFED3-C49A-417D-996A-5A9579421608@packetdam.com> On Nov 14, 2011, at 10:25 PM, Meftah Tayeb wrote: > thank you for that > is a rtsp server no problem > but how do i stream Live DVB traffic through it ? > Thank you > To be honest I haven't followed its development closely lately (although I contribute occasionally with networking related patches and improvements) so I can't answer that, but you should be able to send your stream to RTMPD using either MumuDVB or VLC, then demux it to as many (hundreds or even thousands, it is *that* good) clients as you need. I should have pointed you to the wiki [1] and the mailing list [2], sorry. HTH. [1] http://wiki.rtmpd.com/ [2] http://groups.google.com/group/c-rtmp-server?pli=1 -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com From lorell at hathcock.org Tue Nov 15 23:21:05 2011 From: lorell at hathcock.org (Lorell Hathcock) Date: Tue, 15 Nov 2011 23:21:05 -0600 Subject: FW: Savvis broken link / underperforming between DC and Atlanta? Message-ID: <000001cca41f$8a912050$9fb360f0$@hathcock.org> All: I did not see a reply to this. Anyone else having a problem on this link? Lorell From: Lorell Hathcock [mailto:lorell at hathcock.org] Sent: Friday, November 11, 2011 9:10 AM To: nanog at nanog.org Subject: Savvis broken link / underperforming between DC and Atlanta? Any one else seeing this? This was done yesterday from Hawaii. tracert speedtest.saas.infor.com 3 5 ms 5 ms 4 ms ip64-75-240-210.aloha.net [64.75.240.210] 4 5 ms 5 ms 5 ms hnl-edge-02.inet.qwest.net [67.129.94.69] 5 * * * Request timed out. 6 56 ms 56 ms 56 ms 63-235-40-18.dia.static.qwest.net [63.235.40.18] 7 58 ms 58 ms 59 ms cr1-tenge-0-3-5-0.sanfrancisco.savvis.net [204.70.200.198] 8 138 ms 138 ms 138 ms cr1-bundle-pos2.Washington.savvis.net [204.70.200.90] 9 135 ms 136 ms 136 ms hr1-tengig-2-0-0.sterling2dc2.savvis.net [204.70.197.74] 10 139 ms 136 ms 137 ms 165.193.78.106 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. But from Houston it was fine yesterday. It took a different route. Today I have the same problem from Houston. tracert speedtest.saas.infor.com 4 2 ms 2 ms 2 ms te4-1.3509.ccr01.iah02.atlas.cogentco.com [66.28.6.21] 5 3 ms 2 ms 2 ms te0-2-0-4.ccr21.iah01.atlas.cogentco.com [154.54.3.149] 6 9 ms 10 ms 8 ms te0-1-0-5.ccr21.dfw01.atlas.cogentco.com [154.54.2.225] 7 8 ms 8 ms 8 ms te7-3.mpd01.dfw03.atlas.cogentco.com [154.54.6.66] 8 15 ms 8 ms 12 ms aer1-ge-4-2.dallasequinix.savvis.net [208.175.175.5] 9 17 ms 8 ms 15 ms 204.70.207.182 10 10 ms 9 ms 10 ms cr1-tengig0-7-5-0.Dallas.savvis.net [204.70.200.170] 11 37 ms 37 ms 37 ms cr1-tengig-0-7-0-0.Washington.savvis.net [204.70.196.105] 12 36 ms 36 ms 36 ms hr1-tengig-2-0-0.sterling2dc2.savvis.net [204.70.197.74] 13 37 ms 36 ms 37 ms 165.193.78.106 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. This the end IP address is in Rackspace in Atlanta I am told. Known issues out there? Any de-peering going on? Or is this just a firewall or private IP space that is not responding to traceroute information requests? Thanks for any help, Lorell Hathcock From aservin at lacnic.net Tue Nov 15 23:33:46 2011 From: aservin at lacnic.net (Arturo Servin) Date: Wed, 16 Nov 2011 13:33:46 +0800 Subject: Minimum Allocation Size by RIRs (IPv4) In-Reply-To: References: <4EC27DB7.4000800@init7.net> Message-ID: <7EBFADB7-8607-4673-8298-8312A7B0F63F@lacnic.net> /24 as minimal allocation is only for end-users and critical infrastructure. For ISPs (LIRs) the minimal allocation is /22. /as On 16 Nov 2011, at 00:30, Rubens Kuhl wrote: > LACNIC: /24 - http://lacnic.net/en/politicas/manual3.html From christopher.morrow at gmail.com Tue Nov 15 23:58:47 2011 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 16 Nov 2011 00:58:47 -0500 Subject: Question about operational concerns with Routing Protocol Security Message-ID: Howdy, while enjoying some (oddly not controversial) meeting time at the IETF, one of the presenters (Sam Hartman[1]) noted he's looking for some people to chat with with respect to 'deployment scenarios' surrounding network gear and protocol security. Today that probably takes the form of things like: "Hey, be sure to copy the password into the config before turning up the interfaces!" I can imagine other methods as well, for things like: eBGP iBGP ISIS OSPF would any of the folks on-list that currently have key material (passwords and such) configured for these protocols AND who also deploy new gear into the field be willing to chat some with Sam? (Note, you don't have to tell Sam your passwds/keys, and you don't have to tell anyone else that the passwd is 'chocolate' either...) Thanks! -Chris (also, note that I copied in at least one of Sam's emails, maybe this one won't get too filtered...) [1]: The draft Sam could use some advice on: From guxiaojian at gmail.com Wed Nov 16 00:18:58 2011 From: guxiaojian at gmail.com (Jian Gu) Date: Tue, 15 Nov 2011 22:18:58 -0800 Subject: Foundry MRP cohabit with STP In-Reply-To: <8538341.86454.1321349440970.JavaMail.root@FRM001P08ASU.itc.integra.fr> References: <22933488.86198.1321348355390.JavaMail.root@FRM001P08ASU.itc.integra.fr> <8538341.86454.1321349440970.JavaMail.root@FRM001P08ASU.itc.integra.fr> Message-ID: MRP and STP are configured under VLAN, same physical interface tagged with different VLANs can participate both MRP and STP in different VLAN, if you are asking MRP and STP under the same VLAN, that is not a valid configuration, think about it, what if MRP wants to block an interface but STP wants the same interface to forward traffic? On Tue, Nov 15, 2011 at 1:30 AM, Viet-Hung Ton wrote: > Hi, > > > We are deploying a network using MRP of Foundry (Metro Ring Protocol of Brocade now) and STP (in this case Rapid Spanning Tree Protocol-802.1W). The problem is that in some networking segment, we must enable both of protocols in the same interfaces and vlans for the correct function of our network. By the way, as MRP and STP are 2 protocols of loop prevention, the devices of Brocade force us choosing and activating just one among them that not our intention. > > > Anybody has the same situation of some experiences in this case: how to make coexist these two protocols. (MRP and STP). > > Best thanks, > > > Viet Ton. > > > > > From mtinka at globaltransit.net Wed Nov 16 01:43:14 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Wed, 16 Nov 2011 15:43:14 +0800 Subject: AS9929 - Anyone with Clue Message-ID: <201111161543.14308.mtinka@globaltransit.net> Hi all. If there's anyone on here from AS9929 (Chine Netcom) with some clue, kindly ping me off-list. Thanks. Cheers, 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 quentin.carpent at vtx-telecom.ch Wed Nov 16 01:58:32 2011 From: quentin.carpent at vtx-telecom.ch (Quentin Carpent) Date: Wed, 16 Nov 2011 08:58:32 +0100 Subject: OpenSource IPTV and VoD Solution In-Reply-To: <524AFED3-C49A-417D-996A-5A9579421608@packetdam.com> References: <5435AB89-62D4-425B-BAB2-BC0FAE7604BB@packetdam.com> <7D02F35711B04FE8AEE7FEAB3B127C08@work> <524AFED3-C49A-417D-996A-5A9579421608@packetdam.com> Message-ID: <07C3015B9E21F949AB59B28F2D5B567F0733B489@exch-pul-01.interne.smart-telecom.ch> Hi, I don't know if it meets your requirements but there is DVBlast: http://www.videolan.org/projects/dvblast.html BRs, Quentin?Carpent Network Engineer -----Message d'origine----- De?: Vlad Galu [mailto:galu at packetdam.com] Envoy??: mercredi 16 novembre 2011 06:18 ??: Meftah Tayeb Cc?: nanog at nanog.org Objet?: Re: OpenSource IPTV and VoD Solution On Nov 14, 2011, at 10:25 PM, Meftah Tayeb wrote: > thank you for that > is a rtsp server no problem > but how do i stream Live DVB traffic through it ? > Thank you > To be honest I haven't followed its development closely lately (although I contribute occasionally with networking related patches and improvements) so I can't answer that, but you should be able to send your stream to RTMPD using either MumuDVB or VLC, then demux it to as many (hundreds or even thousands, it is *that* good) clients as you need. I should have pointed you to the wiki [1] and the mailing list [2], sorry. HTH. [1] http://wiki.rtmpd.com/ [2] http://groups.google.com/group/c-rtmp-server?pli=1 -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com From tayeb.meftah at gmail.com Wed Nov 16 03:01:10 2011 From: tayeb.meftah at gmail.com (Tayeb Meftah) Date: Wed, 16 Nov 2011 10:01:10 +0100 Subject: OpenSource IPTV and VoD Solution In-Reply-To: <07C3015B9E21F949AB59B28F2D5B567F0733B489@exch-pul-01.interne.smart-telecom.ch> References: <5435AB89-62D4-425B-BAB2-BC0FAE7604BB@packetdam.com> <7D02F35711B04FE8AEE7FEAB3B127C08@work> <524AFED3-C49A-417D-996A-5A9579421608@packetdam.com> <07C3015B9E21F949AB59B28F2D5B567F0733B489@exch-pul-01.interne.smart-telecom.ch> Message-ID: <7148540074646496230@unknownmsgid> Thx But no rtsp Thx Envoy? de mon iPhone Le 16 nov. 2011 ? 08:58, Quentin Carpent a ?crit : > Hi, > > I don't know if it meets your requirements but there is DVBlast: http://www.videolan.org/projects/dvblast.html > > BRs, > > Quentin Carpent > Network Engineer > > -----Message d'origine----- > De : Vlad Galu [mailto:galu at packetdam.com] > Envoy? : mercredi 16 novembre 2011 06:18 > ? : Meftah Tayeb > Cc : nanog at nanog.org > Objet : Re: OpenSource IPTV and VoD Solution > > > On Nov 14, 2011, at 10:25 PM, Meftah Tayeb wrote: > >> thank you for that >> is a rtsp server no problem >> but how do i stream Live DVB traffic through it ? >> Thank you >> > > To be honest I haven't followed its development closely lately (although I contribute occasionally with networking related patches and improvements) so I can't answer that, but you should be able to send your stream to RTMPD using either MumuDVB or VLC, then demux it to as many (hundreds or even thousands, it is *that* good) clients as you need. > > I should have pointed you to the wiki [1] and the mailing list [2], sorry. > > HTH. > > [1] http://wiki.rtmpd.com/ > [2] http://groups.google.com/group/c-rtmp-server?pli=1 > > -- > PacketDam: a cost-effective > software solution against DDoS > http://www.packetdam.com > > > > > From mysidia at gmail.com Wed Nov 16 07:21:11 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 16 Nov 2011 07:21:11 -0600 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> References: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Nov 15, 2011 at 3:16 PM, Jay Ashworth wrote: >> You can seek layers from other sources but a shallow security process >> will tend to be easily breached. > But mounting *that* attack requires insider knowledge of 4 or 5 layers of > extra information which will be necessary to exploit such an attack. > > My estimation is that that makes that layer of your defense in depth "thicker" > than some other layers might be. Security in depth is a proper approach, but NAT is not a security control, and NAT does not make the firewall defense "thicker" The maginot line was "thick". Before you can properly consider your layers of defense to have a certain thickness, you have to consider types of attack, and whether your changes actually make the layers they defeat any thicker. Now... what would you say is the most common way of defeating a properly implemented firewall? (1) The attack follows _allowed_ paths through the firewall, for example, the attack comes through a port forward that has been configured on the firewall with an ACL that is open too wide. Or, the attack is against a legitimate user's outbound connection, for example: a user behind the firewall connects to a web site, a vulnerability in their browser is exploited to install a trojan -- the trojan tunnels to the attacker over an outgoing port that is allowed on the firewall. And (2) The intruder compromises the firewall and gains control of it. In the case of (1), NAT does not add any "thickness" to the security model, the workstation behind the firewall has full knowledge of its own private IP addressing. The only way you will use NAT to effectively hide information is if the compromised machine is not privvy to the IP network addressing of the sensitive resources. In the case of (2), NAT does not add any thickness to the security model, because the attacker gains knowledge of the Firewall's entire configuration. This is a reason a network with truly sensitive resources where integrity is the greatest security objective should often have multiple separate Firewall units made by different manufacturers administered independently by different groups of security admins; an outer firewall in between the Internet and the DMZ, a second firewall in between the DMZ and the Internal network, and a third firewall in between the Internal network and say the SCADA control network. -- -JH From jra at baylink.com Wed Nov 16 07:36:21 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 16 Nov 2011 08:36:21 -0500 (EST) Subject: Have they stopped teaching Defense in Depth? In-Reply-To: Message-ID: <14755259.2999.1321450581722.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > Or, the attack is against a legitimate user's outbound connection, for example: > a user behind the firewall connects to a web site, a vulnerability > in their browser is exploited > to install a trojan -- the trojan tunnels to the attacker over an > outgoing port that is allowed on the firewall. Oh, certainly; I have lots of web browsers running on my servers. All The World Is Not A Workstation, guys. 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 leigh.porter at ukbroadband.com Wed Nov 16 07:46:16 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 16 Nov 2011 13:46:16 +0000 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: <14755259.2999.1321450581722.JavaMail.root@benjamin.baylink.com> References: <14755259.2999.1321450581722.JavaMail.root@benjamin.baylink.com> Message-ID: > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: 16 November 2011 13:38 > To: NANOG > Subject: Re: Have they stopped teaching Defense in Depth? > > ----- Original Message ----- > > From: "Jimmy Hess" > > > Or, the attack is against a legitimate user's outbound connection, > for example: > > a user behind the firewall connects to a web site, a vulnerability > > in their browser is exploited > > to install a trojan -- the trojan tunnels to the attacker over an > > outgoing port that is allowed on the firewall. > > Oh, certainly; I have lots of web browsers running on my servers. > > All The World Is Not A Workstation, guys. I think the point is that you access your servers from your work station and so if the workstation you use to access the network is compromised then your whole network is potentially compromised. -- Leigh ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From Valdis.Kletnieks at vt.edu Wed Nov 16 08:01:56 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 16 Nov 2011 09:01:56 -0500 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: Your message of "Wed, 16 Nov 2011 08:36:21 EST." <14755259.2999.1321450581722.JavaMail.root@benjamin.baylink.com> References: <14755259.2999.1321450581722.JavaMail.root@benjamin.baylink.com> Message-ID: <22374.1321452116@turing-police.cc.vt.edu> On Wed, 16 Nov 2011 08:36:21 EST, Jay Ashworth said: > ----- Original Message ----- > > From: "Jimmy Hess" > > > Or, the attack is against a legitimate user's outbound connection, for example: > > a user behind the firewall connects to a web site, a vulnerability > > in their browser is exploited > > to install a trojan -- the trojan tunnels to the attacker over an > > outgoing port that is allowed on the firewall. > > Oh, certainly; I have lots of web browsers running on my servers. > > All The World Is Not A Workstation, guys. Is there *anything* on the allegedly protected subnet that has a web browser running on it? Maybe that laptop on the crash cart that you use for downloading firmware and installing it on storage appliances? If it's a corporate-sized NAT, do you have any desktops that have network reachability to the servers (probably do - if the desktops can't reach the servers, the servers aren't useful are they?) and also have web browsers that go to the outside world? I compromise an ad server someplace. Bob over in Accounting visits the CPA forum on the accountants-r-us.com website looking for suggestion on how to handle a tax issue. I now have control of Bob's workstation, and the question of whether your firewall does NAT or not just became totally moot. Defense in depth doesn't mean building a second Maginot Line behind the first is a good idea - it means you *also* have a capable army that will stop a German invasion coming in via Belgium. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jamie at photon.com Wed Nov 16 08:05:20 2011 From: jamie at photon.com (Jamie Bowden) Date: Wed, 16 Nov 2011 09:05:20 -0500 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: <22374.1321452116@turing-police.cc.vt.edu> References: <14755259.2999.1321450581722.JavaMail.root@benjamin.baylink.com> <22374.1321452116@turing-police.cc.vt.edu> Message-ID: <275FEA2949B48341A3B46F424B613D857DBB@WDC-MX.photon.com> > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Wednesday, November 16, 2011 9:02 AM > To: Jay Ashworth > Cc: NANOG > Subject: Re: Have they stopped teaching Defense in Depth? > > On Wed, 16 Nov 2011 08:36:21 EST, Jay Ashworth said: > > ----- Original Message ----- > > > From: "Jimmy Hess" > > > > > Or, the attack is against a legitimate user's outbound connection, > for example: > > > a user behind the firewall connects to a web site, a vulnerability > > > in their browser is exploited > > > to install a trojan -- the trojan tunnels to the attacker over an > > > outgoing port that is allowed on the firewall. > > > > Oh, certainly; I have lots of web browsers running on my servers. > > > > All The World Is Not A Workstation, guys. > > Is there *anything* on the allegedly protected subnet that has a web > browser > running on it? Maybe that laptop on the crash cart that you use for > downloading firmware and installing it on storage appliances? If it's > a > corporate-sized NAT, do you have any desktops that have network > reachability to > the servers (probably do - if the desktops can't reach the servers, the > servers > aren't useful are they?) and also have web browsers that go to the > outside > world? > > I compromise an ad server someplace. Bob over in Accounting visits the > CPA forum > on the accountants-r-us.com website looking for suggestion on how to > handle > a tax issue. I now have control of Bob's workstation, and the question > of whether > your firewall does NAT or not just became totally moot. > > Defense in depth doesn't mean building a second Maginot Line behind the > first > is a good idea - it means you *also* have a capable army that will stop > a > German invasion coming in via Belgium. That's absurd, no one could get an army across that terrain... Jamie From eric at ericheather.com Wed Nov 16 08:14:59 2011 From: eric at ericheather.com (Eric C. Miller) Date: Wed, 16 Nov 2011 14:14:59 +0000 Subject: Arguing against using public IP space Message-ID: Not sure if anyone has thought of it like this, but: Air Gap is still only as secure as the people with access to it. NAT and firewalls provide a compromise between security and connectivity. But remember that at a power plant, the PBX system still connects to the outside world, and there is a phone in the control room. What stops a nefarious social hacker from calling up the control room and convincing the 3rd shift operator to stop producing power (claiming to be from the regional authority)? Caller-ID can be hacked. My personal belief is that all layers of the OSI/DOD model should assume that the adjacent lower level can and will be compromised at some point and measures should be put in place to encrypt or authenticate messages. Unfortunately for us, our critical infrastructure in this country still operates on outdated security-less network architectures like ArcNET. Even most of the PLCs in use at power plants utilize no security or have simple passwords like "supervisor" and "operator." The US gov's NERC has random inspections for CIP compliance, but I feel that they happen so infrequently, that nothing will be done in time to adequately protect us from certain dangers that loom. Eric Miller Network Engineering Consultant From owen at delong.com Wed Nov 16 10:11:29 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Nov 2011 08:11:29 -0800 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: References: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> <20111115215055.72C851737568@drugs.dv.isc.org> Message-ID: <7920B919-FC2E-48A4-87DE-D32D49E40318@delong.com> On Nov 15, 2011, at 2:01 PM, William Herrin wrote: > On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews wrote: >> If you want to use unroutable addresses then use a bastion host / >> proxy. Don't expect to be able to open a TCP socket and have it >> connect to something on the outside. Do it right or don't do it >> at all. > > Mark, > > What is a modern NAT but a bastion host proxy for which application > compatibility has been maximized? It is a mechanism for header mutilation which creates additional costs in hardware (cost of routers), software (development of NAT traversal code in various applications, NAT software in some cases), security (NAT obfuscates audit trails and increases the difficulty and cost of event correlation, forensics, abuser identification, and attack source identification and mitigation, etc.). Owen From jamie at photon.com Wed Nov 16 10:20:28 2011 From: jamie at photon.com (Jamie Bowden) Date: Wed, 16 Nov 2011 11:20:28 -0500 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: <7920B919-FC2E-48A4-87DE-D32D49E40318@delong.com> References: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> <20111115215055.72C851737568@drugs.dv.isc.org> <7920B919-FC2E-48A4-87DE-D32D49E40318@delong.com> Message-ID: <275FEA2949B48341A3B46F424B613D857DBD@WDC-MX.photon.com> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, November 16, 2011 11:11 AM > To: William Herrin > Cc: NANOG > Subject: Re: Have they stopped teaching Defense in Depth? > > > On Nov 15, 2011, at 2:01 PM, William Herrin wrote: > > > On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews wrote: > >> If you want to use unroutable addresses then use a bastion host / > >> proxy. Don't expect to be able to open a TCP socket and have it > >> connect to something on the outside. Do it right or don't do it > >> at all. > > > > Mark, > > > > What is a modern NAT but a bastion host proxy for which application > > compatibility has been maximized? > > It is a mechanism for header mutilation which creates additional costs > in hardware (cost of routers), software (development of NAT traversal > code in various applications, NAT software in some cases), security > (NAT obfuscates audit trails and increases the difficulty and cost of > event correlation, forensics, abuser identification, and attack source > identification and mitigation, etc.). How is that any different than a proxy server, really? From the inside, your apps are either NAT aware or proxy aware, but either way, you're not directly exposed to the world and all your traffic comes from one place as far as the world is concerned. I live behind both (NAT at home; all external traffic of any type (assuming it's even allowed) is proxied at work), and both suck in different and exciting ways. Jamie From owen at delong.com Wed Nov 16 10:33:30 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Nov 2011 08:33:30 -0800 Subject: Arguing against using public IP space In-Reply-To: <1321409276.2514.251.camel@karl> References: <29838609.2919.1321392184239.JavaMail.root@benjamin.baylink.com> <20111116012029.66D99173B09C@drugs.dv.isc.org> <1321409276.2514.251.camel@karl> Message-ID: <721A510B-4D6E-4B20-B64B-0415DA72C315@delong.com> On Nov 15, 2011, at 6:07 PM, Karl Auer wrote: > On Wed, 2011-11-16 at 12:20 +1100, Mark Andrews wrote: >> You are making assumptions about how the NAT is designed. >> [...] >> Unless you know the internals of a NAT you cannot say whether it >> fails open or closed. > > Indeed not! > > From 2010, during an identical discussion: > > http://seclists.org/nanog/2010/Apr/1166 > > To me, "fail" means that a system stops doing what it was designed to > do. The results are by definition undefined. Others seem to think that > "fail" means a kind of default. > Red herring alert. Fact, any given system has failure modes that are more common and failure modes that are less common. Sure, your car can fail by having the engine explode. However, this is nowhere near as common as having your car fail due to a flat tire or a clogged fuel filter. Arguing that flat tires and clogged fuel filters are some form of default is absurd, but, when discussing automotive failures, the discussion will naturally focus more on these failures than on engine explosions. Such has been the case here. The most common failure modes for firewalls are failures due to misconfiguration and/or failures due to loss of configuration information. Some misconfigurations are more common than others. A proper firewall will address most of these failures by no longer forwarding packets. In this case, a router with NAT is slightly more likely to fail closed than a router without NAT. However, a firewall without NAT is more likely to fail closed than a router with or without NAT and equally likely to a firewall with NAT. In other words, NAT doesn't really improve anything, but, the difference between the common failure modes of a firewall vs. a router are worthy of consideration. The infinitesimal advantage of NAT if you use a router instead of a firewall to perform the duties of a firewall is dramatically overshadowed by the costs and damage done by NAT. OTOH, routers, being designed primarily to forward packets and having security appliance features added as a secondary capability will, in many cases, address most of these failures by passing packets which would not be permitted if properly configured and/or functioning. Yes, they are identical and NAT makes no meaningful difference to the chances that undesired packets will be forwarded in the event of a catastrophic failure outside of these more common failure modes. Owen From bill at herrin.us Wed Nov 16 10:43:54 2011 From: bill at herrin.us (William Herrin) Date: Wed, 16 Nov 2011 11:43:54 -0500 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: <7920B919-FC2E-48A4-87DE-D32D49E40318@delong.com> References: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> <20111115215055.72C851737568@drugs.dv.isc.org> <7920B919-FC2E-48A4-87DE-D32D49E40318@delong.com> Message-ID: On Wed, Nov 16, 2011 at 11:11 AM, Owen DeLong wrote: > On Nov 15, 2011, at 2:01 PM, William Herrin wrote: >> On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews wrote: >>> If you want to use unroutable addresses then use a bastion host / >>> proxy. >> >> What is a modern NAT but a bastion host proxy for which application >> compatibility has been maximized? > > It is a mechanism for header mutilation which creates additional costs > in hardware (cost of routers), software (development of NAT traversal > code in various applications, NAT software in some cases), security > (NAT obfuscates audit trails and increases the difficulty and cost of > event correlation, forensics, abuser identification, and attack source > identification and mitigation, etc.). In other words, all of the things a proxy does but without sacrificing as many applications. -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 Wed Nov 16 10:44:00 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Nov 2011 08:44:00 -0800 Subject: Arguing against using public IP space In-Reply-To: <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com> References: <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com> Message-ID: On Nov 15, 2011, at 7:08 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Mark Andrews" > >> In message >> <29838609.2919.1321392184239.JavaMail.root at benjamin.baylink.com>, Ja >> y Ashworth writes: >>>>>> If your firewall is not working, it should not be passing >>>>>> packets. >>>>> >>>>> And of course, things always fail just the way we want them to. >>>> >>>> Your stateful firewall is no more likely to fail open than your >>>> header-mutilating device. >>> >>> Please show your work. >> >> Prove to me that all NAT won't pass packets not addressed directly >> to it. Show your work. > > I did not *assert* that. So I don't have to prove that. > > What I *asserted* was that inbound 1:N DNAT *reduces the probability of > an attacker being able to target a specific inbound attack to a specific > computer*. QED. > No, it is not QED... You have not proven that it reduces said probability vs. a stateful firewall without header mutilation. So, again, please show your work and prove your assertion or accept that your assertion is no more or less credible than the assertion that it does not. >> Given that most NATs only use a small set of address on the inside >> it is actually feasible to probe through a NAT using LSR. Most >> attacks don't do this as there are lots of lower hanging fruit but >> if it is a targeted attack then yes you can expect to see LSR based >> attacks which depending apon how the NAT is built may pass through >> it without even being noticed. > > Someone else has already addressed "low-hanging fruit", so I won't. I do > concur, though: if you have specific examples of boxes which, as you allege, > respect LSR to 1918 internal addresses, please, name and shame. > He probably likes his job too much to do that. I don't know the specifics or the internals of specific boxes, so, I can't point you at one, but, I will point out that Mark works for a manufacturer of MANY of the worlds cheapest NAT gateways and given the other code quality issues observed in these brand-L products in the wild, universal lack of such NAT vulnerabilities in them would truly come as a surprise. >> Now can we put to bed that NAT provides any real security. If you >> want security add and configure a firewall. That firewall can be >> in the same box as the NAT. It can use the same state tables as >> the NAT but it is the firewall, not the NAT functionality, that >> provides the protection. > > Nope; I'm afraid we still can't. As long as you continue to strawman that > I/we are even *alleging* that NAT "provides" security (rather than > "contributing" to it, we're just going to keep talking past each other, Mark. > NAT neither provides nor contributes to security. NAT detracts from security by destroying audit trails and interrupting/obfuscating attack source identification, forensics, etc. Owen From bhmccie at gmail.com Wed Nov 16 11:13:18 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 16 Nov 2011 11:13:18 -0600 Subject: Arguing against using public IP space In-Reply-To: References: <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com> Message-ID: <4EC3EF2E.2040408@gmail.com> "NAT neither provides nor contributes to security. NAT detracts from security by destroying audit trails and interrupting/obfuscating attack source identification, forensics, etc." Respectfully, I'm really struggling with this. Sentence one is an opinion. It's all a matter of the designers viewpoint. Step 1 in most security books is to not reveal ANYTHING to ANYONE that you don't have to. Taken to the extreme, that could include your network layout and native addressing schema. Sentence two is wrong. If employing NAT breaks your audit trail or interferes with your forensics then you need to address your audit/forensics method. We have correlation engines that track the "state" of a conversation (defined as multiple TCP sessions in series) thru our secure architecture. We can 100% tell you the public IP of a session whether it's the destination or source and whether it's been NATted once or three or four times. We have cookies/sessionIDs/JSessionIDs/ and Xforwarders we manipulate to allow the application layer to manage the proper source of the client as well. These are proven technologies that have been around for a decade. They have stood up in court and been used against bad guys w/o question. While I agree that this is an extra layer of complexity, the focus is to make in manageable. I'm not saying you are flat out wrong Owen. I am saying that it's all a matter of your viewpoint. -Hammer- "I was a normal American nerd" -Jack Herer On 11/16/2011 10:44 AM, Owen DeLong wrote: > NAT neither provides nor contributes to security. > > NAT detracts from security by destroying audit trails and interrupting/obfuscating > attack source identification, forensics, etc. > From hiersd at gmail.com Wed Nov 16 11:42:20 2011 From: hiersd at gmail.com (David Hiers) Date: Wed, 16 Nov 2011 09:42:20 -0800 Subject: state.va.us contact on list? Message-ID: We are aparently being attacked from a server in state.va.us. If there is a contact for state.va.us on the list, please contact me off list. Thanks, David From jra at baylink.com Wed Nov 16 12:58:16 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 16 Nov 2011 13:58:16 -0500 (EST) Subject: Arguing against using public IP space In-Reply-To: <721A510B-4D6E-4B20-B64B-0415DA72C315@delong.com> Message-ID: <26943894.3017.1321469896235.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > In this case, a router with NAT is slightly more likely to fail closed than > a router without NAT. "Slightly"? Continuing to assume here, as we have been, that the network behind a NAT is *unroutable*, then a NAT router has, IME, *many* more obvious possible failure modes which will make the internal network inaccessible from outside than modes which cause the opposite. If you're an attacker, targeting a behind-NAT box from the outside, then if the NAT's working, you can hit directly any ports that are forwarded to it. If not, then you have to a) know the private IP of the box and b) be able to get packets to the last upstream hop with source routing on them and c) the box has to have failed (or been configured or built) in such a way as to *listen* to source-routing. Those layers may have varying thicknesses, but there *are* at least 3 more of them, *on top of* "did it fail in a way where it's listening at all?". > However, a firewall without NAT is more likely > to fail closed than a router with or without NAT and equally likely to > a firewall with NAT. If it's a firewall that meets your definition of the word, as opposed to, say, a shorewall box, a smoothwall box, a pf box, or any of the other 3 or 4 dozen packaged linux based firewall routers of which there are *lots* out there. Probably the most common failure more on those is "iptables accidentally cleared; box routes all packets". That's one failure to get to that point, insted of 2, 3 or 4. And since it's human-based a lot of the time, it's probably even more likely. > In other words, NAT doesn't really improve anything, > but, the difference between the common failure modes of a firewall > vs. a router are worthy of consideration. The infinitesimal advantage > of NAT if you use a router instead of a firewall to perform the duties > of a firewall is dramatically overshadowed by the costs and damage > done by NAT. Costs already sunk, IME. Damage is a question-begging term here. > OTOH, routers, being designed primarily to forward packets and having > security appliance features added as a secondary capability will, in > many cases, address most of these failures by passing packets which > would not be permitted if properly configured and/or functioning. Yup. What I've been saying (or implying) right along. So, in networks, or in seats, take your pick, does anyone have any deployment numbers on router-based firewalls vs the other sort, whatever we're calling them? > Yes, they are identical and NAT makes no meaningful difference > to the chances that undesired packets will be forwarded in the event > of a catastrophic failure outside of these more common failure modes. I guess we're going to have to agree to disagree here; our respective clients will decide what their opinions on that are. 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 hiersd at gmail.com Wed Nov 16 13:03:42 2011 From: hiersd at gmail.com (David Hiers) Date: Wed, 16 Nov 2011 11:03:42 -0800 Subject: state.va.us contact on list? In-Reply-To: References: Message-ID: Thanks to all for their off-list replies! NANOGers rock.... We're in contact with the right people now. Thanks again, David On Wed, Nov 16, 2011 at 9:42 AM, David Hiers wrote: > We are aparently being attacked from a server in state.va.us. ?If > there is a contact for state.va.us on the list, please contact me off > list. > > Thanks, > > David > From plosher at isc.org Wed Nov 16 13:52:19 2011 From: plosher at isc.org (Peter Losher) Date: Wed, 16 Nov 2011 11:52:19 -0800 Subject: [ISC Security Advisory] BIND 9 Resolver crashes after logging an error in query.c Message-ID: BIND 9 Resolver crashes after logging an error in query.c Summary: Organizations across the Internet reported crashes interrupting service on BIND 9 nameservers performing recursive queries. Affected servers crashed after logging an error in query.c with the following message: "INSIST(! dns_rdataset_isassociated(sigrdataset))" Multiple versions were reported being affected, including all currently supported release versions of ISC BIND 9. ISC is actively investigating the root cause and has produced patches which prevent the crash. Further information will be made available soon. CVE: CVE-2011-4313 Document Version: 1.1 Document URL: http://www.isc.org/software/bind/advisories/cve-2011-4313 Posting date: 16 Nov 2011 Program Impacted: BIND Versions affected: All currently supported versions of BIND, 9.4-ESV, 9.6-ESV, 9.7.x, 9.8.x Severity: Serious Exploitable: Remotely Description: An as-yet unidentified network event caused BIND 9 resolvers to cache an invalid record, subsequent queries for which could crash the resolvers with an assertion failure. ISC is working on determining the ultimate cause by which a record with this particular inconsistency is cached.At this time we are making available a patch which makes named recover gracefully from the inconsistency, preventing the abnormal exit. The patch has two components. When a client query is handled, the code which processes the response to the client has to ask the cache for the records for the name that is being queried. The first component of the patch prevents the cache from returning the inconsistent data. The second component prevents named from crashing if it detects that it has been given an inconsistent answer of this nature. CVSS Score: 7.8 CVSS Equation: (AV:N/AC:L/Au:N/C:N/I:N/A:C) Workarounds: No workarounds are known. The solution is to upgrade. Upgrade BIND to one of the following patched versions: BIND 9.8.1-P1, 9.7.4-P1, 9.6-ESV-R5-P1, 9.4-ESV-R5-P1 Active exploits: Under investigation Solution: Patches mitigating the issue are available at: https://www.isc.org/software/bind/981-p1 https://www.isc.org/software/bind/974-p1 https://www.isc.org/software/bind/96-esv-r5-p1 https://www.isc.org/software/bind/94-esv-r5-p1 ISC is receiving multiple reports and working with multiple customers on this issue. Please E-mail all questions, packet captures, and details to security-officer at isc.org We very much appreciate all reports received on this issue. Related Documents: Do you have Questions? Questions regarding this advisory should go to security-officer at isc.org. ISC Security Vulnerability Disclosure Policy: Details of our current security advisory policy and practice can be found here: https://www.isc.org/security-vulnerability-disclosure-policy Legal Disclaimer: Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors. -- [ plosher at isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] From nathan at atlasnetworks.us Wed Nov 16 14:05:55 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 16 Nov 2011 20:05:55 +0000 Subject: Security Contact from broward.k12.fl.us (was: Security Contact from k12.fl.us) In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B5E66F2@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C286B5E66A6@ex-mb-1.corp.atlasnetworks.us> <8C26A4FDAE599041A13EB499117D3C286B5E66F2@ex-mb-1.corp.atlasnetworks.us> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5F5483@ex-mb-1.corp.atlasnetworks.us> > > -----Original Message----- > > From: Nathan Eisenberg > > Sent: Thursday, November 10, 2011 2:07 PM > > To: NANOG list > > Subject: Security Contact from k12.fl.us > > > > Please contact me off-list. > > -----Original Message----- > From: Nathan Eisenberg > Sent: Thursday, November 10, 2011 2:15 PM > To: NANOG list > Subject: RE: Security Contact from broward.k12.fl.us (was: Security > Contact from k12.fl.us) > > It was pointed out to me that 'k12.fl.us' is not an organization, but > rather a container. Clarification - I'm looking for a security contact > from broward.k12.fl.us I wanted to follow up and thank the list for their assistance in getting a contact with Browards' IT management team. There were several people who helped me find the right email address to notify. Side note: I received a number of cynical emails opining on the globally sloppy nature of school district IT departments, and suggesting that I not even bother to tell them about a security issue. I'd like to provide this case as evidence to the contrary. Once I'd sent an email to the right place, the call came within 30 minutes. The person I spoke with was grateful (as any of us would be) for the notification, and seemed intent on addressing the issue. So, just a data point! :) Back to our operational (repeat) discussion on the security characteristics of NAT, and how many angels can dance on a pinhead. Nathan Eisenberg From owen at delong.com Wed Nov 16 14:32:22 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Nov 2011 12:32:22 -0800 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: <275FEA2949B48341A3B46F424B613D857DBD@WDC-MX.photon.com> References: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> <20111115215055.72C851737568@drugs.dv.isc.org> <7920B919-FC2E-48A4-87DE-D32D49E40318@delong.com> <275FEA2949B48341A3B46F424B613D857DBD@WDC-MX.photon.com> Message-ID: On Nov 16, 2011, at 8:20 AM, Jamie Bowden wrote: > > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Wednesday, November 16, 2011 11:11 AM >> To: William Herrin >> Cc: NANOG >> Subject: Re: Have they stopped teaching Defense in Depth? >> >> >> On Nov 15, 2011, at 2:01 PM, William Herrin wrote: >> >>> On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews wrote: >>>> If you want to use unroutable addresses then use a bastion host / >>>> proxy. Don't expect to be able to open a TCP socket and have it >>>> connect to something on the outside. Do it right or don't do it >>>> at all. >>> >>> Mark, >>> >>> What is a modern NAT but a bastion host proxy for which application >>> compatibility has been maximized? >> >> It is a mechanism for header mutilation which creates additional costs >> in hardware (cost of routers), software (development of NAT traversal >> code in various applications, NAT software in some cases), security >> (NAT obfuscates audit trails and increases the difficulty and cost of >> event correlation, forensics, abuser identification, and attack source >> identification and mitigation, etc.). > > How is that any different than a proxy server, really? From the inside, > your apps are either NAT aware or proxy aware, but either way, you're > not directly exposed to the world and all your traffic comes from one > place as far as the world is concerned. I live behind both (NAT at > home; all external traffic of any type (assuming it's even allowed) is > proxied at work), and both suck in different and exciting ways. > > Jamie You answered your own question... They suck in different ways. Owen From rps at maine.edu Wed Nov 16 14:38:16 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 16 Nov 2011 15:38:16 -0500 Subject: Arguing against using public IP space In-Reply-To: <26943894.3017.1321469896235.JavaMail.root@benjamin.baylink.com> References: <721A510B-4D6E-4B20-B64B-0415DA72C315@delong.com> <26943894.3017.1321469896235.JavaMail.root@benjamin.baylink.com> Message-ID: Can't believe this is still going on. ;-) NAT does not provide security; it provides utility. It is useful in many situations, though. If you are limited in the amount of public IP space you have, then NAT is one solution to that. If you want to have a backup connection to the Internet, but don't want to involve your ISP, or your ISP won't let you talk BGP with them (often for good reason), then NAT can be a solution to that as well. IPv6 doesn't have NAT yet, because NAT has a lot of issues. We think we can do better. The current momentum is behind Network Prefix Translation (NPT); which rather than re-writing addresses and ports, rewrites only the network segment of an address, leaving the host segment unchanged. This is stateless translation and can be implemented very efficiently to provide utility without limiting performance in a meaningful way. It will likely be the way that most small networks get service from more than one provider as IPv6 adoption grows (predictable internal addresses, independent from provide addressing changes, etc.) Like NAT, though, it doesn't provide security. Stateful Packet Inspection (SPI) provides some level of security; and most NAT devices include an SPI firewall, as state tracking is already a requirement for NAT to function. There is no requirement that SPI to use NAT, though. For the majority of scenarios the failure mode for a firewall running NAT with private IP address space, and the failure mode for a firewall not performing NAT, are identical; except that the extra overhead and complexity required by NAT can actually mean a higher failure rate in some cases. It's an absurd generalization (which is not based in fact) that a NAT firewall will fail closed, and a firewall not using NAT will fail open. The problem with the article in the OP -- the thing that rubs most of this list in the wrong way -- is that it's yet another self-proclaimed expert telling people that private IP addresses provide security. They do not. Most on this list have seen time and time again compromised networks that sit behind NAT. Almost every time it turns out to be that the user though they were protected by NAT, and proceeded to not address security concerns internally. Examples included disabling host firewalls, not updating systems, and not monitoring activity. Worse they then proceed to ask you how to find out which host is compromise because the report only mentioned the IP of their firewall. I would go as far as to argue that the false sense of security provided by NAT is more dangerous than any current threat that NAT alone would prevent. Firewalls are still a necessary tool; but they don't really provide the security that people associate with them. It isn't a magic box; and short of blocking all traffic, they really don't provide comprehensive security. The article in the OP not only makes it sound like a magic box; but goes on to say that the magic box isn't what keeps you safe -- it's the fact that your IP is "private". So the idea that the answer for a nuclear power plant is to use private IP addresses and that will address all their security concerns is just frustrating and ridiculous. The author tried to simplify things so much that the information become incorrect somewhere along the way. I for one hope that our nuclear power plants are protected by more than NAT. I don't care if they don't use NAT. Just as long as they address security. On Wed, Nov 16, 2011 at 1:58 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> In this case, a router with NAT is slightly more likely to fail closed than >> a router without NAT. > > "Slightly"? ?Continuing to assume here, as we have been, that the network > behind a NAT is *unroutable*, then a NAT router has, IME, *many* more obvious > possible failure modes which will make the internal network inaccessible from > outside than modes which cause the opposite. > > If you're an attacker, targeting a behind-NAT box from the outside, then > if the NAT's working, you can hit directly any ports that are forwarded to it. > > If not, then you have to a) know the private IP of the box and b) be able to > get packets to the last upstream hop with source routing on them and c) the > box has to have failed (or been configured or built) in such a way as to > *listen* to source-routing. ?Those layers may have varying thicknesses, but > there *are* at least 3 more of them, *on top of* "did it fail in a way where > it's listening at all?". > >> ? ? ? ? ? ? ? ? ? ? ? ?However, a firewall without NAT is more likely >> to fail closed than a router with or without NAT and equally likely to >> a firewall with NAT. > > If it's a firewall that meets your definition of the word, as opposed to, > say, a shorewall box, a smoothwall box, a pf box, or any of the other 3 or > 4 dozen packaged linux based firewall routers of which there are *lots* out > there. ?Probably the most common failure more on those is "iptables accidentally > cleared; box routes all packets". > > That's one failure to get to that point, insted of 2, 3 or 4. ?And since it's > human-based a lot of the time, it's probably even more likely. > >> ? ? ? ? ? ? ? ? ? ? ?In other words, NAT doesn't really improve anything, >> but, the difference between the common failure modes of a firewall >> vs. a router are worthy of consideration. The infinitesimal advantage >> of NAT if you use a router instead of a firewall to perform the duties >> of a firewall is dramatically overshadowed by the costs and damage >> done by NAT. > > Costs already sunk, IME. ?Damage is a question-begging term here. > >> OTOH, routers, being designed primarily to forward packets and having >> security appliance features added as a secondary capability will, in >> many cases, address most of these failures by passing packets which >> would not be permitted if properly configured and/or functioning. > > Yup. ?What I've been saying (or implying) right along. ?So, in networks, > or in seats, take your pick, does anyone have any deployment numbers on > router-based firewalls vs the other sort, whatever we're calling them? > >> Yes, they are identical and NAT makes no meaningful difference >> to the chances that undesired packets will be forwarded in the event >> of a catastrophic failure outside of these more common failure modes. > > I guess we're going to have to agree to disagree here; our respective > clients will decide what their opinions on that are. > > 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 > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Wed Nov 16 14:35:56 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Nov 2011 12:35:56 -0800 Subject: Have they stopped teaching Defense in Depth? In-Reply-To: References: <33284158.2915.1321391772464.JavaMail.root@benjamin.baylink.com> <20111115215055.72C851737568@drugs.dv.isc.org> <7920B919-FC2E-48A4-87DE-D32D49E40318@delong.com> Message-ID: On Nov 16, 2011, at 8:43 AM, William Herrin wrote: > On Wed, Nov 16, 2011 at 11:11 AM, Owen DeLong wrote: >> On Nov 15, 2011, at 2:01 PM, William Herrin wrote: >>> On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews wrote: >>>> If you want to use unroutable addresses then use a bastion host / >>>> proxy. >>> >>> What is a modern NAT but a bastion host proxy for which application >>> compatibility has been maximized? >> >> It is a mechanism for header mutilation which creates additional costs >> in hardware (cost of routers), software (development of NAT traversal >> code in various applications, NAT software in some cases), security >> (NAT obfuscates audit trails and increases the difficulty and cost of >> event correlation, forensics, abuser identification, and attack source >> identification and mitigation, etc.). > > In other words, all of the things a proxy does but without sacrificing > as many applications. > No, in the proxy case, the sessions internal and sessions external are separate and the proxy software ties them together. In the NAT case, the internal and external sessions are one and the same, but, the header is mutilated as part of the IP forwarding process. However, yes, as someone else pointed out, the key difference is that they suck in different ways. Owen From owen at delong.com Wed Nov 16 14:44:34 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Nov 2011 12:44:34 -0800 Subject: Arguing against using public IP space In-Reply-To: <4EC3EF2E.2040408@gmail.com> References: <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com> <4EC3EF2E.2040408@gmail.com> Message-ID: On Nov 16, 2011, at 9:13 AM, -Hammer- wrote: > "NAT neither provides nor contributes to security. > NAT detracts from security by destroying audit trails and interrupting/obfuscating > attack source identification, forensics, etc." > > Respectfully, I'm really struggling with this. Sentence one is an opinion. It's all a matter of the designers viewpoint. Step 1 in most security books is to not reveal ANYTHING to ANYONE that you don't have to. Taken to the extreme, that could include your network layout and native addressing schema. > Actually, the first rule of security in many texts I have read is "Security through obscurity is no security.". While you don't reveal anything to anyone that you don't have to, it is arguable that you need to reveal enough for security threats (abusers, attackers, etc.) to be identified as part of being a good network citizen. As with most things, taken to extreme, you reach a point of reductio ad absurdum. > Sentence two is wrong. If employing NAT breaks your audit trail or interferes with your forensics then you need to address your audit/forensics method. We have correlation engines that track the "state" of a conversation (defined as multiple TCP sessions in series) thru our secure architecture. We can 100% tell you the public IP of a session whether it's the destination or source and whether it's been NATted once or three or four times. We have cookies/sessionIDs/JSessionIDs/ and Xforwarders we manipulate to allow the application layer to manage the proper source of the client as well. These are proven technologies that have been around for a decade. They have stood up in court and been used against bad guys w/o question. While I agree that this is an extra layer of complexity, the focus is to make in manageable. > It may not break your own, but, it certainly breaks that of your user's victims. Most people don't store port information in their webserver logs, for example. They may not have that data to come back at you to identify the internal host in question. All they have is the public IP address of your NAT box and the date/time the event occurred. Ignoring for a moment the fact that if your clocks aren't perfectly synchronized, that may not necessarily provide the needed identification, even if they do have the port number, without the source port number from your side, they don't have enough for you to find the attacker. > I'm not saying you are flat out wrong Owen. I am saying that it's all a matter of your viewpoint. > I think in considering this in general, all viewpoints must be considered. From the global viewpoint, overall, I think that the case is well made that the security negatives associated with NAT and the cost/impact imposed on everyone, including those outside of the NAT- using organization far outweigh the (very minuscule) possible positives that have been argued so far. This leaves one and only one key benefit to NAT, which is address sharing (conservation). Since we don't have a shortage of IPv6 addresses, bringing a technology forward into IPv6 solely for the purpose of address sharing (conservation) makes little sense. Owen From Jonathon.Exley at kordia.co.nz Wed Nov 16 14:51:44 2011 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Wed, 16 Nov 2011 20:51:44 +0000 Subject: OpenSource IPTV and VoD Solution In-Reply-To: <7148540074646496230@unknownmsgid> References: <5435AB89-62D4-425B-BAB2-BC0FAE7604BB@packetdam.com> <7D02F35711B04FE8AEE7FEAB3B127C08@work> <524AFED3-C49A-417D-996A-5A9579421608@packetdam.com> <07C3015B9E21F949AB59B28F2D5B567F0733B489@exch-pul-01.interne.smart-telecom.ch> <7148540074646496230@unknownmsgid> Message-ID: Maybe LIMBOS (http://sourceforge.net/projects/limbos/ ) would work for you? It seems to be instructions for DVB-H reception on Linux and using VLC to relay to the Darwin Streaming Server. Looks like you just can't get away from VLC. Jonathon -----Original Message----- From: Tayeb Meftah [mailto:tayeb.meftah at gmail.com] Sent: Wednesday, 16 November 2011 10:01 p.m. To: Quentin Carpent Cc: nanog at nanog.org Subject: Re: OpenSource IPTV and VoD Solution Thx But no rtsp Thx Envoy? de mon iPhone Le 16 nov. 2011 ? 08:58, Quentin Carpent a ?crit : > Hi, > > I don't know if it meets your requirements but there is DVBlast: > http://www.videolan.org/projects/dvblast.html > > BRs, > > Quentin Carpent > Network Engineer > > -----Message d'origine----- > De : Vlad Galu [mailto:galu at packetdam.com] Envoy? : mercredi 16 > novembre 2011 06:18 ? : Meftah Tayeb Cc : nanog at nanog.org Objet : Re: > OpenSource IPTV and VoD Solution > > > On Nov 14, 2011, at 10:25 PM, Meftah Tayeb wrote: > >> thank you for that >> is a rtsp server no problem >> but how do i stream Live DVB traffic through it ? >> Thank you >> > > To be honest I haven't followed its development closely lately (although I contribute occasionally with networking related patches and improvements) so I can't answer that, but you should be able to send your stream to RTMPD using either MumuDVB or VLC, then demux it to as many (hundreds or even thousands, it is *that* good) clients as you need. > > I should have pointed you to the wiki [1] and the mailing list [2], sorry. > > HTH. > > [1] http://wiki.rtmpd.com/ > [2] http://groups.google.com/group/c-rtmp-server?pli=1 > > -- > PacketDam: a cost-effective > software solution against DDoS > http://www.packetdam.com > > > > > 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 rps at maine.edu Wed Nov 16 15:00:11 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 16 Nov 2011 16:00:11 -0500 Subject: Arguing against using public IP space In-Reply-To: References: <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com> <4EC3EF2E.2040408@gmail.com> Message-ID: On Wed, Nov 16, 2011 at 3:44 PM, Owen DeLong wrote: > Actually, the first rule of security in many texts I have read is "Security through obscurity > is no security." Relevant: http://penny-arcade.com/comic/2003/03/21 :-) -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From bhmccie at gmail.com Wed Nov 16 15:44:25 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 16 Nov 2011 15:44:25 -0600 Subject: Arguing against using public IP space In-Reply-To: References: <28327223.2951.1321412909463.JavaMail.root@benjamin.baylink.com> <4EC3EF2E.2040408@gmail.com> Message-ID: <4EC42EB9.7040105@gmail.com> Well argued Owen. I can see both sides. -Hammer- "I was a normal American nerd" -Jack Herer On 11/16/2011 02:44 PM, Owen DeLong wrote: > On Nov 16, 2011, at 9:13 AM, -Hammer- wrote: > > >> "NAT neither provides nor contributes to security. >> NAT detracts from security by destroying audit trails and interrupting/obfuscating >> attack source identification, forensics, etc." >> >> Respectfully, I'm really struggling with this. Sentence one is an opinion. It's all a matter of the designers viewpoint. Step 1 in most security books is to not reveal ANYTHING to ANYONE that you don't have to. Taken to the extreme, that could include your network layout and native addressing schema. >> >> > Actually, the first rule of security in many texts I have read is "Security through obscurity > is no security.". While you don't reveal anything to anyone that you don't have to, it is > arguable that you need to reveal enough for security threats (abusers, attackers, etc.) > to be identified as part of being a good network citizen. As with most things, taken > to extreme, you reach a point of reductio ad absurdum. > > >> Sentence two is wrong. If employing NAT breaks your audit trail or interferes with your forensics then you need to address your audit/forensics method. We have correlation engines that track the "state" of a conversation (defined as multiple TCP sessions in series) thru our secure architecture. We can 100% tell you the public IP of a session whether it's the destination or source and whether it's been NATted once or three or four times. We have cookies/sessionIDs/JSessionIDs/ and Xforwarders we manipulate to allow the application layer to manage the proper source of the client as well. These are proven technologies that have been around for a decade. They have stood up in court and been used against bad guys w/o question. While I agree that this is an extra layer of complexity, the focus is to make in manageable. >> >> > It may not break your own, but, it certainly breaks that of your user's victims. > > Most people don't store port information in their webserver logs, for example. They may not have > that data to come back at you to identify the internal host in question. All they have is the public > IP address of your NAT box and the date/time the event occurred. > > Ignoring for a moment the fact that if your clocks aren't perfectly synchronized, that may not > necessarily provide the needed identification, even if they do have the port number, without > the source port number from your side, they don't have enough for you to find the attacker. > > >> I'm not saying you are flat out wrong Owen. I am saying that it's all a matter of your viewpoint. >> >> > I think in considering this in general, all viewpoints must be considered. From the global > viewpoint, overall, I think that the case is well made that the security negatives associated > with NAT and the cost/impact imposed on everyone, including those outside of the NAT- > using organization far outweigh the (very minuscule) possible positives that have been > argued so far. > > This leaves one and only one key benefit to NAT, which is address sharing (conservation). > Since we don't have a shortage of IPv6 addresses, bringing a technology forward into > IPv6 solely for the purpose of address sharing (conservation) makes little sense. > > Owen > > From bonomi at mail.r-bonomi.com Wed Nov 16 16:35:47 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 16 Nov 2011 16:35:47 -0600 (CST) Subject: OT -- seeking a knowledgable AS 701 technical contact. Message-ID: <201111162235.pAGMZl0a039506@mail.r-bonomi.com> Apologies for the noise, but I have been absolutely unable -- despite literally *hours* of trying --to contact anyone at _any_ of the published Verizon Business phone numbers who has any comprehension of what I am talking about -- to wit: "I am looking for someone with _any_ awareness/knowledge of Verizon Business's public-access anonymous FTP server, with the hostname 'ftp.uu.net'." The published Verizon Business technical contact number -- both in 'whois' for uu.net, and Jared's NOC contact list is only the 'ticket center', and won't open a ticket for someone who is not Verizon customer. "Customer service" doesn't know what 'ftp' is, and vacillates between thinking it is a circuit problem, or that I am having a problem with -my- domain. Call-transfer to 'technical support' was answered by someone handling 'delinquent payments'. Another transfer attempt ended up on somebody's cell phone. From shortdudey123 at gmail.com Wed Nov 16 16:51:07 2011 From: shortdudey123 at gmail.com (Grant Ridder) Date: Wed, 16 Nov 2011 16:51:07 -0600 Subject: OT -- seeking a knowledgable AS 701 technical contact. In-Reply-To: <201111162235.pAGMZl0a039506@mail.r-bonomi.com> References: <201111162235.pAGMZl0a039506@mail.r-bonomi.com> Message-ID: Hi, If i remember right, Verizon Business has 3 or 4 different help desks. From my experience, none of the help desks know anything about the others. I dont have any numbers off hand unfortunately. -Grant On Wed, Nov 16, 2011 at 4:35 PM, Robert Bonomi wrote: > > Apologies for the noise, but I have been absolutely unable -- despite > literally *hours* of trying --to contact anyone at _any_ of the published > Verizon Business phone numbers who has any comprehension of what I am > talking about -- to wit: > > "I am looking for someone with _any_ awareness/knowledge of Verizon > Business's public-access anonymous FTP server, with the hostname > 'ftp.uu.net'." > > The published Verizon Business technical contact number -- both in 'whois' > for uu.net, and Jared's NOC contact list is only the 'ticket center', and > won't open a ticket for someone who is not Verizon customer. > > "Customer service" doesn't know what 'ftp' is, and vacillates between > thinking it is a circuit problem, or that I am having a problem with -my- > domain. > > Call-transfer to 'technical support' was answered by someone handling > 'delinquent payments'. Another transfer attempt ended up on somebody's > cell phone. > > > > From owen at delong.com Wed Nov 16 17:04:28 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Nov 2011 15:04:28 -0800 Subject: Arguing against using public IP space In-Reply-To: <26943894.3017.1321469896235.JavaMail.root@benjamin.baylink.com> References: <26943894.3017.1321469896235.JavaMail.root@benjamin.baylink.com> Message-ID: <5AAC007B-A26D-4417-8769-EB991ACF325B@delong.com> On Nov 16, 2011, at 10:58 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> In this case, a router with NAT is slightly more likely to fail closed than >> a router without NAT. > > "Slightly"? Continuing to assume here, as we have been, that the network > behind a NAT is *unroutable*, then a NAT router has, IME, *many* more obvious > possible failure modes which will make the internal network inaccessible from > outside than modes which cause the opposite. > What matters is not the number of failure modes, but, the probability of occurrence. Additionally, I have no reason to assume as you have been that private addresses behind the NAT are for some reason "unroutable". I would argue that this (sometimes) fallacious assumption may be one of the key dependencies in your argument. > If you're an attacker, targeting a behind-NAT box from the outside, then > if the NAT's working, you can hit directly any ports that are forwarded to it. > Correct. > If not, then you have to a) know the private IP of the box and b) be able to > get packets to the last upstream hop with source routing on them and c) the > box has to have failed (or been configured or built) in such a way as to > *listen* to source-routing. Those layers may have varying thicknesses, but > there *are* at least 3 more of them, *on top of* "did it fail in a way where > it's listening at all?". > Incorrect. a) I have to either know, detect, or guess at the private IP of the box (maybe). b) I have to get packets to the last upstream hop. Source routing is just one tool that could be used to do so. There are other possibilities. c) The box doesn't have to listen to source routing. It has to accept packets destined to it's exterior MAC address with an interior IP address (or other address that causes it to meaningfully forward things inside). >> However, a firewall without NAT is more likely >> to fail closed than a router with or without NAT and equally likely to >> a firewall with NAT. > > If it's a firewall that meets your definition of the word, as opposed to, > say, a shorewall box, a smoothwall box, a pf box, or any of the other 3 or > 4 dozen packaged linux based firewall routers of which there are *lots* out > there. Probably the most common failure more on those is "iptables accidentally > cleared; box routes all packets". > Actually, if you configure iptables on those boxes correctly and turn off ip forwarding (requiring instead that iptables actually do the forwarding, which is possible), clearing iptables does not cause it to forward all packets. > That's one failure to get to that point, insted of 2, 3 or 4. And since it's > human-based a lot of the time, it's probably even more likely. > I would argue it's at least two. First you had to configure iptables and/or the OS incorrectly in order for clearing iptables to cause that problem. Then you had to clear iptables. >> In other words, NAT doesn't really improve anything, >> but, the difference between the common failure modes of a firewall >> vs. a router are worthy of consideration. The infinitesimal advantage >> of NAT if you use a router instead of a firewall to perform the duties >> of a firewall is dramatically overshadowed by the costs and damage >> done by NAT. > > Costs already sunk, IME. Damage is a question-begging term here. > For IPv4, that argument can perhaps be made. Since the question was originally about the desirability of bringing NAT forward into IPv6, I don't think that argument actually holds water. >> OTOH, routers, being designed primarily to forward packets and having >> security appliance features added as a secondary capability will, in >> many cases, address most of these failures by passing packets which >> would not be permitted if properly configured and/or functioning. > > Yup. What I've been saying (or implying) right along. So, in networks, > or in seats, take your pick, does anyone have any deployment numbers on > router-based firewalls vs the other sort, whatever we're calling them? > I have no idea. I think based on my observations at a variety of companies it is a relatively even split, but, I will point out that the companies that pay any attention to security at all do, by and large, use firewalls (my definition) rather than attempt to press routers into that role. In fact, many use both a router with ACLs and/or stateful inspection at the ISP handoff in addition to a firewall behind it before you get to anything not intended to be on the public internet. >> Yes, they are identical and NAT makes no meaningful difference >> to the chances that undesired packets will be forwarded in the event >> of a catastrophic failure outside of these more common failure modes. > > I guess we're going to have to agree to disagree here; our respective > clients will decide what their opinions on that are. > I suspect so. Owen From morrowc.lists at gmail.com Wed Nov 16 19:13:52 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 16 Nov 2011 20:13:52 -0500 Subject: OT -- seeking a knowledgable AS 701 technical contact. In-Reply-To: References: <201111162235.pAGMZl0a039506@mail.r-bonomi.com> Message-ID: sorry grant :( (gmail user fail) On Wed, Nov 16, 2011 at 8:12 PM, Christopher Morrow wrote: > On Wed, Nov 16, 2011 at 8:12 PM, Christopher Morrow > wrote: >> what are you trying to do with ftp.uu.net? is it broken in some way? >> > > is it possibly that no login info works on it? > > $ ftp ftp.uu.net > Connected to ftp.uu.net. > 220 FTP server ready. > Name (ftp.uu.net:morrowc): anonymous > 331 Guest login ok, send your complete e-mail address as password. > Password: > 530 Login incorrect. > Login failed. > ftp> quit > > >> On Wed, Nov 16, 2011 at 5:51 PM, Grant Ridder wrote: >>> Hi, >>> >>> If i remember right, Verizon Business has 3 or 4 different help desks. >>> ?From my experience, none of the help desks know anything about the others. >>> ?I dont have any numbers off hand unfortunately. >>> >>> -Grant >>> >>> On Wed, Nov 16, 2011 at 4:35 PM, Robert Bonomi wrote: >>> >>>> >>>> Apologies for the noise, but I have been absolutely unable -- despite >>>> literally *hours* of trying --to contact anyone at _any_ of the published >>>> Verizon Business phone numbers who has any comprehension of what I am >>>> talking about -- to wit: >>>> >>>> ?"I am looking for someone with _any_ awareness/knowledge of Verizon >>>> ? Business's public-access anonymous FTP server, with the hostname >>>> ? 'ftp.uu.net'." >>>> >>>> The published Verizon Business technical contact number -- both in 'whois' >>>> for uu.net, and Jared's NOC contact list is only the 'ticket center', and >>>> won't open a ticket for someone who is not Verizon customer. >>>> >>>> "Customer service" doesn't know what 'ftp' is, and vacillates between >>>> thinking it is a circuit problem, or ?that I am having a problem with -my- >>>> domain. >>>> >>>> Call-transfer to 'technical support' was answered by someone handling >>>> 'delinquent payments'. ?Another transfer attempt ended up on somebody's >>>> cell phone. >>>> >>>> >>>> >>>> >>> >> > From rdobbins at arbor.net Wed Nov 16 22:40:37 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 17 Nov 2011 04:40:37 +0000 Subject: Last call for participation in the Arbor 2011 WISR opsec survey. Message-ID: [Apologies if you've already seen this message in other forums.] We'd be grateful if folks who've yet to do so would take a few minutes to participate in the 2011 WISR opsec survey - responses will be tabulated on Sunday, 20Nov11, and input from the operational community is greatly appreciated! This link redirects to the http/s-enabled survey tool: Thanks much! ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From davehart at gmail.com Wed Nov 16 23:56:07 2011 From: davehart at gmail.com (Dave Hart) Date: Thu, 17 Nov 2011 05:56:07 +0000 Subject: Arguing against using public IP space In-Reply-To: References: <721A510B-4D6E-4B20-B64B-0415DA72C315@delong.com> <26943894.3017.1321469896235.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Nov 16, 2011 at 20:38, Ray Soucy wrote: > I would go as far as to argue that the false sense of security > provided by NAT is more dangerous than any current threat that NAT > alone would prevent. Agreed, and I don't think that's going far at all. My opinion is _both_ stateful firewalls and NATs have been responsible for providing cover for those who fail to secure their endpoints. Yes, dropping a choke point in front of X hosts is X times easier than securing the X hosts. No, it didn't secure X hosts. "Outside is dangerous, inside is trusted" is the root of much current evil. Breaking end-to-end and encouraging everything that needs it to jump through ugly hoops such as UDP NAT traversal or carrying all sorts of non-HTTP over 80 and 443 has made it harder to secure networks, not easier. Cheers, Dave Hart From chase at stumpy.com Thu Nov 17 06:58:46 2011 From: chase at stumpy.com (A. Chase Turner) Date: Thu, 17 Nov 2011 06:58:46 -0600 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages Message-ID: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> I am seeking a $100 turnkey micro hardware appliance to plug into a LAN hub (behind a consumer-level cable modem) whose only purpose in life is to send heartbeat (and simple quality of service metrics) to a pre-configured central aggregation service on the WAN. Key requirement is the micro hardware appliance will be installed by non-technical elderly end-users -- so, it must be pre-configured and literally plug and play without need for the person installing the appliance to open a web browser to configure. And it must be a secure, good-reputation stand-alone hardware appliance ... because the heartbeat cannot / must not be a service installed on the end-user's computer where it becomes a support burden (e.g., did the end-user turn off their computer? Is their antivirus software blocking the outgoing heartbeat? That the end-user needs to enter a username/password/destination to enable the heartbeat, etc) There is a commercial turnkey solution that meets all the requirements except one -- that the solution cannot exceed $100 per remote appliance : http://www.myconnectionserver.com/learnmore/quality.html Question to the list: do you know of an alternative hardware solution under $100 that would suffice -- and be of such quality that an incumbent internet service provider will not thumb their nose at me when I call in to report remote users are down based upon the loss of heartbeats from the remote users? MOTIVATION FOR THE ABOVE Ten elderly neighbors to my mother in a rural area suffer frequent internet outages from their one (and only) incumbent cable internet service provider. All of them have learned they will encounter one of the following responses : "You are the only one reporting a problem" OR "We need three reports before we take action" OR "We fixed it. You need to re-boot your modem. (moments later after rebooting cable modem). It must be your computer that is the problem." OR "We know there is a problem. We'll send a crew out to repair the issue next week" These 10 elderly neighbors are fuming ... and they recently formed a call tree -- so that when one person suffers an internet outage, they call other neighbors in the call tree to see if they too have an outage ... and if so, each calls in an outage report (often 20 minutes of being placed on hold) The call tree is working (somewhat) to improve accountability and response by the cable service provider ... but it is a waste of their time as there is no formal "record" of outage events to spur the provider to provide refunds for unscheduled service outages. Thus, I am seeking a turnkey quality of service micro appliance that automates (and documents) service outage notifications .. so as to allow me (living in a city and my being on a different internet service provider) to take on the role of calling the rural cable service provider and claim (with authority) that I know that 10 individuals systems (who have the heartbeat appliance installed) are down and that the cable service provider needs to fix the issue... From jkrembs at fairpoint.com Thu Nov 17 07:14:47 2011 From: jkrembs at fairpoint.com (Krembs, Jesse) Date: Thu, 17 Nov 2011 08:14:47 -0500 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> Message-ID: http://www.appneta.com/ might fit your need sets. Jesse Krembs - Data Network Architecture & Planning FairPoint Communications | 800 Hinesburg Rd, South Burlington, VT 05403 | jkrembs at fairpoint.com www.FairPoint.com| 802.951.1519 office | 802.735.4886 cell -----Original Message----- From: A. Chase Turner [mailto:chase at stumpy.com] Sent: Thursday, November 17, 2011 7:59 AM To: nanog at nanog.org Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages I am seeking a $100 turnkey micro hardware appliance to plug into a LAN hub (behind a consumer-level cable modem) whose only purpose in life is to send heartbeat (and simple quality of service metrics) to a pre-configured central aggregation service on the WAN. Key requirement is the micro hardware appliance will be installed by non-technical elderly end-users -- so, it must be pre-configured and literally plug and play without need for the person installing the appliance to open a web browser to configure. And it must be a secure, good-reputation stand-alone hardware appliance ... because the heartbeat cannot / must not be a service installed on the end-user's computer where it becomes a support burden (e.g., did the end-user turn off their computer? Is their antivirus software blocking the outgoing heartbeat? That the end-user needs to enter a username/password/destination to enable the heartbeat, etc) There is a commercial turnkey solution that meets all the requirements except one -- that the solution cannot exceed $100 per remote appliance : http://www.myconnectionserver.com/learnmore/quality.html Question to the list: do you know of an alternative hardware solution under $100 that would suffice -- and be of such quality that an incumbent internet service provider will not thumb their nose at me when I call in to report remote users are down based upon the loss of heartbeats from the remote users? MOTIVATION FOR THE ABOVE Ten elderly neighbors to my mother in a rural area suffer frequent internet outages from their one (and only) incumbent cable internet service provider. All of them have learned they will encounter one of the following responses : "You are the only one reporting a problem" OR "We need three reports before we take action" OR "We fixed it. You need to re-boot your modem. (moments later after rebooting cable modem). It must be your computer that is the problem." OR "We know there is a problem. We'll send a crew out to repair the issue next week" These 10 elderly neighbors are fuming ... and they recently formed a call tree -- so that when one person suffers an internet outage, they call other neighbors in the call tree to see if they too have an outage ... and if so, each calls in an outage report (often 20 minutes of being placed on hold) The call tree is working (somewhat) to improve accountability and response by the cable service provider ... but it is a waste of their time as there is no formal "record" of outage events to spur the provider to provide refunds for unscheduled service outages. Thus, I am seeking a turnkey quality of service micro appliance that automates (and documents) service outage notifications .. so as to allow me (living in a city and my being on a different internet service provider) to take on the role of calling the rural cable service provider and claim (with authority) that I know that 10 individuals systems (who have the heartbeat appliance installed) are down and that the cable service provider needs to fix the issue... _______________________________________________________________________ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media. From jlewis at lewis.org Thu Nov 17 08:21:49 2011 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 17 Nov 2011 09:21:49 -0500 (EST) Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> Message-ID: On Thu, 17 Nov 2011, A. Chase Turner wrote: > I am seeking a $100 turnkey micro hardware appliance to plug into a LAN hub (behind a consumer-level cable modem) whose only purpose in life is to send heartbeat (and simple quality of service metrics) to a pre-configured central aggregation service on the WAN. It sounds like all you need is a preconfigured device that can boot up, be plugged into their LAN, do DHCP, and then talk to a "remote monitoring station" at configured intervals. If you're willing to do a bit of work pre-deployment, you could probably pick out an inexpensive DD-WRT/OpenWRT compatible device (i.e. WRT54GL, or maybe a more modern variant with more RAM/Flash) and with a tiny bit of scripting, you're done. Appneta looks even more appropriate, but I couldn't find anything about pricing on them. The WRT54GL is definitely sub $100. The trouble with this sort of thing is that from the docs, it seems alot of the hardware kind of sort of works mostly, and the manufacturers like to make serious enough changes with product revisions, such that you can't be sure a device will work based solely on the model number...you need to know what revision it is. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From davehart at gmail.com Thu Nov 17 08:53:26 2011 From: davehart at gmail.com (Dave Hart) Date: Thu, 17 Nov 2011 14:53:26 +0000 Subject: economic value of low AS numbers Message-ID: AS path geeks: At the risk of invoking ire and eliciting comparisons to the widely-reviled and growing practice of selling IPv4 addresses, I'm wondering if anyone has sold legacy AS numbers for quick cash. For example, NASA has AS23 among others, and does not use 23. Could they help fund a Mars mission study or two by offering it to the highest bidder? Or would they be lucky to top the $500 ARIN charges for a 32-bit ASN? How about AS1? Level3 uses a different AS. There's one nonpaying customer advertised from AS1, and despite their historical involvement creating the first predecessor of the internet, I bet DoD Network Information Center would be willing to use a different AS for the single prefix advertised by 1 now, if Level3 asked them nicely. Is Level3 leaving money on the table? I looked a bit for any transfer or change policy that might apply without success. Given these are legacy assignments, I have a feeling the POC could be changed without merger or acquisition, and I bet the AS descriptive name could be as well. I know I'd personally find a low AS number worth a pretty penny, if I could find a willing seller. I recognize there's no practical shortage of AS numbers. BGP's preference for low AS numbers doesn't come into play much. On the other hand, a low AS number can't hurt at the human level when negotiating peering or attracting customers. Cheers, Dave Hart From s+Mailinglisten.nanog at sloc.de Thu Nov 17 09:04:12 2011 From: s+Mailinglisten.nanog at sloc.de (Sebastian Spies) Date: Thu, 17 Nov 2011 16:04:12 +0100 Subject: economic value of low AS numbers In-Reply-To: References: Message-ID: <4EC5226C.30502@sloc.de> Hi Dave, On 17.11.2011 15:53, Dave Hart wrote: > I recognize there's no practical shortage of AS numbers. BGP's > preference for low AS numbers doesn't come into play much. On the > other hand, a low AS number can't hurt at the human level when > negotiating peering or attracting customers. Could you explain, what you mean with "BGP's preference for low AS numbers". Sebastian From harbor235 at gmail.com Thu Nov 17 09:04:36 2011 From: harbor235 at gmail.com (harbor235) Date: Thu, 17 Nov 2011 10:04:36 -0500 Subject: IP Options Message-ID: Is it just me or has there been an increase in packets with IP options set hitting our front door? There are ways to mitigate e.g. IP options selective discard, and ACL IP options support. ACL entries on the edge appear to be the best way identify and log the source. IP options selective discard drops packets silently so from my view they are not as effective. Is anyone doing anything else to identify and mitigate? I have been seeing hits on our firewalls but would rather take care of it at our edge with little or no impact. Mike From morrowc.lists at gmail.com Thu Nov 17 09:07:48 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 17 Nov 2011 10:07:48 -0500 Subject: IP Options In-Reply-To: References: Message-ID: got pcaps? On Thu, Nov 17, 2011 at 10:04 AM, harbor235 wrote: > Is it just me or has there been an increase in packets with IP options set > hitting > our front door? There are ways to mitigate e.g. IP options selective > discard, and ACL > IP options support. ACL entries on the edge appear to be the best > way identify and log the source. > IP options selective discard drops packets silently so from my view they > are not as effective. > > Is anyone doing anything else to identify and mitigate? ?I have been seeing > hits on our firewalls > but would rather take care of it at our edge with little or no impact. > > > Mike > From harbor235 at gmail.com Thu Nov 17 09:17:50 2011 From: harbor235 at gmail.com (harbor235) Date: Thu, 17 Nov 2011 10:17:50 -0500 Subject: IP Options In-Reply-To: References: Message-ID: Sure, but mirroring a port on the edge may not be the best way to go, ACL hits and logs dumped to syslog may be the best approach. So if your capturing traffic how are you mitigating this traffic with minimal impact? Mike On Thu, Nov 17, 2011 at 10:07 AM, Christopher Morrow < morrowc.lists at gmail.com> wrote: > got pcaps? > > On Thu, Nov 17, 2011 at 10:04 AM, harbor235 wrote: > > Is it just me or has there been an increase in packets with IP options > set > > hitting > > our front door? There are ways to mitigate e.g. IP options selective > > discard, and ACL > > IP options support. ACL entries on the edge appear to be the best > > way identify and log the source. > > IP options selective discard drops packets silently so from my view they > > are not as effective. > > > > Is anyone doing anything else to identify and mitigate? I have been > seeing > > hits on our firewalls > > but would rather take care of it at our edge with little or no impact. > > > > > > Mike > > > From bicknell at ufp.org Thu Nov 17 09:22:44 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 17 Nov 2011 07:22:44 -0800 Subject: economic value of low AS numbers In-Reply-To: References: Message-ID: <20111117152244.GA58484@ussenterprise.ufp.org> In a message written on Thu, Nov 17, 2011 at 02:53:26PM +0000, Dave Hart wrote: > I recognize there's no practical shortage of AS numbers. BGP's > preference for low AS numbers doesn't come into play much. On the > other hand, a low AS number can't hurt at the human level when > negotiating peering or attracting customers. I think you are confusing a "low ASN" with a "low router ID", or maybe "low neighbor IP address". For a refresher, see: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml A low ASN has no technical value, as far as I know. Socially perhaps some folks give additional respect/envy to those with low ASN's. There's an old joke in the peering community, ASN < 3 digits, peer with them. ASN with 4 digits, think about peering with them. ASN with 5 digits, forget it. However, I do believe it's just a joke, I'm sure more folks peer with Akamai (20940) than with NASA (24). -- 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 morrowc.lists at gmail.com Thu Nov 17 09:20:30 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 17 Nov 2011 10:20:30 -0500 Subject: IP Options In-Reply-To: References: Message-ID: On Thu, Nov 17, 2011 at 10:17 AM, harbor235 wrote: > Sure, but mirroring a port on the edge may not be the best way to go, ACL > hits and logs > dumped to syslog may be the best approach. So if your capturing traffic how > are you mitigating this traffic > with minimal impact? > sorry, my question was: "Do you have some pcaps, I'd be interested in seeing what sort of packets you are seeing with options added to them." I've seen things like mcast/pim/etc that will do this, and RSVP, I've not seen in-the-wild packets with options being a 'problem', though in theory they can be painful :( Some vendor gear has 'no ip-options' as an option...(which is really, 'ignore ip options', I believe), some has the ability to filter based on option(s). -chris > Mike > > On Thu, Nov 17, 2011 at 10:07 AM, Christopher Morrow > wrote: >> >> got pcaps? >> >> On Thu, Nov 17, 2011 at 10:04 AM, harbor235 wrote: >> > Is it just me or has there been an increase in packets with IP options >> > set >> > hitting >> > our front door? There are ways to mitigate e.g. IP options selective >> > discard, and ACL >> > IP options support. ACL entries on the edge appear to be the best >> > way identify and log the source. >> > IP options selective discard drops packets silently so from my view they >> > are not as effective. >> > >> > Is anyone doing anything else to identify and mitigate? ?I have been >> > seeing >> > hits on our firewalls >> > but would rather take care of it at our edge with little or no impact. >> > >> > >> > Mike >> > > > From dwbielawa at liberty.edu Thu Nov 17 09:30:01 2011 From: dwbielawa at liberty.edu (Bielawa, Daniel Walter) Date: Thu, 17 Nov 2011 15:30:01 +0000 Subject: Bandwidth Upgrade Message-ID: Greetings, My team is in the process of putting some documentation together to justify a bandwidth upgrade. I am asking if you would be willing to reply back to me, with how you decide that it is time to upgrade your bandwidth. On-line or off-line reply's will be acceptable. Thank You Daniel Bielawa Network Engineer Liberty University Network Services (434)592-7987 LIBERTY UNIVERSITY 40 Years of Training Champions for Christ: 1971-2011 From rirving at antient.org Thu Nov 17 09:45:50 2011 From: rirving at antient.org (Richard Irving) Date: Thu, 17 Nov 2011 10:45:50 -0500 Subject: Bandwidth Upgrade In-Reply-To: References: Message-ID: <4EC52C2E.2020508@antient.org> "40 Years of Training Champions for Christ: " You would have thought they would have trained a /Network Engineer/, or two.. in those 40 years, wouldn't you ? ;-) On 11/17/2011 10:30 AM, Bielawa, Daniel Walter wrote: > Greetings, > My team is in the process of putting some documentation together to justify a bandwidth upgrade. I am asking if you would be willing to reply back to me, with how you decide that it is time to upgrade your bandwidth. On-line or off-line reply's will be acceptable. > > Thank You > > Daniel Bielawa > Network Engineer > Liberty University Network Services > > (434)592-7987 > > LIBERTY UNIVERSITY > 40 Years of Training Champions for Christ: 1971-2011 > From kclapp at staff.gwi.net Thu Nov 17 09:54:51 2011 From: kclapp at staff.gwi.net (Karl Clapp) Date: Thu, 17 Nov 2011 10:54:51 -0500 Subject: Bandwidth Upgrade In-Reply-To: References: Message-ID: Ideally, when our 95th-percentile hits 65% utilization, we begin the pricing and planning process and its up on peoples radar. Once the 95th-percentile hits 80-85% we start planning the maintenance and execute the upgrades. I say ideally, because in a perfect world this would happen 100% of the time. We try to upgrade when the 95th is at 80-85%, because the 95th-percentiles is based off 5-min polls, so I am sure traffic is spiking higher at peak times. Cheers.. ~Karl On Thu, Nov 17, 2011 at 10:30 AM, Bielawa, Daniel Walter < dwbielawa at liberty.edu> wrote: > Greetings, > My team is in the process of putting some documentation > together to justify a bandwidth upgrade. I am asking if you would be > willing to reply back to me, with how you decide that it is time to upgrade > your bandwidth. On-line or off-line reply's will be acceptable. > > Thank You > > Daniel Bielawa > Network Engineer > Liberty University Network Services > > (434)592-7987 > > LIBERTY UNIVERSITY > 40 Years of Training Champions for Christ: 1971-2011 > > From keegan.holley at sungard.com Thu Nov 17 09:54:43 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 17 Nov 2011 10:54:43 -0500 Subject: Bandwidth Upgrade In-Reply-To: References: Message-ID: Start with why you think it's necessary and what happens if mgt doesn't listen. Bandwidth is like electricity in a sense. Either you have what you need or you go belly up until some utility company can give you more juice. If you notice a growth pattern and are trying to get in front of it that's obviously important. If you are approaching the point where a single link in redundant pairs can't handle the full load during an outage, that's important as well. Knowing how to use power point helps too (avoid animation). Maybe I don't understand the question but this is usually a no-brainer especially if there is an existing capacity management strategy. 2011/11/17 Bielawa, Daniel Walter > Greetings, > My team is in the process of putting some documentation > together to justify a bandwidth upgrade. I am asking if you would be > willing to reply back to me, with how you decide that it is time to upgrade > your bandwidth. On-line or off-line reply's will be acceptable. > > Thank You > > Daniel Bielawa > Network Engineer > Liberty University Network Services > > (434)592-7987 > > LIBERTY UNIVERSITY > 40 Years of Training Champions for Christ: 1971-2011 > > > From kloch at kl.net Thu Nov 17 09:55:41 2011 From: kloch at kl.net (Kevin Loch) Date: Thu, 17 Nov 2011 10:55:41 -0500 Subject: economic value of low AS numbers In-Reply-To: References: Message-ID: <4EC52E7D.5040403@kl.net> Dave Hart wrote: > AS path geeks: > > At the risk of invoking ire and eliciting comparisons to the > widely-reviled and growing practice of selling IPv4 addresses, I'm > wondering if anyone has sold legacy AS numbers for quick cash. I have heard first hand stories of folks being offered 5 figures for four digit ASN's in the past (and they did not sell btw). That was before ARIN started recycling unused short ASN's two years ago. There was a three month period in 2009 where almost every ASN assigned by ARIN was < 10000 as they burned through the backlog. - Kevin From keegan.holley at sungard.com Thu Nov 17 10:08:09 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 17 Nov 2011 11:08:09 -0500 Subject: Bandwidth Upgrade In-Reply-To: References: Message-ID: That depends on the network configuration though. If you have redundant links and one link is at 65% and the other is at 35% or more you won't be able to get through a circuit flap or outage without dropping packets. 2011/11/17 Karl Clapp > Ideally, when our 95th-percentile hits 65% utilization, we begin the > pricing and planning process and its up on peoples radar. Once the > 95th-percentile hits 80-85% we start planning the maintenance and execute > the upgrades. I say ideally, because in a perfect world this would happen > 100% of the time. > > We try to upgrade when the 95th is at 80-85%, because the 95th-percentiles > is based off 5-min polls, so I am sure traffic is spiking higher at peak > times. > > Cheers.. > > ~Karl > > On Thu, Nov 17, 2011 at 10:30 AM, Bielawa, Daniel Walter < > dwbielawa at liberty.edu> wrote: > > > Greetings, > > My team is in the process of putting some documentation > > together to justify a bandwidth upgrade. I am asking if you would be > > willing to reply back to me, with how you decide that it is time to > upgrade > > your bandwidth. On-line or off-line reply's will be acceptable. > > > > Thank You > > > > Daniel Bielawa > > Network Engineer > > Liberty University Network Services > > > > (434)592-7987 > > > > LIBERTY UNIVERSITY > > 40 Years of Training Champions for Christ: 1971-2011 > > > > > > From keegan.holley at sungard.com Thu Nov 17 10:16:57 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 17 Nov 2011 11:16:57 -0500 Subject: economic value of low AS numbers In-Reply-To: <4EC52E7D.5040403@kl.net> References: <4EC52E7D.5040403@kl.net> Message-ID: Besides standing at the water cooler at 1:23PM on 12/3 telling AS123 jokes I'm not sure a particular AS number has any relevance or any monetary value unless there is scarcity. 2011/11/17 Kevin Loch > Dave Hart wrote: > >> AS path geeks: >> >> At the risk of invoking ire and eliciting comparisons to the >> widely-reviled and growing practice of selling IPv4 addresses, I'm >> wondering if anyone has sold legacy AS numbers for quick cash. >> > > I have heard first hand stories of folks being offered 5 figures > for four digit ASN's in the past (and they did not sell btw). That was > before ARIN started recycling unused short ASN's two years ago. There > was a three month period in 2009 where almost every ASN assigned by ARIN > was < 10000 as they burned through the backlog. > > - Kevin > > > From kclapp at staff.gwi.net Thu Nov 17 10:18:07 2011 From: kclapp at staff.gwi.net (Karl Clapp) Date: Thu, 17 Nov 2011 11:18:07 -0500 Subject: Bandwidth Upgrade In-Reply-To: References: Message-ID: Very true.. It is an open-ended question that can have many answers, especially without knowing their design... On Thu, Nov 17, 2011 at 11:08 AM, Keegan Holley wrote: > That depends on the network configuration though. If you have redundant > links and one link is at 65% and the other is at 35% or more you won't be > able to get through a circuit flap or outage without dropping packets. > > > > 2011/11/17 Karl Clapp > >> Ideally, when our 95th-percentile hits 65% utilization, we begin the >> pricing and planning process and its up on peoples radar. Once the >> 95th-percentile hits 80-85% we start planning the maintenance and execute >> the upgrades. I say ideally, because in a perfect world this would happen >> 100% of the time. >> >> We try to upgrade when the 95th is at 80-85%, because the 95th-percentiles >> is based off 5-min polls, so I am sure traffic is spiking higher at peak >> times. >> >> Cheers.. >> >> ~Karl >> >> On Thu, Nov 17, 2011 at 10:30 AM, Bielawa, Daniel Walter < >> dwbielawa at liberty.edu> wrote: >> >> > Greetings, >> > My team is in the process of putting some documentation >> > together to justify a bandwidth upgrade. I am asking if you would be >> > willing to reply back to me, with how you decide that it is time to >> upgrade >> > your bandwidth. On-line or off-line reply's will be acceptable. >> > >> > Thank You >> > >> > Daniel Bielawa >> > Network Engineer >> > Liberty University Network Services >> > >> > (434)592-7987 >> > >> > LIBERTY UNIVERSITY >> > 40 Years of Training Champions for Christ: 1971-2011 >> > >> > >> >> > From korvus at comcast.net Thu Nov 17 10:26:00 2011 From: korvus at comcast.net (Steve Polyack) Date: Thu, 17 Nov 2011 11:26:00 -0500 Subject: Comcast DNS Contact? Message-ID: <4EC53598.4040600@comcast.net> Could a Comcast DNS admin please contact me off-list? We're seeing lots of queries from local Comcast resolvers for a domain which we haven't hosted in nearly a year. Thanks, Steve From henry at AegisInfoSys.com Thu Nov 17 10:36:06 2011 From: henry at AegisInfoSys.com (Henry Yen) Date: Thu, 17 Nov 2011 11:36:06 -0500 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> Message-ID: <20111117163606.GP29174@nntp.AegisInfoSys.com> On Thu, Nov 17, 2011 at 06:58:46AM -0600, A. Chase Turner wrote: > I am seeking a $100 turnkey micro hardware appliance to plug into a LAN > hub (behind a consumer-level cable modem) whose only purpose in life is > to send heartbeat (and simple quality of service metrics) to a > pre-configured central aggregation service on the WAN. > Question to the list: do you know of an alternative hardware solution > under $100 that would suffice -- and be of such quality that an > incumbent internet service provider will not thumb their nose at me when > I call in to report remote users are down based upon the loss of > heartbeats from the remote users? Pretty much any programmable/flashable little device would be sufficient, I think. Besides WRTG wireless routers as mentioned elsewhere, the smallest device I've set up so far was one of those Seagate docking stations (I think it was a "FreeAgent"?) which I got for $25 new; flashing it to Linux was straightforward, albeit non-trivial. Other cheap devices that are potentially flashable abound (Raspberry Pi, anyone?), including possibly teensy terminal servers, IP phones, used eBay old smartphone with a cracked screen for $20, etc. The ability to run PoE might also be an attractive feature. > The call tree is working (somewhat) to improve accountability and > response by the cable service provider ... but it is a waste of their > time as there is no formal "record" of outage events to spur the > provider to provide refunds for unscheduled service outages. Thus, I > am seeking a turnkey quality of service micro appliance that automates > (and documents) service outage notifications .. so as to allow me > (living in a city and my being on a different internet service provider) > to take on the role of calling the rural cable service provider and > claim (with authority) that I know that 10 individuals systems (who have > the heartbeat appliance installed) are down and that the cable service > provider needs to fix the issue... In this scenario, it sounds like you're depending on end-to-end connectivity, so remember that loss of ping/heartbeat isn't a guarantee that the failure isn't due to something else, though... -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From r.engehausen at gmail.com Thu Nov 17 10:59:46 2011 From: r.engehausen at gmail.com (Roy) Date: Thu, 17 Nov 2011 08:59:46 -0800 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> Message-ID: <4EC53D82.6000009@gmail.com> I will second the WRT54GL with OpenWRT. I have a number of them deployed. I run an OpenVPN tunnel from the WRT54GL to a Linux server at our shop so I can remotely log into the box and carry out any tests or changes needed. On 11/17/2011 6:21 AM, Jon Lewis wrote: > On Thu, 17 Nov 2011, A. Chase Turner wrote: > >> I am seeking a $100 turnkey micro hardware appliance to plug into a >> LAN hub (behind a consumer-level cable modem) whose only purpose in >> life is to send heartbeat (and simple quality of service metrics) to >> a pre-configured central aggregation service on the WAN. > > It sounds like all you need is a preconfigured device that can boot > up, be plugged into their LAN, do DHCP, and then talk to a "remote > monitoring station" at configured intervals. If you're willing to do > a bit of work pre-deployment, you could probably pick out an > inexpensive DD-WRT/OpenWRT compatible device (i.e. WRT54GL, or maybe a > more modern variant with more RAM/Flash) and with a tiny bit of > scripting, you're done. > > Appneta looks even more appropriate, but I couldn't find anything > about pricing on them. The WRT54GL is definitely sub $100. The > trouble with this sort of thing is that from the docs, it seems alot > of the hardware kind of sort of works mostly, and the manufacturers > like to make serious enough changes with product revisions, such that > you can't be sure a device will work based solely on the model > number...you need to know what revision it is. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > From julien at gormotte.info Thu Nov 17 11:20:35 2011 From: julien at gormotte.info (Julien Gormotte) Date: Thu, 17 Nov 2011 18:20:35 +0100 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: <4EC53D82.6000009@gmail.com> References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> <4EC53D82.6000009@gmail.com> Message-ID: <20111117182035.3d11d7e2@jupc> Le Thu, 17 Nov 2011 08:59:46 -0800, Roy a ?crit : > I will second the WRT54GL with OpenWRT. That's one possibility. Any router compatible with OpenWRT would do an acceptable job. Another possibility may be more interesting : http://pcengines.ch/alix3d2.htm These ones are cheap (around 70 $ iirc), very low-consumption (around 5W), can use PoE, and you can put a lot of systems on it. From Debian to FreeBSD, OpenBSD... And it is quite powerful, so easy to use for something else (I use some as backup servers, with a USB disk, for very cheap systems). From davehart at gmail.com Thu Nov 17 11:22:44 2011 From: davehart at gmail.com (Dave Hart) Date: Thu, 17 Nov 2011 17:22:44 +0000 Subject: economic value of low AS numbers In-Reply-To: <20111117152244.GA58484@ussenterprise.ufp.org> References: <20111117152244.GA58484@ussenterprise.ufp.org> Message-ID: On Thu, Nov 17, 2011 at 15:22, Leo Bicknell wrote: > In a message written on Thu, Nov 17, 2011 at 02:53:26PM +0000, Dave Hart wrote: >> I recognize there's no practical shortage of AS numbers. ?BGP's >> preference for low AS numbers doesn't come into play much. ?On the >> other hand, a low AS number can't hurt at the human level when >> negotiating peering or attracting customers. > > I think you are confusing a "low ASN" with a "low router ID", or > maybe "low neighbor IP address". > > For a refresher, see: > http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml > > A low ASN has no technical value, as far as I know. I am exposed! I have never connected to a router that wasn't a looking glass. I am not worthy... I did try to hide that fact by doing a little research. I was fooled by: "Prefer the route learned from the BGP speaker with the numerically lowest BGP identifier" and (mis)interpreted BGP identifier as ASN. > ?Socially perhaps > some folks give additional respect/envy to those with low ASN's. > There's an old joke in the peering community, ASN < 3 digits, peer > with them. ?ASN with 4 digits, think about peering with them. ?ASN > with 5 digits, forget it. ?However, I do believe it's just a joke, > I'm sure more folks peer with Akamai (20940) than with NASA (24). That's both funny and helpful, thanks. Dave Hart From sethm at rollernet.us Thu Nov 17 11:34:26 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 17 Nov 2011 09:34:26 -0800 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> Message-ID: <4EC545A2.9040208@rollernet.us> On 11/17/11 4:58 AM, A. Chase Turner wrote: > I am seeking a $100 turnkey micro hardware appliance to plug into a LAN hub (behind a consumer-level cable modem) whose only purpose in life is to send heartbeat (and simple quality of service metrics) to a pre-configured central aggregation service on the WAN. > > Key requirement is the micro hardware appliance will be installed by non-technical elderly end-users -- so, it must be pre-configured and literally plug and play without need for the person installing the appliance to open a web browser to configure. And it must be a secure, good-reputation stand-alone hardware appliance ... because the heartbeat cannot / must not be a service installed on the end-user's computer where it becomes a support burden (e.g., did the end-user turn off their computer? Is their antivirus software blocking the outgoing heartbeat? That the end-user needs to enter a username/password/destination to enable the heartbeat, etc) > Mikrotik RouterBoards are low cost and robust. It can be scripted to do things like call a specific URL every X minutes. Some models have just a single Ethernet port as well (they're designed to be used as a wireless AP/CPE with an add-in mini PCI card) for even less confusion about plugging it in. ~Seth From owen at delong.com Thu Nov 17 11:32:07 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Nov 2011 09:32:07 -0800 Subject: economic value of low AS numbers In-Reply-To: References: Message-ID: <899CA84F-A8E7-4D84-9517-FEB50A3E1379@delong.com> On Nov 17, 2011, at 6:53 AM, Dave Hart wrote: > AS path geeks: > > At the risk of invoking ire and eliciting comparisons to the > widely-reviled and growing practice of selling IPv4 addresses, I'm > wondering if anyone has sold legacy AS numbers for quick cash. > > For example, NASA has AS23 among others, and does not use 23. Could > they help fund a Mars mission study or two by offering it to the > highest bidder? Or would they be lucky to top the $500 ARIN charges > for a 32-bit ASN? ARIN also charges $500 for 16 bit ASNs and still has those available. > I recognize there's no practical shortage of AS numbers. BGP's > preference for low AS numbers doesn't come into play much. On the > other hand, a low AS number can't hurt at the human level when > negotiating peering or attracting customers. > ARIN policy does not currently support the transfer of AS numbers in this manner. IMHO, it shouldn't, but, there is a policy proposal to do so. I suggest that anyone interested in this subject review the proposal and join the discussion on arin-ppml. Owen (Speaking only for myself and not on behalf of the ARIN AC) From owen at delong.com Thu Nov 17 11:35:59 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Nov 2011 09:35:59 -0800 Subject: Fwd: Welcome to the "Marketing" mailing list References: Message-ID: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> Um, Can someone explain this one to me? 1. Why was such a list created? 2. Why was I automatically subscribed to it? 3. Why was this done without notice to the community? Thanks, Owen Begin forwarded message: > From: marketing-request at nanog.org > Date: November 17, 2011 7:17:00 AM PST > To: owen at delong.com > Subject: Welcome to the "Marketing" mailing list > > Welcome to the Marketing at nanog.org mailing list! > > To post to this list, send your message to: > > marketing at nanog.org > > General information about the mailing list is at: > > https://mailman.nanog.org/mailman/listinfo/marketing > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > https://mailman.nanog.org/mailman/options/marketing/owen%40delong.com From paul4004 at gmail.com Thu Nov 17 11:54:38 2011 From: paul4004 at gmail.com (PC) Date: Thu, 17 Nov 2011 10:54:38 -0700 Subject: Bandwidth Upgrade In-Reply-To: References: Message-ID: Yes, lot's of missing pieces here. It depends on your tolerance for delayed and dropped packets during periods of high usage, connection media type, speeds we're talking about, who your users are, and the applications you must support. Generally if your graphs says 75% peak usage, you should have upgraded. If you're output drop counters are unacceptable you also need an upgrade. However cases with a a subrate access network (IE: users capped at 5 meg, on a 1000 megabit upstream pipe) can get away with running closer to capacity a lot more than those with a few enterprise "bursty" customers who can single handidly burst 50% of your upstream), and demand no dropped or delayed traffic in their SLAs. Also consider failover issues if you're redundantly connected. On Thu, Nov 17, 2011 at 9:18 AM, Karl Clapp wrote: > Very true.. It is an open-ended question that can have many answers, > especially without knowing their design... > > > On Thu, Nov 17, 2011 at 11:08 AM, Keegan Holley > wrote: > > > That depends on the network configuration though. If you have redundant > > links and one link is at 65% and the other is at 35% or more you won't be > > able to get through a circuit flap or outage without dropping packets. > > > > > > > > 2011/11/17 Karl Clapp > > > >> Ideally, when our 95th-percentile hits 65% utilization, we begin the > >> pricing and planning process and its up on peoples radar. Once the > >> 95th-percentile hits 80-85% we start planning the maintenance and > execute > >> the upgrades. I say ideally, because in a perfect world this would > happen > >> 100% of the time. > >> > >> We try to upgrade when the 95th is at 80-85%, because the > 95th-percentiles > >> is based off 5-min polls, so I am sure traffic is spiking higher at peak > >> times. > >> > >> Cheers.. > >> > >> ~Karl > >> > >> On Thu, Nov 17, 2011 at 10:30 AM, Bielawa, Daniel Walter < > >> dwbielawa at liberty.edu> wrote: > >> > >> > Greetings, > >> > My team is in the process of putting some documentation > >> > together to justify a bandwidth upgrade. I am asking if you would be > >> > willing to reply back to me, with how you decide that it is time to > >> upgrade > >> > your bandwidth. On-line or off-line reply's will be acceptable. > >> > > >> > Thank You > >> > > >> > Daniel Bielawa > >> > Network Engineer > >> > Liberty University Network Services > >> > > >> > (434)592-7987 > >> > > >> > LIBERTY UNIVERSITY > >> > 40 Years of Training Champions for Christ: 1971-2011 > >> > > >> > > >> > >> > > > From shrdlu at deaddrop.org Thu Nov 17 11:55:45 2011 From: shrdlu at deaddrop.org (Lynda) Date: Thu, 17 Nov 2011 09:55:45 -0800 Subject: Fwd: Welcome to the "Marketing" mailing list In-Reply-To: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> References: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> Message-ID: <4EC54AA1.5070607@deaddrop.org> On 11/17/2011 9:35 AM, Owen DeLong wrote: > Um, > > Can someone explain this one to me? > > 1. Why was such a list created? > 2. Why was I automatically subscribed to it? > 3. Why was this done without notice to the community? Before this erupts in yet another thread, this was already asked (and answered) on Futures. Betty had an oops moment this morning, and has since repaired it. Followups to Futures. -- You've confused equality of opportunity for equality of outcomes, and have seriously confused justice with equality. (Woodchuck) From betty at newnog.org Thu Nov 17 11:59:38 2011 From: betty at newnog.org (Betty Burke ) Date: Thu, 17 Nov 2011 12:59:38 -0500 Subject: Welcome to the "Marketing" mailing list In-Reply-To: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> References: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> Message-ID: So Sorry Owen, as explained earlier, my mistake in list management! All resolved and those members added to the wrong list have been removed. Again sorry for the email noise. Sincerely, Betty On Thu, Nov 17, 2011 at 12:35 PM, Owen DeLong wrote: > Um, > > Can someone explain this one to me? > > 1. Why was such a list created? > 2. Why was I automatically subscribed to it? > 3. Why was this done without notice to the community? > > Thanks, > > Owen > > Begin forwarded message: > > > From: marketing-request at nanog.org > > Date: November 17, 2011 7:17:00 AM PST > > To: owen at delong.com > > Subject: Welcome to the "Marketing" mailing list > > > > Welcome to the Marketing at nanog.org mailing list! > > > > To post to this list, send your message to: > > > > marketing at nanog.org > > > > General information about the mailing list is at: > > > > https://mailman.nanog.org/mailman/listinfo/marketing > > > > If you ever want to unsubscribe or change your options (eg, switch to > > or from digest mode, change your password, etc.), visit your > > subscription page at: > > > > https://mailman.nanog.org/mailman/options/marketing/owen%40delong.com > > -- Betty Burke NewNOG/NANOG Executive Director Office (810) 214-1218 Direct (510) 492-4030 From owen at delong.com Thu Nov 17 12:08:05 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Nov 2011 10:08:05 -0800 Subject: economic value of low AS numbers In-Reply-To: References: <899CA84F-A8E7-4D84-9517-FEB50A3E1379@delong.com> Message-ID: On Nov 17, 2011, at 9:44 AM, Dave Hart wrote: > On Thu, Nov 17, 2011 at 17:32, Owen DeLong wrote: >> ARIN policy does not currently support the transfer of AS numbers in >> this manner. IMHO, it shouldn't, but, there is a policy proposal to >> do so. I suggest that anyone interested in this subject review the >> proposal and join the discussion on arin-ppml. >> >> Owen >> (Speaking only for myself and not on behalf of the ARIN AC) > > Thanks. My policy search was focused on arin.net, but I didn't find > what you apparently know. In particular, there's no reference to > transfer of AS numbers in the NRPM, nor could I find any policy or > procedure regarding updating POC or any other information associated > with an AS registration. Do keep in mind I was referring specifically > to legacy AS numbers, where it is not clear to me ARIN policy would > control, particularly in the case of a merger or acquisition. > ARIN is the successor registry to the prior registries that distributed AS Numbers, so, I believe that they are subject to ARIN policy. I realize there are others that have different opinions, but I really don't want to engage in that debate here. ARIN policy currently does not provide for transfer of AS numbers other than through NRPM 8.2 for merger/acquisition. Martin Hannigan proposed the following: http://lists.arin.net/pipermail/arin-ppml/2011-September/023136.html which is on the AC docket as Proposal 158. Personally, I do not favor this proposal. I don't think there is good reason to allow the transfer of ASNs and I think that allowing transfers of IPv6 numbers is a really bad idea. However, anyone with an interest in this proposal, whether in favor or opposed should bring their opinion to arin-ppml. > Would you refer me to the current ARIN policy regarding transfers of > or updates to ASN registrations? > Updates are processed through the standard ARIN-online process like updates to any other number resources. If you want additional assistance on that, I suggest contacting the registration services help desk by phone (703-227-0660) or email (hostmaster at arin.net). Owen From rgolodner at infratection.com Thu Nov 17 12:15:02 2011 From: rgolodner at infratection.com (Richard Golodner) Date: Thu, 17 Nov 2011 12:15:02 -0600 Subject: Fwd: Welcome to the "Marketing" mailing list In-Reply-To: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> References: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> Message-ID: <1321553702.31117.11.camel@Andromeda> On Thu, 2011-11-17 at 09:35 -0800, Owen DeLong wrote: > Can someone explain this one to me? > > 1. Why was such a list created? > 2. Why was I automatically subscribed to it? > 3. Why was this done without notice to the community? > > Thanks, This has a lot of us wondering the same as Owen. This is also not typical of how NANOG does things. Hopefully as the day progresses we will get some insight. Richard Golodner From drc at virtualized.org Thu Nov 17 12:21:59 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 17 Nov 2011 10:21:59 -0800 Subject: economic value of low AS numbers In-Reply-To: References: <4EC52E7D.5040403@kl.net> Message-ID: On Nov 17, 2011, at 8:16 AM, Keegan Holley wrote: > Besides standing at the water cooler at 1:23PM on 12/3 telling AS123 jokes > I'm not sure a particular AS number has any relevance or any monetary value > unless there is scarcity. You are discounting (pun intended) vanity and marketing. I am no longer surprised at what people will be willing to pay (sometimes astonishing amounts of) money for. Regards, -drc From Valdis.Kletnieks at vt.edu Thu Nov 17 12:21:20 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 17 Nov 2011 13:21:20 -0500 Subject: Welcome to the "Marketing" mailing list In-Reply-To: Your message of "Thu, 17 Nov 2011 12:59:38 EST." References: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> Message-ID: <8647.1321554080@turing-police.cc.vt.edu> On Thu, 17 Nov 2011 12:59:38 EST, "Betty Burke " said: > So Sorry Owen, as explained earlier, my mistake in list management! All > resolved and those members added to the wrong list have been removed. It's OK.. Everybody's entitled to at least one low-caffeine low-impact faux pax a year. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From hank at efes.iucc.ac.il Thu Nov 17 12:26:31 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 17 Nov 2011 20:26:31 +0200 Subject: economic value of low AS numbers In-Reply-To: References: <4EC52E7D.5040403@kl.net> Message-ID: <5.1.0.14.2.20111117202559.00c196d8@efes.iucc.ac.il> At 10:21 17/11/2011 -0800, David Conrad wrote: >On Nov 17, 2011, at 8:16 AM, Keegan Holley wrote: > > Besides standing at the water cooler at 1:23PM on 12/3 telling AS123 jokes > > I'm not sure a particular AS number has any relevance or any monetary value > > unless there is scarcity. > >You are discounting (pun intended) vanity and marketing. I am no longer >surprised at what people will be willing to pay (sometimes astonishing >amounts of) money for. AS-envy. -Hank From betty at newnog.org Thu Nov 17 12:34:15 2011 From: betty at newnog.org (Betty Burke ) Date: Thu, 17 Nov 2011 13:34:15 -0500 Subject: Fwd: Welcome to the "Marketing" mailing list In-Reply-To: <1321553702.31117.11.camel@Andromeda> References: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> <1321553702.31117.11.camel@Andromeda> Message-ID: Everyone: This was truly just a honest mistake on my part. You are all right, should not have happened and I apologize. Marketing at nanog.org is a list used in connection with Sponsorship inquiries/activity. refer to http://www.nanog.org/sponsors/ Membership of marketing at nanog.or is the Development Committee and NANOG Staff. As I indicated, I was planning to update the members at nanog,org list, and just happened to be in the wrong interface. All best. Betty On Thu, Nov 17, 2011 at 1:15 PM, Richard Golodner < rgolodner at infratection.com> wrote: > On Thu, 2011-11-17 at 09:35 -0800, Owen DeLong wrote: > > Can someone explain this one to me? > > > > 1. Why was such a list created? > > 2. Why was I automatically subscribed to it? > > 3. Why was this done without notice to the community? > > > > Thanks, > This has a lot of us wondering the same as Owen. > This is also not typical of how NANOG does things. Hopefully as the > day > progresses we will get some insight. > Richard Golodner > > > -- Betty Burke NewNOG/NANOG Executive Director Office (810) 214-1218 Direct (510) 492-4030 From heather.schiller at verizon.com Thu Nov 17 12:45:36 2011 From: heather.schiller at verizon.com (Schiller, Heather A) Date: Thu, 17 Nov 2011 13:45:36 -0500 Subject: OT -- seeking a knowledgable AS 701 technical contact. In-Reply-To: <201111162235.pAGMZl0a039506@mail.r-bonomi.com> References: <201111162235.pAGMZl0a039506@mail.r-bonomi.com> Message-ID: Hi! Now that you have my email address, ping me offline and I'll see if I can help. --Heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241 security at verizonbusiness.com -----Original Message----- From: Robert Bonomi [mailto:bonomi at mail.r-bonomi.com] Sent: Wednesday, November 16, 2011 5:36 PM To: nanog at nanog.org Subject: OT -- seeking a knowledgable AS 701 technical contact. Apologies for the noise, but I have been absolutely unable -- despite literally *hours* of trying --to contact anyone at _any_ of the published Verizon Business phone numbers who has any comprehension of what I am talking about -- to wit: "I am looking for someone with _any_ awareness/knowledge of Verizon Business's public-access anonymous FTP server, with the hostname 'ftp.uu.net'." The published Verizon Business technical contact number -- both in 'whois' for uu.net, and Jared's NOC contact list is only the 'ticket center', and won't open a ticket for someone who is not Verizon customer. "Customer service" doesn't know what 'ftp' is, and vacillates between thinking it is a circuit problem, or that I am having a problem with -my- domain. Call-transfer to 'technical support' was answered by someone handling 'delinquent payments'. Another transfer attempt ended up on somebody's cell phone. From keegan.holley at sungard.com Thu Nov 17 12:55:46 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 17 Nov 2011 13:55:46 -0500 Subject: economic value of low AS numbers In-Reply-To: References: <4EC52E7D.5040403@kl.net> Message-ID: 2011/11/17 David Conrad > On Nov 17, 2011, at 8:16 AM, Keegan Holley wrote: > > Besides standing at the water cooler at 1:23PM on 12/3 telling AS123 > jokes > > I'm not sure a particular AS number has any relevance or any monetary > value > > unless there is scarcity. > > You are discounting (pun intended) vanity and marketing. I am no longer > surprised at what people will be willing to pay (sometimes astonishing > amounts of) money for. > > I suppose I can't argue with that, but anyone technical enough to know what an AS is should know better. Also, would it really count? What if I opened a small ISP in some carrier hotel and paid 1000 bucks for AS 1. I'm not sure I'd want to sign a contract with someone dumb enough to think I was the first company on the internet. From rirving at antient.org Thu Nov 17 13:01:31 2011 From: rirving at antient.org (Richard Irving) Date: Thu, 17 Nov 2011 14:01:31 -0500 Subject: economic value of low AS numbers In-Reply-To: References: <4EC52E7D.5040403@kl.net> Message-ID: <4EC55A0B.2070103@antient.org> Since AS1 (BBNPLANET) was bought for around 666 million way back when, as I recall.. your 1k purchase would be -outstanding-. On 11/17/2011 01:55 PM, Keegan Holley wrote: > 2011/11/17 David Conrad > >> On Nov 17, 2011, at 8:16 AM, Keegan Holley wrote: >>> Besides standing at the water cooler at 1:23PM on 12/3 telling AS123 >> jokes >>> I'm not sure a particular AS number has any relevance or any monetary >> value >>> unless there is scarcity. >> You are discounting (pun intended) vanity and marketing. I am no longer >> surprised at what people will be willing to pay (sometimes astonishing >> amounts of) money for. >> >> I suppose I can't argue with that, but anyone technical enough to know > what an AS is should know better. Also, would it really count? What if I > opened a small ISP in some carrier hotel and paid 1000 bucks for AS 1. I'm > not sure I'd want to sign a contract with someone dumb enough to think I > was the first company on the internet. From rs at seastrom.com Thu Nov 17 13:06:49 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 17 Nov 2011 14:06:49 -0500 Subject: Fwd: Welcome to the "Marketing" mailing list In-Reply-To: (Betty Burke's message of "Thu, 17 Nov 2011 13:34:15 -0500") References: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> <1321553702.31117.11.camel@Andromeda> Message-ID: <86k46y601i.fsf@seastrom.com> To echo what Betty said and address an unspoken concern: "marketing at nanog.org" is the mailing list (and external interface?) for the folks who make sure that there are good cookies and other break goodies, beer-n-gear sponsors, meeting hosts, etc. It is most assuredly not a spamming list, which I suppose is probably what went through folks' minds when they got that email. I know that's what I would be wondering if I randomly got that kind of mail with no background info. If you've ever been unfortunate enough to manage Mailman, you're probably as astonished as I am that this sort of pilot error doesn't happen more often. :-) Now that that's out of the way, if you think you might have something to contribute to the community (marketing or otherwise) they're always looking for volunteers... so maybe you *want* to be on that mailing list - the community will be grateful. -R (former Board, fomrer MLC) "Betty Burke " writes: > Everyone: > > This was truly just a honest mistake on my part. You are all right, should > not have happened and I apologize. > > Marketing at nanog.org is a list used in connection with Sponsorship > inquiries/activity. refer to http://www.nanog.org/sponsors/ > Membership of marketing at nanog.or is the Development Committee and NANOG > Staff. > > As I indicated, I was planning to update the members at nanog,org list, and > just happened to be in the wrong interface. > > All best. > Betty > > > > On Thu, Nov 17, 2011 at 1:15 PM, Richard Golodner < > rgolodner at infratection.com> wrote: > >> On Thu, 2011-11-17 at 09:35 -0800, Owen DeLong wrote: >> > Can someone explain this one to me? >> > >> > 1. Why was such a list created? >> > 2. Why was I automatically subscribed to it? >> > 3. Why was this done without notice to the community? >> > >> > Thanks, >> This has a lot of us wondering the same as Owen. >> This is also not typical of how NANOG does things. Hopefully as the >> day >> progresses we will get some insight. >> Richard Golodner >> >> >> > > > -- > Betty Burke > NewNOG/NANOG Executive Director > Office (810) 214-1218 > Direct (510) 492-4030 From drc at virtualized.org Thu Nov 17 13:08:34 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 17 Nov 2011 11:08:34 -0800 Subject: economic value of low AS numbers In-Reply-To: References: <4EC52E7D.5040403@kl.net> Message-ID: <36F72AF8-5233-4666-9F58-8416B5746014@virtualized.org> On Nov 17, 2011, at 10:55 AM, Keegan Holley wrote: > You are discounting (pun intended) vanity and marketing. I am no longer surprised at what people will be willing to pay (sometimes astonishing amounts of) money for. > > I suppose I can't argue with that, but anyone technical enough to know what an AS is should know better. whois -h whois.arin.net 42 :-) (no idea if any money changed hands) Regards, -drc From davehart at gmail.com Thu Nov 17 13:09:56 2011 From: davehart at gmail.com (Dave Hart) Date: Thu, 17 Nov 2011 19:09:56 +0000 Subject: economic value of low AS numbers In-Reply-To: References: <4EC52E7D.5040403@kl.net> Message-ID: On Thu, Nov 17, 2011 at 18:55, Keegan Holley wrote: > I suppose I can't argue with that, but anyone technical enough to know > what an AS is should know better. ?Also, would it really count? ?What if I > opened a small ISP in some carrier hotel and paid 1000 bucks for AS 1. ?I'm > not sure I'd want to sign a contract with someone dumb enough to think I > was the first company on the internet. Did you intend to say the first autonomous system number assigned for use on ARPAnet? Pedantically yours, Dave Hart From Valdis.Kletnieks at vt.edu Thu Nov 17 13:12:09 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 17 Nov 2011 14:12:09 -0500 Subject: economic value of low AS numbers In-Reply-To: Your message of "Thu, 17 Nov 2011 13:55:46 EST." References: <4EC52E7D.5040403@kl.net> Message-ID: <10568.1321557129@turing-police.cc.vt.edu> On Thu, 17 Nov 2011 13:55:46 EST, Keegan Holley said: > I suppose I can't argue with that, but anyone technical enough to know > what an AS is should know better. Also, would it really count? What if I > opened a small ISP in some carrier hotel and paid 1000 bucks for AS 1. I'm > not sure I'd want to sign a contract with someone dumb enough to think I > was the first company on the internet. On the other hand, if you are unable to sign said contract on *very* favorable terms, maybe *you* shouldn't be signing contracts. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From davehart at gmail.com Thu Nov 17 13:30:17 2011 From: davehart at gmail.com (Dave Hart) Date: Thu, 17 Nov 2011 19:30:17 +0000 Subject: economic value of low AS numbers In-Reply-To: <36F72AF8-5233-4666-9F58-8416B5746014@virtualized.org> References: <4EC52E7D.5040403@kl.net> <36F72AF8-5233-4666-9F58-8416B5746014@virtualized.org> Message-ID: On Thu, Nov 17, 2011 at 19:08, David Conrad wrote: > whois -h whois.arin.net 42 RFC 943: 42 THINK-AS [BJN1] [BJN1] Bruce Nemnich TMC BJN at MIT-MC.ARPA I have no idea which registry was maintaining AS number registrations when AS42 changed hands. I suppose it's possible the current registrant acquired or merged with whatever entity THINK refers to, but I doubt it, so it seems likely at least at one time transfers were reflected in updated registrations. I bet Douglas would have been tickled. Cheers, Dave Hart From keegan.holley at sungard.com Thu Nov 17 13:34:48 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 17 Nov 2011 14:34:48 -0500 Subject: economic value of low AS numbers In-Reply-To: References: <4EC52E7D.5040403@kl.net> Message-ID: 2011/11/17 Dave Hart > On Thu, Nov 17, 2011 at 18:55, Keegan Holley > wrote: > > I suppose I can't argue with that, but anyone technical enough to know > > what an AS is should know better. Also, would it really count? What if > I > > opened a small ISP in some carrier hotel and paid 1000 bucks for AS 1. > I'm > > not sure I'd want to sign a contract with someone dumb enough to think I > > was the first company on the internet. > > Did you intend to say the first autonomous system number assigned for > use on ARPAnet? > > Pedantically yours, > > I have to admit I wasn't sure. I know ARPAnet predated BGP and EGP I believe so I wasn't sure if there were ASN's then. From dr at cluenet.de Thu Nov 17 13:59:37 2011 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 17 Nov 2011 20:59:37 +0100 Subject: economic value of low AS numbers In-Reply-To: References: <4EC52E7D.5040403@kl.net> <36F72AF8-5233-4666-9F58-8416B5746014@virtualized.org> Message-ID: <20111117195937.GA18444@srv03.cluenet.de> On Thu, Nov 17, 2011 at 07:30:17PM +0000, Dave Hart wrote: > 42 THINK-AS [BJN1] > > [BJN1] Bruce Nemnich TMC BJN at MIT-MC.ARPA > > I have no idea which registry was maintaining AS number registrations > when AS42 changed hands. I suppose it's possible the current > registrant acquired or merged with whatever entity THINK refers to, "THINK", "TMC" and MIT give strong hints towards Thinking Machines Corporation, a once-famous vendor of pretty supercomputers. :) http://en.wikipedia.org/wiki/Thinking_Machines_Corporation Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From owen at delong.com Thu Nov 17 14:21:42 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Nov 2011 15:21:42 -0500 Subject: economic value of low AS numbers In-Reply-To: References: <899CA84F-A8E7-4D84-9517-FEB50A3E1379@delong.com> Message-ID: <562C6175-E570-421C-831D-FD77810637D2@delong.com> >> >> Updates are processed through the standard ARIN-online process >> like updates to any other number resources. If you want additional >> assistance on that, I suggest contacting the registration services >> help desk by phone (703-227-0660) or email (hostmaster at arin.net). > > I was looking for policy, not actually attempting to change > registration information for a specific AS, and I think you've > provided it. > It is a common misconception that these contact points are only for making changes. The folks at ARIN are actually quite helpful in answering policy questions and helping folks navigate or understand the various ARIN processes. My policy information may not be complete and may or may not address your specific needs. The ARIN staff is a much more authoritative source. Owen From bzs at TheWorld.com Thu Nov 17 14:27:27 2011 From: bzs at TheWorld.com (Barry Shein) Date: Thu, 17 Nov 2011 15:27:27 -0500 Subject: economic value of low AS numbers In-Reply-To: References: <4EC52E7D.5040403@kl.net> <36F72AF8-5233-4666-9F58-8416B5746014@virtualized.org> Message-ID: <41A2E02D-0596-4FF8-B4B4-C1576E00BD56@TheWorld.com> http://en.m.wikipedia.org/wiki/Thinking_Machines_Corporation Assets acquired by Sun Microsystems do maybe Oracle today. -b Sent from my iPhone On Nov 17, 2011, at 14:30, Dave Hart wrote: > On Thu, Nov 17, 2011 at 19:08, David Conrad wrote: >> whois -h whois.arin.net 42 > > RFC 943: > > 42 THINK-AS [BJN1] > > [BJN1] Bruce Nemnich TMC BJN at MIT-MC.ARPA > > I have no idea which registry was maintaining AS number registrations > when AS42 changed hands. I suppose it's possible the current > registrant acquired or merged with whatever entity THINK refers to, > but I doubt it, so it seems likely at least at one time transfers were > reflected in updated registrations. > > I bet Douglas would have been tickled. > > Cheers, > Dave Hart From john_c.bell at yahoo.com Thu Nov 17 14:30:09 2011 From: john_c.bell at yahoo.com (John Bell) Date: Thu, 17 Nov 2011 12:30:09 -0800 (PST) Subject: CDN locations for US eyeball networks Message-ID: <1321561809.11111.YahooMailNeo@web122206.mail.ne1.yahoo.com> Hello NANOGers. I am in the process of scouting for CDN node locations for content delivery to end users in the US. Currently looking at Seattle, Los Angeles, Dallas, Chicago, Miami and New York. Would much appreciate any recommendations, best practices or advice on how/where to get good connectivity to the large eyeball networks. Being small fish, connectivity will be based on the transit I can score or in general connectivity that DCs/server providers offer in the locations chosen. John From streiner at cluebyfour.org Thu Nov 17 14:34:52 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 17 Nov 2011 15:34:52 -0500 (EST) Subject: Bandwidth Upgrade In-Reply-To: References: Message-ID: On Thu, 17 Nov 2011, Bielawa, Daniel Walter wrote: > My team is in the process of putting some documentation > together to justify a bandwidth upgrade. I am asking if you would be > willing to reply back to me, with how you decide that it is time to > upgrade your bandwidth. On-line or off-line reply's will be acceptable. Capacity planning is one of those things that (can) fall into the technical, business, and political aspects of network engineering. Addressing the technical aspects is pretty straightforward. The first thing is having data to show how much of your bandwidth you're using now. Even something as basic as a set of MRTG (not knocking MRTG at all) graphs. If you have that, or data from some other package, then that's a good start. If they show things like saturation of your existing pipe, then that's an important data point to share with your management, because flat-topping has a tendency to turn into sluggish performance and unhappy customers pretty quickly. I would agree with other posters that we start looking at capacity upgrades when we get to about 65% usage, and have the upgrades completed before we get to 80-85%. Depending on what size pipes you have now, you can also possibly significantly reduce your cost per Mb/s, though this depends a lot on your location and what sort of comms facilities are in your area. Don't be afraid to call some carriers and get quotes. Having historical data that shows the growth of your bandwidth needs is even more useful, to a point. The reason I said to a point, is because a straight graph of inbound and outbound traffic doesn't answer questions about what is going on that is driving traffic growth. At that point, you start getting into the realm of traffic analysis. Addressing the business aspects starts to get into areas that we (people on NANOG) can only offer generic advice, because you would know how to present the business case for an upgrade to your management better than we would. For example, if keeping customer complaints about network performance as low as possible is a business priority, then showing reports of related trouble tickets your helpdesk has received from your user base might be another important data point as well. Also keep in mind that what might start out as "we need more bandwidth" could turn into other costs as well. A larger pipe might mean you need a new interface card for your router, or other upgrades to the internal network to make use of that larger external pipe. Most managers I've worked with would rather get the bad news (requests for money) all at once, so they only have to 'go to the well' one time, rather than making requests for money to upgrade the pipe, then another request for the new interface card, etc. That also starts to get you into the possibly political aspects of working through your business environment. Hope this helps. jms From ren.provo at gmail.com Thu Nov 17 14:45:57 2011 From: ren.provo at gmail.com (Ren Provo) Date: Thu, 17 Nov 2011 15:45:57 -0500 Subject: CDN locations for US eyeball networks In-Reply-To: <1321561809.11111.YahooMailNeo@web122206.mail.ne1.yahoo.com> References: <1321561809.11111.YahooMailNeo@web122206.mail.ne1.yahoo.com> Message-ID: Hi John, Take a look at - http://as7018.peeringdb.com http://as701.peeringdb.com http://as7922.peeringdb.com http://as7843.peeringdb.com http://as22773.peeringdb.com http://as20115.peeringdb.com Most list interconnect locations, others have policy pointers which list cities of interest. Cheers, -ren On Thu, Nov 17, 2011 at 3:30 PM, John Bell wrote: > Hello NANOGers. > > I am in the process of scouting for CDN node > locations for content delivery to end users in the US. Currently looking > ?at Seattle, Los Angeles, Dallas, Chicago, Miami and New York. > Would > much appreciate any recommendations, best practices or advice on > how/where to get good connectivity to the large eyeball networks. Being > small fish, connectivity will be based on the transit I can score or in > general connectivity that DCs/server providers offer in the locations > chosen. > > > John > > From jra at baylink.com Thu Nov 17 14:47:37 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 17 Nov 2011 15:47:37 -0500 (EST) Subject: Welcome to the "Marketing" mailing list In-Reply-To: <1321553702.31117.11.camel@Andromeda> Message-ID: <14124644.3165.1321562857917.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Richard Golodner" > > 1. Why was such a list created? > > 2. Why was I automatically subscribed to it? > > 3. Why was this done without notice to the community? > This has a lot of us wondering the same as Owen. > This is also not typical of how NANOG does things. Hopefully as the > day progresses we will get some insight. My, but there are a lot of people, in my best friend's favorite phrase, "spring loaded to the pissed-off position". I didn't think NANOGers were quite so prone to recreational indignation... 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 aoxomoxoa at sunlightdata.com Thu Nov 17 14:48:59 2011 From: aoxomoxoa at sunlightdata.com (Fred Heutte) Date: Thu, 17 Nov 2011 12:48:59 -0800 Subject: J.D. Falk has passed on Message-ID: <201111172049.pAHKn84M004764@stark.hevanet.com> A wonderful colleague, friend, and "leading purveyor of industry counter-rhetoric solutions." http://www.maawg.org/page/memorial-jd-falk http://www.cauce.org/2011/11/jdfalk.html http://www.facebook.com/jdfalk regards, fh ----------- Pure J.D. :) "Whether you are acting as a Mailbox Provider or a Feedback Consumer, Complaint Feedback processing can be complex and scary -- or, with some intelligence and automation, simple and easy. In either case, it is an important and necessary tool for detecting messaging abuse and ensuring End User satisfaction." http://www.rfc-editor.org/?rfc/pdfrfc/rfc6449.txt.pdf From bill at herrin.us Thu Nov 17 14:50:52 2011 From: bill at herrin.us (William Herrin) Date: Thu, 17 Nov 2011 15:50:52 -0500 Subject: CDN locations for US eyeball networks In-Reply-To: <1321561809.11111.YahooMailNeo@web122206.mail.ne1.yahoo.com> References: <1321561809.11111.YahooMailNeo@web122206.mail.ne1.yahoo.com> Message-ID: On Thu, Nov 17, 2011 at 3:30 PM, John Bell wrote: > I am in the process of scouting for CDN node > locations for content delivery to end users in the US. Currently looking > ?at Seattle, Los Angeles, Dallas, Chicago, Miami and New York. Hi John, Add Northern Virginia to the list. Then move it to the top. Historically, telecommunications on the US east coast hubbed in NoVA, just outside Washington DC, making it an attractive area for early Internet peering points like MAE-East. That has evolved over the past decade but NoVA still holds a commanding position in Internet interconnectivity. There are a number of local data centers most interconnected by multiple dark fiber providers. The most connected is probably Equinix in Ashburn VA. YMMV as to whether its cost-effective for a "small fish." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jra at baylink.com Thu Nov 17 14:52:33 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 17 Nov 2011 15:52:33 -0500 (EST) Subject: economic value of low AS numbers In-Reply-To: Message-ID: <27249796.3169.1321563153416.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Dave Hart" > On Thu, Nov 17, 2011 at 19:08, David Conrad > wrote: > > whois -h whois.arin.net 42 > > RFC 943: > > 42 THINK-AS [BJN1] > > [BJN1] Bruce Nemnich TMC BJN at MIT-MC.ARPA > > I have no idea which registry was maintaining AS number registrations > when AS42 changed hands. I suppose it's possible the current > registrant acquired or merged with whatever entity THINK refers to, > but I doubt it, so it seems likely at least at one time transfers were > reflected in updated registrations. I'd be shocked, shocked I tell... oh, yes; put the money over here please. Shocked, I tell you, if that wasn't Thinking Machines Corp., which was formed by MIT grads, as I remember it. The real question is whether it was issued after HHGTTG. 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 jeff at ocjtech.us Thu Nov 17 15:01:36 2011 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 17 Nov 2011 15:01:36 -0600 Subject: economic value of low AS numbers In-Reply-To: <27249796.3169.1321563153416.JavaMail.root@benjamin.baylink.com> References: <27249796.3169.1321563153416.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, Nov 17, 2011 at 2:52 PM, Jay Ashworth wrote: > > The real question is whether it was issued after HHGTTG. HHGTTG first appeared on the BBC in 1978. Thinking Machines Corporation was formed in 1982. As far as I can tell the first BGP RFC is 1105 and was published in 1989. -- Jeff Ollie From kris at kriskinc.com Thu Nov 17 15:03:07 2011 From: kris at kriskinc.com (Kristian Kielhofner) Date: Thu, 17 Nov 2011 16:03:07 -0500 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> Message-ID: On Thu, Nov 17, 2011 at 7:58 AM, A. Chase Turner wrote: > I am seeking a $100 turnkey micro hardware appliance to plug into a LAN hub (behind a consumer-level cable modem) whose only purpose in life is to send heartbeat (and simple quality of service metrics) to a pre-configured central aggregation service on the WAN. > > Key requirement is the micro hardware appliance will be installed by non-technical elderly end-users -- so, it must be pre-configured and literally plug and play without need for the person installing the appliance to open a web browser to configure. ?And it must be a secure, good-reputation stand-alone hardware appliance ... because the heartbeat cannot / must not be a service installed on the end-user's computer where it becomes a support burden (e.g., did the end-user turn off their computer? ?Is their antivirus software blocking the outgoing heartbeat? That the end-user needs to enter a username/password/destination to enable the heartbeat, etc) > > There is a commercial turnkey solution that meets all the requirements except one -- that the solution cannot exceed $100 per remote appliance ?: > ? ? ? ?http://www.myconnectionserver.com/learnmore/quality.html > > Question to the list: do you know of an alternative hardware solution under $100 that would suffice -- and be of such quality that an incumbent internet service provider will not thumb their nose at me when I call in to report remote users are down based upon the loss of heartbeats from the remote users? > > MOTIVATION FOR THE ABOVE > > Ten elderly neighbors to my mother in a rural area suffer frequent internet outages from their one (and only) incumbent cable internet service provider. ?All of them have learned they will encounter one of the following responses : > > ?"You are the only one reporting a problem" > OR > ?"We need three reports before we take action" > OR > ?"We fixed it. ?You need to re-boot your modem. ?(moments later after rebooting cable modem). ?It must be your computer that is the problem." > OR > ?"We know there is a problem. ?We'll send a crew out to repair the issue next week" > > These 10 elderly neighbors are fuming ... and they recently formed a call tree -- so that when one person suffers an internet outage, they call other neighbors in the call tree to see if they too have an outage ... and if so, each calls in an outage report (often 20 minutes of being placed on hold) > > The call tree is working (somewhat) to improve accountability and response by the cable service provider ... but it is a waste of their time as there is no formal "record" of outage events to spur the provider to provide refunds for unscheduled service outages. ? Thus, I am seeking a turnkey quality of service micro appliance that automates (and documents) service outage notifications .. so as to allow me (living in a city and my being on a different internet service provider) to take on the role of calling the rural cable service provider and claim (with authority) that I know that 10 individuals systems (who have the heartbeat appliance installed) are down and that the cable service provider needs to fix the issue... > > OpenWRT running on one of these: http://embeddedtimes.blogspot.com/2011/09/tp-link-tl-wr703n-tiny-linux-capable.html I ordered mine from the Volume Rates link: http://www.volumerates.com/product/genuine-tp-link-tl-wr703n-150m-11n-mini-wifi-wireless-router-for-instant-wifi-connection-99273 You could order all 10 for around $180 + shipping (straight from Hong Kong). I have two, they're pretty awesome and potentially useful for all kinds of things... -- Kristian Kielhofner From rs at seastrom.com Thu Nov 17 15:11:54 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 17 Nov 2011 16:11:54 -0500 Subject: economic value of low AS numbers In-Reply-To: (Jeffrey Ollie's message of "Thu, 17 Nov 2011 15:01:36 -0600") References: <27249796.3169.1321563153416.JavaMail.root@benjamin.baylink.com> Message-ID: <86ty624fol.fsf@seastrom.com> Jeffrey Ollie writes: > On Thu, Nov 17, 2011 at 2:52 PM, Jay Ashworth wrote: >> >> The real question is whether it was issued after HHGTTG. > > HHGTTG first appeared on the BBC in 1978. Thinking Machines > Corporation was formed in 1982. As far as I can tell the first BGP > RFC is 1105 and was published in 1989. http://tools.ietf.org/html/rfc827 -r From james.cutler at consultant.com Thu Nov 17 15:16:28 2011 From: james.cutler at consultant.com (Cutler James R) Date: Thu, 17 Nov 2011 16:16:28 -0500 Subject: Welcome to the "Marketing" mailing list In-Reply-To: <14124644.3165.1321562857917.JavaMail.root@benjamin.baylink.com> References: <14124644.3165.1321562857917.JavaMail.root@benjamin.baylink.com> Message-ID: On Nov 17, 2011, at 3:47 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Richard Golodner" > >>> 1. Why was such a list created? >>> 2. Why was I automatically subscribed to it? >>> 3. Why was this done without notice to the community? > >> This has a lot of us wondering the same as Owen. >> This is also not typical of how NANOG does things. Hopefully as the >> day progresses we will get some insight. > > My, but there are a lot of people, in my best friend's favorite phrase, > "spring loaded to the pissed-off position". I didn't think NANOGers were > quite so prone to recreational indignation... > > 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 > Someone once wrote,approximately, "Assume the best possible intentions." Thus, bafflement .ne. "spring loaded to the pissed-off position". Regards. James R. Cutler james.cutler at consultant.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1861 bytes Desc: not available URL: From matthew at corp.crocker.com Thu Nov 17 15:17:32 2011 From: matthew at corp.crocker.com (Matthew S. Crocker) Date: Thu, 17 Nov 2011 16:17:32 -0500 (EST) Subject: Bandwidth Upgrade In-Reply-To: Message-ID: <971a5546-c9d2-4be3-86be-aaf068708a35@zimbra1.crocker.com> For the past 17 years I have managed to keep my bandwidth budget the same. I had 1 T1 in 1994 and have multiple GigEs now. I still pay roughly the same price. So, shop it around and see if you can upgrade without affecting your budget. It is much easier to justify when it doesn't change the bottom line. -Matt ----- Original Message ----- > From: "Daniel Walter Bielawa" > To: nanog at nanog.org > Sent: Thursday, November 17, 2011 10:30:01 AM > Subject: Bandwidth Upgrade > > Greetings, > My team is in the process of putting some > documentation together to justify a bandwidth > upgrade. I am asking if you would be willing to > reply back to me, with how you decide that it is > time to upgrade your bandwidth. On-line or off-line > reply's will be acceptable. > > Thank You > > Daniel Bielawa > Network Engineer > Liberty University Network Services > > (434)592-7987 > > LIBERTY UNIVERSITY > 40 Years of Training Champions for Christ: 1971-2011 > > > From jeff at ocjtech.us Thu Nov 17 15:27:09 2011 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 17 Nov 2011 15:27:09 -0600 Subject: economic value of low AS numbers In-Reply-To: <86ty624fol.fsf@seastrom.com> References: <27249796.3169.1321563153416.JavaMail.root@benjamin.baylink.com> <86ty624fol.fsf@seastrom.com> Message-ID: On Thu, Nov 17, 2011 at 3:11 PM, Robert E. Seastrom wrote: > > Jeffrey Ollie writes: > >> On Thu, Nov 17, 2011 at 2:52 PM, Jay Ashworth wrote: >>> >>> The real question is whether it was issued after HHGTTG. >> >> HHGTTG first appeared on the BBC in 1978. Thinking Machines >> Corporation was formed in 1982. ?As far as I can tell the first BGP >> RFC is 1105 and was published in 1989. > > http://tools.ietf.org/html/rfc827 Which describes EGP and was published in 1982. EGP does use the notion of an autonomous system number. When the conversion from EGP to BGP was made did networks keep the same autonomous system numbers? -- Jeff Ollie From trelane at trelane.net Thu Nov 17 15:29:55 2011 From: trelane at trelane.net (Andrew Kirch) Date: Thu, 17 Nov 2011 16:29:55 -0500 Subject: Welcome to the "Marketing" mailing list In-Reply-To: <14124644.3165.1321562857917.JavaMail.root@benjamin.baylink.com> References: <14124644.3165.1321562857917.JavaMail.root@benjamin.baylink.com> Message-ID: <4EC57CD3.3050707@trelane.net> On 11/17/2011 3:47 PM, Jay Ashworth wrote: > My, but there are a lot of people, in my best friend's favorite phrase, > "spring loaded to the pissed-off position". I didn't think NANOGers were > quite so prone to recreational indignation... > > Cheers, > -- jra If only there was some sort of movement where they could show up and, by their presence let us know of their impotent rage. Perhaps if they all sat in a park near the hosting facility that holds NANOG.org, occupying it in some way, things might get better here. Andrew From bonomi at mail.r-bonomi.com Thu Nov 17 15:39:00 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 17 Nov 2011 15:39:00 -0600 (CST) Subject: economic value of low AS numbers In-Reply-To: <27249796.3169.1321563153416.JavaMail.root@benjamin.baylink.com> Message-ID: <201111172139.pAHLd0x1048819@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Thu Nov 17 14:53:57 2011 > Date: Thu, 17 Nov 2011 15:52:33 -0500 (EST) > From: Jay Ashworth > To: NANOG > Subject: Re: economic value of low AS numbers > > ----- Original Message ----- >> From: "Dave Hart" > >> On Thu, Nov 17, 2011 at 19:08, David Conrad >> wrote: >> > whois -h whois.arin.net 42 >> >> RFC 943: >> >> 42 THINK-AS [BJN1] >> >> [BJN1] Bruce Nemnich TMC BJN at MIT-MC.ARPA >> >> I have no idea which registry was maintaining AS number registrations >> when AS42 changed hands. I suppose it's possible the current >> registrant acquired or merged with whatever entity THINK refers to, >> but I doubt it, so it seems likely at least at one time transfers were >> reflected in updated registrations. > > I'd be shocked, shocked I tell... oh, yes; put the money over here please. > > Shocked, I tell you, if that wasn't Thinking Machines Corp., which was > formed by MIT grads, as I remember it. > > The real question is whether it was issued after HHGTTG. I think it was abaout the time they clustered a group of nine 6-node machines. From paul at paulgraydon.co.uk Thu Nov 17 15:41:12 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Thu, 17 Nov 2011 11:41:12 -1000 Subject: Welcome to the "Marketing" mailing list In-Reply-To: <14124644.3165.1321562857917.JavaMail.root@benjamin.baylink.com> References: <14124644.3165.1321562857917.JavaMail.root@benjamin.baylink.com> Message-ID: <4EC57F78.1090204@paulgraydon.co.uk> On 11/17/2011 10:47 AM, Jay Ashworth wrote: > My, but there are a lot of people, in my best friend's favorite phrase, > "spring loaded to the pissed-off position". I didn't think NANOGers were > quite so prone to recreational indignation... > > Cheers, > -- jra NANOG where no day is complete without a bit of righteous indignation. Paul From jra at baylink.com Thu Nov 17 15:41:38 2011 From: jra at baylink.com (Jay Ashworth) Date: Thu, 17 Nov 2011 16:41:38 -0500 (EST) Subject: economic value of low AS numbers In-Reply-To: <201111172139.pAHLd0x1048819@mail.r-bonomi.com> Message-ID: <14311463.3185.1321566098066.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert Bonomi" > >> 42 THINK-AS [BJN1] > > The real question is whether it was issued after HHGTTG. > > I think it was abaout the time they clustered a group of nine 6-node > machines. As long as they worked in base-13. As it happens, Woody owns that ASN now, according to my whois, at least. 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 Thu Nov 17 15:51:14 2011 From: davehart at gmail.com (Dave Hart) Date: Thu, 17 Nov 2011 21:51:14 +0000 Subject: economic value of low AS numbers In-Reply-To: <86ty624fol.fsf@seastrom.com> References: <27249796.3169.1321563153416.JavaMail.root@benjamin.baylink.com> <86ty624fol.fsf@seastrom.com> Message-ID: On Thu, Nov 17, 2011 at 21:11, Robert E. Seastrom wrote: > > Jeffrey Ollie writes: > >> On Thu, Nov 17, 2011 at 2:52 PM, Jay Ashworth wrote: >>> >>> The real question is whether it was issued after HHGTTG. >> >> HHGTTG first appeared on the BBC in 1978. Thinking Machines >> Corporation was formed in 1982. ?As far as I can tell the first BGP >> RFC is 1105 and was published in 1989. > > http://tools.ietf.org/html/rfc827 AS42 was assigned after publication of RFC 923 (Oct 1984) and no later than the superceding RFC 943 (April 1985). AS numbers definitely predate BGP. AS1 was assigned by or before RFC 820 (Jan 1983). EGP was RFC 827 (Oct 1982). Presumably the development involved informal assignment of at least test AS numbers. Cheers, Dave Hart From jim at reptiles.org Thu Nov 17 15:58:37 2011 From: jim at reptiles.org (Jim Mercer) Date: Thu, 17 Nov 2011 16:58:37 -0500 Subject: economic value of low AS numbers In-Reply-To: References: <4EC52E7D.5040403@kl.net> Message-ID: <20111117215837.GA29408@reptiles.org> On Thu, Nov 17, 2011 at 10:21:59AM -0800, David Conrad wrote: > On Nov 17, 2011, at 8:16 AM, Keegan Holley wrote: > > Besides standing at the water cooler at 1:23PM on 12/3 telling AS123 jokes > > I'm not sure a particular AS number has any relevance or any monetary value > > unless there is scarcity. > > You are discounting (pun intended) vanity and marketing. I am no longer surprised at what people will be willing to pay (sometimes astonishing amounts of) money for. UAE license plate auctions, "1" sold for $14 million http://www.bloomberg.com/apps/news?pid=newsarchive&sid=aJ8EZTdrItjs Lebanon phone number auction, 71-444444 went for $68,000 http://www.ameinfo.com/207677.html -- [ Jim Mercer Reptilian Research jim at reptiles.org +1 416 410-5633 ] [ stressed spelled backwards is desserts. ] [ coincidence? i think not. ] From tvhawaii at shaka.com Thu Nov 17 16:16:21 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 17 Nov 2011 12:16:21 -1000 Subject: Fwd: Welcome to the "Marketing" mailing list References: <91CF7F56-C656-4208-A56B-E3E3ADA643FF@delong.com> <1321553702.31117.11.camel@Andromeda> Message-ID: <9E42A002E83B42A9B5AAC4336A95D960@owner59e1f1502> Betty Burke wrote: > Everyone: > > This was truly just a honest mistake on my part. You are all right, should > not have happened and I apologize. No worries, Betty. The only ones amongst us who don't make mistakes are the ones who don't do anything. --Michael From up at 3.am Thu Nov 17 16:24:43 2011 From: up at 3.am (up at 3.am) Date: Thu, 17 Nov 2011 17:24:43 -0500 Subject: J.D. Falk has passed on In-Reply-To: <201111172049.pAHKn84M004764@stark.hevanet.com> References: <201111172049.pAHKn84M004764@stark.hevanet.com> Message-ID: <42f27b8d087e75067bde6026fea0070d.squirrel@ssl.pil.net> Somewhere in hell, Spamford Wallace is smiling. > A wonderful colleague, friend, and "leading purveyor of > industry counter-rhetoric solutions." > > http://www.maawg.org/page/memorial-jd-falk > > http://www.cauce.org/2011/11/jdfalk.html > > http://www.facebook.com/jdfalk > > regards, > > fh > > ----------- > > Pure J.D. :) > > "Whether you are acting as a Mailbox Provider or a Feedback Consumer, > Complaint Feedback processing can be complex and scary -- or, with > some intelligence and automation, simple and easy. In either case, > it is an important and necessary tool for detecting messaging abuse > and ensuring End User satisfaction." > > http://www.rfc-editor.org/?rfc/pdfrfc/rfc6449.txt.pdf > > > From surfer at mauigateway.com Thu Nov 17 17:21:25 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 17 Nov 2011 15:21:25 -0800 Subject: Bandwidth Upgrade Message-ID: <20111117152125.A32B51D5@m0005311.ppops.net> --- dwbielawa at liberty.edu wrote: From: "Bielawa, Daniel Walter" My team is in the process of putting some documentation together to justify a bandwidth upgrade. I am asking if you would be willing to reply back to me, with how you decide that it is time to upgrade your bandwidth. On-line or off-line reply's will be acceptable. -------------------------------------------------------- Empirical data rules; WAGs don't... ;-) If you have a year's worth of traffic graphed, extrapolate the growth to find out when you will hit about 85%-90% of the capacity of the circuit at peak load. Find out how long the providers in your area take to turn up a circuit of the type and size you need. Then work backwards from there, so that the circuit is in production when you hit that percentage of utilization. Your particular numbers will depend on your growth rate. scott From graham at g-rock.net Thu Nov 17 18:21:13 2011 From: graham at g-rock.net (Graham Wooden) Date: Thu, 17 Nov 2011 18:21:13 -0600 Subject: Folks colo'd at COCOFLMA Message-ID: Hello, I have a need to for layer2 connectivity between the COCOFLMA CO in Cocoa, FL over to ColoSolutions in Orlando. If any folks are on the list that are located in both locations and have some room (20-40Mb) on your backhaul circuits, please let me know off-list please. Would rather pay you than AT&T. Thanks! -graham From esavage at digitalrage.org Thu Nov 17 23:09:48 2011 From: esavage at digitalrage.org (Elijah Savage) Date: Fri, 18 Nov 2011 00:09:48 -0500 Subject: Verizon 3G/4G Message-ID: Multi question email. Is there anyone on this list that supports this infrastructure, (verizon 3G/4G Broadband) or is there a place a seasoned admin can go outside of the general support desk to get assistance when a major outage is occurring? Secondly has anyone on this list deployed this technology within their infrastructure and can speak on the experience. Thank you From fearghas at gmail.com Fri Nov 18 11:35:20 2011 From: fearghas at gmail.com (Fearghas McKay) Date: Fri, 18 Nov 2011 17:35:20 +0000 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> Message-ID: <2455871F-06B6-4B3F-8943-53CFC46438C5@gmail.com> On 17 Nov 2011, at 12:58, A. Chase Turner wrote: > I am seeking a $100 turnkey micro hardware appliance to plug into a LAN hub (behind a consumer-level cable modem) whose only purpose in life is to send heartbeat (and simple quality of service metrics) to a pre-configured central aggregation service on the WAN. Have a look at the Atlas project from RIPE - http://atlas.ripe.net/ Their hardware is aimed at costing 50? including distribution etc. They have said they were not going to make it available but they might collaborate ? HTH f From erik at mrhz.net Fri Nov 18 12:33:48 2011 From: erik at mrhz.net (Erik Beebe) Date: Fri, 18 Nov 2011 10:33:48 -0800 (PST) Subject: DSCI (AS33748) Reference Message-ID: Hi all; Are there any DSCI BGP customers in the Boston area that could contact me off-list? I'm considering purchasing service from them, and would like to hear about any experience (good or bad) you may have. Thanks in advance, Erik From cscora at apnic.net Fri Nov 18 13:19:52 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 Nov 2011 05:19:52 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201111181919.pAIJJqrU005365@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, 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 19 Nov, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 382518 Prefixes after maximum aggregation: 166913 Deaggregation factor: 2.29 Unique aggregates announced to Internet: 187922 Total ASes present in the Internet Routing Table: 39344 Prefixes per ASN: 9.72 Origin-only ASes present in the Internet Routing Table: 32426 Origin ASes announcing only one prefix: 15480 Transit ASes present in the Internet Routing Table: 5275 Transit-only ASes present in the Internet Routing Table: 133 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1738 Unregistered ASNs in the Routing Table: 898 Number of 32-bit ASNs allocated by the RIRs: 1966 Number of 32-bit ASNs visible in the Routing Table: 1643 Prefixes from 32-bit ASNs in the Routing Table: 3811 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 85 Number of addresses announced to Internet: 2491183488 Equivalent to 148 /8s, 124 /16s and 113 /24s Percentage of available address space announced: 67.2 Percentage of allocated address space announced: 67.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.6 Total number of prefixes smaller than registry allocations: 161662 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 95270 Total APNIC prefixes after maximum aggregation: 31163 APNIC Deaggregation factor: 3.06 Prefixes being announced from the APNIC address blocks: 91712 Unique aggregates announced from the APNIC address blocks: 38427 APNIC Region origin ASes present in the Internet Routing Table: 4610 APNIC Prefixes per ASN: 19.89 APNIC Region origin ASes announcing only one prefix: 1269 APNIC Region transit ASes present in the Internet Routing Table: 709 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 110 Number of APNIC addresses announced to Internet: 630281568 Equivalent to 37 /8s, 145 /16s and 85 /24s Percentage of available APNIC address space announced: 79.9 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-132095, 132096-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: 145957 Total ARIN prefixes after maximum aggregation: 74487 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 118097 Unique aggregates announced from the ARIN address blocks: 48616 ARIN Region origin ASes present in the Internet Routing Table: 14749 ARIN Prefixes per ASN: 8.01 ARIN Region origin ASes announcing only one prefix: 5633 ARIN Region transit ASes present in the Internet Routing Table: 1567 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 13 Number of ARIN addresses announced to Internet: 803282880 Equivalent to 47 /8s, 225 /16s and 31 /24s Percentage of available ARIN address space announced: 63.8 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: 92363 Total RIPE prefixes after maximum aggregation: 51229 RIPE Deaggregation factor: 1.80 Prefixes being announced from the RIPE address blocks: 84633 Unique aggregates announced from the RIPE address blocks: 54540 RIPE Region origin ASes present in the Internet Routing Table: 16120 RIPE Prefixes per ASN: 5.25 RIPE Region origin ASes announcing only one prefix: 7983 RIPE Region transit ASes present in the Internet Routing Table: 2536 Average RIPE Region AS path length visible: 4.7 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1143 Number of RIPE addresses announced to Internet: 492243904 Equivalent to 29 /8s, 87 /16s and 11 /24s Percentage of available RIPE address space announced: 79.3 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 196608-198655 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: 36318 Total LACNIC prefixes after maximum aggregation: 7909 LACNIC Deaggregation factor: 4.59 Prefixes being announced from the LACNIC address blocks: 35776 Unique aggregates announced from the LACNIC address blocks: 18643 LACNIC Region origin ASes present in the Internet Routing Table: 1547 LACNIC Prefixes per ASN: 23.13 LACNIC Region origin ASes announcing only one prefix: 439 LACNIC Region transit ASes present in the Internet Routing Table: 283 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 18 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 373 Number of LACNIC addresses announced to Internet: 93166208 Equivalent to 5 /8s, 141 /16s and 154 /24s Percentage of available LACNIC address space announced: 61.7 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: 8616 Total AfriNIC prefixes after maximum aggregation: 2052 AfriNIC Deaggregation factor: 4.20 Prefixes being announced from the AfriNIC address blocks: 6675 Unique aggregates announced from the AfriNIC address blocks: 2049 AfriNIC Region origin ASes present in the Internet Routing Table: 499 AfriNIC Prefixes per ASN: 13.38 AfriNIC Region origin ASes announcing only one prefix: 156 AfriNIC Region transit ASes present in the Internet Routing Table: 108 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: 4 Number of AfriNIC addresses announced to Internet: 27745280 Equivalent to 1 /8s, 167 /16s and 92 /24s Percentage of available AfriNIC address space announced: 41.3 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 2506 11072 963 Korea Telecom (KIX) 17974 1647 511 36 PT TELEKOMUNIKASI INDONESIA 7545 1627 303 87 TPG Internet Pty Ltd 4755 1528 378 169 TATA Communications formerly 7552 1394 1064 7 Vietel Corporation 9829 1166 989 28 BSNL National Internet Backbo 4808 1097 2073 310 CNCGROUP IP network: China169 9583 1094 80 494 Sify Limited 24560 965 343 218 Bharti Airtel Ltd., Telemedia 18101 952 119 148 Reliance Infocom Ltd Internet 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 3543 3814 219 bellsouth.net, inc. 7029 2906 1016 199 Windstream Communications Inc 18566 2093 383 177 Covad Communications 1785 1848 680 121 PaeTec Communications, Inc. 4323 1613 1077 387 Time Warner Telecom 20115 1596 1546 624 Charter Communications 22773 1500 2909 103 Cox Communications, Inc. 30036 1428 257 670 Mediacom Communications Corp 19262 1387 4683 401 Verizon Global Networks 7018 1312 7029 860 AT&T WorldNet Services 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 1548 416 14 Corbina telecom 6830 646 1927 411 UPC Distribution Services 34984 601 112 188 BILISIM TELEKOM 20940 553 182 435 Akamai Technologies European 3320 512 8168 389 Deutsche Telekom AG 12479 484 596 9 Uni2 Autonomous System 3292 480 2106 408 TDC Tele Danmark 8866 462 133 26 Bulgarian Telecommunication C 8551 415 366 45 Bezeq International 31148 409 22 114 FreeNet ISP 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 1706 316 157 TVCABLE BOGOTA 28573 1500 1044 70 NET Servicos de Comunicao S.A 8151 1448 2972 345 UniNet S.A. de C.V. 7303 1238 751 173 Telecom Argentina Stet-France 27947 602 72 86 Telconet S.A 22047 580 322 17 VTR PUNTO NET S.A. 6503 557 434 68 AVANTEL, S.A. 7738 553 1050 31 Telecomunicacoes da Bahia S.A 3816 540 234 96 Empresa Nacional de Telecomun 11172 529 85 95 Servicios Alestra S.A de C.V 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 24863 778 146 36 LINKdotNET AS number 8452 685 446 12 TEDATA 15475 444 74 8 Nile Online 36992 283 415 21 Etisalat MISR 3741 281 939 230 The Internet Solution 15706 242 32 6 Sudatel Internet Exchange Aut 6713 235 519 14 Itissalat Al-MAGHRIB 29571 218 17 13 Ci Telecom Autonomous system 33776 212 13 14 Starcomms Nigeria Limited 12258 196 28 57 Vodacom Internet Company 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 3543 3814 219 bellsouth.net, inc. 7029 2906 1016 199 Windstream Communications Inc 4766 2506 11072 963 Korea Telecom (KIX) 18566 2093 383 177 Covad Communications 1785 1848 680 121 PaeTec Communications, Inc. 10620 1706 316 157 TVCABLE BOGOTA 17974 1647 511 36 PT TELEKOMUNIKASI INDONESIA 7545 1627 303 87 TPG Internet Pty Ltd 4323 1613 1077 387 Time Warner Telecom 20115 1596 1546 624 Charter Communications 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 2906 2707 Windstream Communications Inc 18566 2093 1916 Covad Communications 1785 1848 1727 PaeTec Communications, Inc. 17974 1647 1611 PT TELEKOMUNIKASI INDONESIA 10620 1706 1549 TVCABLE BOGOTA 4766 2506 1543 Korea Telecom (KIX) 7545 1627 1540 TPG Internet Pty Ltd 8402 1548 1534 Corbina telecom 28573 1500 1430 NET Servicos de Comunicao S.A 22773 1500 1397 Cox Communications, Inc. 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 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 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 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.0.0/16 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 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 37345 MEDALLION Communications 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 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:12 /10:27 /11:81 /12:236 /13:465 /14:807 /15:1426 /16:12011 /17:6087 /18:10125 /19:20002 /20:27673 /21:27853 /22:37927 /23:35487 /24:198837 /25:1153 /26:1361 /27:758 /28:162 /29:4 /30:0 /31:0 /32:5 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2535 2906 Windstream Communications Inc 6389 2185 3543 bellsouth.net, inc. 18566 2042 2093 Covad Communications 10620 1601 1706 TVCABLE BOGOTA 8402 1524 1548 Corbina telecom 30036 1388 1428 Mediacom Communications Corp 11492 1117 1154 Cable One 1785 1058 1848 PaeTec Communications, Inc. 7011 1050 1167 Citizens Utilities 22773 960 1500 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:411 2:487 4:15 5:1 6:3 8:355 12:1959 13:1 14:551 15:11 16:3 17:7 20:9 23:63 24:1688 27:1027 31:697 32:65 33:2 34:2 36:4 38:762 39:1 40:109 41:2689 42:61 43:1 44:3 46:1051 47:3 49:295 50:455 52:13 55:8 56:2 57:49 58:927 59:479 60:360 61:1143 62:1095 63:1965 64:4075 65:2301 66:4334 67:2000 68:1170 69:3146 70:904 71:384 72:1816 74:2640 75:429 76:320 77:892 78:891 79:439 80:1123 81:838 82:513 83:518 84:622 85:1150 86:405 87:907 88:357 89:1597 90:235 91:4274 92:539 93:1446 94:1306 95:1115 96:428 97:285 98:805 99:37 101:240 103:489 106:1 107:94 108:81 109:1188 110:674 111:805 112:363 113:497 114:595 115:715 116:879 117:720 118:894 119:1271 120:353 121:670 122:1576 123:1028 124:1367 125:1352 128:247 129:184 130:176 131:630 132:155 133:21 134:228 135:54 136:212 137:146 138:285 139:122 140:492 141:251 142:389 143:400 144:489 145:65 146:470 147:219 148:632 149:263 150:161 151:192 152:449 153:172 154:7 155:390 156:208 157:358 158:158 159:494 160:330 161:215 162:368 163:175 164:511 165:369 166:542 167:444 168:823 169:145 170:879 171:87 172:4 173:1745 174:592 175:432 176:297 177:393 178:1117 180:1147 181:39 182:656 183:239 184:394 185:1 186:1409 187:779 188:980 189:1159 190:5209 192:5933 193:5038 194:3544 195:3108 196:1276 197:166 198:3623 199:4216 200:5533 201:1704 202:8546 203:8549 204:4307 205:2398 206:2592 207:2820 208:4030 209:3577 210:2740 211:1465 212:2010 213:1807 214:815 215:97 216:4923 217:1601 218:577 219:339 220:1253 221:520 222:327 223:279 End of report From dholmes at mwdh2o.com Fri Nov 18 13:27:23 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Fri, 18 Nov 2011 11:27:23 -0800 Subject: Verizon 3G/4G In-Reply-To: References: Message-ID: <922ACC42D498884AA02B3565688AF995340255EC92@USEXMBS01.mwd.h2o> For fixed 3G sites where 3G is used as a backup to wireline access, this has been found to be an acceptable solution, although round trip latency is quite high. My understanding is that the wireless and wireline backbone networks interconnect/peer in the eastern Texas area, meaning that a wireless-to-wireline connection where both ends are in Southern California must traverse the US back to Texas for every packet. Another issue for fixed 3G locations is their inadvertent association with microcell or picocell devices, where the geographical telco wireline/wireless backbone interconnect is also not geographically distributed throughout the US, resulting in longer round trip latency. Make sure that the telco's underlying cellular backbone, and its wireline interconnection/peering points are well understood. -----Original Message----- From: Elijah Savage [mailto:esavage at digitalrage.org] Sent: Thursday, November 17, 2011 9:10 PM To: NANOG list Subject: Verizon 3G/4G Multi question email. Is there anyone on this list that supports this infrastructure, (verizon 3G/4G Broadband) or is there a place a seasoned admin can go outside of the general support desk to get assistance when a major outage is occurring? Secondly has anyone on this list deployed this technology within their infrastructure and can speak on the experience. Thank you This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From BEJones at semprautilities.com Fri Nov 18 15:50:31 2011 From: BEJones at semprautilities.com (Jones, Barry) Date: Fri, 18 Nov 2011 13:50:31 -0800 Subject: Portable Analyzers Message-ID: Just curious if anyone is using handheld network analyzers or to what extent and results - yeah/neah? I have used this product, and others, but wondered if anyone had others? OptiView(r) Portable Network Analyzer -Thanks for the feedback. --------------------------------------- Barry Jones - CISSP GSNA Project Manager II Sempra Energy Utilities (760) 271-6822 P please don't print this e-mail unless you really need to. ---------------------------------------- From cidr-report at potaroo.net Fri Nov 18 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Nov 2011 22:00:00 GMT Subject: BGP Update Report Message-ID: <201111182200.pAIM001Z073931@wattle.apnic.net> BGP Update Report Interval: 10-Nov-11 -to- 17-Nov-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 48265 2.6% 28.0 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS9829 38906 2.1% 52.9 -- BSNL-NIB National Internet Backbone 3 - AS7552 38240 2.1% 27.4 -- VIETEL-AS-AP Vietel Corporation 4 - AS15180 28145 1.5% 827.8 -- Diveo do Brasil Telecomunicacoes Ltda 5 - AS19743 27477 1.5% 3925.3 -- 6 - AS32528 23428 1.3% 5857.0 -- ABBOTT Abbot Labs 7 - AS6316 21598 1.2% 260.2 -- AS-PAETEC-NET - PaeTec Communications, Inc. 8 - AS27738 20805 1.1% 61.2 -- Ecuadortelecom S.A. 9 - AS20632 19602 1.1% 612.6 -- PETERSTAR-AS PeterStar 10 - AS31148 16200 0.9% 39.6 -- FREENET-AS FreeNet ISP 11 - AS11492 13132 0.7% 13.9 -- CABLEONE - CABLE ONE, INC. 12 - AS9498 12596 0.7% 15.0 -- BBIL-AP BHARTI Airtel Ltd. 13 - AS5800 11958 0.7% 49.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 14 - AS8866 10511 0.6% 159.3 -- BTC-AS Bulgarian Telecommunication Company Plc. 15 - AS36923 10226 0.6% 53.3 -- SWIFTNG-ASN 16 - AS12880 9615 0.5% 100.2 -- DCI-AS Information Technology Company (ITC) 17 - AS6389 9593 0.5% 2.7 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 18 - AS28885 9025 0.5% 73.4 -- OMANTEL-NAP-AS OmanTel NAP 19 - AS29049 8420 0.5% 21.9 -- DELTA-TELECOM-AS Delta Telecom LTD. 20 - AS8151 8284 0.5% 8.3 -- Uninet S.A. de C.V. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 23428 1.3% 5857.0 -- ABBOTT Abbot Labs 2 - AS19743 27477 1.5% 3925.3 -- 3 - AS17408 3184 0.2% 3184.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 4 - AS15180 28145 1.5% 827.8 -- Diveo do Brasil Telecomunicacoes Ltda 5 - AS20136 778 0.0% 778.0 -- MCGASN1 - Mainstream Consulting Group, Inc 6 - AS57405 769 0.0% 769.0 -- MIHAN-NOC2 MIHAN COMMUNICATION SYSTEMS CO.,LTD 7 - AS38528 671 0.0% 671.0 -- LANIC-AS-AP Lao National Internet Committee 8 - AS49466 614 0.0% 614.0 -- DECLIC-TELECOM Declic Telecom SAS 9 - AS20632 19602 1.1% 612.6 -- PETERSTAR-AS PeterStar 10 - AS11323 595 0.0% 595.0 -- GETTYIMAGES - Getty Images 11 - AS46088 560 0.0% 560.0 -- ZECONTECH - Zecontech, Inc. 12 - AS36995 1012 0.1% 506.0 -- MTN-CI 13 - AS37909 496 0.0% 496.0 -- WAKHOK-NET Wakkanai Hokusei Gakuen University 14 - AS56939 470 0.0% 470.0 -- CREDOS Credo-S Ltd. 15 - AS28272 912 0.1% 456.0 -- F-TELECOM TELECOMUNICA??ES LTDA 16 - AS16916 7274 0.4% 454.6 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 17 - AS6072 6286 0.3% 449.0 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com 18 - AS53558 1774 0.1% 443.5 -- TSG-3 - TCN Systems Group 19 - AS46975 2443 0.1% 407.2 -- MHS-CHI - Merriman Hosting Solutions, LLC 20 - AS12170 403 0.0% 403.0 -- PENTELOFAMERICA - Pentel of America, LTD. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 84.204.132.0/24 19433 1.0% AS20632 -- PETERSTAR-AS PeterStar 2 - 130.36.34.0/24 11712 0.6% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.35.0/24 11712 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 66.248.104.0/21 10750 0.6% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 5 - 213.16.48.0/24 10176 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 6 - 202.92.235.0/24 9581 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 7 - 66.248.120.0/21 7638 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 8 - 206.80.93.0/24 7247 0.4% AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 9 - 65.122.196.0/24 6482 0.3% AS19743 -- 10 - 208.98.239.0/24 4464 0.2% AS25983 -- ENMAX-ENVISION - Enmax Envision Inc. 11 - 66.238.91.0/24 4199 0.2% AS19743 -- 12 - 65.162.204.0/24 4199 0.2% AS19743 -- 13 - 66.89.98.0/24 4199 0.2% AS19743 -- 14 - 65.163.182.0/24 4199 0.2% AS19743 -- 15 - 72.164.144.0/24 4198 0.2% AS19743 -- 16 - 202.153.174.0/24 3184 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 17 - 66.248.96.0/21 2959 0.1% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 18 - 192.139.142.0/24 2270 0.1% AS23498 -- CDSI - Cogeco Data Services Inc. 19 - 217.52.130.0/24 1869 0.1% AS15475 -- NOL AS36992 -- ETISALAT-MISR 20 - 217.52.70.0/24 1803 0.1% AS15475 -- NOL AS36992 -- ETISALAT-MISR 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 Nov 18 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Nov 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201111182200.pAIM00l0073924@wattle.apnic.net> This report has been generated at Fri Nov 18 21:12:31 2011 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 11-11-11 383517 224976 12-11-11 383866 222778 13-11-11 382573 224878 14-11-11 383706 224973 15-11-11 384163 225105 16-11-11 384097 225263 17-11-11 384218 225441 18-11-11 384382 225242 AS Summary 39442 Number of ASes in routing system 16629 Number of ASes announcing only one prefix 3541 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108833792 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'). --- 18Nov11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 384714 225263 159451 41.4% All ASes AS6389 3541 227 3314 93.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2093 406 1687 80.6% COVAD - Covad Communications Co. AS4766 2516 994 1522 60.5% KIXS-AS-KR Korea Telecom AS7029 2947 1529 1418 48.1% WINDSTREAM - Windstream Communications Inc AS22773 1500 112 1388 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1524 245 1279 83.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1615 391 1224 75.8% TWTC - tw telecom holdings, inc. AS28573 1501 423 1078 71.8% NET Servicos de Comunicao S.A. AS1785 1851 781 1070 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 1387 401 986 71.1% VZGNI-TRANSIT - Verizon Online LLC AS7552 1394 426 968 69.4% VIETEL-AS-AP Vietel Corporation AS10620 1706 745 961 56.3% Telmex Colombia S.A. AS8402 1539 604 935 60.8% CORBINA-AS OJSC "Vimpelcom" AS7303 1238 360 878 70.9% Telecom Argentina S.A. AS18101 953 149 804 84.4% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1451 677 774 53.3% Uninet S.A. de C.V. AS4808 1097 341 756 68.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS30036 1428 676 752 52.7% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS7545 1627 948 679 41.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1107 457 650 58.7% LEVEL3 Level 3 Communications AS17974 1647 1007 640 38.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS24560 965 339 626 64.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 663 71 592 89.3% GIGAINFRA Softbank BB Corp. AS20115 1596 1008 588 36.8% CHARTER-NET-HKY-NC - Charter Communications AS4804 680 95 585 86.0% MPX-AS Microplex PTY LTD AS3549 1013 445 568 56.1% GBLX Global Crossing Ltd. AS22561 935 375 560 59.9% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 580 33 547 94.3% VTR BANDA ANCHA S.A. AS7011 1168 646 522 44.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS17488 908 392 516 56.8% HATHWAY-NET-AP Hathway IP Over Cable Internet Total 44170 15303 28867 65.4% 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- 41.222.79.0/24 AS37345 MEDALLION 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 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 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 100.42.16.0/20 AS46841 FORKNETWORKING - Fork Networking, LLC 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 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 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 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.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 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.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 205.233.73.0/24 AS11605 FLUIDSOFT-14 - Fluidsoft Incorporated 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 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 barry at opensolutions.ie Sat Nov 19 03:53:20 2011 From: barry at opensolutions.ie (Barry O'Donovan) Date: Sat, 19 Nov 2011 09:53:20 +0000 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: <4EC545A2.9040208@rollernet.us> References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> <4EC545A2.9040208@rollernet.us> Message-ID: <4EC77C90.9070906@opensolutions.ie> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/11/11 17:34, Seth Mattinen wrote: > Mikrotik RouterBoards are low cost and robust. It can be scripted > to do things like call a specific URL every X minutes. Some models > have just a single Ethernet port as well (they're designed to be > used as a wireless AP/CPE with an add-in mini PCI card) for even > less confusion about plugging it in. +1 E.g.: http://routerboard.com/RB750 @ $39.99. I'm sure for bulk buying they get a lot cheaper. Should easily fit into an automated provisioning process. - Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7HfJAACgkQ9qwC7To4L8y0dQCgy1p1Zoh/7ZqLue74E6W89NGh QsUAn1fm8g/r6QasPJb7Od0F+EA8Qw87 =MoIy -----END PGP SIGNATURE----- From joelja at bogus.com Sat Nov 19 14:34:41 2011 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 20 Nov 2011 04:34:41 +0800 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: <2455871F-06B6-4B3F-8943-53CFC46438C5@gmail.com> References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> <2455871F-06B6-4B3F-8943-53CFC46438C5@gmail.com> Message-ID: <4EC812E1.401@bogus.com> On 11/19/11 01:35 , Fearghas McKay wrote: > > On 17 Nov 2011, at 12:58, A. Chase Turner wrote: > >> I am seeking a $100 turnkey micro hardware appliance to plug into a LAN hub (behind a consumer-level cable modem) whose only purpose in life is to send heartbeat (and simple quality of service metrics) to a pre-configured central aggregation service on the WAN. > > Have a look at the Atlas project from RIPE - http://atlas.ripe.net/ > > Their hardware is aimed at costing 50? including distribution etc. They have said they were not going to make it available but they might collaborate ? > > HTH http://ubnt.com/rspro is a board I've run openwrt on with a great deal of success. it's powerful enough to host rather a lot of things compared to a basic ap. > > f > > > From don at bowenvale.co.nz Sat Nov 19 15:31:18 2011 From: don at bowenvale.co.nz (Don Gould) Date: Sun, 20 Nov 2011 10:31:18 +1300 Subject: abuse@brasiltelecom.com.br Contact - Re: http://ipcacoal.org/ipcacoal/includes/kiwi.htm Message-ID: <4EC82026.4080409@bowenvale.co.nz> Anyone with any clue on how to contact abuse at brasiltelecom.com.br like to forward this? Their abuse contact in the whois database is just bouncing. I do realise this is just day to day noise, but as you can see from the trail below, I have used the normal tools that we put in place to mange these sorts of issues. I have noted over the past 12 months, quite a bit of discussion on NANog about Whois and that fact that the resource is now failing. I would like to see the community address the whois database, clean it up and return it to being functional. Mine is not perfect either, and I will pledge to work on that over the next 12 months. I'd like to year your commitment to the same. Cheers D Sirs, A host in your IP range is hosting a bank security breach web site. Can you please address this? http://ipcacoal.org/ipcacoal/includes/kiwi.htm - Please see the correct site at www.kiwibank.co.nz # whois ipcacoal.org NOTICE: Access to .ORG WHOIS information is provided to assist persons in determining the contents of a domain name registration record in the Public Interest Registry registry database. The data in this record is provided by Public Interest Registry for informational purposes only, and Public Interest Registry does not guarantee its accuracy. This service is intended only for query-based access. You agree that you will use this data only for lawful purposes and that, under no circumstances will you use this data to: (a) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-Accredited Registrar, except as reasonably necessary to register domain names or modify existing registrations. All rights reserved. Public Interest Registry reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy. Domain ID:D155949678-LROR Domain Name:IPCACOAL.ORG Created On:24-Apr-2009 12:20:02 UTC Last Updated On:02-Apr-2011 20:41:14 UTC Expiration Date:24-Apr-2012 12:20:02 UTC Sponsoring Registrar:eNom, Inc. (R39-LROR) Status:CLIENT TRANSFER PROHIBITED Registrant ID:a81fb17fb96efad6 Registrant Name:Kallew Cesar Braganca Pavao Registrant Organization:ipcacoal.org Registrant Street1:Rua Carlos SCherrer, 478 Registrant Street2: Registrant Street3: Registrant City:Cacoal Registrant State/Province: Registrant Postal Code:76962-278 Registrant Country:BR Registrant Phone:+55.6934418628 Registrant Phone Ext.: Registrant FAX:+55.6934418628 Registrant FAX Ext.: Registrant Email:k182_ at hotmail.com Admin ID:a81fb17fb96efad6 Admin Name:Kallew Cesar Braganca Pavao Admin Organization:ipcacoal.org Admin Street1:Rua Carlos SCherrer, 478 Admin Street2: Admin Street3: Admin City:Cacoal Admin State/Province: Admin Postal Code:76962-278 Admin Country:BR Admin Phone:+55.6934418628 Admin Phone Ext.: Admin FAX:+55.6934418628 Admin FAX Ext.: Admin Email:k182_ at hotmail.com Tech ID:a81fb17fb96efad6 Tech Name:Kallew Cesar Braganca Pavao Tech Organization:ipcacoal.org Tech Street1:Rua Carlos SCherrer, 478 Tech Street2: Tech Street3: Tech City:Cacoal Tech State/Province: Tech Postal Code:76962-278 Tech Country:BR Tech Phone:+55.6934418628 Tech Phone Ext.: Tech FAX:+55.6934418628 Tech FAX Ext.: Tech Email:k182_ at hotmail.com Name Server:NS1.SERVIDORPROTEGIDO.NET Name Server:NS2.SERVIDORPROTEGIDO.NET Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: DNSSEC:Unsigned # host ipcacoal.org ipcacoal.org has address 200.160.239.14 ipcacoal.org mail is handled by 0 ipcacoal.org. # whois 200.160.239.14 % Copyright (c) Nic.br % The use of the data below is only permitted as described in % full by the terms of use (http://registro.br/termo/en.html), % being prohibited its distribution, comercialization or % reproduction, in particular, to use it for advertising or % any similar purpose. % 2011-11-19 19:16:09 (BRST -02:00) inetnum: 200.160.239/24 aut-num: AS8167 abuse-c: BTA17 owner: Gallas Software e Internet LTDA. ownerid: 005.753.287/0001-44 responsible: Depto. Registro de Dom?nios / ABUSE country: BR owner-c: HOHSI2 tech-c: HOHSI2 inetrev: 200.160.239/24 nserver: ns1.homehost.com.br nsstat: 20111116 AA nslastaa: 20111116 nserver: ns2.homehost.com.br nsstat: 20111116 AA nslastaa: 20111116 created: 20081020 changed: 20081020 inetnum-up: 200.160.224/19 nic-hdl-br: BTA17 person: Brasil Telecom S. A - Abuso e-mail: abuse at noc.brasiltelecom.net.br created: 20030624 changed: 20050214 nic-hdl-br: HOHSI2 person: HOMEHOST Hospedagem de Sites e-mail: registro at homehost.com.br created: 20060716 changed: 20101014 % Security and mail abuse issues should also be addressed to % cert.br, http://www.cert.br/, respectivelly to cert at cert.br % and mail-abuse at cert.br % % whois.registro.br accepts only direct match queries. Types % of queries are: domain (.br), ticket, provider, ID, CIDR % block, IP and ASN. -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From mysidia at gmail.com Sat Nov 19 15:50:07 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 19 Nov 2011 15:50:07 -0600 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> Message-ID: On Thu, Nov 17, 2011 at 6:58 AM, A. Chase Turner wrote: > I am seeking a $100 turnkey micro hardware appliance to plug into a LAN hub (behind a consumer-level cable modem) whose only purpose in life is to send heartbeat (and simple quality of service metrics) to a pre-configured central aggregation service on the WAN. > Key requirement is the micro hardware appliance will be installed by non-technical elderly end-users -- so, it must [snip] I think your expectation of finding an off-the-shelf turnkey unit that will do such a specialized thing for $100 or less with no extra work, is a bit unreasonable. Your requirement is such a niche requirement, that there is little demand for such a unit, meaning you won't find a mass produced hardware component out of a box specifically designed to do that specific thing at optimal cost, and general purpose miniature embedded computer boards are cheaper. Although you get the work of building the firmware components to make it do what you intend. Companies that build products for such a niche market need a decent margin for each unit sold, to compensate for low volume. I would say look at something like a Soekris net4501 or other low-cost mini computer board, that you can load a flash card on and install BSD on; I think approximately $90 for board + case, then you need to factor in cost of other components such as flash memory. >From there you need to build the configuration GUI, write some scripts, and build an image to load on your customized general purpose computing devices. Your end user doesn't need to do all that extra work of scripting or copying data to the unit as long as you provide the pre-assembled unit with your prepared image -- -JH From joe at nethead.com Sat Nov 19 16:25:42 2011 From: joe at nethead.com (Joe Hamelin) Date: Sat, 19 Nov 2011 14:25:42 -0800 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play appliance to report network outages In-Reply-To: References: <5738C4CB-0114-40B7-9B6D-946F1DFD0104@stumpy.com> Message-ID: On Thu, Nov 17, 2011 at 6:58 AM, A. Chase Turner wrote: > I am seeking a $100 turnkey micro hardware appliance to plug into a LAN hub... Why micro? Just get a pile of free for the carting-off old Pentium machines and run them headless with a BSD. Set them up to heartbeat to a cacti box. Why buy new when you have a good use for the old stuff that is going to a dump anyway? -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From jgreco at ns.sol.net Sat Nov 19 18:04:59 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 19 Nov 2011 18:04:59 -0600 (CST) Subject: Query : seeking a (low cost & secure) turnkey plug-and-play In-Reply-To: Message-ID: <201111200004.pAK04xav073821@aurora.sol.net> > On Thu, Nov 17, 2011 at 6:58 AM, A. Chase Turner wrote: > > I am seeking a $100 turnkey micro hardware appliance to plug into a LAN > hub... > > Why micro? Just get a pile of free for the carting-off old Pentium > machines and run them headless with a BSD. Set them up to heartbeat to a > cacti box. Why buy new when you have a good use for the old stuff that is > going to a dump anyway? As long as you're not paying the electric bill. But quite frankly, some of the stuff that's been put out over the years is better off in a dump. ... 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 jra at baylink.com Sat Nov 19 18:22:09 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 19 Nov 2011 19:22:09 -0500 (EST) Subject: Query : seeking a (low cost & secure) turnkey plug-and-play In-Reply-To: <201111200004.pAK04xav073821@aurora.sol.net> Message-ID: <31096929.3417.1321748529285.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Greco" > Subject: Re: Query : seeking a (low cost & secure) turnkey plug-and-play > > On Thu, Nov 17, 2011 at 6:58 AM, A. Chase Turner > > wrote: > > > I am seeking a $100 turnkey micro hardware appliance to plug into > > > a LAN hub... > > > > Why micro? Just get a pile of free for the carting-off old Pentium > > machines and run them headless with a BSD. Set them up to heartbeat > > to a cacti box. Why buy new when you have a good use for the old stuff > > that is going to a dump anyway? > > As long as you're not paying the electric bill. But quite frankly, > some of the stuff that's been put out over the years is better off in a > dump. I find myself pretty surprised that no one I've seen so far has suggested *these*: http://techreport.com/discussions.x/16466 They seem directly on target for what Chase is looking for. 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 Nov 19 18:25:31 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 19 Nov 2011 19:25:31 -0500 (EST) Subject: Query : seeking a (low cost & secure) turnkey plug-and-play In-Reply-To: <31096929.3417.1321748529285.JavaMail.root@benjamin.baylink.com> Message-ID: <11827950.3419.1321748731479.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Ashworth" > I find myself pretty surprised that no one I've seen so far has > suggested *these*: > > http://techreport.com/discussions.x/16466 > > They seem directly on target for what Chase is looking for. Here (apologies) is some retail: http://www.globalscaletechnologies.com/ http://www.ionicsplug.com/products.html And Marvell's page: http://www.marvell.com/solutions/plug-computers/ I don't think these have Powerline ethernet, more's the pity... 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 r.engehausen at gmail.com Sat Nov 19 18:30:39 2011 From: r.engehausen at gmail.com (Roy) Date: Sat, 19 Nov 2011 16:30:39 -0800 Subject: Query : seeking a (low cost & secure) turnkey plug-and-play In-Reply-To: <201111200004.pAK04xav073821@aurora.sol.net> References: <201111200004.pAK04xav073821@aurora.sol.net> Message-ID: <4EC84A2F.40605@gmail.com> On 11/19/2011 4:04 PM, Joe Greco wrote: >> On Thu, Nov 17, 2011 at 6:58 AM, A. Chase Turner wrote: >>> I am seeking a $100 turnkey micro hardware appliance to plug into a LAN >> hub... >> >> Why micro? Just get a pile of free for the carting-off old Pentium >> machines and run them headless with a BSD. Set them up to heartbeat to a >> cacti box. Why buy new when you have a good use for the old stuff that is >> going to a dump anyway? > As long as you're not paying the electric bill. But quite frankly, some > of the stuff that's been put out over the years is better off in a dump. > > ... JG They also have moving parts like disk drives and fans that will wear out and need replacement. From jgreco at ns.sol.net Sat Nov 19 18:32:33 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 19 Nov 2011 18:32:33 -0600 (CST) Subject: Query : seeking a (low cost & secure) turnkey plug-and-play In-Reply-To: <4EC84A2F.40605@gmail.com> Message-ID: <201111200032.pAK0WXLQ074198@aurora.sol.net> > On 11/19/2011 4:04 PM, Joe Greco wrote: > >> On Thu, Nov 17, 2011 at 6:58 AM, A. Chase Turner wrote: > >>> I am seeking a $100 turnkey micro hardware appliance to plug into a LAN > >> hub... > >> > >> Why micro? Just get a pile of free for the carting-off old Pentium > >> machines and run them headless with a BSD. Set them up to heartbeat to a > >> cacti box. Why buy new when you have a good use for the old stuff that is > >> going to a dump anyway? > > As long as you're not paying the electric bill. But quite frankly, some > > of the stuff that's been put out over the years is better off in a dump. > > > > ... JG > > They also have moving parts like disk drives and fans that will wear out > and need replacement. In all fairness, everything breaks. But, yeah, it may also break quicker. ... 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 detoler at gmail.com Sat Nov 19 18:51:24 2011 From: detoler at gmail.com (Duane Toler) Date: Sat, 19 Nov 2011 19:51:24 -0500 Subject: ASA log viewer Message-ID: Hey NANOG! My employer is deploying CIsco ASA firewalls to our clients (specifically the 5505, 5510 for our smaller clients). We are having problems finding a decent log viewer. Several products seem to mean well, but they all fall short for various reasons. We primarily use Check Point firewalls, and for those of you with that experience, you know the SmartViewer Tracker is quite powerful. Is there anything close to the flexibility and filtering capabilities of Check Point's SmartView Tracker? For now, I've been dumping the logs via syslog with TLS using syslog-ng to our server, but that is mediocre at best with varying degrees of reliability. The syslog-ng server then sends that to a perl script to put that into a database. That allows us to run our monthly reports, but that doesn't help us with live or historical log parsing and filtering (see above, re: SmartView Tracker). If a customer called to help us troubleshoot connection issues over the past few days, there's no way to review the logs and figure out what happened back then. Every CCIE we've talked to, and Cisco themselves, seem to not care about firewall traffic logs or the ability to parse and review them. We know about Cisco Security Center, but that seems incapable of handling logs, etc. CS-MARS would've been great, but that's overpriced and now discontinued anyway. We'd hate to spend the time writing our own app if there's a viable product already available (we're willing to pay a reasonable price for one, too). Any ideas? Thanks!! From jra at baylink.com Sat Nov 19 19:04:05 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 19 Nov 2011 20:04:05 -0500 (EST) Subject: ASA log viewer In-Reply-To: Message-ID: <14658629.3421.1321751045105.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Duane Toler" > My employer is deploying CIsco ASA firewalls to our clients > (specifically the 5505, 5510 for our smaller clients). We are having > problems finding a decent log viewer. Several products seem to mean > well, but they all fall short for various reasons. We primarily use > Check Point firewalls, and for those of you with that experience, you > know the SmartViewer Tracker is quite powerful. Is there anything > close to the flexibility and filtering capabilities of Check Point's > SmartView Tracker? Is your problem the aggregation proper, or the mining? Do the ASA's log to syslog? 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.lyon at gmail.com Sat Nov 19 19:30:40 2011 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 19 Nov 2011 17:30:40 -0800 Subject: ASA log viewer In-Reply-To: References: Message-ID: <-7906887935908757220@unknownmsgid> Check out Splunk (www.splunk.com) -mike Sent from my iPhone On Nov 19, 2011, at 16:51, Duane Toler wrote: > Hey NANOG! > > My employer is deploying CIsco ASA firewalls to our clients > (specifically the 5505, 5510 for our smaller clients). We are having > problems finding a decent log viewer. Several products seem to mean > well, but they all fall short for various reasons. We primarily use > Check Point firewalls, and for those of you with that experience, you > know the SmartViewer Tracker is quite powerful. Is there anything > close to the flexibility and filtering capabilities of Check Point's > SmartView Tracker? > > For now, I've been dumping the logs via syslog with TLS using > syslog-ng to our server, but that is mediocre at best with varying > degrees of reliability. The syslog-ng server then sends that to a > perl script to put that into a database. That allows us to run our > monthly reports, but that doesn't help us with live or historical log > parsing and filtering (see above, re: SmartView Tracker). > > If a customer called to help us troubleshoot connection issues over > the past few days, there's no way to review the logs and figure out > what happened back then. Every CCIE we've talked to, and Cisco > themselves, seem to not care about firewall traffic logs or the > ability to parse and review them. We know about Cisco Security > Center, but that seems incapable of handling logs, etc. CS-MARS > would've been great, but that's overpriced and now discontinued > anyway. We'd hate to spend the time writing our own app if there's a > viable product already available (we're willing to pay a reasonable > price for one, too). > > Any ideas? > > Thanks!! > From jof at thejof.com Sat Nov 19 19:30:49 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Sat, 19 Nov 2011 17:30:49 -0800 Subject: ASA log viewer In-Reply-To: References: Message-ID: On Sat, Nov 19, 2011 at 4:51 PM, Duane Toler wrote: > Hey NANOG! > > My employer is deploying CIsco ASA firewalls to our clients > (specifically the 5505, 5510 for our smaller clients). We are having > problems finding a decent log viewer. Several products seem to mean > well, but they all fall short for various reasons. We primarily use > Check Point firewalls, and for those of you with that experience, you > know the SmartViewer Tracker is quite powerful. Is there anything > close to the flexibility and filtering capabilities of Check Point's > SmartView Tracker? > > For now, I've been dumping the logs via syslog with TLS using > syslog-ng to our server, but that is mediocre at best with varying > degrees of reliability. The syslog-ng server then sends that to a > perl script to put that into a database. That allows us to run our > monthly reports, but that doesn't help us with live or historical log > parsing and filtering (see above, re: SmartView Tracker). > It sounds like you've already got a pretty good aggregation setup going, here. I've had great luck with UDP Syslog from devices to a site-local log aggregator that then ships off log streams to a central place over TCP (for the WAN paths) and/or TLS/SSL. It sounds like you may have something similar going here, though I'd be curious to know where you've had this fall down reliability-wise. If a customer called to help us troubleshoot connection issues over > the past few days, there's no way to review the logs and figure out > what happened back then. Every CCIE we've talked to, and Cisco > themselves, seem to not care about firewall traffic logs or the > ability to parse and review them. We know about Cisco Security > Center, but that seems incapable of handling logs, etc. CS-MARS > would've been great, but that's overpriced and now discontinued > anyway. We'd hate to spend the time writing our own app if there's a > viable product already available (we're willing to pay a reasonable > price for one, too). > I don't know of any great commercial products, as I've only built homegrown tools for various organizations. I'm curious though, what kinds of features are you looking for? Searching log data? Alerting on events based on log data? Cheers, jof From detoler at gmail.com Sat Nov 19 19:32:15 2011 From: detoler at gmail.com (Duane Toler) Date: Sat, 19 Nov 2011 20:32:15 -0500 Subject: ASA log viewer In-Reply-To: <14658629.3421.1321751045105.JavaMail.root@benjamin.baylink.com> References: <14658629.3421.1321751045105.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, Nov 19, 2011 at 20:04, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Duane Toler" > >> My employer is deploying CIsco ASA firewalls to our clients >> (specifically the 5505, 5510 for our smaller clients). We are having >> problems finding a decent log viewer. Several products seem to mean >> well, but they all fall short for various reasons. We primarily use >> Check Point firewalls, and for those of you with that experience, you >> know the SmartViewer Tracker is quite powerful. Is there anything >> close to the flexibility and filtering capabilities of Check Point's >> SmartView Tracker? > > Is your problem the aggregation proper, or the mining? > > Do the ASA's log to syslog? > > Cheers, > -- jra > -- Yep, we log to syslog, and the issue is the mining. Not that I/we *can't* grep/regex/sed/awk/perl our way thru the log files. It's just that it's overly tedious. Especially when compared to Check Point's product (given that they are aiming to compete...). From jof at thejof.com Sat Nov 19 19:36:22 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Sat, 19 Nov 2011 17:36:22 -0800 Subject: ASA log viewer In-Reply-To: References: <14658629.3421.1321751045105.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, Nov 19, 2011 at 5:32 PM, Duane Toler wrote: > On Sat, Nov 19, 2011 at 20:04, Jay Ashworth wrote: > > ----- Original Message ----- > >> From: "Duane Toler" > > > >> My employer is deploying CIsco ASA firewalls to our clients > >> (specifically the 5505, 5510 for our smaller clients). We are having > >> problems finding a decent log viewer. Several products seem to mean > >> well, but they all fall short for various reasons. We primarily use > >> Check Point firewalls, and for those of you with that experience, you > >> know the SmartViewer Tracker is quite powerful. Is there anything > >> close to the flexibility and filtering capabilities of Check Point's > >> SmartView Tracker? > > > > Is your problem the aggregation proper, or the mining? > > > > Do the ASA's log to syslog? > > > > Cheers, > > -- jra > > -- > > Yep, we log to syslog, and the issue is the mining. Not that I/we > *can't* grep/regex/sed/awk/perl our way thru the log files. It's just > that it's overly tedious. Especially when compared to Check Point's > product (given that they are aiming to compete...). > I'd second Mike's suggestion then -- check out Splunk. They make a commercial log viewing, searching, and reporting product that's pretty awesome. They license based on log volume, and the pricing scales somewhat logarithmically. So, I would consider your log volume and budget before sinking too much time into it. There's a free trial installation and license that's available if you want to try it out. Cheers, jof From detoler at gmail.com Sat Nov 19 19:46:06 2011 From: detoler at gmail.com (Duane Toler) Date: Sat, 19 Nov 2011 20:46:06 -0500 Subject: ASA log viewer In-Reply-To: References: Message-ID: On Sat, Nov 19, 2011 at 20:30, Jonathan Lassoff wrote: > On Sat, Nov 19, 2011 at 4:51 PM, Duane Toler wrote: >> >> Hey NANOG! >> >> My employer is deploying CIsco ASA firewalls to our clients >> (specifically the 5505, 5510 for our smaller clients). ?We are having >> problems finding a decent log viewer. ?Several products seem to mean >> well, but they all fall short for various reasons. ?We primarily use >> Check Point firewalls, and for those of you with that experience, you >> know the SmartViewer Tracker is quite powerful. ?Is there anything >> close to the flexibility and filtering capabilities of Check Point's >> SmartView Tracker? >> >> For now, I've been dumping the logs via syslog with TLS using >> syslog-ng to our server, but that is mediocre at best with varying >> degrees of reliability. ?The syslog-ng server then sends that to a >> perl script to put that into a database. ?That allows us to run our >> monthly reports, but that doesn't help us with live or historical log >> parsing and filtering (see above, re: SmartView Tracker). > > It sounds like you've already got a pretty good aggregation setup going, > here. I've had great luck with UDP Syslog from devices to a site-local log > aggregator that then ships off log streams to a central place over TCP (for > the WAN paths) and/or TLS/SSL. > It sounds like you may have something similar going here, though I'd be > curious to know where you've had this fall down reliability-wise. We considered that, but didn't want to "burden" small customers with a classic scenario of "ok well you have to have our other box in your room" and have to deal with procurement, maintenance, upkeep, monitoring, blah blah. Recent ASA code (8.3-ish, 8.4? i forget) had syslog-tls built in and finally able to ship logs out across the lowest security zone, which was quite a nice addition. The break down is periodic log-reporting failures. After some indeterminate time, the device seems to just "give up" and just not send logs. Plus, it doesn't reconnect on a failure. I added a Nagios check to monitor the state of things, so now I get notified in this situation (or at least within a few minutes). When this does occur, I ssh to the ASA and have to run the 'no logging enable' and then 'logging enable' to "jump start" it again. Sometime that's not even enough and I have to remove the logging command for external syslog and re-add it again. It's very weird and quite spurious. >> >> If a customer called to help us troubleshoot connection issues over >> the past few days, there's no way to review the logs and figure out >> what happened back then. ?Every CCIE we've talked to, and Cisco >> themselves, seem to not care about firewall traffic logs or the >> ability to parse and review them. ?We know about Cisco Security >> Center, but that seems incapable of handling logs, etc. ?CS-MARS >> would've been great, but that's overpriced and now discontinued >> anyway. ?We'd hate to spend the time writing our own app if there's a >> viable product already available (we're willing to pay a reasonable >> price for one, too). > > I don't know of any great commercial products, as I've only built homegrown > tools for various organizations. I'm curious though, what kinds of features > are you looking for? Searching log data? Alerting on events based on log > data? > Cheers, > jof I'd like to fully search on an 'column', a la 'ladder logic' style., as well as have the data presented in an orderly well-defined fashion. I know that sounded like the beginnings of "use XML!" but oh dear, not XML, please. :) Poor syslog is just too flat and in a state of general disarray. The bizarre arrangement of connection setup, NAT, non-NAT, traffic destined to the device, originating from the device, traffic routing across the to another zone, etc. ... it's very nonsensical, verbose, and frankly maddening. Best I can tell, the whole thing doesn't make any sense (and was a bear to tease apart with regex). I've gotten a few suggestions to check out Splunk, so I'll toss that into the review pile and see how that works out. Thanks to the folks who suggested that! -- Duane Toler detoler at gmail.com From jof at thejof.com Sat Nov 19 20:05:47 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Sat, 19 Nov 2011 18:05:47 -0800 Subject: ASA log viewer In-Reply-To: References: Message-ID: On Sat, Nov 19, 2011 at 5:46 PM, Duane Toler wrote: > On Sat, Nov 19, 2011 at 20:30, Jonathan Lassoff wrote: > > On Sat, Nov 19, 2011 at 4:51 PM, Duane Toler wrote: > >> > >> Hey NANOG! > >> > >> My employer is deploying CIsco ASA firewalls to our clients > >> (specifically the 5505, 5510 for our smaller clients). We are having > >> problems finding a decent log viewer. Several products seem to mean > >> well, but they all fall short for various reasons. We primarily use > >> Check Point firewalls, and for those of you with that experience, you > >> know the SmartViewer Tracker is quite powerful. Is there anything > >> close to the flexibility and filtering capabilities of Check Point's > >> SmartView Tracker? > >> > >> For now, I've been dumping the logs via syslog with TLS using > >> syslog-ng to our server, but that is mediocre at best with varying > >> degrees of reliability. The syslog-ng server then sends that to a > >> perl script to put that into a database. That allows us to run our > >> monthly reports, but that doesn't help us with live or historical log > >> parsing and filtering (see above, re: SmartView Tracker). > > > > It sounds like you've already got a pretty good aggregation setup going, > > here. I've had great luck with UDP Syslog from devices to a site-local > log > > aggregator that then ships off log streams to a central place over TCP > (for > > the WAN paths) and/or TLS/SSL. > > It sounds like you may have something similar going here, though I'd be > > curious to know where you've had this fall down reliability-wise. > > We considered that, but didn't want to "burden" small customers with a > classic scenario of "ok well you have to have our other box in your > room" and have to deal with procurement, maintenance, upkeep, > monitoring, blah blah. Recent ASA code (8.3-ish, 8.4? i forget) had > syslog-tls built in and finally able to ship logs out across the > lowest security zone, which was quite a nice addition. > Ah, this totally makes sense now. I can see why you'd want to use features that are already on your ASAs. Sounds like a bug to me, though. I wonder what Cisco calls syslog-tls though. Syslog-like packet bodies, over a TLS-wrapped TCP socket? Sorry to hear it's been so unreliable -- I guess that's why I'm biased towards just running generic PCs and open source software for this kind of stuff; when bugs happen, you're actually empowered to debug and fix problems. I'd like to fully search on an 'column', a la 'ladder logic' style., > as well as have the data presented in an orderly well-defined fashion. > I know that sounded like the beginnings of "use XML!" but oh dear, > not XML, please. :) Poor syslog is just too flat and in a state of > general disarray. The bizarre arrangement of connection setup, NAT, > non-NAT, traffic destined to the device, originating from the device, > traffic routing across the to another zone, etc. ... it's very > nonsensical, verbose, and frankly maddening. > This does indeed sound like a good application for splunk. They have ways of defining custom logging formats that will parse out simple column and message types so that you can construct queries based on that information. There's some more information here in Splunk's docs on custom field extraction: http://docs.splunk.com/Documentation/Splunk/latest/Knowledge/Managesearch-timefieldextractions Cheers, jof From pfunix at gmail.com Sat Nov 19 20:19:24 2011 From: pfunix at gmail.com (Beavis) Date: Sat, 19 Nov 2011 20:19:24 -0600 Subject: ASA log viewer In-Reply-To: <-7906887935908757220@unknownmsgid> References: <-7906887935908757220@unknownmsgid> Message-ID: +1 here i use splunk for sorting out logs pretty cool tool. easy to install. On Sat, Nov 19, 2011 at 7:30 PM, Mike Lyon wrote: > Check out Splunk (www.splunk.com) > > -mike > > Sent from my iPhone > > On Nov 19, 2011, at 16:51, Duane Toler wrote: > >> Hey NANOG! >> >> My employer is deploying CIsco ASA firewalls to our clients >> (specifically the 5505, 5510 for our smaller clients). ?We are having >> problems finding a decent log viewer. ?Several products seem to mean >> well, but they all fall short for various reasons. ?We primarily use >> Check Point firewalls, and for those of you with that experience, you >> know the SmartViewer Tracker is quite powerful. ?Is there anything >> close to the flexibility and filtering capabilities of Check Point's >> SmartView Tracker? >> >> For now, I've been dumping the logs via syslog with TLS using >> syslog-ng to our server, but that is mediocre at best with varying >> degrees of reliability. ?The syslog-ng server then sends that to a >> perl script to put that into a database. ?That allows us to run our >> monthly reports, but that doesn't help us with live or historical log >> parsing and filtering (see above, re: SmartView Tracker). >> >> If a customer called to help us troubleshoot connection issues over >> the past few days, there's no way to review the logs and figure out >> what happened back then. ?Every CCIE we've talked to, and Cisco >> themselves, seem to not care about firewall traffic logs or the >> ability to parse and review them. ?We know about Cisco Security >> Center, but that seems incapable of handling logs, etc. ?CS-MARS >> would've been great, but that's overpriced and now discontinued >> anyway. ?We'd hate to spend the time writing our own app if there's a >> viable product already available (we're willing to pay a reasonable >> price for one, too). >> >> Any ideas? >> >> Thanks!! >> > > -- ()? ascii ribbon campaign - against html e-mail /\? www.asciiribbon.org?? - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From detoler at gmail.com Sat Nov 19 20:20:12 2011 From: detoler at gmail.com (Duane Toler) Date: Sat, 19 Nov 2011 21:20:12 -0500 Subject: ASA log viewer In-Reply-To: References: Message-ID: <7226709195947507494@unknownmsgid> On Nov 19, 2011, at 9:05 PM, Jonathan Lassoff wrote: Ah, this totally makes sense now. I can see why you'd want to use features that are already on your ASAs. Sounds like a bug to me, though. I wonder what Cisco calls syslog-tls though. Syslog-like packet bodies, over a TLS-wrapped TCP socket? Sorry to hear it's been so unreliable -- I guess that's why I'm biased towards just running generic PCs and open source software for this kind of stuff; when bugs happen, you're actually empowered to debug and fix problems. Yep all of our other gear is Linux for that reason (plus Mac OS on the desktop so things "just work"). Cisco called the syslog-TLS stuff just "syslog" plus a "secure" parameter, and port 1470 by default. ASDM had a fairly helpful interface to get it configured. I think it requires the K9 image or whatever it's called to get the option. This does indeed sound like a good application for splunk. They have ways of defining custom logging formats that will parse out simple column and message types so that you can construct queries based on that information. There's some more information here in Splunk's docs on custom field extraction: http://docs.splunk.com/Documentation/Splunk/latest/Knowledge/Managesearch-timefieldextractions Cheers, jof Sounds promising! Thanks again! Sent from my iPad From Joel.Snyder at Opus1.COM Sun Nov 20 00:10:46 2011 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Sun, 20 Nov 2011 07:10:46 +0100 Subject: ASA log viewer Message-ID: <4EC899E6.3060606@opus1.com> >I'd like to fully search on an 'column', a la 'ladder logic' style., >as well as have the data presented in an orderly well-defined fashion. Yes, Splunk. See: http://www.networkworld.com/reviews/2011/092611-splunk-test-250836.html for a recent Network World test of Splunk which may help. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From goemon at anime.net Sun Nov 20 00:18:19 2011 From: goemon at anime.net (goemon at anime.net) Date: Sat, 19 Nov 2011 22:18:19 -0800 (PST) Subject: abuse@brasiltelecom.com.br Contact - Re: http://ipcacoal.org/ipcacoal/includes/kiwi.htm In-Reply-To: <4EC82026.4080409@bowenvale.co.nz> References: <4EC82026.4080409@bowenvale.co.nz> Message-ID: On Sun, 20 Nov 2011, Don Gould wrote: > Anyone with any clue on how to contact abuse at brasiltelecom.com.br like to > forward this? Their abuse contact in the whois database is just bouncing. I think most sane operators totally blocked brasiltelecom ages ago. > I would like to see the community address the whois database, clean it up and > return it to being functional. Mine is not perfect either, and I will pledge > to work on that over the next 12 months. I'd like to year your commitment to > the same. Until there are real, serious consequences to out of date / incorrect / forged data, nobody will fix it. If you can't be bothered to keep your contact information up to date, you obviously don't need the address space and it should be revoked. -Dan From Joe.Happe at archlearning.com Sun Nov 20 06:42:42 2011 From: Joe.Happe at archlearning.com (Joe Happe) Date: Sun, 20 Nov 2011 12:42:42 +0000 Subject: ASA log viewer In-Reply-To: <4EC899E6.3060606@opus1.com> References: <4EC899E6.3060606@opus1.com> Message-ID: Completely agree with splunk for log searching / analysis, even has some ASA/PIX modules. Please note, unless something has changed that I completely missed, an ASA/PIX will stop forwarding user traffic if it is configured for tcp syslogs and the connection breaks. (no more disk, network issue, etc) This is based on the premise that a system cannot be considered secure if the audit trail is unavailable, and tcp syslogging(vs udp) is usually used to make sure you don't miss an entry due to a dropped packet. Something that dates back to the old C2 security standard??(not sure of the current version). Typically this requires admin intervention (by design) to clear the condition. If you use udp for syslog the ASA won't be in this mode, and you won't block traffic if syslog fails. With that said, there may be a command I'm unaware of that allows a tcp syslog to fail and not block traffic. ~jdh -----Original Message----- From: Joel M Snyder [mailto:Joel.Snyder at Opus1.COM] Sent: Sunday, November 20, 2011 12:11 AM To: nanog at nanog.org Subject: Re: ASA log viewer >I'd like to fully search on an 'column', a la 'ladder logic' style., >as well as have the data presented in an orderly well-defined fashion. Yes, Splunk. See: http://www.networkworld.com/reviews/2011/092611-splunk-test-250836.html for a recent Network World test of Splunk which may help. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms ______________________________________________________________________________________________________ The information contained in this electronic message and any attachments is confidential, is for the sole use of the intended recipient(s) and may contain privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, you must not read, use or disseminate the information, and should immediately contact the sender by reply email and destroy all copies of the original message. From jjanusze at wd-tek.com Sun Nov 20 08:23:29 2011 From: jjanusze at wd-tek.com (jjanusze at wd-tek.com) Date: Sun, 20 Nov 2011 09:23:29 -0500 (EST) Subject: ASA log viewer In-Reply-To: References: <4EC899E6.3060606@opus1.com> Message-ID: <58287622.486183.1321799009465.JavaMail.open-xchange@email.1and1.com The logging host command enables a secure connection via TLS, and to configure use of a TCP port for logging. ???? e.g.,? interface_name syslog_ip[tcp/port] [emblem format] [secure] Also, when you do a sho log, do you have the following set? ???? Deny Conn when Queue Full: disabled ? On November 20, 2011 at 7:42 AM Joe Happe wrote: > Completely agree with splunk for log searching / analysis, even has some > ASA/PIX modules.? Please note, unless something has changed that I completely > missed, an ASA/PIX will stop forwarding user traffic if it is configured for > tcp syslogs and the connection breaks.? (no more disk, network issue, etc) > This is based on the premise that a system cannot be considered secure if the > audit trail is unavailable, and tcp syslogging(vs udp) is usually used to make > sure you don't miss an entry due to a dropped packet.? Something that dates > back to the old C2 security standard??(not sure of the current version).? > ?Typically this requires admin intervention (by design) to clear the > condition.? ?If you use udp for syslog the ASA won't be in this mode, and you > won't block traffic if syslog fails.? With that said, there may be a command > I'm unaware of that allows a tcp syslog to fail and not block traffic.? > > ~jdh > > -----Original Message----- > From: Joel M Snyder [mailto:Joel.Snyder at Opus1.COM] > Sent: Sunday, November 20, 2011 12:11 AM > To: nanog at nanog.org > Subject: Re: ASA log viewer > >? >I'd like to fully search on an 'column', a la 'ladder logic' style.,? >as >well as have the data presented in an orderly well-defined fashion. > > Yes, Splunk. > > See: > http://www.networkworld.com/reviews/2011/092611-splunk-test-250836.html > > for a recent Network World test of Splunk which may help. > > jms > > > -- > Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 > Senior Partner, Opus One? ? ? ?Phone: +1 520 324 0494 > jms at Opus1.COM? ? ? ? ? ? ? ? http://www.opus1.com/jms > > ______________________________________________________________________________________________________ > > The information contained in this electronic message and any attachments is > confidential, > is for the sole use of the intended recipient(s) and may contain privileged > information. > Any unauthorized review, use, disclosure or distribution is prohibited. If you > are not the > intended recipient, you must not read, use or disseminate the information, and > should immediately > contact the sender by reply email and destroy all copies of the original > message. > > > From detoler at gmail.com Sun Nov 20 13:48:17 2011 From: detoler at gmail.com (Duane Toler) Date: Sun, 20 Nov 2011 14:48:17 -0500 Subject: ASA log viewer In-Reply-To: References: <4EC899E6.3060606@opus1.com> Message-ID: <6985415210366850948@unknownmsgid> I think it was ASA 8.3 that began to provide an option to NOT cease functionality when tcp syslog server was unreachable. In ASDM, it is a checkbox at the bottom of the logging servers config section. Sent from my iPhone On Nov 20, 2011, at 7:43, Joe Happe wrote: > Completely agree with splunk for log searching / analysis, even has some ASA/PIX modules. Please note, unless something has changed that I completely missed, an ASA/PIX will stop forwarding user traffic if it is configured for tcp syslogs and the connection breaks. (no more disk, network issue, etc) This is based on the premise that a system cannot be considered secure if the audit trail is unavailable, and tcp syslogging(vs udp) is usually used to make sure you don't miss an entry due to a dropped packet. Something that dates back to the old C2 security standard??(not sure of the current version). Typically this requires admin intervention (by design) to clear the condition. If you use udp for syslog the ASA won't be in this mode, and you won't block traffic if syslog fails. With that said, there may be a command I'm unaware of that allows a tcp syslog to fail and not block traffic. > > ~jdh > From detoler at gmail.com Sun Nov 20 13:48:54 2011 From: detoler at gmail.com (Duane Toler) Date: Sun, 20 Nov 2011 14:48:54 -0500 Subject: ASA log viewer In-Reply-To: <4ec90d77.4366e70a.5cfb.52f6SMTPIN_ADDED@mx.google.com> References: <4EC899E6.3060606@opus1.com> <4ec90d77.4366e70a.5cfb.52f6SMTPIN_ADDED@mx.google.com> Message-ID: <4998255390203579112@unknownmsgid> I'll go back to check that option about queue size. Thanks for the hint! Sent from my iPhone On Nov 20, 2011, at 9:23, "jjanusze at wd-tek.com" wrote: > > e.g., interface_name syslog_ip[tcp/port] [emblem format] [secure] > > > Also, when you do a sho log, do you have the following set? > > > Deny Conn when Queue Full: disabled > > From mysidia at gmail.com Sun Nov 20 16:33:52 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 20 Nov 2011 16:33:52 -0600 Subject: ASA log viewer In-Reply-To: References: <4EC899E6.3060606@opus1.com> Message-ID: On Sun, Nov 20, 2011 at 6:42 AM, Joe Happe wrote: >udp for syslog the ASA won't be in this mode, and you won't block traffic if syslog fails. ?With that said, there may be a command I'm unaware of that allows a tcp syslog to fail and not block traffic. Yes. logging permit-hostdown However, if you don't need to refuse connections when TCP syslog fails, then you don't need 100% of your syslog messages, you should use UDP syslog for performance. TCP just makes sure you will get all syslog messages between time A and time B or none of them. If there are WAN issues, there are many cases where one would prefer SOME syslog messages, with an understanding that the network bottleneck means messages are being lost, rather than few/no syslog messages to help debug the issue -- -JH From paul4004 at gmail.com Sun Nov 20 16:57:49 2011 From: paul4004 at gmail.com (PC) Date: Sun, 20 Nov 2011 15:57:49 -0700 Subject: ASA log viewer In-Reply-To: References: <4EC899E6.3060606@opus1.com> Message-ID: I guess this depends on how aggressive the TCP reconnection algorithm is vs. the packet loss of UDP... On the other hand, does ASA support "buffering" of syslog messages while TCP is down? I believe on some IOS platforms, with the right syslog options, it has the capability of queuing and delivering syslog messages generated during a period of network outage once the syslog session is re-established. Does ASA do this, or discard them? Now on the other hand, never route two ASAs to one another (IE: summary route design). They don't decrement TTL by default. I had one case where a loopy route got installed and the traffic just kept ping-ponging back and forth maxing the port. The brutal part was not the pegged port, but rather the many megabits of udp syslog that resulted that the WAN link couldn't handle. decrement-ttl and logging rate-limit are now on as a result. On the other hand, TCP syslog would have handled it much better without a denial of service condition. On Sun, Nov 20, 2011 at 3:33 PM, Jimmy Hess wrote: > On Sun, Nov 20, 2011 at 6:42 AM, Joe Happe > wrotewi: > >udp for syslog the ASA won't be in this mode, and you won't block traffic > if syslog fails. With that said, there may be a command I'm unaware of > that allows a tcp syslog to fail and not block traffic. > > Yes. > logging permit-hostdown > > However, if you don't need to refuse connections when TCP syslog > fails, then you don't need 100% of your syslog messages, you should > use UDP syslog for performance. > > TCP just makes sure you will get all syslog messages between time A > and time B or none of them. > If there are WAN issues, there are many cases where one would prefer > SOME syslog messages, with an understanding that the network > bottleneck means messages are being lost, rather than few/no syslog > messages to help debug the issue > > -- > -JH > > From tyler.haske at gmail.com Sun Nov 20 20:40:08 2011 From: tyler.haske at gmail.com (Tyler Haske) Date: Sun, 20 Nov 2011 21:40:08 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. Message-ID: Hi. I have some big goals and a lot of enthusiasm but I need direction. I'm looking for a mentor who can help me focus my career so eventually I wind up working at one of the Tier I ISPs as a senior tech. I want to handle the big pipes that hold everyone's data. This is what I want to do with my life. I have my CCNA, and when I graduate college I'll have a CCNP, and the ability to move anywhere in the USA. Please message me off-list. Thank you, Tyler. From morrowc.lists at gmail.com Sun Nov 20 20:47:06 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 20 Nov 2011 21:47:06 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: Message-ID: On Sun, Nov 20, 2011 at 9:40 PM, Tyler Haske wrote: > I'm looking for a mentor who can help me focus my career so eventually I > wind up working at one of the Tier I ISPs as a senior tech. I want to > handle the big pipes that hold everyone's data. why not just apply as a tech at any of the dozen or so large ISP's in the US? I'm sure some google-searching (or bing or whatever) would lead you in the right direction. From deleskie at gmail.com Sun Nov 20 20:58:30 2011 From: deleskie at gmail.com (jim deleskie) Date: Sun, 20 Nov 2011 22:58:30 -0400 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: Message-ID: What Chris said.... Get a job in the industry.. work like crazy learning as much as you can to learn, get involved in the industry to make connections. -jim On Sun, Nov 20, 2011 at 10:47 PM, Christopher Morrow wrote: > On Sun, Nov 20, 2011 at 9:40 PM, Tyler Haske wrote: >> I'm looking for a mentor who can help me focus my career so eventually I >> wind up working at one of the Tier I ISPs as a senior tech. I want to >> handle the big pipes that hold everyone's data. > > why not just apply as a tech at any of the dozen or so large ISP's in the US? > > > > > > > > I'm sure some google-searching (or bing or whatever) would lead you in > the right direction. > > From bmanning at vacation.karoshi.com Sun Nov 20 23:01:40 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 21 Nov 2011 05:01:40 +0000 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: Message-ID: <20111121050140.GB12920@vacation.karoshi.com.> Well, thats two mentors - and now one from the old school.... Why wait? Start Now. Use the resources Chris gave you & others you find, take Jims advice re total commitment, and then weigh that in the balance w/ your academic path. (noting that vendor credentials are good for the HR folks filtering the krill, but are not a reliable indication of skill or passion) Look for an internship while in school. Something part time. Build little ISPs in your dorm room using the VM tools and build/test complex topologies and random failure modes. Pipe size is one thing, engineering in your sleep is something else. of course YMMV. /bill (now too old/slow to run w/ the big dogs) From don at bowenvale.co.nz Sun Nov 20 23:35:45 2011 From: don at bowenvale.co.nz (Don Gould) Date: Mon, 21 Nov 2011 18:35:45 +1300 Subject: abuse@brasiltelecom.com.br Contact - Re: http://ipcacoal.org/ipcacoal/includes/kiwi.htm In-Reply-To: <4EC82026.4080409@bowenvale.co.nz> References: <4EC82026.4080409@bowenvale.co.nz> Message-ID: <4EC9E331.8090904@bowenvale.co.nz> Thank you to all those who ventured assistance and off line responses. There was, as you might expect a good range of some what amusing responses. It was also very uplifting to see some very helpful responses from people with contacts in the right areas, who speak the required languages and were willing to make some attempt to close down these issues. So thanks again to those who put in time and effort to just clean up these little messes. I promise I won't bring you every single one of these that hits my inbox. :) I do hope others will rise to my pledge to clean up my whois. :) D On 20/11/2011 10:31 a.m., Don Gould wrote: > Anyone with any clue on how to contact abuse at brasiltelecom.com.br like > to forward this? Their abuse contact in the whois database is just > bouncing. > > I do realise this is just day to day noise, but as you can see from the > trail below, I have used the normal tools that we put in place to mange > these sorts of issues. > > I have noted over the past 12 months, quite a bit of discussion on NANog > about Whois and that fact that the resource is now failing. > > I would like to see the community address the whois database, clean it > up and return it to being functional. Mine is not perfect either, and I > will pledge to work on that over the next 12 months. I'd like to year > your commitment to the same. > > Cheers D > > > Sirs, > > A host in your IP range is hosting a bank security breach web site. Can > you please address this? > > http://ipcacoal.org/ipcacoal/includes/kiwi.htm - Please see the correct > site at www.kiwibank.co.nz > > > # whois ipcacoal.org > NOTICE: Access to .ORG WHOIS information is provided to assist persons in > determining the contents of a domain name registration record in the > Public Interest Registry > registry database. The data in this record is provided by Public > Interest Registry > for informational purposes only, and Public Interest Registry does not > guarantee its > accuracy. This service is intended only for query-based access. You agree > that you will use this data only for lawful purposes and that, under no > circumstances will you use this data to: (a) allow, enable, or otherwise > support the transmission by e-mail, telephone, or facsimile of mass > unsolicited, commercial advertising or solicitations to entities other than > the data recipient's own existing customers; or (b) enable high volume, > automated, electronic processes that send queries or data to the systems of > Registry Operator or any ICANN-Accredited Registrar, except as reasonably > necessary to register domain names or modify existing registrations. All > rights reserved. Public Interest Registry reserves the right to modify > these terms at any > time. By submitting this query, you agree to abide by this policy. > > Domain ID:D155949678-LROR > Domain Name:IPCACOAL.ORG > Created On:24-Apr-2009 12:20:02 UTC > Last Updated On:02-Apr-2011 20:41:14 UTC > Expiration Date:24-Apr-2012 12:20:02 UTC > Sponsoring Registrar:eNom, Inc. (R39-LROR) > Status:CLIENT TRANSFER PROHIBITED > Registrant ID:a81fb17fb96efad6 > Registrant Name:Kallew Cesar Braganca Pavao > Registrant Organization:ipcacoal.org > Registrant Street1:Rua Carlos SCherrer, 478 > Registrant Street2: > Registrant Street3: > Registrant City:Cacoal > Registrant State/Province: > Registrant Postal Code:76962-278 > Registrant Country:BR > Registrant Phone:+55.6934418628 > Registrant Phone Ext.: > Registrant FAX:+55.6934418628 > Registrant FAX Ext.: > Registrant Email:k182_ at hotmail.com > Admin ID:a81fb17fb96efad6 > Admin Name:Kallew Cesar Braganca Pavao > Admin Organization:ipcacoal.org > Admin Street1:Rua Carlos SCherrer, 478 > Admin Street2: > Admin Street3: > Admin City:Cacoal > Admin State/Province: > Admin Postal Code:76962-278 > Admin Country:BR > Admin Phone:+55.6934418628 > Admin Phone Ext.: > Admin FAX:+55.6934418628 > Admin FAX Ext.: > Admin Email:k182_ at hotmail.com > Tech ID:a81fb17fb96efad6 > Tech Name:Kallew Cesar Braganca Pavao > Tech Organization:ipcacoal.org > Tech Street1:Rua Carlos SCherrer, 478 > Tech Street2: > Tech Street3: > Tech City:Cacoal > Tech State/Province: > Tech Postal Code:76962-278 > Tech Country:BR > Tech Phone:+55.6934418628 > Tech Phone Ext.: > Tech FAX:+55.6934418628 > Tech FAX Ext.: > Tech Email:k182_ at hotmail.com > Name Server:NS1.SERVIDORPROTEGIDO.NET > Name Server:NS2.SERVIDORPROTEGIDO.NET > Name Server: > Name Server: > Name Server: > Name Server: > Name Server: > Name Server: > Name Server: > Name Server: > Name Server: > Name Server: > Name Server: > DNSSEC:Unsigned > > > # host ipcacoal.org > ipcacoal.org has address 200.160.239.14 > ipcacoal.org mail is handled by 0 ipcacoal.org. > # whois 200.160.239.14 > > % Copyright (c) Nic.br > % The use of the data below is only permitted as described in > % full by the terms of use (http://registro.br/termo/en.html), > % being prohibited its distribution, comercialization or > % reproduction, in particular, to use it for advertising or > % any similar purpose. > % 2011-11-19 19:16:09 (BRST -02:00) > > inetnum: 200.160.239/24 > aut-num: AS8167 > abuse-c: BTA17 > owner: Gallas Software e Internet LTDA. > ownerid: 005.753.287/0001-44 > responsible: Depto. Registro de Dom?nios / ABUSE > country: BR > owner-c: HOHSI2 > tech-c: HOHSI2 > inetrev: 200.160.239/24 > nserver: ns1.homehost.com.br > nsstat: 20111116 AA > nslastaa: 20111116 > nserver: ns2.homehost.com.br > nsstat: 20111116 AA > nslastaa: 20111116 > created: 20081020 > changed: 20081020 > inetnum-up: 200.160.224/19 > > nic-hdl-br: BTA17 > person: Brasil Telecom S. A - Abuso > e-mail: abuse at noc.brasiltelecom.net.br > created: 20030624 > changed: 20050214 > > nic-hdl-br: HOHSI2 > person: HOMEHOST Hospedagem de Sites > e-mail: registro at homehost.com.br > created: 20060716 > changed: 20101014 > > % Security and mail abuse issues should also be addressed to > % cert.br, http://www.cert.br/, respectivelly to cert at cert.br > % and mail-abuse at cert.br > % > % whois.registro.br accepts only direct match queries. Types > % of queries are: domain (.br), ticket, provider, ID, CIDR > % block, IP and ASN. > -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 From piotr.1234 at interia.pl Mon Nov 21 07:24:32 2011 From: piotr.1234 at interia.pl (Piotr) Date: Mon, 21 Nov 2011 14:24:32 +0100 Subject: actual problems in networks Message-ID: <4ECA5110.3040903@interia.pl> Hello There is some working service about problems in tier's networks ? Like this: http://www.backbone-news.com/ thanks Piotr From Valdis.Kletnieks at vt.edu Mon Nov 21 07:49:29 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 21 Nov 2011 08:49:29 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: Your message of "Sun, 20 Nov 2011 21:40:08 EST." References: Message-ID: <48778.1321883369@turing-police.cc.vt.edu> On Sun, 20 Nov 2011 21:40:08 EST, Tyler Haske said: > I'm looking for a mentor who can help me focus my career so eventually I > wind up working at one of the Tier I ISPs as a senior tech. I want to > handle the big pipes that hold everyone's data. OK, so I'm not a mentor from a Tier-1, and I don't directly monkey with routers as part of $DAYJOB. But anyhow... :) With great power comes great responsibility. Be prepared for high stress levels. ;) Also, keep in mind that unless you're insanely brilliant, three things will happen before you get experienced enough to be a senior tech at a Tier 1: 1) You will have grey hair (at least some). 2) The half life of technical know-how in this industry is about 5 years. You'll have been through several half-lifes of what you'll know when you escape from college. Develop the skills needed to learn the next 3 or 4 Next Big Things quickly. 3) You'll have learned that handling a big pipe at a Tier 1 isn't all there is to running a network - and in fact, quite often the Really Cool Toys are elsewhere. Sure, they may have the fastest line cards, but they're going to tend to lag on feature sets just because you *don't* want to deploy cutting-edge code if you're a Tier-1. As an example, AS1312 deployed IPv6 over a decade before some of the Tier 1's could even *spell* it (find out why 6bone existed - it's instructive history). I'm sure that MPLS didn't make its first appearance in TIer-1 core nets either. And the list goes on.. (Hint - where did the Tier 1's get the IPv6/MPLS/whatever experienced engineers to guide their deployment? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tyler.haske at gmail.com Mon Nov 21 08:09:50 2011 From: tyler.haske at gmail.com (Tyler Haske) Date: Mon, 21 Nov 2011 09:09:50 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <48778.1321883369@turing-police.cc.vt.edu> References: <48778.1321883369@turing-police.cc.vt.edu> Message-ID: I really appreciate the specific insights offered by Keegan and Valdis. - Linking me places to apply for jobs doesn't help. I'm aware of who is considered Tier I, and how to find their website. - I'm in Kalamazoo Michigan, and I can commute up to 50 miles. I can't move until I finish my Bachelors in Computer Networking. - The job market here is bad. - I do have a home lab. (Cisco equipment) 2 3350s 2 2950s 4 2611XMs. - This isn't merely a technical request. I'd like support in this endeavor, from someone who's 'been there', to tell me things I CAN'T Google. Tyler. From bmanning at vacation.karoshi.com Mon Nov 21 08:34:36 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 21 Nov 2011 14:34:36 +0000 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> Message-ID: <20111121143436.GA16077@vacation.karoshi.com.> On Mon, Nov 21, 2011 at 09:09:50AM -0500, Tyler Haske wrote: > I really appreciate the specific insights offered by Keegan and Valdis. > > - Linking me places to apply for jobs doesn't help. I'm aware of who is > considered Tier I, and how to find their website. > > - I'm in Kalamazoo Michigan, and I can commute up to 50 miles. I can't move > until I finish my Bachelors in Computer Networking. > > - The job market here is bad. > > - I do have a home lab. (Cisco equipment) > > 2 3350s > 2 2950s > 4 2611XMs. > > - This isn't merely a technical request. I'd like support in this endeavor, > from someone who's 'been there', to tell me things I CAN'T Google. > > Tyler. Valdis evolked fond memories... (built the 6bone's first node! and was part of the baseline mesh for over a decade, when it was dismantled) wrt your home lab. you are at a disadvantage (except of course for your certifications) in that the cool toys are not yet in vendor code. consider augmenting your kit w/ OSS versions of routing code (I still like zebra) and dig into fundamentals (ISIS & BGP interaction, MPLS, esp with the still unstable OAM code - pick ITU/SG15 or IETF flavors -, consider where the market is headed... look into dynamic discovery in HIP networks, true mobility (not the mobile-IP that is current fashion))... if you are still keen, I can put you in touch w/ some good researchers doing dynamic BGP failover and over the Internet rekeying, if you want to collaberate on things. /bill From jared at puck.nether.net Mon Nov 21 09:00:06 2011 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 21 Nov 2011 10:00:06 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> Message-ID: <21126C66-6871-4634-9ED2-93C44FC3FA0F@puck.nether.net> On Nov 21, 2011, at 9:09 AM, Tyler Haske wrote: > I really appreciate the specific insights offered by Keegan and Valdis. > > - Linking me places to apply for jobs doesn't help. I'm aware of who is > considered Tier I, and how to find their website. > > - I'm in Kalamazoo Michigan, and I can commute up to 50 miles. I can't move > until I finish my Bachelors in Computer Networking. > > - The job market here is bad. > > - I do have a home lab. (Cisco equipment) > > 2 3350s > 2 2950s > 4 2611XMs. > > - This isn't merely a technical request. I'd like support in this endeavor, > from someone who's 'been there', to tell me things I CAN'T Google. The problem is that even talking about commuting to grand rapids (next biggest city compared to kz, excluding bc) there aren't a lot of local places. There is a nice set of WISPs out there on the west side that may be interesting. There's a few interesting things to think about here: 1) The core space has gotten "less interesting" in recent years IMHO. While there are still cool things to do, there's more interesting ways to think about problems. 2) A multi-talented person is more useful than someone who thinks only about networking or hosts. This also comes with its own perils as you may not fit well in places that place you inside a box. 3) are you at WMU? Any openings there in the IT/Networking group? What about KVCC, or others? There used to be a more robust local community of ISPs out there (e.g.: net-link/corecomm/voyager). You may want to consider talking to the folks at Climax Telephone as well. They were doing some interesting things last I checked. Learn about the difference between purchasing and leasing. Understand the business side of the equation, not just the technical. These skills will bear fruit when you ask for hardware. Hope this helps some. The market does change quickly (but is becoming a bit slower in some ways) so do be prepared for the business constant of change. If you are unable to adapt to change, you will be left behind. - Jared From jjanusze at wd-tek.com Mon Nov 21 09:06:48 2011 From: jjanusze at wd-tek.com (jjanusze at wd-tek.com) Date: Mon, 21 Nov 2011 10:06:48 -0500 (EST) Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> Message-ID: <862832644.508190.1321888008127.JavaMail.open-xchange@email.1and1.com Although it is outside of your current commuting distance, if you are looking to stay in Michigan, you might look into Merit in Ann Arbor, or one of the major universities.? Merit has been around since the NSFNET/MichNet days. On November 21, 2011 at 9:09 AM Tyler Haske wrote: > I really appreciate the specific insights offered by Keegan and Valdis. > > - Linking me places to apply for jobs doesn't help. I'm aware of who is > considered Tier I, and how to find their website. > > - I'm in Kalamazoo Michigan, and I can commute up to 50 miles. I can't move > until I finish my Bachelors in Computer Networking. > > - The job market here is bad. > > - I do have a home lab. (Cisco equipment) > > 2 3350s > 2 2950s > 4 2611XMs. > > - This isn't merely a technical request. I'd like support in this endeavor, > from someone who's 'been there', to tell me things I CAN'T Google. > > Tyler. From seth.mos at dds.nl Mon Nov 21 09:21:59 2011 From: seth.mos at dds.nl (Seth Mos) Date: Mon, 21 Nov 2011 16:21:59 +0100 Subject: Dynamic (changing) IPv6 prefix delegation Message-ID: <4ECA6C97.6030208@dds.nl> Hello List, As a pfSense developer I recently ran into a test system that (actually) gets a IPv6 prefix from it's ISP. (Hurrah). What is bewildering to me is that each time the system establishes a new PPPoE session to the ISP they assign a different IPv6 prefix via delegation together with a differing IPv4 address for the WAN. Is this going to be forward for other consumer ISPs in the world? One of the thoughts that came to mind is T-Online in Germany that still disconnects it's (PPPoE) user base every 24 hours for a new random IP. Short of setting really short timers on the RA messages for the LAN I can see a multitude of complications for consumers in the long run. People that configure their NAS, Media Player and Printer on their own network. And using ULA for either is not workable unless they somehow manage to grow DNS skill on the end user. Their NAS probably wants to download from the 'net and access videos from the NAS. The media player wants to be able to access youtube and the laptop needs to (reliably) find it's printer each time. I really hope that ISPs will commit to assigning the same prefix to the same user on each successive connection. Here is to hoping. Kind regards, Seth From jra at baylink.com Mon Nov 21 09:32:33 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 21 Nov 2011 10:32:33 -0500 (EST) Subject: First real-world SCADA attack in US Message-ID: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security 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 detoler at gmail.com Mon Nov 21 10:01:54 2011 From: detoler at gmail.com (Duane Toler) Date: Mon, 21 Nov 2011 11:01:54 -0500 Subject: ASA log viewer In-Reply-To: References: <4EC899E6.3060606@opus1.com> Message-ID: On Sun, Nov 20, 2011 at 17:33, Jimmy Hess wrote: > Yes. > logging permit-hostdown > > However, ?if you don't need to refuse connections when TCP syslog > fails, then you don't need 100% of your syslog messages, ? you should > use UDP syslog for performance. > > TCP just makes sure you will get all syslog messages between time A > and time B ? ? or none of them. > If there are WAN issues, ?there are many cases where one would prefer > SOME syslog messages, with an understanding that the network > bottleneck means messages are being lost, ?rather than ?few/no syslog > messages to help ?debug the issue > > -- > -JH > Except you can't do syslog via TLS with UDP. :-/ -- Duane Toler detoler at gmail.com From bjorn at mork.no Mon Nov 21 10:33:59 2011 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Mon, 21 Nov 2011 17:33:59 +0100 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <4ECA6C97.6030208@dds.nl> (Seth Mos's message of "Mon, 21 Nov 2011 16:21:59 +0100") References: <4ECA6C97.6030208@dds.nl> Message-ID: <877h2t1ll4.fsf@nemi.mork.no> Seth Mos writes: > Hello List, > > As a pfSense developer I recently ran into a test system that (actually) > gets a IPv6 prefix from it's ISP. (Hurrah). > > What is bewildering to me is that each time the system establishes a new > PPPoE session to the ISP they assign a different IPv6 prefix via > delegation together with a differing IPv4 address for the WAN. > > Is this going to be forward for other consumer ISPs in the world? I certainly hope not. But you should be prepared to handle the situation anyway. Even those ISPs providing a stable prefix may have to change it from time to time. Which means that there is always a risk that the prefix changes with a new PPPoE session, even if that doesn't happen every time. And if the prefix does change, then the old prefix will most likely not be routed out the new PPP interface even if the lease hasn't expired yet. You'll probably want to deprecate the old prefix when this happens, signalling to the hosts that they should prefer the new prefix for new sessions. Bj?rn From nick at foobar.org Mon Nov 21 10:56:44 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 21 Nov 2011 16:56:44 +0000 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <877h2t1ll4.fsf@nemi.mork.no> References: <4ECA6C97.6030208@dds.nl> <877h2t1ll4.fsf@nemi.mork.no> Message-ID: <4ECA82CC.1010106@foobar.org> On 21/11/2011 16:33, Bj?rn Mork wrote: > But you should be prepared to handle the situation anyway. s/be prepared to handle the situation/plan to handle this as default/ Nick From nicolas.strina at as30781.net Mon Nov 21 13:07:11 2011 From: nicolas.strina at as30781.net (Nicolas Strina) Date: Mon, 21 Nov 2011 20:07:11 +0100 Subject: XO Contact Message-ID: <4ECAA15F.2080903@as30781.net> Hello, Can someone from XO contact me offlist please ? Regards, From arturo.servin at gmail.com Mon Nov 21 13:17:53 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Mon, 21 Nov 2011 17:17:53 -0200 Subject: First real-world SCADA attack in US In-Reply-To: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> Message-ID: <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> I wonder if they are using private IP addresses. -as On 21 Nov 2011, at 13:32, Jay Ashworth wrote: > On an Illinois water utility: > > http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security > > 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 bhmccie at gmail.com Mon Nov 21 13:30:44 2011 From: bhmccie at gmail.com (-Hammer-) Date: Mon, 21 Nov 2011 13:30:44 -0600 Subject: First real-world SCADA attack in US In-Reply-To: <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> Message-ID: <4ECAA6E4.3030108@gmail.com> LOL. I see what you did there..... -Hammer- "I was a normal American nerd" -Jack Herer On 11/21/2011 01:17 PM, Arturo Servin wrote: > I wonder if they are using private IP addresses. > > -as > > On 21 Nov 2011, at 13:32, Jay Ashworth wrote: > > >> On an Illinois water utility: >> >> http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security >> >> 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 leigh.porter at ukbroadband.com Mon Nov 21 13:48:54 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 21 Nov 2011 19:48:54 +0000 Subject: First real-world SCADA attack in US In-Reply-To: <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com>, <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> Message-ID: <6D392E7D-1436-4422-A069-F4F82DFD1BCB@ukbroadband.com> I checked the SCADA boxes used in our "smart" building. They are all using 127.0.0.1 Is that a security risk? -- Leigh Porter On 21 Nov 2011, at 19:20, "Arturo Servin" wrote: > > I wonder if they are using private IP addresses. > > -as > > On 21 Nov 2011, at 13:32, Jay Ashworth wrote: > >> On an Illinois water utility: >> >> http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security >> >> 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 > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From paradox at nac.net Mon Nov 21 14:22:01 2011 From: paradox at nac.net (Ryan Pavely) Date: Mon, 21 Nov 2011 15:22:01 -0500 Subject: First real-world SCADA attack in US In-Reply-To: <6D392E7D-1436-4422-A069-F4F82DFD1BCB@ukbroadband.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com>, <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> <6D392E7D-1436-4422-A069-F4F82DFD1BCB@ukbroadband.com> Message-ID: <4ECAB2E9.4070503@nac.net> Might I suggest using 127.0.0.2 if you want less spam :P Pretty scary that folks have 1. Their scada gear on public networks, not behind vpns and firewalls. 2. Allow their hardware vendor to keep a list of usernames / passwords. 2b. Obviously don't change these so often. Whens the last time they really "called support" and refreshed the password with the hw vendor.... Probably when they installed the gear... Sheesh.. Perhaps the laws people suggest we need to protect ourselves should be added to. If you are the operator of a network and due to complete insanity leave yourself wide open to attack, you are just as guilty as the bad guys... But then again I don't want to goto jail for leaving my car door open and having someone steal my car, so nix that idea. Ryan Pavely Director Research And Development Net Access Corporation http://www.nac.net/ On 11/21/2011 2:48 PM, Leigh Porter wrote: > I checked the SCADA boxes used in our "smart" building. They are all using 127.0.0.1 > > Is that a security risk? > From owen at delong.com Mon Nov 21 14:27:55 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 21 Nov 2011 12:27:55 -0800 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <4ECA6C97.6030208@dds.nl> References: <4ECA6C97.6030208@dds.nl> Message-ID: <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> On Nov 21, 2011, at 7:21 AM, Seth Mos wrote: > Hello List, > > As a pfSense developer I recently ran into a test system that (actually) > gets a IPv6 prefix from it's ISP. (Hurrah). > > What is bewildering to me is that each time the system establishes a new > PPPoE session to the ISP they assign a different IPv6 prefix via > delegation together with a differing IPv4 address for the WAN. > > Is this going to be forward for other consumer ISPs in the world? > Unfortunately, there are some ISPs that believe this is the right thing to do. Some go so far as to claim that scrambling customer prefixes is a mechanism to help insure customer privacy. > One of the thoughts that came to mind is T-Online in Germany that still > disconnects it's (PPPoE) user base every 24 hours for a new random IP. > > Short of setting really short timers on the RA messages for the LAN I > can see a multitude of complications for consumers in the long run. > Yep... It remains to be seen whether they will persist in this ill-conceived behavior after the support calls start rolling in. > People that configure their NAS, Media Player and Printer on their own > network. And using ULA for either is not workable unless they somehow > manage to grow DNS skill on the end user. Their NAS probably wants to > download from the 'net and access videos from the NAS. The media player > wants to be able to access youtube and the laptop needs to (reliably) > find it's printer each time. > I suspect that mDNS/Rendezvous will become much more widespread in the IPv6 household and will become the primary service discovery mechanism. It actually works quite well and is relatively resilient to either frequent renumbering or the ill-advised use of ULA. > I really hope that ISPs will commit to assigning the same prefix to the > same user on each successive connection. > It would be nice, but, I suspect there will always be some fraction of residential ISPs determined not to do the right thing. Look at the number that are refusing to make generous prefix allocations to residential end users and limiting them to /56, /60, or even worse, /64. Owen From blakjak at blakjak.net Mon Nov 21 14:32:38 2011 From: blakjak at blakjak.net (Mark Foster) Date: Tue, 22 Nov 2011 09:32:38 +1300 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> Message-ID: <4ECAB566.5070408@blakjak.net> On 22/11/11 03:09, Tyler Haske wrote: > I really appreciate the specific insights offered by Keegan and Valdis. > > - Linking me places to apply for jobs doesn't help. I'm aware of who is > considered Tier I, and how to find their website. Don't limit yourself to Tier 1's on the outset. A lot of Network Engineers have worked at least a couple of engineering roles before landing the one that best suits them. Companies usually want to hire experience. That experience coming from as many varied places as possible, actually has some value. In my own case, aside from pure bit-pushing I have had retail sales (electronics sector), technical support, sales, pre-sales and design experience as well as the hands-on engineering of supporting infrastructure (datacentre & rack environments, electricity and environmental systems exposure, plus Layer 1-4+...) The disadvantage in angling directly to Tier 1 and working your way up within that organisation will be the potential lack of diversity in your experience. The best thing you can do (IMHO) in lieu of moving to a network-hub city for your hunt, is get your foot in the door with a company that has a significant need for input at the network level, that can help you get your start in terms of hands-on exposure to network operations and management. It'll give you some real-world perspective and it'll provide some of the experience that people will be looking for when reviewing your CV. If you have that, are visibly keen, flexible and continue to (visibly) develop your talents as an engineer, you'll never struggle for work. You can pidgeon-hole yourself pretty quickly if you narrow your skill-focus too far. Mark. PS: Accepted i'm not in the US, so YMMV, but nothing i'm saying strikes me as generically unreasonable. From jra at baylink.com Mon Nov 21 14:33:50 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 21 Nov 2011 15:33:50 -0500 (EST) Subject: First real-world SCADA attack in US In-Reply-To: <4ECAB2E9.4070503@nac.net> Message-ID: <31346344.3601.1321907630362.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ryan Pavely" > Perhaps the laws people suggest we need to protect ourselves should be > added to. If you are the operator of a network and due to complete > insanity leave yourself wide open to attack, you are just as guilty as > the bad guys... But then again I don't want to goto jail for leaving > my car door open and having someone steal my car, so nix that idea. There is a difference, there, Ryan, both in degree of danger, and in duty of care. If you leave your car open, the odds that someone will steal it *and use it to plow into a crowd of people* are pretty low; the odds that someone breaking into a SCADA network mean to cause harm to the unsuspecting public are probably a bit higher. Also, the people running that SCADA network *get paid* to do so in a fashion which does not cause undue risk to the general public be they customers of the utility or not; this is also not true of your stolen car. So I don't think there's all that much danger of "making laws to protect the public from attacked SCADA networks not secured in accordance with generally accepted best practices" being generalized into "you're going to jail if someone steals your car, even if they *do* use it as a weapon". Even as stupid and grandstander as our Congress is. 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 blakjak at blakjak.net Mon Nov 21 14:34:28 2011 From: blakjak at blakjak.net (Mark Foster) Date: Tue, 22 Nov 2011 09:34:28 +1300 Subject: First real-world SCADA attack in US In-Reply-To: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> Message-ID: <4ECAB5D4.8040507@blakjak.net> "First" https://ciip.wordpress.com/2009/06/21/a-list-of-reported-scada-incidents/ On 22/11/11 04:32, Jay Ashworth wrote: > On an Illinois water utility: > > http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security > > Cheers, > -- jra From stb at lassitu.de Mon Nov 21 14:35:37 2011 From: stb at lassitu.de (Stefan Bethke) Date: Mon, 21 Nov 2011 21:35:37 +0100 Subject: First real-world SCADA attack in US In-Reply-To: <4ECAB2E9.4070503@nac.net> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com>, <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> <6D392E7D-1436-4422-A069-F4F82DFD1BCB@ukbroadband.com> <4ECAB2E9.4070503@nac.net> Message-ID: Am 21.11.2011 um 21:22 schrieb Ryan Pavely: > But then again I don't want to goto jail for leaving my car door open and having someone steal my car, so nix that idea. Oh, but you are. (Not sure about criminal liability, but definitely civil.) -- Stefan Bethke Fon +49 151 14070811 From jra at baylink.com Mon Nov 21 14:37:31 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 21 Nov 2011 15:37:31 -0500 (EST) Subject: First real-world SCADA attack in US In-Reply-To: <4ECAB5D4.8040507@blakjak.net> Message-ID: <3483379.3605.1321907851852.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Foster" > "First" Hey; I don't write em; I just quote em. :-) > https://ciip.wordpress.com/2009/06/21/a-list-of-reported-scada-incidents/ The Willows CA is the only one in the first part of that list that was a) an actual attack, b) that actually had results c) in the US, but yeah; I was unsurprised to find out they were wrong in their characterization. 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 dr at cluenet.de Mon Nov 21 14:47:45 2011 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 21 Nov 2011 21:47:45 +0100 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> Message-ID: <20111121204745.GA29847@srv03.cluenet.de> On Mon, Nov 21, 2011 at 12:27:55PM -0800, Owen DeLong wrote: > Unfortunately, there are some ISPs that believe this is the right thing to do. > Some go so far as to claim that scrambling customer prefixes is a mechanism > to help insure customer privacy. s/ISPs/governments, privacy people and influential media outlets/ There is significant political pressure (at least over here) to continue that IPv4 habit for IPv6 as well. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From tyler.haske at gmail.com Mon Nov 21 14:50:59 2011 From: tyler.haske at gmail.com (Tyler Haske) Date: Mon, 21 Nov 2011 15:50:59 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ECAB566.5070408@blakjak.net> References: <48778.1321883369@turing-police.cc.vt.edu> <4ECAB566.5070408@blakjak.net> Message-ID: I appreciate the feedback so far. I'd love to have varied experience with a bunch of different companies, but first I'm trying to guarantee my first network engineering job out of college. Currently I'm studying for the CCNP, exam, with plans to do the CCIP also (its what I have the equipment for). Learning IPv6 is a good idea. With regards to a bigger lab I really wish I had more money to throw at equipment. (I'm aware I can emulate & virtualize up to a point) I've looked at the career sites for Western, KVCC, Davenport, CTS Telecommunication, Charter Communication and Stryker today, and nothing is posted. How aggressive should I be at trying to work at one of these places? I really don't have a solid plan for getting a job after graduation. Should I sidetrack and learn Active Directory and Exchange for instance? It would make me more marketable, but distract me from my goals. Tyler From owen at delong.com Mon Nov 21 14:59:21 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 21 Nov 2011 12:59:21 -0800 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <20111121204745.GA29847@srv03.cluenet.de> References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> <20111121204745.GA29847@srv03.cluenet.de> Message-ID: On Nov 21, 2011, at 12:47 PM, Daniel Roesen wrote: > On Mon, Nov 21, 2011 at 12:27:55PM -0800, Owen DeLong wrote: >> Unfortunately, there are some ISPs that believe this is the right thing to do. >> Some go so far as to claim that scrambling customer prefixes is a mechanism >> to help insure customer privacy. > > s/ISPs/governments, privacy people and influential media outlets/ > > There is significant political pressure (at least over here) to > continue that IPv4 habit for IPv6 as well. > Yes, IMHO, Germany has some of the most misguided privacy laws and habits in human history. In the rest of the world, it is primarily ISPs that are repeating this mantra, but, hopefully reality will eventually set in and correct the situation even in Germany. Owen From leigh.porter at ukbroadband.com Mon Nov 21 15:09:45 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Mon, 21 Nov 2011 21:09:45 +0000 Subject: First real-world SCADA attack in US In-Reply-To: <4ECAB2E9.4070503@nac.net> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com>, <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> <6D392E7D-1436-4422-A069-F4F82DFD1BCB@ukbroadband.com>, <4ECAB2E9.4070503@nac.net> Message-ID: <7F096857-0585-423A-86F4-AF4E80836497@ukbroadband.com> On 21 Nov 2011, at 20:23, "Ryan Pavely" wrote: > Might I suggest using 127.0.0.2 if you want less spam :P > > Pretty scary that folks have > 1. Their scada gear on public networks, not behind vpns and firewalls. Do people really do that? Just dump a /24 of routable space on a network and use it? Fifteen years ago perhaps, but now, really? Or are these legacy installations with Cisco routers that don't do 'ip classless' and that everybody has forgotten about? > 2. Allow their hardware vendor to keep a list of usernames / passwords. Yeah I can believe this. That's if they bothered changing the passwords at all. > 2b. Obviously don't change these so often. Whens the last time they really "called support" and refreshed the password with the hw vendor.... Probably when they installed the gear... Sheesh.. I am curious now as to what you would find port scanning for port 23 on some space owned by utility companies. Now, I'm not about to do this, but it would be interesting. Does anybody know what really happened here? We're they just using some ancient VHF radio link to an unmanned pumping station that somebody hacked with an old TCM3105 or AM2911 modem chip and a ham radio? -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From mark at amplex.net Mon Nov 21 15:30:46 2011 From: mark at amplex.net (Mark Radabaugh) Date: Mon, 21 Nov 2011 16:30:46 -0500 Subject: First real-world SCADA attack in US In-Reply-To: <7F096857-0585-423A-86F4-AF4E80836497@ukbroadband.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com>, <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> <6D392E7D-1436-4422-A069-F4F82DFD1BCB@ukbroadband.com>, <4ECAB2E9.4070503@nac.net> <7F096857-0585-423A-86F4-AF4E80836497@ukbroadband.com> Message-ID: <4ECAC306.7020202@amplex.net> On 11/21/11 4:09 PM, Leigh Porter wrote: > On 21 Nov 2011, at 20:23, "Ryan Pavely" wrote: > >> Might I suggest using 127.0.0.2 if you want less spam :P >> >> Pretty scary that folks have >> 1. Their scada gear on public networks, not behind vpns and firewalls. > Do people really do that? Just dump a /24 of routable space on a network and use it? > Fifteen years ago perhaps, but now, really? Or are these legacy installations with Cisco routers that don't do 'ip classless' and that everybody has forgotten about? > > >> 2. Allow their hardware vendor to keep a list of usernames / passwords. > Yeah I can believe this. That's if they bothered changing the passwords at all. > >> 2b. Obviously don't change these so often. Whens the last time they really "called support" and refreshed the password with the hw vendor.... Probably when they installed the gear... Sheesh.. > I am curious now as to what you would find port scanning for port 23 on some space owned by utility companies. Now, I'm not about to do this, but it would be interesting. > > Does anybody know what really happened here? We're they just using some ancient VHF radio link to an unmanned pumping station that somebody hacked with an old TCM3105 or AM2911 modem chip and a ham radio? > > > -- > Leigh > > Probably nowhere near that sophisticated. More like somebody owned the PC running Windows 98 being used as an operator interface to the control system. Then they started poking buttons on the pretty screen. Somewhere there is a terrified 12 year old. Please don't think I am saying infrastructure security should not be improved - it really does need help. But I really doubt this was anything truly interesting. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From mark at amplex.net Mon Nov 21 15:35:34 2011 From: mark at amplex.net (Mark Radabaugh) Date: Mon, 21 Nov 2011 16:35:34 -0500 Subject: First real-world SCADA attack in US In-Reply-To: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> Message-ID: <4ECAC426.9090203@amplex.net> On 11/21/11 10:32 AM, Jay Ashworth wrote: > On an Illinois water utility: > > http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security > > Cheers, > -- jra Having worked on plenty of industrial and other control systems I can safely say security on the systems is generally very poor. The vulnerabilities have existed for years but are just now getting attention. This is a problem that doesn't really need a bunch of new legislation. It's an education / resource issue. The existing methods that have been used for years with reasonable success in the IT industry can 'fix' this problem. Industrial Controls systems are normally only replaced when they are so old that parts can no longer be obtained. PC's started to be widely used as operator interfaces about the time Windows 95 came out. A lot of those Win95 boxes are still running and have been connected to the network over the years. And... if you can destroy a pump by turning it off and on too often then somebody engineered the control and drive system incorrectly. Operators (and processes) do stupid things all the time. As the control systems engineer your supposed to deal with that so that things don't go boom. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From w3yni1 at gmail.com Mon Nov 21 15:38:42 2011 From: w3yni1 at gmail.com (Charles Mills) Date: Mon, 21 Nov 2011 16:38:42 -0500 Subject: First real-world SCADA attack in US In-Reply-To: <4ECAC426.9090203@amplex.net> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> <4ECAC426.9090203@amplex.net> Message-ID: Having worked on plenty of industrial and other control systems I can safely say security on the systems is generally very poor. The vulnerabilities have existed for years but are just now getting attention. This is a problem that doesn't really need a bunch of new legislation. It's an education / resource issue. The existing methods that have been used for years with reasonable success in the IT industry can 'fix' this problem. > > Industrial Controls systems are normally only replaced when they are so > old that parts can no longer be obtained. PC's started to be widely used > as operator interfaces about the time Windows 95 came out. A lot of those > Win95 boxes are still running and have been connected to the network over > the years. > > And... if you can destroy a pump by turning it off and on too often then > somebody engineered the control and drive system incorrectly. Operators > (and processes) do stupid things all the time. As the control systems > engineer your supposed to deal with that so that things don't go boom. > > > > -- > Mark Radabaugh > Amplex > > mark at amplex.net 419.837.5015 > > =============================================== > There are still industrial control machines out there running MS-DOS. As you said not replaced until you can't get parts anymore. Chuck From mark at amplex.net Mon Nov 21 15:46:03 2011 From: mark at amplex.net (Mark Radabaugh) Date: Mon, 21 Nov 2011 16:46:03 -0500 Subject: First real-world SCADA attack in US In-Reply-To: References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> <4ECAC426.9090203@amplex.net> Message-ID: <4ECAC69B.1080305@amplex.net> On 11/21/11 4:38 PM, Charles Mills wrote: > Having worked on plenty of industrial and other control systems I can > safely say security on the systems is generally very poor. The > vulnerabilities have existed for years but are just now getting > attention. This is a problem that doesn't really need a bunch of > new legislation. It's an education / resource issue. The existing > methods that have been used for years with reasonable success in the > IT industry can 'fix' this problem. > > > Industrial Controls systems are normally only replaced when they > are so old that parts can no longer be obtained. PC's started to > be widely used as operator interfaces about the time Windows 95 > came out. A lot of those Win95 boxes are still running and have > been connected to the network over the years. > > And... if you can destroy a pump by turning it off and on too > often then somebody engineered the control and drive system > incorrectly. Operators (and processes) do stupid things all the > time. As the control systems engineer your supposed to deal with > that so that things don't go boom. > > > > -- > Mark Radabaugh > Amplex > > mark at amplex.net 419.837.5015 > > > =============================================== > > There are still industrial control machines out there running MS-DOS. > > As you said not replaced until you can't get parts anymore. > Chuck Oh yeah.... just not too many of those MS-DOS machines have TCP stacks :-) I still get calls to work on machines I designed in 1999. It's a real pain finding a computer that can run the programming software. A lot of the software was written for 386 or slower machines and used timing loops to control the RS-232 ports. Modern processors really screw that software up. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From zeusdadog at gmail.com Mon Nov 21 15:52:53 2011 From: zeusdadog at gmail.com (Jay Nakamura) Date: Mon, 21 Nov 2011 16:52:53 -0500 Subject: First real-world SCADA attack in US In-Reply-To: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, Nov 21, 2011 at 10:32 AM, Jay Ashworth wrote: > On an Illinois water utility: > > http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security > > Cheers, > -- jra I can say from experience working on one rural sewage treatment plant that IT security is not even in their consciousness. I have also seen major medical software companies that have the same admin password on all install sites and don't see a problem with it. Trying to explain the consequence of this is almost impossible. It's very very scary. From jasongurtz at npumail.com Mon Nov 21 15:51:02 2011 From: jasongurtz at npumail.com (Jason Gurtz) Date: Mon, 21 Nov 2011 16:51:02 -0500 Subject: First real-world SCADA attack in US In-Reply-To: <4ECAC426.9090203@amplex.net> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> <4ECAC426.9090203@amplex.net> Message-ID: > Having worked on plenty of industrial and other control systems I can > safely say security on the systems is generally very poor. The > vulnerabilities have existed for years but are just now getting > attention. +1 Just for context, let me tell everyone about an operational characteristic of one such system (Sold by a Fortune 10 (almost Fortune 5 ;) company for not a small amt. of $) that might be surprising; the hostname of the server system cannot be longer than eight characters. The software gets so many things so very very wrong I wonder how it is there are not more exploits! ~JasonG From morrowc.lists at gmail.com Mon Nov 21 16:02:34 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 21 Nov 2011 17:02:34 -0500 Subject: First real-world SCADA attack in US In-Reply-To: References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> <4ECAC426.9090203@amplex.net> Message-ID: On Mon, Nov 21, 2011 at 4:51 PM, Jason Gurtz wrote: >> Having worked on plenty of industrial and other control systems I can >> safely say security on the systems is generally very poor. ? The >> vulnerabilities have existed for years but are just now getting >> attention. > > +1 > > Just for context, let me tell everyone about an operational characteristic > of one such system (Sold by a Fortune 10 (almost Fortune 5 ;) company for > not a small amt. of $) that might be surprising; the hostname of the > server system cannot be longer than eight characters. > > The software gets so many things so very very wrong I wonder how it is > there are not more exploits! siemens, honeywell... essentially all of the large named folks have just horrendous security postures when it comes to any facilities/scada-type systems. they all believe that their systems are deployed on stand-alone networks, and that in the worst case there is a firewall/vpn between their 'management' site and the actually deployed system(s). You think your SCADA network is "secure", what about your management company's network? What about actual AAA for any of the changes made? Can you patch the servers/software on-demand? or must you wait for the vendor to supply you with the patch set? folks running scada systems (this includes alarm systems for buildings, or access systems! HVAC in larger complexes, etc) really, really ought to start with RFC requirements that include strong security measures, before outfitting a building you'll be in for 'years'. -chris From keegan.holley at sungard.com Mon Nov 21 16:12:42 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Mon, 21 Nov 2011 17:12:42 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <48778.1321883369@turing-police.cc.vt.edu> References: <48778.1321883369@turing-police.cc.vt.edu> Message-ID: 2011/11/21 > On Sun, 20 Nov 2011 21:40:08 EST, Tyler Haske said: > > > I'm looking for a mentor who can help me focus my career so eventually I > > wind up working at one of the Tier I ISPs as a senior tech. I want to > > handle the big pipes that hold everyone's data. > > OK, so I'm not a mentor from a Tier-1, and I don't directly monkey with > routers > as part of $DAYJOB. But anyhow... :) > > With great power comes great responsibility. Be prepared for high stress > levels. ;) > > Also, keep in mind that unless you're insanely brilliant, three things > will happen > before you get experienced enough to be a senior tech at a Tier 1: > > 1) You will have grey hair (at least some). > > Not at all required.. Although you may grow a few belt loops and maybe ruin a marriage or two trying to get there early. Also, don't forget to read, cert guides, config guides, websites, RFC's. Grey hair and wisdom aren't mutually inclusive. > 3) You'll have learned that handling a big pipe at a Tier 1 isn't all > there is > to running a network - and in fact, quite often the Really Cool Toys are > elsewhere. Sure, they may have the fastest line cards, but they're going > to > tend to lag on feature sets just because you *don't* want to deploy > cutting-edge code if you're a Tier-1. Totally agree. I touch alot of routers some of them close to what Tier-1 would use. I also have a few friends that work in large ISP's. I'd say their ultimate goal is to touch a little as possible which is usually as unglamorous as it sounds. Also, alot of things are scripted so much of what you touch may not be as fun. > As an example, AS1312 deployed IPv6 over > a decade before some of the Tier 1's could even *spell* it (find out why > 6bone > existed - it's instructive history). I'm sure that MPLS didn't make its > first > appearance in TIer-1 core nets either. And the list goes on.. (Hint - > where > did the Tier 1's get the IPv6/MPLS/whatever experienced engineers to guide > their deployment? :) > Also, how many junior and mid-level guys leave a Tier I for a network where they can touch things and then come back as experts. Also, the intermediate job tends to pay for certs and training which is a plus. From nathan at atlasnetworks.us Mon Nov 21 16:18:16 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 21 Nov 2011 22:18:16 +0000 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> > Look at the number that are refusing to make generous prefix > allocations > to residential end users and limiting them to /56, /60, or even worse, > /64. Owen, What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? Nathan From hmurray at megapathdsl.net Mon Nov 21 16:21:21 2011 From: hmurray at megapathdsl.net (Hal Murray) Date: Mon, 21 Nov 2011 14:21:21 -0800 Subject: First real-world SCADA attack in US Message-ID: <20111121222121.6B105800037@ip-64-139-1-69.sjc.megapath.net> > On an Illinois water utility: > http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security That URL says: > The Nov. 8 incident was described in a one-page report from the Illinois > Statewide Terrorism and Intelligence Center, according to Joe Weiss, a > prominent expert on protecting infrastructure from cyber attacks. Joe Weiss gave a good talk at Stanford last Oct 12. http://www.stanford.edu/class/ee380/ My quick summary: The whole SCADA industry isn't tuned into network security issues. It's not part of their culture. ---------- Several years ago, Idaho National Labs ran an experiment. They blew up a diesel generator by remote control. Aurora is the buzzword. The abstract page for his talk has a link to a CNN video. It only has a few seconds of the generator. Here is a longer version on YouTube: http://www.youtube.com/watch?v=fJyWngDco3g -- These are my opinions, not necessarily my employer's. I hate spam. From andrew.wallace at rocketmail.com Mon Nov 21 16:24:48 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Mon, 21 Nov 2011 14:24:48 -0800 (PST) Subject: First real-world SCADA attack in US In-Reply-To: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> Message-ID: <1321914288.5681.YahooMailNeo@web162102.mail.bf1.yahoo.com> If NSA had no signals information prior to the attack, this should be a wake up call for the industry. Andrew ________________________________ From: Jay Ashworth To: NANOG Sent: Monday, November 21, 2011 3:32 PM Subject: First real-world SCADA attack in US On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security 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 surfer at mauigateway.com Mon Nov 21 16:32:53 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 21 Nov 2011 14:32:53 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. Message-ID: <20111121143253.BA43DBAD@resin13.mta.everyone.net> --- tyler.haske at gmail.com wrote: From: Tyler Haske I'd love to have varied experience with a bunch of different companies, but first I'm trying to guarantee my first network engineering job out of college. ----------------------------------------------- You've already taken the first step. That step being you becoming more motivated than many of the other soon-to-be-graduates around you. This motivation will carry you a long way in your career. Who knows, you may be applying to someone here on this list one day... scott From gary.buhrmaster at gmail.com Mon Nov 21 16:39:21 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 21 Nov 2011 22:39:21 +0000 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Mon, Nov 21, 2011 at 22:18, Nathan Eisenberg wrote: >> Look at the number that are refusing to make generous prefix >> allocations >> to residential end users and limiting them to /56, /60, or even worse, >> /64. > > Owen, > > What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? Flexibility. With dhcpv6 prefix delegation, you are going to want devices to be able to request (at least) /60s for further delegation (and better yet /56s to allow them to delegate /60s with further delegation when needed). While Joe may not have as complex of an environment as his neighbor Sue, should we target the common Joe, or the advanced Sue? As I suspect Owen will say, there is no reason *not* to give out /48s (ipv6 space is huge), and this is good opportunity to enable the residential user to not have to work around artificial limits in the future. Gary From bmanning at vacation.karoshi.com Mon Nov 21 16:51:30 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 21 Nov 2011 22:51:30 +0000 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <20111121143253.BA43DBAD@resin13.mta.everyone.net> References: <20111121143253.BA43DBAD@resin13.mta.everyone.net> Message-ID: <20111121225130.GA17425@vacation.karoshi.com.> On Mon, Nov 21, 2011 at 02:32:53PM -0800, Scott Weeks wrote: > --- tyler.haske at gmail.com wrote: > From: Tyler Haske > > I'd love to have varied experience with a bunch of different companies, but > first I'm trying to guarantee my first network engineering job out of > college. > ----------------------------------------------- > > > You've already taken the first step. That step being you becoming more motivated > than many of the other soon-to-be-graduates around you. This motivation will carry > you a long way in your career. Who knows, you may be applying to someone here on ===--> replying > this list one day... line-wrapped that for you scott... gift bows are USD2.00 extra. > > scott /bill From nathan at atlasnetworks.us Mon Nov 21 17:07:42 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 21 Nov 2011 23:07:42 +0000 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B5FD097@ex-mb-1.corp.atlasnetworks.us> > > What does Joe Sixpack do at home with a /48 that he cannot do with a > /56 or a /60? > > Flexibility. With dhcpv6 prefix delegation, you are going to want > devices > to be able to request (at least) /60s for further delegation (and > better yet > /56s to allow them to delegate /60s with further delegation when > needed). > > While Joe may not have as complex of an environment as his neighbor > Sue, should we target the common Joe, or the advanced Sue? As I > suspect Owen will say, there is no reason *not* to give out /48s > (ipv6 space is huge), and this is good opportunity to enable the > residential user to not have to work around artificial limits in the > future. > > Gary Prefix delegation for what? What does Sue do at home that requires 2 levels of prefix delegation inside the house? Does Sue really need to be able to have 65536 subnets instead of 256 in her home? Nathan From owen at delong.com Mon Nov 21 17:38:08 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 21 Nov 2011 15:38:08 -0800 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> Message-ID: <35AF366E-BA8F-48BD-BDEB-D7D1B1894CCE@delong.com> Sent from my iPhone On Nov 21, 2011, at 14:18, Nathan Eisenberg wrote: >> Look at the number that are refusing to make generous prefix >> allocations >> to residential end users and limiting them to /56, /60, or even worse, >> /64. > > Owen, > > What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? > > Nathan > First, the better question is what advantage is there in building such limiting present day limitations into the future? Second, the answer is facilitate a broad range of automated hierarchical topologies allowing for both breadth and depth of prefix distribution among partitions within the home environment. I admit we have not even begun to scratch the surface of how, where, or why these topologies may evolve, but I can see that due to the tendency for software to be developed to the lowest common denominator, if we make said denominator too low, we will forever blockade the opportunities for such innovations to see the light of day. Owen From frnkblk at iname.com Mon Nov 21 20:34:02 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 21 Nov 2011 20:34:02 -0600 Subject: actual problems in networks In-Reply-To: <4ECA5110.3040903@interia.pl> References: <4ECA5110.3040903@interia.pl> Message-ID: <007001cca8bf$32696690$973c33b0$@iname.com> Yes, the outages listserv, on a good day: http://www.outages.org/index.php/Main_Page#Outages_Mailing_Lists -----Original Message----- From: Piotr [mailto:piotr.1234 at interia.pl] Sent: Monday, November 21, 2011 7:25 AM To: nanog at nanog.org Subject: actual problems in networks Hello There is some working service about problems in tier's networks ? Like this: http://www.backbone-news.com/ thanks Piotr From smb at cs.columbia.edu Mon Nov 21 20:46:19 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 21 Nov 2011 21:46:19 -0500 Subject: First real-world SCADA attack in US In-Reply-To: <4ECAC306.7020202@amplex.net> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com>, <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> <6D392E7D-1436-4422-A069-F4F82DFD1BCB@ukbroadband.com>, <4ECAB2E9.4070503@nac.net> <7F096857-0585-423A-86F4-AF4E80836497@ukbroadband.com> <4ECAC306.7020202@amplex.net> Message-ID: <33DF112F-7BD6-441B-B222-DF3B8B188DED@cs.columbia.edu> On Nov 21, 2011, at 4:30 PM, Mark Radabaugh wrote: >> >> > Probably nowhere near that sophisticated. More like somebody owned the PC running Windows 98 being used as an operator interface to the control system. Then they started poking buttons on the pretty screen. > > Somewhere there is a terrified 12 year old. > > Please don't think I am saying infrastructure security should not be improved - it really does need help. But I really doubt this was anything truly interesting. That's precisely the problem: it does appear to have been an easy attack. (My thoughts are at https://www.cs.columbia.edu/~smb/blog/2011-11/2011-11-18.html) --Steve Bellovin, https://www.cs.columbia.edu/~smb From gbonser at seven.com Mon Nov 21 21:04:19 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 22 Nov 2011 03:04:19 +0000 Subject: First real-world SCADA attack in US In-Reply-To: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C3AF48@RWC-MBX1.corp.seven.com> > Subject: First real-world SCADA attack in US > > On an Illinois water utility: > > http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security "that which does not kill us makes us stronger" --Friedrich Nietzsche From mysidia at gmail.com Mon Nov 21 21:43:47 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 21 Nov 2011 21:43:47 -0600 Subject: First real-world SCADA attack in US In-Reply-To: <4ECAC426.9090203@amplex.net> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> <4ECAC426.9090203@amplex.net> Message-ID: On Mon, Nov 21, 2011 at 3:35 PM, Mark Radabaugh wrote: > On 11/21/11 10:32 AM, Jay Ashworth wrote: > education / resource issue. ? The existing methods that have been used for > years with reasonable success in the IT industry can 'fix' this problem. The "existing normal methods" used by much of the IT industry fail way too often, and therefore, some measure of regulation is in order, when the matter is about critical public infrastructure -- it's simply not in the public interest to let agencies fail or use slipshod/ half measure techniques that are commonly practiced by some of the IT industry. They should be required to engage in practices that can be proven to mitigate risks to a know controllable quantity. The weakness of typical IT security is probably OK, when the only danger of compromise is that an intruder might get some sensitive information, or IT might need to go to the tapes. That just won't do, when the result of compromise is, industrial equipment is forced outside of safe parameters, resulting in deaths, or a city's water supply is shut down, resulting in deaths. Hard perimeter and mushy interior with OS updates just to address known issues, and malware scanners to "try and catch" things just won't do. ..."an OS patch introduces a serious crash bug" is also a type of security issue. Patching doesn't necessarily improve security; it only helps with issues you know about, and might introduce issues you don't know about. Enumerating badness is simply not reliable, and patch patch patch is simply an example of that -- when security really matters, don't attach it to a network, especially not one that might eventually be internet connected -- indirect or not. Connection to a management LAN that has any PC on it that is or was ever internet connected "counts" as an internet connection. > Industrial Controls systems are normally only replaced when they are so old > that parts can no longer be obtained. ? PC's started to be widely used as > operator interfaces about the time Windows 95 came out. ? A lot of those > Win95 boxes are still running and have been connected to the network over > the years. The "Windows 95" part is fine. The "connected to the network" part is not fine. -- -JH From jra at baylink.com Mon Nov 21 22:16:14 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 21 Nov 2011 23:16:14 -0500 (EST) Subject: First real-world SCADA attack in US In-Reply-To: Message-ID: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > On Mon, Nov 21, 2011 at 3:35 PM, Mark Radabaugh > wrote: > > On 11/21/11 10:32 AM, Jay Ashworth wrote: > > education / resource issue. The existing methods that have been used for > > years with reasonable success in the IT industry can 'fix' this > > problem. Careful with the attribution; you're quoting Mark, not me. > The weakness of typical IT security is probably OK, when the only danger of compromise > is that an intruder might get some sensitive information, or IT might need to go to the tapes. > > That just won't do, when the result of compromise is, industrial equipment > is forced outside > of safe parameters, resulting in deaths, or a city's water supply is shut down, > resulting in deaths. (72 character hard wrap... please.) > Hard perimeter and mushy interior with OS updates just to address > known issues, and malware scanners to "try and catch" things just won't do. Precisely. THe case in point example these days is traffic light controllers. I know from traffic light controllers; when I was a kid, that was my dad's beat for the City of Boston. Being a geeky kid, I drilled the guys in the signal shop, the few times I got to go there (Saturdays, and such). The old design for traffic signal controllers was that the relays that drove each signal/group were electrically interlocked: the relay that made N/S able to engage it's greens *got its power from* the relay that made E/W red; if there wasn't a red there, you *couldn't* make the other direction green. These days, I'm not sure that's still true: I can *see* the signal change propagate across a row of 5 LED signals from one end to the other. Since I don't think the speed of electricity is slow enough to do that (it's probably on the order of 5ms light to light), I have to assume that it's processor delay as the processor runs a display list to turn on output transistors that drive the LED light heads. That implies to me that it is *physically* possible to get opposing greens (which we refer to, in technical terms as "traffic fatalities") out of the controller box... in exactly the same way that it didn't used to be. That's unsettling enough that I'm going to go hunt down a signal mechanic and ask. 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 pelzi at pelzi.net Mon Nov 21 23:11:43 2011 From: pelzi at pelzi.net (Jussi Peltola) Date: Tue, 22 Nov 2011 07:11:43 +0200 Subject: First real-world SCADA attack in US In-Reply-To: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> Message-ID: <20111122051142.GJ21062@pokute.pelzi.net> On Mon, Nov 21, 2011 at 11:16:14PM -0500, Jay Ashworth wrote: > That implies to me that it is *physically* possible to get opposing greens > (which we refer to, in technical terms as "traffic fatalities") out of the > controller box... in exactly the same way that it didn't used to be. Not necessarily. Microwave ovens have an interlock system that has 3 sequentially timed microswitches. The first two cut power to the oven, and the third one shorts out the power supply in case the previous two failed, blowing a fuse. The switches are operated by 2 "fingers" placed on the door so that if the door is bent enough to not seal properly, the switches will be activated in the wrong order causing the shorting switch to operate. This can also happen if you slam the door closed too hard. This is all nice in theory, in practice the microswitches are so flimsy nowadays that I'd not be too surprised if the shorting switch did not succeed in blowing a fuse - and the other two will easily weld together even in normal use (I have seen this happen. Swap the switches and fuse and the oven works again.) The traffic lights can also have some kind of fault-detection logic that sees they are in an illegal state and latches them into a fault mode. IMHO this is stupid extra complexity when relays are obviously 100% correct and reliable for this function, but it seems to be all the rage nowadays to use some kind of "proven correct" software system for safety critical logic. It is so much sexier than mechanical or electro-mechanical interlocks. Anybody who has seen what kind of bizarre malfunctions failed electrolytics cause in consumer electronics will probably not feel very comfortable trusting traffic lights whose safety relies on software that is proven correct. OTOH, the risk is astronomically small compared to someone just running the red lights. Jussi Peltola From furry13 at gmail.com Mon Nov 21 23:24:59 2011 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 22 Nov 2011 16:24:59 +1100 Subject: First real-world SCADA attack in US In-Reply-To: <4ECAC426.9090203@amplex.net> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> <4ECAC426.9090203@amplex.net> Message-ID: On Tue, Nov 22, 2011 at 8:35 AM, Mark Radabaugh wrote: > Having worked on plenty of industrial and other control systems I can safely > say security on the systems is generally very poor. ? The vulnerabilities > have existed for years but are just now getting attention. ? ?This is a > problem that doesn't really need a bunch of new legislation. ? It's an > education / resource issue. ? The existing methods that have been used for > years with reasonable success in the IT industry can 'fix' this problem. I agree, it is mostly education and resources issue . But the environment of control networks is slightly different from IT industry, IMHO. 1) control network people have been living in a kind of isolation for too long and haven't realized that their networks are connected to Big Bad Internet (or at least intranet..) now so the threat model has changed completely. 2) There aren't many published cases of successful (or even unsuccessful) attacks on control networks. As a result, the risk of an attack is considered to have large potential loss and but *very* low probability of occurring and high cost of countermeasures => ignoring.. 3) Interconnections between control networks and "normal" LANs are a kind of grey area (especially taking into account that both types of networks are run by different teams of engineers). It is very hard to get any technical/security requirements etc - usually none of them exist. And as the whole system as as secure as the weakest element.... the result is easily predictable. 4) any changes in control network are to be done in much more conservative way. all those "apply the patch..oh, damn, it crashed..rollback' doesn't work there. In addition (from my experience which might not be statistically reliable) the testing/lab resources are usually much more limited for control networks; 5) as the life cycle of hw&sw is much longer than in IT industry, it is very hard to meet the security requirements w/o significant changes to existing control network (inc. procedures/policies) - but see #4 above.. So there is a gap - those control networks are 10 (20?) years behind internet in terms of security. This gap can be filled but not immediately. The good news that such stories as the one we are discussing could help scary the decision makers..oops, sorry, I was going to say 'raise the level of security awareness' -- SY, Jen Linkova aka Furry From Valdis.Kletnieks at vt.edu Mon Nov 21 23:27:48 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 22 Nov 2011 00:27:48 -0500 Subject: First real-world SCADA attack in US In-Reply-To: Your message of "Tue, 22 Nov 2011 07:11:43 +0200." <20111122051142.GJ21062@pokute.pelzi.net> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122051142.GJ21062@pokute.pelzi.net> Message-ID: <17626.1321939668@turing-police.cc.vt.edu> On Tue, 22 Nov 2011 07:11:43 +0200, Jussi Peltola said: > Anybody who has seen what kind of bizarre malfunctions failed > electrolytics cause in consumer electronics will probably not feel very > comfortable trusting traffic lights whose safety relies on software that > is proven correct. Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bjorn at mork.no Tue Nov 22 03:50:50 2011 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 22 Nov 2011 10:50:50 +0100 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> (Nathan Eisenberg's message of "Mon, 21 Nov 2011 22:18:16 +0000") References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> Message-ID: <8762iczds5.fsf@nemi.mork.no> Nathan Eisenberg writes: > What does Joe Sixpack do at home with a /48 that he cannot do with a > /56 or a /60? What does Joe's ISPack save the missing bits for? Bj?rn From a.harrowell at gmail.com Tue Nov 22 04:33:07 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Tue, 22 Nov 2011 10:33:07 +0000 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> Message-ID: <201111221033.23880.a.harrowell@gmail.com> On Monday 21 Nov 2011 20:27:55 Owen DeLong wrote: > I suspect that mDNS/Rendezvous will become much more widespread in > the IPv6 household and will become the primary service discovery > mechanism. It actually works quite well and is relatively resilient to > either frequent renumbering or the ill-advised use of ULA. A while ago there was some discussion of "wouldn't mDNS/Rendezvous/Bonjour that doesn't suck be nice?" on the list. I for one agree with Owen that it's important for a whole lot of things and will get more so in trying to deliver the promises of IPv6. (If you want "network everywhere" you probably need "zero-configuration everywhere", and the network that's everywhere is IP.) I also think it's an underestimated contribution to the success of Apple in the iDevice era, much as network people tend to hate it. So perhaps we could identify what it is about mDNS service discovery that we hate and what could be improved. -- 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 david at davidswafford.com Tue Nov 22 05:52:29 2011 From: david at davidswafford.com (David Swafford) Date: Tue, 22 Nov 2011 06:52:29 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <20111121143253.BA43DBAD@resin13.mta.everyone.net> References: <20111121143253.BA43DBAD@resin13.mta.everyone.net> Message-ID: Scott's point is very true! Motivation will help you go very far, much farther than certs/knowledge alone. As a soon to be college-grad, be ready for the initial disappointment, :-), even though you'll have your CCNP, you have no real experience, so you'll start at the entry level. That's not a bad thing, but you might see it as such. The reason it is good, is that while at the entry level (networking that is, I'm not talking about a helpdesk), you'll get to touch and interact with a lot of different things with very little "total" responsibility. As you impress your peers, this will trickle up towards management, and eventually work it's way out into better tasks and larger responsibilities (try to not get caught up in "the title"). I'm speaking from experience here, I'm a senior network engineer for a $2 B company, yet only 25 years old, currently working on my R/S CCIE purely for the learning experience. It took me nearly 4 years to move from an associate to a senior in my company, which is not common in that short of a time-frame for my employer, but that's where the motivation piece comes in -- expressing true passion, and learning things because "they are cool/interest you" will take you far. Learning on paper is what you're taught in college and it only works so far, but learning from hand-on, like the lab you've got built, is where you attain the knowledge/troubleshooting/experience that will help you succeed. A comment earlier in the thread mentioned "should I learn active directory/exchange"? I hear this a lot from our fellow associate's on the team.... and to be honest, if you are learning something just to add it to your resume, that will be a waste of your time. But, if you are learning it because you find it interesting or just want to explore, then by all means go deep into it. I personally go by the motto "go full in or don't go at all". So if I'm going to learn something, I'll get as deep as I can into it, and focus on just it for a little while, then I'll move to something else, and focus on just that. If you try to focus on too many separate things, you'll become this odd ball of knowledge that can't really hold you own -- a tip in the industry that will get you far: be able to take ownership, and fully run/own what you're working on. Regardless of level/title/role, a person who takes initive (within the scope/dynamic of their position), will go far. Best of luck to you, David. On Mon, Nov 21, 2011 at 5:32 PM, Scott Weeks wrote: > > > --- tyler.haske at gmail.com wrote: > From: Tyler Haske > > I'd love to have varied experience with a bunch of different companies, but > first I'm trying to guarantee my first network engineering job out of > college. > ----------------------------------------------- > > > You've already taken the first step. ?That step being you becoming more motivated than many of the other soon-to-be-graduates around you. ?This motivation will carry you a long way in your career. ?Who knows, you may be applying to someone here on this list one day... > > scott > > From Valdis.Kletnieks at vt.edu Tue Nov 22 06:19:18 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 22 Nov 2011 07:19:18 -0500 Subject: First real-world SCADA attack in US In-Reply-To: Your message of "Mon, 21 Nov 2011 14:24:48 PST." <1321914288.5681.YahooMailNeo@web162102.mail.bf1.yahoo.com> References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com> <1321914288.5681.YahooMailNeo@web162102.mail.bf1.yahoo.com> Message-ID: <29363.1321964358@turing-police.cc.vt.edu> On Mon, 21 Nov 2011 14:24:48 PST, "andrew.wallace" said: > If NSA had no signals information prior to the attack, this should be a wake up call for the industry. Actually, it should be a wake up call whether or not NSA had signals information. However, it's pretty obvious that the entire SCADA segment is pretty much bound and determined to keep hitting the snooze button as long as possible - they've known they have an endemic security problem just about the same number of years the telecom segment has known they will need to deploy IPv6. ;) And let's think about this for a moment - given that there's *no* indication that the attack was an organized effort from a known group, and could quite possibly be just a bored 12 year old in Toledo Ohio, why should the NSA have any signals info before the attack? Let's think it through a bit more. Even if the NSA *did* have info beforehand that pointed at a kid in Toledo, they can't easily release that info before the fact, for several reasons: (a) they're not supposed to be surveillancing US citizens, so having intel on a kid in Toledo would be embarassing at the least, and (b) revealing they have the intel would almost certainly leak out the details of where, when, and how they got said info - and the NSA would almost certainly be willing to sacrifice somebody else's water pump rather than reveal how they got the info. Bottom line - the fact the NSA didn't say something beforehand means that they either didn't know, or didn't wish to tell. So why are you bringing the NSA into it? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rbf+nanog at panix.com Tue Nov 22 07:59:56 2011 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Tue, 22 Nov 2011 07:59:56 -0600 Subject: First real-world SCADA attack in US In-Reply-To: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> Message-ID: <20111122135956.GA21368@panix.com> On Mon, Nov 21, 2011 at 11:16:14PM -0500, Jay Ashworth wrote: > > Precisely. THe case in point example these days is traffic light > controllers. > > I know from traffic light controllers; when I was a kid, that was my dad's > beat for the City of Boston. Being a geeky kid, I drilled the guys in the > signal shop, the few times I got to go there (Saturdays, and such). > > The old design for traffic signal controllers was that the relays that drove > each signal/group were electrically interlocked: the relay that made N/S able > to engage it's greens *got its power from* the relay that made E/W red; if there > wasn't a red there, you *couldn't* make the other direction green. > > These days, I'm not sure that's still true: I can *see* the signal > change propagate across a row of 5 LED signals from one end to the > other. Since I don't think the speed of electricity is slow enough > to do that (it's probably on the order of 5ms light to light), I have > to assume that it's processor delay as the processor runs a display > list to turn on output transistors that drive the LED light heads. > > That implies to me that it is *physically* possible to get opposing greens > (which we refer to, in technical terms as "traffic fatalities") out of the > controller box... in exactly the same way that it didn't used to be. > > That's unsettling enough that I'm going to go hunt down a signal mechanic > and ask. The typical implementation in a modern controller is to have a separate conflict monitor unit that will detect when conflicting greens (for example) are displayed, and trigger a (also separate) flasher unit that will cause the signal to display a flashing red in all directions (sometimes flashing yellow for one higher volume route). So the controller would output conflicting greens if it failed or was misprogrammed, but the conflict monitor would detect that and restore the signal to a safe (albeit flashing, rather than normal operation) state. -- Brett From rps at maine.edu Tue Nov 22 09:05:22 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 22 Nov 2011 10:05:22 -0500 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <4ECA6C97.6030208@dds.nl> References: <4ECA6C97.6030208@dds.nl> Message-ID: On Mon, Nov 21, 2011 at 10:21 AM, Seth Mos wrote: > What is bewildering to me is that each time the system establishes a new > PPPoE session to the ISP they assign a different IPv6 prefix via > delegation together with a differing IPv4 address for the WAN. > Is this going to be forward for other consumer ISPs in the world? As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. I often hear "if you need a static IP, you need business class server"; bundled with "we don't provide business service to residential customers". Almost makes one think there ought to be some consumer protection laws regulating it. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From jra at baylink.com Tue Nov 22 09:16:56 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 22 Nov 2011 10:16:56 -0500 (EST) Subject: First real-world SCADA attack in US In-Reply-To: <20111122135956.GA21368@panix.com> Message-ID: <20364217.3717.1321975016306.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brett Frankenberger" > The typical implementation in a modern controller is to have a separate > conflict monitor unit that will detect when conflicting greens (for > example) are displayed, and trigger a (also separate) flasher unit that > will cause the signal to display a flashing red in all directions > (sometimes flashing yellow for one higher volume route). > > So the controller would output conflicting greens if it failed or was > misprogrammed, but the conflict monitor would detect that and restore > the signal to a safe (albeit flashing, rather than normal operation) > state. "... assuming the *conflict monitor* hasn't itself failed." There, FTFY. Moron designers. 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 Tue Nov 22 09:30:30 2011 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Tue, 22 Nov 2011 09:30:30 -0600 Subject: First real-world SCADA attack in US In-Reply-To: <20364217.3717.1321975016306.JavaMail.root@benjamin.baylink.com> References: <20111122135956.GA21368@panix.com> <20364217.3717.1321975016306.JavaMail.root@benjamin.baylink.com> Message-ID: <20111122153030.GA7645@panix.com> On Tue, Nov 22, 2011 at 10:16:56AM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Brett Frankenberger" > > > The typical implementation in a modern controller is to have a separate > > conflict monitor unit that will detect when conflicting greens (for > > example) are displayed, and trigger a (also separate) flasher unit that > > will cause the signal to display a flashing red in all directions > > (sometimes flashing yellow for one higher volume route). > > > > So the controller would output conflicting greens if it failed or was > > misprogrammed, but the conflict monitor would detect that and restore > > the signal to a safe (albeit flashing, rather than normal operation) > > state. > > "... assuming the *conflict monitor* hasn't itself failed." > > There, FTFY. > > Moron designers. Yes, but then you're two failures deep -- you need a controller failure, in a manner that creates an unsafe condition, followed by a failure of the conflict monitor. Lots of systems are vulnerable to multiple failure conditions. Relays can have interesting failure modes also. You can only protect for so many failures deep. -- Brett From jmaslak at antelope.net Tue Nov 22 09:38:33 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 22 Nov 2011 08:38:33 -0700 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: References: <4ECA6C97.6030208@dds.nl> Message-ID: <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> On Nov 22, 2011, at 8:05 AM, Ray Soucy wrote: > As long as a static allocation can be billed as a premium service, > most providers will unfortunately do it. Exactly. ISPs are in business to make as much money as they can - go figure. For myself, having a static IP is the least of my concerns - even on my inside network. Everything I have (printers, media boxes, etc) does some sort of lookup protocol so I have no problem connecting (and thus they get assigned dynamic addresses by my router). I'm personally much more concerned about other things: 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). 3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). 4) What would happen if someone wrote a popular app that used IP options? I don't want to know that answer even though I already know it. "Break the internet" is about how I'd phrase it. 5) I have a server in a datacenter that provides IPv6. They even assign me a /48. They assigned the /48 to my subnet. I guess they thought I'd run out of addresses in a /64 and heard that you are supposed to assign /48's. The only problem is that a subnet /48 means I can't route /64s elsewhere, nor does autoconfiguration work (maybe that is a feature?). 6) The same server can't receive IP fragments, except for the first one. For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6 will cause longer answers). Yes, I know I can turn off large UDP responses on my resolver. I bet more than a few people don't know that though. 7) Even UDP and TCP aren't going to work everywhere. Hense why everything seems to tunnel over HTTP or HTTPS even when that's an inappropriate method (such as when reliable ordered packet delivery is a hinderence). 8) Don't use the "wrong" ToS on your packets. It'll be eaten by some random provider. So if you use any ToS internally, you need a middlebox to unset your ToS bits. I'd gladly give up a static IP address just to have an internet that delivered my packets from my home or server to the remote destination. From deric.kwok2000 at gmail.com Tue Nov 22 09:38:40 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Tue, 22 Nov 2011 10:38:40 -0500 Subject: Any recommended router. They are reliable and have good support. Message-ID: Hi Can I know any selection of Linux routers except cisco / juniper? They are reliable and have good support provided We would like to get one for testing. Thank you From galu at packetdam.com Tue Nov 22 09:41:20 2011 From: galu at packetdam.com (Vlad Galu) Date: Tue, 22 Nov 2011 15:41:20 +0000 Subject: Lossy compression HTTP proxy Message-ID: <7BD6551D-A812-4298-929F-9C4B9F4B9D2F@packetdam.com> Hello, I am looking for a proprietary $subj, a la ziproxy [1]. Caching is not the main concern (well, I wouldn't mind it caching compressed JPEGs). Mobile telco people should probably know a few vendors. Thanks! [1] http://ziproxy.sourceforge.net -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com From leigh.porter at ukbroadband.com Tue Nov 22 09:43:33 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 22 Nov 2011 15:43:33 +0000 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: References: Message-ID: Brocade have some reasonable boxes. -- Leigh Porter On 22 Nov 2011, at 15:40, "Deric Kwok" wrote: > Hi > > Can I know any selection of Linux routers except cisco / juniper? > > They are reliable and have good support provided > > We would like to get one for testing. > > Thank you > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From lorddoskias at gmail.com Tue Nov 22 09:43:10 2011 From: lorddoskias at gmail.com (lorddoskias) Date: Tue, 22 Nov 2011 15:43:10 +0000 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: References: Message-ID: <4ECBC30E.4080008@gmail.com> On 11/22/2011 3:38 PM, Deric Kwok wrote: > Hi > > Can I know any selection of Linux routers except cisco / juniper? > > They are reliable and have good support provided > > We would like to get one for testing. > > Thank you > > http://www.vyatta.com/ might be worth checking. From tetherow at shwisp.net Tue Nov 22 09:45:30 2011 From: tetherow at shwisp.net (Sam Tetherow) Date: Tue, 22 Nov 2011 09:45:30 -0600 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: References: Message-ID: <4ECBC39A.3000407@shwisp.net> http://imagestream.com On 11/22/11 9:38 AM, Deric Kwok wrote: > Hi > > Can I know any selection of Linux routers except cisco / juniper? > > They are reliable and have good support provided > > We would like to get one for testing. > > Thank you > From faisal at snappydsl.net Tue Nov 22 09:55:47 2011 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 22 Nov 2011 10:55:47 -0500 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: References: Message-ID: <4ECBC603.1060609@snappydsl.net> mikrotik family .. you can have all sizes and shapes of routers .. lots of support available online or from independent consultants. Regards. Faisal Imtiaz Snappy Internet& Telecom On 11/22/2011 10:38 AM, Deric Kwok wrote: > Hi > > Can I know any selection of Linux routers except cisco / juniper? > > They are reliable and have good support provided > > We would like to get one for testing. > > Thank you > > From mohacsi at niif.hu Tue Nov 22 09:55:57 2011 From: mohacsi at niif.hu (Janos Mohacsi) Date: Tue, 22 Nov 2011 16:55:57 +0100 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <4ECA6C97.6030208@dds.nl> References: <4ECA6C97.6030208@dds.nl> Message-ID: <4ECBC60D.7060006@niif.hu> Hello, On 11/21/11 16:21, Seth Mos wrote: > Hello List, > > As a pfSense developer I recently ran into a test system that (actually) > gets a IPv6 prefix from it's ISP. (Hurrah). > > What is bewildering to me is that each time the system establishes a new > PPPoE session to the ISP they assign a different IPv6 prefix via > delegation together with a differing IPv4 address for the WAN. > > Is this going to be forward for other consumer ISPs in the world? I think it should be to option for the end users. Select if they want stable IPv6 prefix or random IPv6 prefix. > One of the thoughts that came to mind is T-Online in Germany that still > disconnects it's (PPPoE) user base every 24 hours for a new random IP. This is "kind of solution" for preserving IPv4 addresses. Side effect of the changing IP address is that user can be tracked back if ISP is logging the actual IP binding. > Short of setting really short timers on the RA messages for the LAN I > can see a multitude of complications for consumers in the long run. > > People that configure their NAS, Media Player and Printer on their own > network. And using ULA for either is not workable unless they somehow > manage to grow DNS skill on the end user. Their NAS probably wants to > download from the 'net and access videos from the NAS. The media player > wants to be able to access youtube and the laptop needs to (reliably) > find it's printer each time. > > I really hope that ISPs will commit to assigning the same prefix to the > same user on each successive connection. Agree. Kind Regards, Janos Mohacsi From leigh.porter at ukbroadband.com Tue Nov 22 10:02:11 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 22 Nov 2011 16:02:11 +0000 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: <4ECBC603.1060609@snappydsl.net> References: , <4ECBC603.1060609@snappydsl.net> Message-ID: <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? -- Leigh On 22 Nov 2011, at 15:57, "Faisal Imtiaz" wrote: > mikrotik family .. you can have all sizes and shapes of routers .. > lots of support available online or from independent consultants. > > Regards. > > Faisal Imtiaz > Snappy Internet& Telecom > > > On 11/22/2011 10:38 AM, Deric Kwok wrote: >> Hi >> >> Can I know any selection of Linux routers except cisco / juniper? >> >> They are reliable and have good support provided >> >> We would like to get one for testing. >> >> Thank you >> >> > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From tayeb.meftah at gmail.com Mon Nov 21 08:24:24 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Mon, 21 Nov 2011 16:24:24 +0200 Subject: Any recommended router. They are reliable and have good support. References: Message-ID: <1F342086A5E3480BB1D82DF3577A66C9@work> +1 MikroTik http://www.mikrotik.com ----- Original Message ----- From: "Deric Kwok" To: "nanog list" Sent: Tuesday, November 22, 2011 5:38 PM Subject: Any recommended router. They are reliable and have good support. > Hi > > Can I know any selection of Linux routers except cisco / juniper? > > They are reliable and have good support provided > > We would like to get one for testing. > > Thank you > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6651 (20111122) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (20111122) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From tayeb.meftah at gmail.com Mon Nov 21 08:26:28 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Mon, 21 Nov 2011 16:26:28 +0200 Subject: Any recommended router. They are reliable and have good support. References: , <4ECBC603.1060609@snappydsl.net> <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> Message-ID: Leigh, MT is very responcive wonderfull fast bug fixs and very organised RouterOs releases i use it a lot and have a hell load of features support all major routing protocols BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much more. thank you ----- Original Message ----- From: "Leigh Porter" To: Cc: "nanog list" Sent: Tuesday, November 22, 2011 6:02 PM Subject: Re: Any recommended router. They are reliable and have good support. Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? -- Leigh On 22 Nov 2011, at 15:57, "Faisal Imtiaz" wrote: > mikrotik family .. you can have all sizes and shapes of routers .. > lots of support available online or from independent consultants. > > Regards. > > Faisal Imtiaz > Snappy Internet& Telecom > > > On 11/22/2011 10:38 AM, Deric Kwok wrote: >> Hi >> >> Can I know any selection of Linux routers except cisco / juniper? >> >> They are reliable and have good support provided >> >> We would like to get one for testing. >> >> Thank you >> >> > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ __________ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (20111122) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (20111122) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From leigh.porter at ukbroadband.com Tue Nov 22 10:09:05 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 22 Nov 2011 16:09:05 +0000 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: References: , <4ECBC603.1060609@snappydsl.net> <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com>, Message-ID: I have used quite a few of their devices and have been impressed. The bang for your buck is unlike anything else. I sometimes wonder why I bother buying other kit, apart from the larger boxes. Maybe I'll find a bug and test them out ;-) -- Leigh On 22 Nov 2011, at 16:04, "Meftah Tayeb" wrote: > Leigh, > MT is very responcive > wonderfull > fast bug fixs and very organised RouterOs releases > i use it a lot and have a hell load of features > support all major routing protocols BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much more. > thank you > > ----- Original Message ----- From: "Leigh Porter" > To: > Cc: "nanog list" > Sent: Tuesday, November 22, 2011 6:02 PM > Subject: Re: Any recommended router. They are reliable and have good support. > > > Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? > > -- > Leigh > > > On 22 Nov 2011, at 15:57, "Faisal Imtiaz" wrote: > >> mikrotik family .. you can have all sizes and shapes of routers .. >> lots of support available online or from independent consultants. >> >> Regards. >> >> Faisal Imtiaz >> Snappy Internet& Telecom >> >> >> On 11/22/2011 10:38 AM, Deric Kwok wrote: >>> Hi >>> >>> Can I know any selection of Linux routers except cisco / juniper? >>> >>> They are reliable and have good support provided >>> >>> We would like to get one for testing. >>> >>> Thank you >>> >>> >> >> >> ______________________________________________________________________ >> This email has been scanned by the Symantec Email Security.cloud service. >> For more information please visit http://www.symanteccloud.com >> ______________________________________________________________________ > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (20111122) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6651 (20111122) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From owen at delong.com Tue Nov 22 10:07:49 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Nov 2011 08:07:49 -0800 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: References: <4ECA6C97.6030208@dds.nl> Message-ID: <67A2C143-76CD-44E7-9CEB-E4FC9911E58C@delong.com> Worst case, you can always get an IPv6 static /48 from at least one provider without any additional cost. Owen On Nov 22, 2011, at 7:05 AM, Ray Soucy wrote: > On Mon, Nov 21, 2011 at 10:21 AM, Seth Mos wrote: > >> What is bewildering to me is that each time the system establishes a new >> PPPoE session to the ISP they assign a different IPv6 prefix via >> delegation together with a differing IPv4 address for the WAN. > >> Is this going to be forward for other consumer ISPs in the world? > > As long as a static allocation can be billed as a premium service, > most providers will unfortunately do it. > > I often hear "if you need a static IP, you need business class > server"; bundled with "we don't provide business service to > residential customers". > > Almost makes one think there ought to be some consumer protection laws > regulating it. > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ From arturo.servin at gmail.com Tue Nov 22 10:16:02 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Tue, 22 Nov 2011 14:16:02 -0200 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> References: <4ECA6C97.6030208@dds.nl> <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> Message-ID: On 22 Nov 2011, at 13:38, Joel Maslak wrote: > 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. > > 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). Add to your list: 1.5) Instead of getting IPv6, getting private IPv4 and CGN service. -as From jra at baylink.com Tue Nov 22 10:16:54 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 22 Nov 2011 11:16:54 -0500 (EST) Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: Message-ID: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > As in all cases, additional flexibility results in additional ability > to make mistakes. Simple mechanical lockouts do not scale to the > modern world. The benefits of these additional capabilities far > outweigh the perceived risks of programming errors. The perceived risk in this case is "multiple high-speed traffic fatalities". I believe we rank that pretty high; it's entirely possible that a traffic light controller is the most potentially dangerous artifact (in terms of number of possible deaths) that the average citizen interacts with on a daily basis. -- 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 Tue Nov 22 10:19:25 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Nov 2011 08:19:25 -0800 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> References: <4ECA6C97.6030208@dds.nl> <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> Message-ID: <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: > On Nov 22, 2011, at 8:05 AM, Ray Soucy wrote: > >> As long as a static allocation can be billed as a premium service, >> most providers will unfortunately do it. > > Exactly. ISPs are in business to make as much money as they can - go figure. > How do you make more money by refusing to meet customer requests? I could understand how it MIGHT make more money to force customers that want static to purchase business class, but, if you then refuse to offer them business class service, that doesn't sound like more money, it just sounds like angry customers. > For myself, having a static IP is the least of my concerns - even on my inside network. Everything I have (printers, media boxes, etc) does some sort of lookup protocol so I have no problem connecting (and thus they get assigned dynamic addresses by my router). > I like being able to reach things in my house when I'm on the road. Having the prefix not bounce around turns out to be convenient for that. > I'm personally much more concerned about other things: > > 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. > That's beyond tragic if it's actually true. You should name and shame your provider if that's really the case. > 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). > I haven't run into too many of these in the real world any more other than actual tiered services where you have the option of buying a higher bandwidth service. What I mostly see these days is hard-limits on negotiated speed of the connection. > 3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). This hasn't been my experience unless you're behind some form of NAT. Yes, it is well known that NAT breaks most protocols. > > 4) What would happen if someone wrote a popular app that used IP options? I don't want to know that answer even though I already know it. "Break the internet" is about how I'd phrase it. The app would never become popular because most people would be unable to use it. It wouldn't break the internet. The internet would break the app. in its current state. Whether either of those possibilities is good or bad is left as an exercise for the reader. > > 5) I have a server in a datacenter that provides IPv6. They even assign me a /48. They assigned the /48 to my subnet. I guess they thought I'd run out of addresses in a /64 and heard that you are supposed to assign /48's. The only problem is that a subnet /48 means I can't route /64s elsewhere, nor does autoconfiguration work (maybe that is a feature?). Mostly it means that your provider sort of gets IPv6, but, not really. If you want to provide me with contact information off-list, I'll attempt to engage in an educational outreach. > > 6) The same server can't receive IP fragments, except for the first one. For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6 will cause longer answers). Yes, I know I can turn off large UDP responses on my resolver. I bet more than a few people don't know that though. Yes, sounds like your provider needs to be hit with a clue-by-four. I don't think that typifies the rest of the world, though it's not as uncommon as I would like, either. > > 7) Even UDP and TCP aren't going to work everywhere. Hense why everything seems to tunnel over HTTP or HTTPS even when that's an inappropriate method (such as when reliable ordered packet delivery is a hinderence). Yes, this is an increasingly common problem. Thanks, Micr0$0ft. > > 8) Don't use the "wrong" ToS on your packets. It'll be eaten by some random provider. So if you use any ToS internally, you need a middlebox to unset your ToS bits. > Huh? I haven't seen this problem at all. I've seen packets arrive with the ToS bits stripped, but, I haven't seen ToS cause a packet to get dropped. You seem to have found a particularly bleak set of providers to use. > I'd gladly give up a static IP address just to have an internet that delivered my packets from my home or server to the remote destination. > I expect my packets to get delivered (and they generally do) and I have static addresses too. You can have it all if you try. Owen From Valdis.Kletnieks at vt.edu Tue Nov 22 10:36:48 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 22 Nov 2011 11:36:48 -0500 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: Your message of "Tue, 22 Nov 2011 08:19:25 PST." <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> References: <4ECA6C97.6030208@dds.nl> <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> Message-ID: <5367.1321979808@turing-police.cc.vt.edu> On Tue, 22 Nov 2011 08:19:25 PST, Owen DeLong said: > On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: > > Exactly. ISPs are in business to make as much money as they can - go figure. > > How do you make more money by refusing to meet customer requests? > > I could understand how it MIGHT make more money to force customers that > want static to purchase business class, but, if you then refuse to offer > them business class service, that doesn't sound like more money, it just > sounds like angry customers. A number of providers seem to be doing just fine with that business model over on the IPv4 side of the fence. And since they're usually a near-monopoly in their service area, angry customers aren't likely to actually vote with their wallets. Why is there any expectation that it will be any different in the IPv6 world? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tim at pelican.org Tue Nov 22 10:48:15 2011 From: tim at pelican.org (Tim Franklin) Date: Tue, 22 Nov 2011 16:48:15 -0000 (GMT) Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> Message-ID: >> 3) If you write an application using anything other than UDP or TCP, >> it won't work on most networks (with some minor exceptions for PPTP >> and IPSEC, which work sometimes). > > This hasn't been my experience unless you're behind some form of NAT. > Yes, it is well known that NAT breaks most protocols. I've come across a non-zero number of "residential" providers, who, with or without NAT, explicitly discard protocols 50 and 51. The same argument is applied - if you want this, you must buy a "business" connection. Which is usually double-speak for "add an order of magnitude to the price, turn off *some* of the broken-ness". Regards, Tim. From rps at maine.edu Tue Nov 22 10:51:51 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 22 Nov 2011 11:51:51 -0500 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <5367.1321979808@turing-police.cc.vt.edu> References: <4ECA6C97.6030208@dds.nl> <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> <5367.1321979808@turing-police.cc.vt.edu> Message-ID: On Tue, Nov 22, 2011 at 11:36 AM, ? wrote: > A number of providers seem to be doing just fine with that business model over> on the IPv4 side of the fence. ?And since they're usually a near-monopoly in> their service area, angry customers aren't likely to actually vote with their> wallets. ?Why is there any expectation that it will be any different in the> IPv6 world? This. My options for home are Time Warner Cable 15M down, 1M up; or Fairpoint DSL, 3M down, 128K up. So my option is really only TWC. And I live 3 miles off the University of Maine campus. Other parts of the state don't have the luxury of more than one option, if any. You can't vote with your wallet if you're stuck with a monopoly. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Tue Nov 22 10:53:04 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Nov 2011 08:53:04 -0800 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <5367.1321979808@turing-police.cc.vt.edu> References: <4ECA6C97.6030208@dds.nl> <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> <5367.1321979808@turing-police.cc.vt.edu> Message-ID: <05C4C0E8-2882-4B0F-9036-A27F4F995C7E@delong.com> On Nov 22, 2011, at 8:36 AM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 22 Nov 2011 08:19:25 PST, Owen DeLong said: >> On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: >>> Exactly. ISPs are in business to make as much money as they can - go figure. >> >> How do you make more money by refusing to meet customer requests? >> >> I could understand how it MIGHT make more money to force customers that >> want static to purchase business class, but, if you then refuse to offer >> them business class service, that doesn't sound like more money, it just >> sounds like angry customers. > > A number of providers seem to be doing just fine with that business model over > on the IPv4 side of the fence. And since they're usually a near-monopoly in > their service area, angry customers aren't likely to actually vote with their > wallets. Why is there any expectation that it will be any different in the > IPv6 world? > I didn't say they wouldn't make money... I said they wouldn't make "MORE" money. Owen From listas at esds.com.br Tue Nov 22 10:59:13 2011 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 22 Nov 2011 14:59:13 -0200 Subject: RES: Any recommended router. They are reliable and have good support. In-Reply-To: References: Message-ID: <000901cca938$11a88020$34f98060$@esds.com.br> On 22/11/2011 1:39pm, Deric Kwok wrote: > Can I know any selection of Linux routers except cisco / juniper? I prefer Freebsd. Take a look on BSDRP (BSD Route Project). http://bsdrp.net/ -- Eduardo Schoedler From lists at mtin.net Tue Nov 22 11:02:13 2011 From: lists at mtin.net (Justin Wilson) Date: Tue, 22 Nov 2011 12:02:13 -0500 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: <1F342086A5E3480BB1D82DF3577A66C9@work> Message-ID: Imagestream is *nix based and has excellent customer service. -- 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: Meftah Tayeb Date: Mon, 21 Nov 2011 16:24:24 +0200 To: Deric Kwok , nanog list Subject: Re: Any recommended router. They are reliable and have good support. >+1 MikroTik >http://www.mikrotik.com > >----- Original Message ----- >From: "Deric Kwok" >To: "nanog list" >Sent: Tuesday, November 22, 2011 5:38 PM >Subject: Any recommended router. They are reliable and have good support. > > >> Hi >> >> Can I know any selection of Linux routers except cisco / juniper? >> >> They are reliable and have good support provided >> >> We would like to get one for testing. >> >> Thank you >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 6651 (20111122) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> > > >__________ Information from ESET NOD32 Antivirus, version of virus >signature database 6651 (20111122) __________ > >The message was checked by ESET NOD32 Antivirus. > >http://www.eset.com > > > > From listas at esds.com.br Tue Nov 22 11:03:37 2011 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 22 Nov 2011 15:03:37 -0200 Subject: RES: Any recommended router. They are reliable and have good support. In-Reply-To: References: , <4ECBC603.1060609@snappydsl.net> <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> Message-ID: <000a01cca938$af910000$0eb30000$@esds.com.br> One important feature for me is MPLS/VPLS support. +1 MikroTik -- Eduardo Schoedler > -----Mensagem original----- > De: Meftah Tayeb [mailto:tayeb.meftah at gmail.com] > Enviada em: segunda-feira, 21 de novembro de 2011 12:26 > Para: Leigh Porter; Faisal at snappydsl.net > Cc: nanog list > Assunto: Re: Any recommended router. They are reliable and have good > support. > > Leigh, > MT is very responcive > wonderfull > fast bug fixs and very organised RouterOs releases i use it a lot and have > a hell load of features support all major routing protocols BGP, OSPF / > OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much more. > thank you > > ----- Original Message ----- > From: "Leigh Porter" > To: > Cc: "nanog list" > Sent: Tuesday, November 22, 2011 6:02 PM > Subject: Re: Any recommended router. They are reliable and have good > support. > > > Has anybody had experience of mikrotik support? Is it any good? Any > thoughts about the time to fix bugs? > > -- > Leigh > > > On 22 Nov 2011, at 15:57, "Faisal Imtiaz" wrote: > > > mikrotik family .. you can have all sizes and shapes of routers .. > > lots of support available online or from independent consultants. > > > > Regards. > > > > Faisal Imtiaz > > Snappy Internet& Telecom > > > > > > On 11/22/2011 10:38 AM, Deric Kwok wrote: > >> Hi > >> > >> Can I know any selection of Linux routers except cisco / juniper? > >> > >> They are reliable and have good support provided > >> > >> We would like to get one for testing. > >> > >> Thank you From julien at gormotte.info Tue Nov 22 11:05:36 2011 From: julien at gormotte.info (Julien Gormotte) Date: Tue, 22 Nov 2011 18:05:36 +0100 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: <000901cca938$11a88020$34f98060$@esds.com.br> References: <000901cca938$11a88020$34f98060$@esds.com.br> Message-ID: <20111122180536.643fff17@jupc> Le Tue, 22 Nov 2011 14:59:13 -0200, "Eduardo Schoedler" a ?crit : > On 22/11/2011 1:39pm, Deric Kwok wrote: > > Can I know any selection of Linux routers except cisco / juniper? > > I prefer Freebsd. > Take a look on BSDRP (BSD Route Project). > http://bsdrp.net/ The problem with this is to find good hardware for it, that is affordable, robust, and does not uses the power of a desktop pc. > > > -- > Eduardo Schoedler > > From listas at esds.com.br Tue Nov 22 11:07:20 2011 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 22 Nov 2011 15:07:20 -0200 Subject: RES: Any recommended router. They are reliable and have good support. In-Reply-To: <20111122180536.643fff17@jupc> References: <000901cca938$11a88020$34f98060$@esds.com.br> <20111122180536.643fff17@jupc> Message-ID: <000b01cca939$33bdab80$9b390280$@esds.com.br> On 22/11/2011 3:06pm, Julien Gormotte wrote: > Le Tue, 22 Nov 2011 14:59:13 -0200, > "Eduardo Schoedler" a ?crit : > > > On 22/11/2011 1:39pm, Deric Kwok wrote: > > > Can I know any selection of Linux routers except cisco / juniper? > > > > I prefer Freebsd. > > Take a look on BSDRP (BSD Route Project). > > http://bsdrp.net/ > > The problem with this is to find good hardware for it, that is affordable, > robust, and does not uses the power of a desktop pc. I agree, but with Intel hardware, that's not a problem. -- Eduardo Schoedler From james at freedomnet.co.nz Tue Nov 22 11:09:18 2011 From: james at freedomnet.co.nz (James Jones) Date: Tue, 22 Nov 2011 12:09:18 -0500 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: <4ECBC30E.4080008@gmail.com> References: <4ECBC30E.4080008@gmail.com> Message-ID: On Tue, Nov 22, 2011 at 10:43 AM, lorddoskias wrote: > On 11/22/2011 3:38 PM, Deric Kwok wrote: > >> Hi >> >> Can I know any selection of Linux routers except cisco / juniper? >> >> They are reliable and have good support provided >> >> We would like to get one for testing. >> >> Thank you >> >> >> > http://www.vyatta.com/ might be worth checking. > > If you are not afraid of the command line check xorp it is what vyatta is based on. From drc at virtualized.org Tue Nov 22 11:15:15 2011 From: drc at virtualized.org (David Conrad) Date: Tue, 22 Nov 2011 09:15:15 -0800 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> References: <4ECA6C97.6030208@dds.nl> <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> Message-ID: On Nov 22, 2011, at 8:19 AM, Owen DeLong wrote: >> Exactly. ISPs are in business to make as much money as they can - go figure. > How do you make more money by refusing to meet customer requests? Not rocket science. The vast majority of customers fall into a small number of categories. You make money by optimizing for those categories. For the folks that don't fit in those categories (e.g., people who actually ask for IPv6), you treat them as special cases until there are sufficient requests to justify a new category. >> 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. > That's beyond tragic if it's actually true. You should name and shame your provider if that's really the case. I suspect most (all?) very large scale service providers amortize their equipment over quite long periods. If said equipment doesn't support , it becomes a relatively simple cost/benefit analysis to determine whether or not upgrading the hardware out of cycle would have sufficient ROI to justify the cost. A lot depends on how many customers will bolt if isn't offered before the equipment is put out to pasture naturally. Since (currently) the vast majority of large scale providers' customers have no interest in (or even knowledge of) IPv6, it's unlikely the cost/benefit analysis ends up in a pro-IPv6 way. There are, of course, more forward looking ISPs, but they appear to be the exception rather than the rule. >> 3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). > This hasn't been my experience unless you're behind some form of NAT. Yes, it is well known that NAT breaks most protocols. Not NAT. Default deny firewalls. Look at the recommended firewall configs from pretty much any security consultant/vendor and see what happens when you try to turn on (say) SCTP. >> 4) What would happen if someone wrote a popular app that used IP options? I don't want to know that answer even though I already know it. "Break the internet" is about how I'd phrase it. > The app would never become popular because most people would be unable to use it. Right. See 'default deny firewalls'. >> 6) The same server can't receive IP fragments, except for the first one. For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6 will cause longer answers). Yes, I know I can turn off large UDP responses on my resolver. I bet more than a few people don't know that though. I believe at least one resolver (BIND) will do this for you. It first tries using an extension that allows for a 4096-byte buffer. If that fails, it tries using the extension with a 512-byte buffer. If that fails, it turns off the extension. In the latter 2 cases, if the response is larger than 512 bytes, DNS will automatically fall back to TCP. Increases latency, but that's life on the Real Internet(tm). >> 7) Even UDP and TCP aren't going to work everywhere. Hense why everything seems to tunnel over HTTP or HTTPS even when that's an inappropriate method (such as when reliable ordered packet delivery is a hinderence). > Yes, this is an increasingly common problem. Thanks, Micr0$0ft. Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be the real IPng. Regards, -drc From robert at vyatta.com Tue Nov 22 11:15:29 2011 From: robert at vyatta.com (Robert Bays) Date: Tue, 22 Nov 2011 09:15:29 -0800 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: References: <4ECBC30E.4080008@gmail.com> Message-ID: On Nov 22, 2011, at 9:09 AM, James Jones wrote: > On Tue, Nov 22, 2011 at 10:43 AM, lorddoskias wrote: > >> On 11/22/2011 3:38 PM, Deric Kwok wrote: >> >>> Hi >>> >>> Can I know any selection of Linux routers except cisco / juniper? >>> >>> They are reliable and have good support provided >>> >>> We would like to get one for testing. >>> >>> Thank you >>> >>> >>> >> http://www.vyatta.com/ might be worth checking. >> >> > If you are not afraid of the command line check xorp it is what vyatta is > based on. Vyatta uses Quagga for the protocol stack. We switched away from XORP a few years ago. Cheers, Robert. From mpetach at netflight.com Tue Nov 22 11:46:24 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 22 Nov 2011 09:46:24 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> Message-ID: On Mon, Nov 21, 2011 at 2:12 PM, Keegan Holley wrote: > 2011/11/21 >> On Sun, 20 Nov 2011 21:40:08 EST, Tyler Haske said: >> >> > I'm looking for a mentor who can help me focus my career so eventually I >> > wind up working at one of the Tier I ISPs as a senior tech. I want to >> > handle the big pipes that hold everyone's data. ... > I'd say > their ultimate goal is to touch a little as possible which is usually as > unglamorous as it sounds. ?Also, alot of things are scripted so much of > what you touch may not be as fun. Tyler, this is absolutely key, and absolutely true; if you really, really want to get a jump in the industry, don't worry about learning active directory or exchange (unless it's a particular hobby interest of yours); instead, learn a good scripting language; PERL is the canonical example, but python or tcl are equally fine candidates these days. Most of the really big networks, whether access ISPs, content providers, or tier 1 transit networks try to automate as much of the work as possible; it's the only way to stay ahead of the demand curve. If you want to be a hot property in networking, you should have a good blend of network skills, scripting/development skills, and ideally enough system administration background to know how to make the boxes running those tools happy as well. Being able to understand the packet flow from the application, down through the OS, and onto the wire, and then back up again at the far end is going to make you much more useful than an engineer that just knows how to get bits from point A to point Z, but that's it. Being able to turn up a 100GE link by hand is useful; but being able to write a script to turn up dozens at a time--that's what networks will fight over to get. (Also...echoing an undercurrent from several of the other voices...set up an account on tunnelbroker.net, get a v6 tunnel going to your house, set up a linux box with your favorite flavour of DNS server on it; start learning how to handle v6 DNS zones, the odd and occasional challenges involved with dual-stacked hosts and different DNS entries. And then start experimenting and breaking things--some of your best understanding is going to come from breaking your setup when experimenting, and then figuring out why it broke, and how to get it working again in the way you want. Debugging dual-stack networks is going to be required knowledge by the time you hit the industry; no reason not to start learning and using the information today, to really get comfortable with it.) You'll find that many of us are happy to answer intelligent, well-thought-through questions; what we don't tend to like are answering questions that are easily found through quick search engine queries. If you've done your own exploration first, and come up empty, chances are it'll be an interesting enough question someone out here will be willing to give a shot at answering it for you. But if you ask questions that would be just as easily answered through spending 5 minutes with a search engine, you'll find even the best mentors will start to give you the cold shoulder. ^_^; And finally...don't get discouraged; if you're pretty sure this is what you want to do with your life, stick with it. There can be some big ups and downs in this industry, but the chance to build something really big that touches millions of lives every day brings with it that huge sense of accomplishment that only comes with achieving something on a truly global scale. Best of luck! Matt From bonomi at mail.r-bonomi.com Tue Nov 22 11:53:47 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 22 Nov 2011 11:53:47 -0600 (CST) Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> Message-ID: <201111221753.pAMHrlEq093936@mail.r-bonomi.com> Owen DeLong naively wrote: > > On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: > > > On Nov 22, 2011, at 8:05 AM, Ray Soucy wrote: > > > >> As long as a static allocation can be billed as a premium service, > >> most providers will unfortunately do it. > > > > Exactly. ISPs are in business to make as much money as they can - go figure. > > > > How do you make more money by refusing to meet customer requests? > By 'encouraging' those 'high cost / low profit' customers to 'go elsewhere', and devoting the resources that they would otherwise consume to supporting 'lower-cost/ higher-profit' customers. This is 'no-brainer' free-market economics. :) From listas at esds.com.br Tue Nov 22 12:00:17 2011 From: listas at esds.com.br (Eduardo Schoedler) Date: Tue, 22 Nov 2011 16:00:17 -0200 Subject: RES: Any recommended router. They are reliable and have good support. In-Reply-To: <000a01cca938$af910000$0eb30000$@esds.com.br> References: , <4ECBC603.1060609@snappydsl.net> <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> <000a01cca938$af910000$0eb30000$@esds.com.br> Message-ID: <004501cca940$99ad1500$cd073f00$@esds.com.br> One missing feature in MikroTik is IS-IS. -- Eduardo Schoedler > -----Mensagem original----- > De: Eduardo Schoedler [mailto:listas at esds.com.br] > Enviada em: ter?a-feira, 22 de novembro de 2011 15:04 > Para: 'Meftah Tayeb'; 'Leigh Porter'; Faisal at snappydsl.net > Cc: 'nanog list' > Assunto: RES: Any recommended router. They are reliable and have good > support. > > One important feature for me is MPLS/VPLS support. > > +1 MikroTik > > -- > Eduardo Schoedler > > > > -----Mensagem original----- > > De: Meftah Tayeb [mailto:tayeb.meftah at gmail.com] Enviada em: > > segunda-feira, 21 de novembro de 2011 12:26 > > Para: Leigh Porter; Faisal at snappydsl.net > > Cc: nanog list > > Assunto: Re: Any recommended router. They are reliable and have good > > support. > > > > Leigh, > > MT is very responcive > > wonderfull > > fast bug fixs and very organised RouterOs releases i use it a lot and > > have a hell load of features support all major routing protocols BGP, > > OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless and much > more. > > thank you > > > > ----- Original Message ----- > > From: "Leigh Porter" > > To: > > Cc: "nanog list" > > Sent: Tuesday, November 22, 2011 6:02 PM > > Subject: Re: Any recommended router. They are reliable and have good > > support. > > > > > > Has anybody had experience of mikrotik support? Is it any good? Any > > thoughts about the time to fix bugs? > > > > -- > > Leigh > > > > > > On 22 Nov 2011, at 15:57, "Faisal Imtiaz" wrote: > > > > > mikrotik family .. you can have all sizes and shapes of routers .. > > > lots of support available online or from independent consultants. > > > > > > Regards. > > > > > > Faisal Imtiaz > > > Snappy Internet& Telecom > > > > > > > > > On 11/22/2011 10:38 AM, Deric Kwok wrote: > > >> Hi > > >> > > >> Can I know any selection of Linux routers except cisco / juniper? > > >> > > >> They are reliable and have good support provided > > >> > > >> We would like to get one for testing. > > >> > > >> Thank you From owen at delong.com Tue Nov 22 12:43:35 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Nov 2011 10:43:35 -0800 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: References: <4ECA6C97.6030208@dds.nl> <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> Message-ID: <86A32692-289B-4679-B7EA-191E54EE4CF0@delong.com> > >>> 3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). >> This hasn't been my experience unless you're behind some form of NAT. Yes, it is well known that NAT breaks most protocols. > > Not NAT. Default deny firewalls. Look at the recommended firewall configs from pretty much any security consultant/vendor and see what happens when you try to turn on (say) SCTP. > No, NAT. Yes, default deny firewalls can add additional breakage, but, even if you add the requisite permits in many cases NAT will still break most things for which ALGs haven't been provided in the NAT box. Default deny firewalls are a configuration problem that can be easily addressed through configuration. NAT is a fundamental damage to network services which requires modifying the actual NAT device or its firmware to work around or the elimination of NAT to resolve. >>> >>> 7) Even UDP and TCP aren't going to work everywhere. Hense why everything seems to tunnel over HTTP or HTTPS even when that's an inappropriate method (such as when reliable ordered packet delivery is a hinderence). >> Yes, this is an increasingly common problem. Thanks, Micr0$0ft. > > Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be the real IPng. > Perhaps because they have done more than any other vendor to enable/encourage this trend? Owen From straterra at fuhell.com Tue Nov 22 12:58:04 2011 From: straterra at fuhell.com (Thomas York) Date: Tue, 22 Nov 2011 13:58:04 -0500 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: <004501cca940$99ad1500$cd073f00$@esds.com.br> References: , <4ECBC603.1060609@snappydsl.net> <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> <000a01cca938$af910000$0eb30000$@esds.com.br> <004501cca940$99ad1500$cd073f00$@esds.com.br> Message-ID: <002301cca948$aea17ca0$0be475e0$@fuhell.com> I've had one major, glaring issue with RouterBoard/Mikrotik. Quite often, I will configure a new router/AP/whatever Mikrotik device and it simply will not work. The config is correct, but the device just won't work properly (sometimes it won't pass data, it won't bridge correctly, VLAN membership isn't correct, etc). However, if I reset the device to factory settings (Which takes forever because you have to find the little metal half circles and use a flat-head screwdriver to bridge them) and redo the EXACT same config everything will magically work. This annoyance hasn't been enough to make me switch to another brand yet, but I know every time I have to deploy a new device I'm likely to wrestle this issue. --Thomas York -----Original Message----- From: Eduardo Schoedler [mailto:listas at esds.com.br] Sent: Tuesday, November 22, 2011 1:00 PM To: 'Meftah Tayeb'; 'Leigh Porter'; Faisal at snappydsl.net Cc: 'nanog list' Subject: RES: Any recommended router. They are reliable and have good support. One missing feature in MikroTik is IS-IS. -- Eduardo Schoedler > -----Mensagem original----- > De: Eduardo Schoedler [mailto:listas at esds.com.br] Enviada em: > ter?a-feira, 22 de novembro de 2011 15:04 > Para: 'Meftah Tayeb'; 'Leigh Porter'; Faisal at snappydsl.net > Cc: 'nanog list' > Assunto: RES: Any recommended router. They are reliable and have good > support. > > One important feature for me is MPLS/VPLS support. > > +1 MikroTik > > -- > Eduardo Schoedler > > > > -----Mensagem original----- > > De: Meftah Tayeb [mailto:tayeb.meftah at gmail.com] Enviada em: > > segunda-feira, 21 de novembro de 2011 12:26 > > Para: Leigh Porter; Faisal at snappydsl.net > > Cc: nanog list > > Assunto: Re: Any recommended router. They are reliable and have good > > support. > > > > Leigh, > > MT is very responcive > > wonderfull > > fast bug fixs and very organised RouterOs releases i use it a lot > > and have a hell load of features support all major routing protocols > > BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless > > and much > more. > > thank you > > > > ----- Original Message ----- > > From: "Leigh Porter" > > To: > > Cc: "nanog list" > > Sent: Tuesday, November 22, 2011 6:02 PM > > Subject: Re: Any recommended router. They are reliable and have good > > support. > > > > > > Has anybody had experience of mikrotik support? Is it any good? Any > > thoughts about the time to fix bugs? > > > > -- > > Leigh > > > > > > On 22 Nov 2011, at 15:57, "Faisal Imtiaz" wrote: > > > > > mikrotik family .. you can have all sizes and shapes of routers .. > > > lots of support available online or from independent consultants. > > > > > > Regards. > > > > > > Faisal Imtiaz > > > Snappy Internet& Telecom > > > > > > > > > On 11/22/2011 10:38 AM, Deric Kwok wrote: > > >> Hi > > >> > > >> Can I know any selection of Linux routers except cisco / juniper? > > >> > > >> They are reliable and have good support provided > > >> > > >> We would like to get one for testing. > > >> > > >> Thank you -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6400 bytes Desc: not available URL: From rbf+nanog at panix.com Tue Nov 22 13:13:04 2011 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Tue, 22 Nov 2011 13:13:04 -0600 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> References: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> Message-ID: <20111122191304.GA12264@panix.com> On Tue, Nov 22, 2011 at 11:16:54AM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Owen DeLong" > > > As in all cases, additional flexibility results in additional > > ability to make mistakes. Simple mechanical lockouts do not scale > > to the modern world. The benefits of these additional capabilities > > far outweigh the perceived risks of programming errors. Relay logic has the potential for programming (i.e. wiring) errors also. It's not fair to compare "conflict monitor" to "properly programmed relay logic". We either have to include the risk of programming failures (which means "improper wiring" in the case of relay logic) in both cases, or exclude programming failures in both cases. > The perceived risk in this case is "multiple high-speed traffic fatalities". Some of the benefits of the newer systems are safety related also. > I believe we rank that pretty high; it's entirely possible that a traffic > light controller is the most potentially dangerous artifact (in terms of > number of possible deaths) that the average citizen interacts with on a > daily basis. Some other things to consider. Relays are more likely to fail. Yes, the relay architecture was carefully designed such that the most failures would not result in conflicting greens, but that's not the only risk. When the traffic signal is failing, even if it's failing with dark or red in every direction, the intersection becomes more dangerous. Not as dangerous as conflicting greens, but more dangerous than a properly operating intersection. If we can eliminate 1000 failures without conflicting greens, at the cost of one failure with a conflicting green, it might be a net win in terms of safety. Modern intersections are often considerably more complicated than a two phase "allow N/S, then allow E/W, then repeat" system. Wiring relays to completley avoid conflict in that case is very complex, and, therefore, more error prone. Even if a properly configured relay solution is more reliable than a properly configured solid-state conflict-monitor solution, if the relay solution is more likely to be misconfigured, then there's not necessarily a net win. Cost is an object. If implementing a solid state controller is less expensive (on CapEx and OpEx basis) than a relay-based controller, then it might be possible to implement traffic signals at four previously uncontrolled intersections, instead of just three. That's a pretty big safety win. And, yes, convenience is also an objective. Most people wouldn't want to live in a city where the throughput benefit of modern traffic signalling weren't available, even if they have to accept a very, very small increase in risk. -- Brett From faisal at snappydsl.net Tue Nov 22 13:19:02 2011 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Tue, 22 Nov 2011 14:19:02 -0500 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: <002301cca948$aea17ca0$0be475e0$@fuhell.com> References: , <4ECBC603.1060609@snappydsl.net> <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> <000a01cca938$af910000$0eb30000$@esds.com.br> <004501cca940$99ad1500$cd073f00$@esds.com.br> <002301cca948$aea17ca0$0be475e0$@fuhell.com> Message-ID: <4ECBF5A6.6030102@snappydsl.net> Having worked with approx 10-15 units of RouterBoards, I cannot say that I have see this issue. Could it be some sort of a software bug ? we typically update the mikrotik OS and Firmware before we deploy. Faisal Imtiaz Snappy Internet& Telecom On 11/22/2011 1:58 PM, Thomas York wrote: > I've had one major, glaring issue with RouterBoard/Mikrotik. Quite often, I > will configure a new router/AP/whatever Mikrotik device and it simply will > not work. The config is correct, but the device just won't work properly > (sometimes it won't pass data, it won't bridge correctly, VLAN membership > isn't correct, etc). However, if I reset the device to factory settings > (Which takes forever because you have to find the little metal half circles > and use a flat-head screwdriver to bridge them) and redo the EXACT same > config everything will magically work. > > This annoyance hasn't been enough to make me switch to another brand yet, > but I know every time I have to deploy a new device I'm likely to wrestle > this issue. > > --Thomas York > > -----Original Message----- > From: Eduardo Schoedler [mailto:listas at esds.com.br] > Sent: Tuesday, November 22, 2011 1:00 PM > To: 'Meftah Tayeb'; 'Leigh Porter'; Faisal at snappydsl.net > Cc: 'nanog list' > Subject: RES: Any recommended router. They are reliable and have good > support. > > One missing feature in MikroTik is IS-IS. > > -- > Eduardo Schoedler > > > >> -----Mensagem original----- >> De: Eduardo Schoedler [mailto:listas at esds.com.br] Enviada em: >> ter?a-feira, 22 de novembro de 2011 15:04 >> Para: 'Meftah Tayeb'; 'Leigh Porter'; Faisal at snappydsl.net >> Cc: 'nanog list' >> Assunto: RES: Any recommended router. They are reliable and have good >> support. >> >> One important feature for me is MPLS/VPLS support. >> >> +1 MikroTik >> >> -- >> Eduardo Schoedler >> >> >>> -----Mensagem original----- >>> De: Meftah Tayeb [mailto:tayeb.meftah at gmail.com] Enviada em: >>> segunda-feira, 21 de novembro de 2011 12:26 >>> Para: Leigh Porter; Faisal at snappydsl.net >>> Cc: nanog list >>> Assunto: Re: Any recommended router. They are reliable and have good >>> support. >>> >>> Leigh, >>> MT is very responcive >>> wonderfull >>> fast bug fixs and very organised RouterOs releases i use it a lot >>> and have a hell load of features support all major routing protocols >>> BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless >>> and much >> more. >>> thank you >>> >>> ----- Original Message ----- >>> From: "Leigh Porter" >>> To: >>> Cc: "nanog list" >>> Sent: Tuesday, November 22, 2011 6:02 PM >>> Subject: Re: Any recommended router. They are reliable and have good >>> support. >>> >>> >>> Has anybody had experience of mikrotik support? Is it any good? Any >>> thoughts about the time to fix bugs? >>> >>> -- >>> Leigh >>> >>> >>> On 22 Nov 2011, at 15:57, "Faisal Imtiaz" wrote: >>> >>>> mikrotik family .. you can have all sizes and shapes of routers .. >>>> lots of support available online or from independent consultants. >>>> >>>> Regards. >>>> >>>> Faisal Imtiaz >>>> Snappy Internet& Telecom >>>> >>>> >>>> On 11/22/2011 10:38 AM, Deric Kwok wrote: >>>>> Hi >>>>> >>>>> Can I know any selection of Linux routers except cisco / juniper? >>>>> >>>>> They are reliable and have good support provided >>>>> >>>>> We would like to get one for testing. >>>>> >>>>> Thank you > From jra at baylink.com Tue Nov 22 13:26:34 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 22 Nov 2011 14:26:34 -0500 (EST) Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <20111122191304.GA12264@panix.com> Message-ID: <27628410.3767.1321989994469.JavaMail.root@benjamin.baylink.com> > Relay logic has the potential for programming (i.e. wiring) errors > also. Yes, but the complexity of a computerized controller is 3-6 orders of magnitude higher, *and none of it is visible* > It's not fair to compare "conflict monitor" to "properly programmed > relay logic". We either have to include the risk of programming > failures (which means "improper wiring" in the case of relay logic) in > both cases, or exclude programming failures in both cases. See above, and note that there are at least a couple orders of magnitude more possible failure modes on a computerized controller as well. > Some other things to consider. > > Relays are more likely to fail. Yes, the relay architecture was > carefully designed such that the most failures would not result in > conflicting greens, My understanding was that it was completely impossible. You could fail dark, but you *could not* fail crossing-green. > but that's not the only risk. When the traffic > signal is failing, even if it's failing with dark or red in every > direction, the intersection becomes more dangerous. Not as dangerous > as conflicting greens, By 2 or 3 orders of magnitude, usually; the second thing they teach you in driver ed is "a dark traffic signal is a 4-way stop". > but more dangerous than a properly operating > intersection. If we can eliminate 1000 failures without conflicting > greens, at the cost of one failure with a conflicting green, it might > be a net win in terms of safety. The underlying issue is trust, as it so often is. People assume (for very good reason) that crossing greens is completely impossible. The cost of a crossing-greens accident is *much* higher than might be imagined; think "new Coke". > Modern intersections are often considerably more complicated than a > two phase "allow N/S, then allow E/W, then repeat" system. Wiring relays > to completley avoid conflict in that case is very complex, and, > therefore, more error prone. Even if a properly configured relay > solution is more reliable than a properly configured solid-state > conflict-monitor solution, if the relay solution is more likely to be > misconfigured, then there's not necessarily a net win. Sure. But we have no numbers on either side. > Cost is an object. If implementing a solid state controller is less > expensive (on CapEx and OpEx basis) than a relay-based controller, then > it might be possible to implement traffic signals at four previously > uncontrolled intersections, instead of just three. That's a pretty big > safety win. See above about whether people trust green lights to be safe. > And, yes, convenience is also an objective. Most people wouldn't want > to live in a city where the throughput benefit of modern traffic > signalling weren't available, even if they have to accept a very, very > small increase in risk. Assuming they knew they were accepting it. But if it amounts to "Well, it's going to cost you more if we do it [right]", well, look out for #OccupyMainStreet. "We can fake it cause it's cheaper" is pretty close to a dead approach, I suspect. 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 jon at smugmug.com Tue Nov 22 13:35:56 2011 From: jon at smugmug.com (Jon Heise) Date: Tue, 22 Nov 2011 11:35:56 -0800 Subject: automated config backups for SFTOS Message-ID: Does anyone know of a method of automating config backups for force10 switches running SFTOS ? I've got an python expect script that works on our routers running FTOS, it uses a role account that can show the running configs without having to use the enable password. i could expand the script to use the enable password but i'm hesitant to have it lying around in a script Jon Heise From jason at biel-tech.com Tue Nov 22 13:40:48 2011 From: jason at biel-tech.com (Jason Biel) Date: Tue, 22 Nov 2011 13:40:48 -0600 Subject: automated config backups for SFTOS In-Reply-To: References: Message-ID: Deploy RANCID? On Tue, Nov 22, 2011 at 1:35 PM, Jon Heise wrote: > Does anyone know of a method of automating config backups for force10 > switches running SFTOS ? I've got an python expect script that works on our > routers running FTOS, it uses a role account that can show the running > configs without having to use the enable password. i could expand the > script to use the enable password but i'm hesitant to have it lying around > in a script > > Jon Heise > -- Jason From tayeb.meftah at gmail.com Mon Nov 21 12:07:22 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Mon, 21 Nov 2011 20:07:22 +0200 Subject: Any recommended router. They are reliable and have good support. References: , <4ECBC603.1060609@snappydsl.net> <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> <000a01cca938$af910000$0eb30000$@esds.com.br> <004501cca940$99ad1500$cd073f00$@esds.com.br> <002301cca948$aea17ca0$0be475e0$@fuhell.com> <4ECBF5A6.6030102@snappydsl.net> Message-ID: <4C33242232A548BAB6983E09448980DC@work> +1 Faisal never has any kind of issue with RouterBoards :) Faisal, please contact me offlist ----- Original Message ----- From: "Faisal Imtiaz" To: "Thomas York" Cc: ; ; ; Sent: Tuesday, November 22, 2011 9:19 PM Subject: Re: Any recommended router. They are reliable and have good support. > Having worked with approx 10-15 units of RouterBoards, I cannot say that > I have see this issue. > > Could it be some sort of a software bug ? we typically update the > mikrotik OS and Firmware before we deploy. > > Faisal Imtiaz > Snappy Internet& Telecom > > > On 11/22/2011 1:58 PM, Thomas York wrote: >> I've had one major, glaring issue with RouterBoard/Mikrotik. Quite often, >> I >> will configure a new router/AP/whatever Mikrotik device and it simply >> will >> not work. The config is correct, but the device just won't work properly >> (sometimes it won't pass data, it won't bridge correctly, VLAN membership >> isn't correct, etc). However, if I reset the device to factory settings >> (Which takes forever because you have to find the little metal half >> circles >> and use a flat-head screwdriver to bridge them) and redo the EXACT same >> config everything will magically work. >> >> This annoyance hasn't been enough to make me switch to another brand yet, >> but I know every time I have to deploy a new device I'm likely to wrestle >> this issue. >> >> --Thomas York >> >> -----Original Message----- >> From: Eduardo Schoedler [mailto:listas at esds.com.br] >> Sent: Tuesday, November 22, 2011 1:00 PM >> To: 'Meftah Tayeb'; 'Leigh Porter'; Faisal at snappydsl.net >> Cc: 'nanog list' >> Subject: RES: Any recommended router. They are reliable and have good >> support. >> >> One missing feature in MikroTik is IS-IS. >> >> -- >> Eduardo Schoedler >> >> >> >>> -----Mensagem original----- >>> De: Eduardo Schoedler [mailto:listas at esds.com.br] Enviada em: >>> ter?a-feira, 22 de novembro de 2011 15:04 >>> Para: 'Meftah Tayeb'; 'Leigh Porter'; Faisal at snappydsl.net >>> Cc: 'nanog list' >>> Assunto: RES: Any recommended router. They are reliable and have good >>> support. >>> >>> One important feature for me is MPLS/VPLS support. >>> >>> +1 MikroTik >>> >>> -- >>> Eduardo Schoedler >>> >>> >>>> -----Mensagem original----- >>>> De: Meftah Tayeb [mailto:tayeb.meftah at gmail.com] Enviada em: >>>> segunda-feira, 21 de novembro de 2011 12:26 >>>> Para: Leigh Porter; Faisal at snappydsl.net >>>> Cc: nanog list >>>> Assunto: Re: Any recommended router. They are reliable and have good >>>> support. >>>> >>>> Leigh, >>>> MT is very responcive >>>> wonderfull >>>> fast bug fixs and very organised RouterOs releases i use it a lot >>>> and have a hell load of features support all major routing protocols >>>> BGP, OSPF / OSPFv3, RIP/RIPNG, PIM for multicast, MME for wireless >>>> and much >>> more. >>>> thank you >>>> >>>> ----- Original Message ----- >>>> From: "Leigh Porter" >>>> To: >>>> Cc: "nanog list" >>>> Sent: Tuesday, November 22, 2011 6:02 PM >>>> Subject: Re: Any recommended router. They are reliable and have good >>>> support. >>>> >>>> >>>> Has anybody had experience of mikrotik support? Is it any good? Any >>>> thoughts about the time to fix bugs? >>>> >>>> -- >>>> Leigh >>>> >>>> >>>> On 22 Nov 2011, at 15:57, "Faisal Imtiaz" wrote: >>>> >>>>> mikrotik family .. you can have all sizes and shapes of routers .. >>>>> lots of support available online or from independent consultants. >>>>> >>>>> Regards. >>>>> >>>>> Faisal Imtiaz >>>>> Snappy Internet& Telecom >>>>> >>>>> >>>>> On 11/22/2011 10:38 AM, Deric Kwok wrote: >>>>>> Hi >>>>>> >>>>>> Can I know any selection of Linux routers except cisco / juniper? >>>>>> >>>>>> They are reliable and have good support provided >>>>>> >>>>>> We would like to get one for testing. >>>>>> >>>>>> Thank you >> > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 6652 (20111122) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 6652 (20111122) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From rs at seastrom.com Tue Nov 22 13:52:05 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 22 Nov 2011 14:52:05 -0500 Subject: Any recommended router. They are reliable and have good support. In-Reply-To: <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> (Leigh Porter's message of "Tue, 22 Nov 2011 16:02:11 +0000") References: <4ECBC603.1060609@snappydsl.net> <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> Message-ID: <864nxwrl3u.fsf@seastrom.com> Leigh Porter writes: > Has anybody had experience of mikrotik support? Is it any good? Any > thoughts about the time to fix bugs? I have dealt with Mikrotik support. They were easily comparable to [CJ]TAC. Which is to say "guy was pleasant and courteous, I could tell through the language barrier that he wasn't really interested in addressing my problems or understanding them, and eventually I got exasperated and figured out a work-around". That said, it's easy to exceed expectations when you've spent something like $70 on a router that does five ports of gigabit ethernet. Several dot releases after that little ordeal, at least one of my laundry list of problems (ssh connections blew up if you are using application layer keepalives) seems to have gotten fixed, at least in 5.8, with nary a mention in the release notes so I assume it was a matter of syncing the codebase to whatever they run for an ssh server. Still no fix for the "your CLI only partially implements Emacs key binds, please try libcli.a which is LGPL instead", which is annoying since this shortcoming is really up in your grill whenever you're logged into the router. Still can't traceroute to an IPv6 host by name, only by number. Dunno if they figured out what the "G" in "GRE" stands for yet and started allowing protocols other than IPv4 (and ethertypes other than 0x0800) in a GRE tunnel - can't be bothered to test it out since I managed to get 6in4 tunneling working instead. There are more random gripes, but you get the idea - routeros definitely shows a certain lack of polish but can get the job done for low-end stuff at a very acceptably low-end price. All in all, despite the gripes it's worth your time to check out. Don't let the folks who sing their praises get your hopes up too much but hey, for pocket change invested? Pretty decent. There are some good surprises in there too, like putative support for 32 bit ASNs (haven't tested that myself) and scriptability that will allow you to send TSIG-signed dns update messages periodically for when you have customers to support that are on the far end of a non-sticky DHCP. -r From rbf+nanog at panix.com Tue Nov 22 14:04:23 2011 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Tue, 22 Nov 2011 14:04:23 -0600 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <27628410.3767.1321989994469.JavaMail.root@benjamin.baylink.com> References: <20111122191304.GA12264@panix.com> <27628410.3767.1321989994469.JavaMail.root@benjamin.baylink.com> Message-ID: <20111122200422.GA1840@panix.com> On Tue, Nov 22, 2011 at 02:26:34PM -0500, Jay Ashworth wrote: > > Yes, but the complexity of a computerized controller is 3-6 orders of > magnitude higher, *and none of it is visible* You can't see the electrons in the relays either. > > Some other things to consider. > > > > Relays are more likely to fail. Yes, the relay architecture was > > carefully designed such that the most failures would not result in > > conflicting greens, > > My understanding was that it was completely impossible. You could > fail dark, but you *could not* fail crossing-green. If properly wired, maybe. But probably not. I'd have to see the architecture, but, for example, is there any risk of a power surge at the wrong time welding the green contacts togethor and resulting in a permanent green in one direction that doesn't lock the other direction out? (Maybe not. But I'm confident that some failure could be contrived with a detailed explanation of a real system.) > > but that's not the only risk. When the traffic > > signal is failing, even if it's failing with dark or red in every > > direction, the intersection becomes more dangerous. Not as > > dangerous as conflicting greens, > > By 2 or 3 orders of magnitude, usually; the second thing they teach you > in driver ed is "a dark traffic signal is a 4-way stop". Of course, not everyone follows the rules. People learn "red means stop" well before driver ed, but sometimes they don't stop, even at a red. Traffic Signal Out cases are often a mess, because you have a relatively complicated or busy intersection, and a collection of drivers only 95% of which (for example) actually know how to handle the case, and even many of those 95% are very tentative because they know that not all the other drivers know the rules. The upside is that most of the collisions that result are low speed. > > but more dangerous than a properly operating > > intersection. If we can eliminate 1000 failures without conflicting > > greens, at the cost of one failure with a conflicting green, it might > > be a net win in terms of safety. > > The underlying issue is trust, as it so often is. People assume (for > very good reason) that crossing greens is completely impossible. The > cost of a crossing-greens accident is *much* higher than might be > imagined; think "new Coke". New Coke was imposed on all coke drinkers, though. A better analogy is airline plane crashes. They are exceedingly rare, but when they happen, almost everyone knows about them. Yet people still fly. Even immediately after the crash. (And a modern airplane is orders of magnitude more complicated than a solid state conflict monitor.) Conflicting greens are also exceedingly rare, and it's not nationwide or worldwide news when they occur. If conflicting greens start occuring routinely, yeah, people are going to lose confidence in the system. But we could likely withstand a couple orders of magnitude increase in the number of green-on-green incidents without any meaningful reduction in confidence in traffic signals. Still, obviously, the point isn't to keep increasing the frequency of conflicting green incidents until people start to lose confidence. The point is that there's no evidence of any meaningful increase in risk with electronic controllers. > > Modern intersections are often considerably more complicated than a > > two phase "allow N/S, then allow E/W, then repeat" system. Wiring relays > > to completley avoid conflict in that case is very complex, and, > > therefore, more error prone. Even if a properly configured relay > > solution is more reliable than a properly configured solid-state > > conflict-monitor solution, if the relay solution is more likely to be > > misconfigured, then there's not necessarily a net win. > > Sure. But we have no numbers on either side. Yeah, and I looked. There's nothing I could find. But ... I'd be shocked to find evidence of a statistically higher risk of conflicting greens in electronic conflict-monitor implementations over relay-based systems of comparable intersection complexity. Vital electronics is a well-established industry. We all work in a bug-of-the-week industry, where we demand more speed, more features, and so on, and accept quite a bit of risk associated with that. Even the careful networks that nominally place a high value on stability don't have a reliability comparable to a traffic signal or an airplane. But that doesn't mean reliable electronic systems can't be built. Just that you have to prioritize that over other things if that's what you want. And that's what the vital electronics industry does. -- Brett From joseph.sullivan at alyrica.net Tue Nov 22 14:31:26 2011 From: joseph.sullivan at alyrica.net (Joseph Sullivan) Date: Tue, 22 Nov 2011 12:31:26 -0800 Subject: Any recommended router. They are reliable and have good support. References: <4ECBC603.1060609@snappydsl.net> <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> <864nxwrl3u.fsf@seastrom.com> Message-ID: We use a lot of Mikrotik in our network. They are fantastic little routers as long as you remember that they are not Cisco/Juniper/whatever. In other words, you pay a few hundred bucks, you get something worth at least that much. But don't put it head to head against a $10k router. Support is technically sound, but you have to email Latvia and then wait for the time difference to get a response. If you expect to pay $100 for a router and then get prompt, courteous, 24/7 tech support, you will be disappointed. :) We use their routers mostly for end user gateways doing QOS. They do a superb job of this. I wouldn't particularly want them as network edge devices or core routers; they will choke up if the PPS rate gets too high and you are doing any kind of packet mangling. There have been a lot of bugs in various versions of RouterOS, but the current (5.8?) OS seems pretty good. They added IPv6 support and fixed a ton of bugs. OSPF implementation was buggy before OS5, but seems to be relatively stable since we upgraded. BGP works fine but is perhaps less feature rich than Cisco/Zebra. Joseph Alyrica Networks Inc / www.alyrica.net ----- Original Message ----- From: "Robert E. Seastrom" To: "Leigh Porter" Cc: "nanog list" Sent: Tuesday, November 22, 2011 11:52 AM Subject: Re: Any recommended router. They are reliable and have good support. > > Leigh Porter writes: > >> Has anybody had experience of mikrotik support? Is it any good? Any >> thoughts about the time to fix bugs? > > I have dealt with Mikrotik support. They were easily comparable to > [CJ]TAC. Which is to say "guy was pleasant and courteous, I could > tell through the language barrier that he wasn't really interested in > addressing my problems or understanding them, and eventually I got > exasperated and figured out a work-around". > > That said, it's easy to exceed expectations when you've spent > something like $70 on a router that does five ports of gigabit > ethernet. > > Several dot releases after that little ordeal, at least one of my > laundry list of problems (ssh connections blew up if you are using > application layer keepalives) seems to have gotten fixed, at least in > 5.8, with nary a mention in the release notes so I assume it was a > matter of syncing the codebase to whatever they run for an ssh server. > Still no fix for the "your CLI only partially implements Emacs key > binds, please try libcli.a which is LGPL instead", which is annoying > since this shortcoming is really up in your grill whenever you're > logged into the router. Still can't traceroute to an IPv6 host by > name, only by number. Dunno if they figured out what the "G" in "GRE" > stands for yet and started allowing protocols other than IPv4 (and > ethertypes other than 0x0800) in a GRE tunnel - can't be bothered to > test it out since I managed to get 6in4 tunneling working instead. > There are more random gripes, but you get the idea - routeros > definitely shows a certain lack of polish but can get the job done for > low-end stuff at a very acceptably low-end price. > > All in all, despite the gripes it's worth your time to check out. > Don't let the folks who sing their praises get your hopes up too much > but hey, for pocket change invested? Pretty decent. There are some > good surprises in there too, like putative support for 32 bit ASNs > (haven't tested that myself) and scriptability that will allow you to > send TSIG-signed dns update messages periodically for when you have > customers to support that are on the far end of a non-sticky DHCP. > > -r From Valdis.Kletnieks at vt.edu Tue Nov 22 14:30:59 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 22 Nov 2011 15:30:59 -0500 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: Your message of "Tue, 22 Nov 2011 10:43:35 PST." <86A32692-289B-4679-B7EA-191E54EE4CF0@delong.com> References: <4ECA6C97.6030208@dds.nl> <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> <86A32692-289B-4679-B7EA-191E54EE4CF0@delong.com> Message-ID: <13448.1321993859@turing-police.cc.vt.edu> On Tue, 22 Nov 2011 10:43:35 PST, Owen DeLong said: > > Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be the real IPng. > Perhaps because they have done more than any other vendor to enable/encourage this trend? Actually, I'd nominate the creator of the PIX firewall box for that honor, mostly because it made it socially acceptable to do firewalling that caused other sites pain and suffering (SMTP fixups, anybody? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Tue Nov 22 14:37:17 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Nov 2011 12:37:17 -0800 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <27628410.3767.1321989994469.JavaMail.root@benjamin.baylink.com> References: <27628410.3767.1321989994469.JavaMail.root@benjamin.baylink.com> Message-ID: > >> but that's not the only risk. When the traffic >> signal is failing, even if it's failing with dark or red in every >> direction, the intersection becomes more dangerous. Not as dangerous >> as conflicting greens, > > By 2 or 3 orders of magnitude, usually; the second thing they teach you > in driver ed is "a dark traffic signal is a 4-way stop". > I'm not so sure that's true. (The 2-3 orders of magnitude part). When I worked ambulance, we responded to a lot more collisions in 4-way stop intersections and malfunctioning (dark or flashing red) signal intersections than we did in intersections with conflicting greens. A whole lot ore, like none of the conflicting greens and many of the others. As such, I'd say that the probability of a conflicting green occurring and causing an injury accident is pretty low even with (relatively) modern digital signal controllers. >> but more dangerous than a properly operating >> intersection. If we can eliminate 1000 failures without conflicting >> greens, at the cost of one failure with a conflicting green, it might >> be a net win in terms of safety. > > The underlying issue is trust, as it so often is. People assume (for > very good reason) that crossing greens is completely impossible. The > cost of a crossing-greens accident is *much* higher than might be > imagined; think "new Coke". > Sorry, I have trouble understanding how you draw a parallel between a crossing greens accident and new coke. Yes, people assume a crossing greens situation is completely impossible. People assume a lot of very unlikely things are completely impossible. Many people think that winning the lottery is completely impossible for them. A fraction of those people choose not to play on that basis, rendering that belief basically true. Even with modern software-controlled signaling, crossing greens events are extremely uncommon. So much so that I have never actually encountered one. >> Modern intersections are often considerably more complicated than a >> two phase "allow N/S, then allow E/W, then repeat" system. Wiring relays >> to completley avoid conflict in that case is very complex, and, >> therefore, more error prone. Even if a properly configured relay >> solution is more reliable than a properly configured solid-state >> conflict-monitor solution, if the relay solution is more likely to be >> misconfigured, then there's not necessarily a net win. > > Sure. But we have no numbers on either side. > I will say that the relative complexity of configuring the software systems vs. wiring a relay based system to correctly protect a modern complex intersection would make the relay system inherently significantly less likely to have completely protected logic. In fact, it might even be electrically impossible to completely protect the logic in some modern intersection configurations because they don't make relays with that many poles. Conversely, the software configuration interface is pretty well abstracted to the level of essentially describing the intersection in terms of source/destination pairs and paths crossed by each pair. Short of a serious bug in the overall firmware or the configuration compiler (for lack of a better term), I'd say that such gross errors in the configuration of the conflict monitor are pretty unlikely. Indeed, the history of traffic light malfunctions with digital controllers would seem to bear this out. The safety record appears to be pretty good. So rare, in fact, that traffic light malfunctions do not appear in a list of traffic accident causes that totaled more than 99% of traffic accidents when I added up the percentages. I can only assume that since light malfunctions overall are not a statistically significant fraction of accidents, conflicting greens must represent an even smaller and more insignificant fraction. >> Cost is an object. If implementing a solid state controller is less >> expensive (on CapEx and OpEx basis) than a relay-based controller, then >> it might be possible to implement traffic signals at four previously >> uncontrolled intersections, instead of just three. That's a pretty big >> safety win. > > See above about whether people trust green lights to be safe. > People trust cars to be safe. What is your point? Owen From owen at delong.com Tue Nov 22 14:49:24 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Nov 2011 12:49:24 -0800 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <13448.1321993859@turing-police.cc.vt.edu> References: <4ECA6C97.6030208@dds.nl> <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> <86A32692-289B-4679-B7EA-191E54EE4CF0@delong.com> <13448.1321993859@turing-police.cc.vt.edu> Message-ID: <2A1E1B71-7BD9-43FD-A558-E211D4AA50B8@delong.com> On Nov 22, 2011, at 12:30 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 22 Nov 2011 10:43:35 PST, Owen DeLong said: > >>> Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be the real IPng. > >> Perhaps because they have done more than any other vendor to enable/encourage this trend? > > Actually, I'd nominate the creator of the PIX firewall box for that honor, > mostly because it made it socially acceptable to do firewalling that caused > other sites pain and suffering (SMTP fixups, anybody? :) > That would be John Mayes. The PIX was an outgrowth of Cisco's purchase of a company called Network Address Translation (translation.com back in the day). Frankly, the trend towards NAT and the need for some level of security that was evolving in that day made most of those things inevitable. Were there better approaches, perhaps. However, even with the PIX in place, I think that Micr0$0ft did more to make http-based tunneling a widespread and common phenomenon. It may have been pragmatic from their perspective, but, it was also damaging to the internet and they were the ones that chose to be pragmatic like that on a wide scale. Owen From bruns at 2mbit.com Tue Nov 22 15:08:44 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 22 Nov 2011 14:08:44 -0700 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <13448.1321993859@turing-police.cc.vt.edu> References: <4ECA6C97.6030208@dds.nl> <4D12DB50-DDB6-4D2F-84E0-85019649A932@antelope.net> <8484B33A-061C-494F-9DEB-4F8C1F1E4204@delong.com> <86A32692-289B-4679-B7EA-191E54EE4CF0@delong.com> <13448.1321993859@turing-police.cc.vt.edu> Message-ID: *** *** **** right. ******* like ***** ****** to ****** *** what *** ***** *** ** ******. :) -- Brielle (sent from my phone) On Nov 22, 2011, at 1:30 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 22 Nov 2011 10:43:35 PST, Owen DeLong said: > >>> Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be the real IPng. > >> Perhaps because they have done more than any other vendor to enable/encourage this trend? > > Actually, I'd nominate the creator of the PIX firewall box for that honor, > mostly because it made it socially acceptable to do firewalling that caused > other sites pain and suffering (SMTP fixups, anybody? :) > From bonomi at mail.r-bonomi.com Tue Nov 22 15:36:06 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 22 Nov 2011 15:36:06 -0600 (CST) Subject: OT: Traffic Light Control Message-ID: <201111222136.pAMLa6mh095590@mail.r-bonomi.com> On Tue, Nov 22, 2011 at 02:26:34PM -0500, Jay Ashworth wrote: > > > Some other things to consider. > > > > Relays are more likely to fail. Yes, the relay architecture was > > carefully designed such that the most failures would not result in > > conflicting greens, > > My understanding was that it was completely impossible. You could > fail dark, but you *could not* fail crossing-green. Just to put one point to rest. I, personally, have witnessed traffic lights showing 'green both directions'. *TWICE*. One was in the mid-1960s, with what was undoubtedly relay-based control logic; the second was in the late 1990s, *probably* with solid-state 'management' controls , but I don't know for certain. (The 'relatively recent' unit's I've seen the insides of have solid-state logic driving final 'output' relays that provide power to the actual signal head.) In the first case, the pedestal-mounted control unit had been subjected to excessive impact forces, and some of the 'output' wires had shorted together. From dmburgess at linktechs.net Tue Nov 22 15:38:01 2011 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 22 Nov 2011 15:38:01 -0600 Subject: Any recommended router. They are reliable and have good support. References: <4ECBC603.1060609@snappydsl.net> <66B71961-B75A-4DAE-BA62-7EB0891DFAD9@ukbroadband.com> <864nxwrl3u.fsf@seastrom.com> Message-ID: <13175F96BDC3B34AB1425BAE905B3CE50BA68E09@ltiserver.lti.local> I could look though our customer list and show over 2,000 networks being ran by RouterOS from small networks running 20-50 meg all the way up to networks running 10GigE BGP feeds. We just turned up a location running 4 BGP GigE feeds in a single router. ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" > -----Original Message----- > From: Joseph Sullivan [mailto:joseph.sullivan at alyrica.net] > Sent: Tuesday, November 22, 2011 2:31 PM > To: nanog at nanog.org > Subject: Re: Any recommended router. They are reliable and have good > support. > > > We use a lot of Mikrotik in our network. They are fantastic little routers as > long as you remember that they are not Cisco/Juniper/whatever. In other > words, you pay a few hundred bucks, you get something worth at least that > much. But don't put it head to head against a $10k router. > > Support is technically sound, but you have to email Latvia and then wait for > the time difference to get a response. If you expect to pay $100 for a router > and then get prompt, courteous, 24/7 tech support, you will be disappointed. > :) > > We use their routers mostly for end user gateways doing QOS. They do a > superb job of this. I wouldn't particularly want them as network edge > devices or core routers; they will choke up if the PPS rate gets too high and > you are doing any kind of packet mangling. > > There have been a lot of bugs in various versions of RouterOS, but the > current (5.8?) OS seems pretty good. They added IPv6 support and fixed a > ton of bugs. > > OSPF implementation was buggy before OS5, but seems to be relatively > stable since we upgraded. BGP works fine but is perhaps less feature rich > than Cisco/Zebra. > > Joseph > > Alyrica Networks Inc / www.alyrica.net > > > ----- Original Message ----- > From: "Robert E. Seastrom" > To: "Leigh Porter" > Cc: "nanog list" > Sent: Tuesday, November 22, 2011 11:52 AM > Subject: Re: Any recommended router. They are reliable and have good > support. > > > > > > Leigh Porter writes: > > > >> Has anybody had experience of mikrotik support? Is it any good? Any > >> thoughts about the time to fix bugs? > > > > I have dealt with Mikrotik support. They were easily comparable to > > [CJ]TAC. Which is to say "guy was pleasant and courteous, I could > > tell through the language barrier that he wasn't really interested in > > addressing my problems or understanding them, and eventually I got > > exasperated and figured out a work-around". > > > > That said, it's easy to exceed expectations when you've spent > > something like $70 on a router that does five ports of gigabit > > ethernet. > > > > Several dot releases after that little ordeal, at least one of my > > laundry list of problems (ssh connections blew up if you are using > > application layer keepalives) seems to have gotten fixed, at least in > > 5.8, with nary a mention in the release notes so I assume it was a > > matter of syncing the codebase to whatever they run for an ssh server. > > Still no fix for the "your CLI only partially implements Emacs key > > binds, please try libcli.a which is LGPL instead", which is annoying > > since this shortcoming is really up in your grill whenever you're > > logged into the router. Still can't traceroute to an IPv6 host by > > name, only by number. Dunno if they figured out what the "G" in "GRE" > > stands for yet and started allowing protocols other than IPv4 (and > > ethertypes other than 0x0800) in a GRE tunnel - can't be bothered to > > test it out since I managed to get 6in4 tunneling working instead. > > There are more random gripes, but you get the idea - routeros > > definitely shows a certain lack of polish but can get the job done for > > low-end stuff at a very acceptably low-end price. > > > > All in all, despite the gripes it's worth your time to check out. > > Don't let the folks who sing their praises get your hopes up too much > > but hey, for pocket change invested? Pretty decent. There are some > > good surprises in there too, like putative support for 32 bit ASNs > > (haven't tested that myself) and scriptability that will allow you to > > send TSIG-signed dns update messages periodically for when you have > > customers to support that are on the far end of a non-sticky DHCP. > > > > -r > From BEJones at semprautilities.com Tue Nov 22 16:26:44 2011 From: BEJones at semprautilities.com (Jones, Barry) Date: Tue, 22 Nov 2011 14:26:44 -0800 Subject: Net Brain? Message-ID: Anyone using Net Brain? Just curious what you think.... ---------------------------------------- Barry Jones - CISSP GSNA P please don't print this e-mail unless you really need to. ---------------------------------------- From matthew at matthew.at Tue Nov 22 16:59:43 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 22 Nov 2011 14:59:43 -0800 Subject: First real-world SCADA attack in US In-Reply-To: <20111122135956.GA21368@panix.com> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> Message-ID: <4ECC295F.3020909@matthew.at> On 11/22/2011 5:59 AM, Brett Frankenberger wrote: > The typical implementation in a modern controller is to have a > separate conflict monitor unit that will detect when conflicting > greens (for example) are displayed, and trigger a (also separate) > flasher unit that will cause the signal to display a flashing red in > all directions (sometimes flashing yellow for one higher volume > route). So the controller would output conflicting greens if it failed > or was misprogrammed, but the conflict monitor would detect that and > restore the signal to a safe (albeit flashing, rather than normal > operation) state. -- Brett Indeed. All solid-state controllers, microprocessor or not, are required to have a completely independent conflict monitor that watches the actual HV outputs to the lamps and, in the event of a fault, uses electromechanical relays to disconnect the controller and connect the reds to a separate flasher circuit. The people building these things and writing the requirements do understand the consequences of failure. Matthew Kaufman From andrew.wallace at rocketmail.com Tue Nov 22 17:01:31 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Tue, 22 Nov 2011 15:01:31 -0800 (PST) Subject: First real-world SCADA attack in US In-Reply-To: <4ECC295F.3020909@matthew.at> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> <4ECC295F.3020909@matthew.at> Message-ID: <1322002891.66700.YahooMailNeo@web162102.mail.bf1.yahoo.com> Here is the latest folks, "DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system in Springfield, Illinois." http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html Andrew From tvhawaii at shaka.com Tue Nov 22 17:10:38 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 22 Nov 2011 13:10:38 -1000 Subject: First real-world SCADA attack in US References: <18459778.3577.1321889553820.JavaMail.root@benjamin.baylink.com>, <3A5EC203-AC6F-4C55-97F6-9EF037BA6F97@gmail.com> <6D392E7D-1436-4422-A069-F4F82DFD1BCB@ukbroadband.com>, <4ECAB2E9.4070503@nac.net> <7F096857-0585-423A-86F4-AF4E80836497@ukbroadband.com> <4ECAC306.7020202@amplex.net> <33DF112F-7BD6-441B-B222-DF3B8B188DED@cs.columbia.edu> Message-ID: <26AF466F69044BEB846FE00584D11DC3@owner59e1f1502> Steven Bellovin wrote: > On Nov 21, 2011, at 4:30 PM, Mark Radabaugh wrote: >>> >>> >> Probably nowhere near that sophisticated. More like somebody owned the PC running Windows 98 being used as an >> operator >> interface to the control system. Then they started poking buttons on the pretty screen. >> >> Somewhere there is a terrified 12 year old. >> >> Please don't think I am saying infrastructure security should not be improved - it really does need help. But I >> really doubt >> this was anything truly interesting. > > > That's precisely the problem: it does appear to have been an easy attack. > (My thoughts are at https://www.cs.columbia.edu/~smb/blog/2011-11/2011-11-18.html) > > --Steve Bellovin, https://www.cs.columbia.edu/~smb Umm hmm. And here's another one poking around: http://pastebin.com/Wx90LLum "I'm not going to expose the details of the box. No damage was done to any of the machinery; I don't really like mindless vandalism. It's stupid and silly. On the other hand, so is connecting interfaces to your SCADA machinery to the Internet. I wouldn't even call this a hack, either, just to say. This required almost no skill and could be reproduced by a two year old with a basic knowledge of Simatic." --Michael From jra at baylink.com Tue Nov 22 17:14:54 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 22 Nov 2011 18:14:54 -0500 (EST) Subject: First real-world SCADA attack in US In-Reply-To: <4ECC295F.3020909@matthew.at> Message-ID: <28130383.3795.1322003694473.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Kaufman" > Indeed. All solid-state controllers, microprocessor or not, are required > to have a completely independent conflict monitor that watches the > actual HV outputs to the lamps and, in the event of a fault, uses > electromechanical relays to disconnect the controller and connect the > reds to a separate flasher circuit. > > The people building these things and writing the requirements do > understand the consequences of failure. If you mean "an independent conflict monitor which, *in the event there is NO discernable fault*, *connects* the controller to the lamp outputs... so that in the event the monitor itself fails, gravity or springs will return those outputs to the flasher circuit", than I'll accept that latter assertion. 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 Tue Nov 22 17:23:38 2011 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Tue, 22 Nov 2011 17:23:38 -0600 Subject: First real-world SCADA attack in US In-Reply-To: <28130383.3795.1322003694473.JavaMail.root@benjamin.baylink.com> References: <4ECC295F.3020909@matthew.at> <28130383.3795.1322003694473.JavaMail.root@benjamin.baylink.com> Message-ID: <20111122232337.GA26405@panix.com> On Tue, Nov 22, 2011 at 06:14:54PM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Matthew Kaufman" > > > Indeed. All solid-state controllers, microprocessor or not, are required > > to have a completely independent conflict monitor that watches the > > actual HV outputs to the lamps and, in the event of a fault, uses > > electromechanical relays to disconnect the controller and connect the > > reds to a separate flasher circuit. > > > > The people building these things and writing the requirements do > > understand the consequences of failure. > > If you mean "an independent conflict monitor which, *in the event > there is NO discernable fault*, *connects* the controller to the lamp > outputs... so that in the event the monitor itself fails, gravity or > springs will return those outputs to the flasher circuit", than I'll > accept that latter assertion. That protects against a conflicting output from the controller at the same time the conflict monitor completely dies (assuming its death is in a manner that removes voltage from the relays). It doesn't protect against the case of conflicting output from the controller which the conflict monitor fails to detect. (Which is one of the cases you seemed to be concerned about before.) -- Brett From tvhawaii at shaka.com Tue Nov 22 17:32:23 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 22 Nov 2011 13:32:23 -1000 Subject: First real-world SCADA attack in US References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> <4ECC295F.3020909@matthew.at> <1322002891.66700.YahooMailNeo@web162102.mail.bf1.yahoo.com> Message-ID: <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> andrew.wallace wrote: > Here is the latest folks, > > "DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system in Springfield, Illinois." > > http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html > > Andrew And "In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as previously reported." I'd bet we'll soon be hearing more from this loldhs pr0f character in .ro. --Michael From joe at nethead.com Tue Nov 22 18:00:52 2011 From: joe at nethead.com (Joe Hamelin) Date: Tue, 22 Nov 2011 16:00:52 -0800 Subject: First real-world SCADA attack in US In-Reply-To: <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> <4ECC295F.3020909@matthew.at> <1322002891.66700.YahooMailNeo@web162102.mail.bf1.yahoo.com> <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> Message-ID: This might be of interest to those wishing to dive deeper into the subject. Telecommunications Handbook for Transportation Professionals: The Basics of Telecommunications by the Federal Highway Administration. http://ops.fhwa.dot.gov/publications/telecomm_handbook/ I'm still digging through it to see what they say about network security. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From Valdis.Kletnieks at vt.edu Tue Nov 22 18:51:59 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 22 Nov 2011 19:51:59 -0500 Subject: First real-world SCADA attack in US In-Reply-To: Your message of "Tue, 22 Nov 2011 13:32:23 -1000." <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> <4ECC295F.3020909@matthew.at> <1322002891.66700.YahooMailNeo@web162102.mail.bf1.yahoo.com> <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> Message-ID: <8045.1322009519@turing-police.cc.vt.edu> On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: > > http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html > And "In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as > previously reported." It's interesting to read the rest of the text while doing some deconstruction: "There is no evidence to support claims made in the initial Fusion Center report ... that any credentials were stolen, or that the vendor was involved in any malicious activity that led to a pump failure at the water plant." Notice that they're carefully framing it as "no evidence that credentials were stolen" - while carefully tap-dancing around the fact that you don't need to steal credentials in order to totally pwn a box via an SQL injection or a PHP security issue, or to log into a box that's still got the vendor-default userid/passwords on them. You don't need to steal the admin password if Google tells you the default login is "admin/admin" ;) "No evidence that the vendor was involved" - *HAH*. When is the vendor *EVER* involved? The RSA-related hacks of RSA's customers are conspicuous by their uniqueness. And I've probably missed a few weasel words in there... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From smb at cs.columbia.edu Tue Nov 22 19:08:58 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 22 Nov 2011 20:08:58 -0500 Subject: First real-world SCADA attack in US In-Reply-To: <8045.1322009519@turing-police.cc.vt.edu> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> <4ECC295F.3020909@matthew.at> <1322002891.66700.YahooMailNeo@web162102.mail.bf1.yahoo.com> <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> <8045.1322009519@turing-police.cc.vt.edu> Message-ID: <5F708076-4FD0-42B2-9E37-4E5599010278@cs.columbia.edu> On Nov 22, 2011, at 7:51 59PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: > >>> http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html > >> And "In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as >> previously reported." > > It's interesting to read the rest of the text while doing some deconstruction: > > "There is no evidence to support claims made in the initial Fusion Center > report ... that any credentials were stolen, or that the vendor was involved > in any malicious activity that led to a pump failure at the water plant." > > Notice that they're carefully framing it as "no evidence that credentials were > stolen" - while carefully tap-dancing around the fact that you don't need to > steal credentials in order to totally pwn a box via an SQL injection or a PHP > security issue, or to log into a box that's still got the vendor-default > userid/passwords on them. You don't need to steal the admin password > if Google tells you the default login is "admin/admin" ;) > > "No evidence that the vendor was involved" - *HAH*. When is the vendor *EVER* > involved? The RSA-related hacks of RSA's customers are conspicuous by their > uniqueness. > > And I've probably missed a few weasel words in there... They do state categorically that "After detailed analysis, DHS and the FBI have found no evidence of a cyber intrusion into the SCADA system of the Curran-Gardner Public Water District in Springfield, Illinois." I'm waiting to see Joe Weiss's response. --Steve Bellovin, https://www.cs.columbia.edu/~smb From smb at cs.columbia.edu Tue Nov 22 20:07:08 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 22 Nov 2011 21:07:08 -0500 Subject: First real-world SCADA attack in US In-Reply-To: <5F708076-4FD0-42B2-9E37-4E5599010278@cs.columbia.edu> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> <4ECC295F.3020909@matthew.at> <1322002891.66700.YahooMailNeo@web162102.mail.bf1.yahoo.com> <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> <8045.1322009519@turing-police.cc.vt.edu> <5F708076-4FD0-42B2-9E37-4E5599010278@cs.columbia.edu> Message-ID: On Nov 22, 2011, at 8:08 58PM, Steven Bellovin wrote: > > On Nov 22, 2011, at 7:51 59PM, Valdis.Kletnieks at vt.edu wrote: > >> On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: >> >>>> http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html >> >>> And "In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as >>> previously reported." >> >> It's interesting to read the rest of the text while doing some deconstruction: >> >> "There is no evidence to support claims made in the initial Fusion Center >> report ... that any credentials were stolen, or that the vendor was involved >> in any malicious activity that led to a pump failure at the water plant." >> >> Notice that they're carefully framing it as "no evidence that credentials were >> stolen" - while carefully tap-dancing around the fact that you don't need to >> steal credentials in order to totally pwn a box via an SQL injection or a PHP >> security issue, or to log into a box that's still got the vendor-default >> userid/passwords on them. You don't need to steal the admin password >> if Google tells you the default login is "admin/admin" ;) >> >> "No evidence that the vendor was involved" - *HAH*. When is the vendor *EVER* >> involved? The RSA-related hacks of RSA's customers are conspicuous by their >> uniqueness. >> >> And I've probably missed a few weasel words in there... > > They do state categorically that "After detailed analysis, DHS and the > FBI have found no evidence of a cyber intrusion into the SCADA system of > the Curran-Gardner Public Water District in Springfield, Illinois." > > I'm waiting to see Joe Weiss's response. See http://www.wired.com/threatlevel/2011/11/scada-hack-report-wrong/ --Steve Bellovin, https://www.cs.columbia.edu/~smb From mysidia at gmail.com Tue Nov 22 20:51:46 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 22 Nov 2011 20:51:46 -0600 Subject: First real-world SCADA attack in US In-Reply-To: <20111122232337.GA26405@panix.com> References: <4ECC295F.3020909@matthew.at> <28130383.3795.1322003694473.JavaMail.root@benjamin.baylink.com> <20111122232337.GA26405@panix.com> Message-ID: On Tue, Nov 22, 2011 at 5:23 PM, Brett Frankenberger wrote: > On Tue, Nov 22, 2011 at 06:14:54PM -0500, Jay Ashworth wrote: > in a manner that removes voltage from the relays). ?It doesn't protect > against the case of conflicting output from the controller which the > conflict monitor fails to detect. ?(Which is one of the cases you > seemed to be concerned about before.) Reliable systems have triple redundancy. And indeed... hardwired safety is a lot better than relying on software. But it's not like transistors/capacitors don't fail either, so whether solid state or not, a measure of added protection is in order beyond a single monitor. There should be a "conflict monitor test path" that involves a third circuit intentionally creating a safe "test" conflict at pre-defined sub-millisecond intervals, by generating a conflict in a manner the monitor is supposed to detect but won't actually produce current through the light, and checking for absence of a test signal on green; if the test fails, the test circuit should intentionally blow a pair of fuses, breaking the test circuit's connections to the controller and conflict monitor. In addition the 'test circuit' should generate a pair of clock signals of its own, that is a side effect and only possible with correct test outcomes and will be verified by both the conflict monitor and the controller; if the correct clock indicating successful test outcomes is not detected by either the conflict monitor or by the controller, both systems should independently force a fail, using different methods. So you have 3 circuits, and any one circuit can detect the most severe potential failure of any pair of the other circuits. > ? ? -- Brett -- -JH From jra at baylink.com Tue Nov 22 21:00:20 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 22 Nov 2011 22:00:20 -0500 (EST) Subject: First real-world SCADA attack in US In-Reply-To: Message-ID: <30691794.18.1322017219976.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > So you have 3 circuits, and any one circuit can detect the most > severe potential failure of any pair of the other circuits. Just so. Byzantine monitoring, just like a Byzantine clock. 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 dennis at justipit.com Tue Nov 22 21:12:09 2011 From: dennis at justipit.com (Dennis) Date: Tue, 22 Nov 2011 22:12:09 -0500 Subject: First real-world SCADA attack in US Message-ID: <4mxv6vjvnsbmtld0tus50oc4.1322017929639@email.android.com> Like any of the decades largest breaches this could have been avoided by following BCP's. In addition SCADA networks are easily protected via behavioral and signature based security technologies. Steven Bellovin wrote: > >On Nov 22, 2011, at 8:08 58PM, Steven Bellovin wrote: > >> >> On Nov 22, 2011, at 7:51 59PM, Valdis.Kletnieks at vt.edu wrote: >> >>> On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: >>> >>>>> http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html >>> >>>> And "In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as >>>> previously reported." >>> >>> It's interesting to read the rest of the text while doing some deconstruction: >>> >>> "There is no evidence to support claims made in the initial Fusion Center >>> report ... that any credentials were stolen, or that the vendor was involved >>> in any malicious activity that led to a pump failure at the water plant." >>> >>> Notice that they're carefully framing it as "no evidence that credentials were >>> stolen" - while carefully tap-dancing around the fact that you don't need to >>> steal credentials in order to totally pwn a box via an SQL injection or a PHP >>> security issue, or to log into a box that's still got the vendor-default >>> userid/passwords on them. You don't need to steal the admin password >>> if Google tells you the default login is "admin/admin" ;) >>> >>> "No evidence that the vendor was involved" - *HAH*. When is the vendor *EVER* >>> involved? The RSA-related hacks of RSA's customers are conspicuous by their >>> uniqueness. >>> >>> And I've probably missed a few weasel words in there... >> >> They do state categorically that "After detailed analysis, DHS and the >> FBI have found no evidence of a cyber intrusion into the SCADA system of >> the Curran-Gardner Public Water District in Springfield, Illinois." >> >> I'm waiting to see Joe Weiss's response. > > >See http://www.wired.com/threatlevel/2011/11/scada-hack-report-wrong/ > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > From paradox at nac.net Tue Nov 22 21:48:09 2011 From: paradox at nac.net (Ryan Pavely) Date: Tue, 22 Nov 2011 22:48:09 -0500 Subject: First real-world SCADA attack in US In-Reply-To: <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> <4ECC295F.3020909@matthew.at> <1322002891.66700.YahooMailNeo@web162102.mail.bf1.yahoo.com> <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> Message-ID: <4ECC6CF9.300@nac.net> Note to self. When my opc/modbus code goes to hell and wipes out an hvac unit; blame cyber terrorists, crappy vendors, and provide a random shady ip address. This was sad when it was possibly an unprotected network, with poor password procedures, horrible protection code in the logics, etc etc. Now it even got worse. Sigh. Ryan Pavely Director Research And Development Net Access Corporation http://www.nac.net/ On 11/22/2011 6:32 PM, Michael Painter wrote: > andrew.wallace wrote: >> Here is the latest folks, >> >> "DHS and the FBI have found no evidence of a cyber intrusion into the >> SCADA system in Springfield, Illinois." >> >> http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html >> >> >> Andrew > > And "In addition, DHS and FBI have concluded that there was no > malicious traffic from Russia or any foreign entities, as previously > reported." > > I'd bet we'll soon be hearing more from this loldhs pr0f character in > .ro. > > --Michael From tvhawaii at shaka.com Tue Nov 22 21:54:58 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 22 Nov 2011 17:54:58 -1000 Subject: First real-world SCADA attack in US References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> <4ECC295F.3020909@matthew.at> <1322002891.66700.YahooMailNeo@web162102.mail.bf1.yahoo.com> <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> <8045.1322009519@turing-police.cc.vt.edu> <5F708076-4FD0-42B2-9E37-4E5599010278@cs.columbia.edu> Message-ID: <4D9561AB624D4B4EB30611AF8770245B@owner59e1f1502> On Nov 22, 2011, at 8:08 58PM, Steven Bellovin wrote: > They do state categorically that "After detailed analysis, DHS and the > FBI have found no evidence of a cyber intrusion into the SCADA system of > the Curran-Gardner Public Water District in Springfield, Illinois." > > I'm waiting to see Joe Weiss's response. > See http://www.wired.com/threatlevel/2011/11/scada-hack-report-wrong/ > --Steve Bellovin, https://www.cs.columbia.edu/~smb "Weiss expressed frustration over the conflicting reports." Somewhat related...New broom at DHS. From SANS NewsBites Vol.13, Num.93: "Good News! Yesterday, Mark Weatherford took over as Deputy Undersecretary for Cyber Security at the U.S. Department of Homeland Security. For the first time in many years, the U.S. cybersecurity program will be run by a technologist rather than by a lawyer. There are good reasons to believe that this change will herald an era of greater balance in national cybersecurity leadership between NSA and DHS." From andrew.wallace at rocketmail.com Tue Nov 22 22:26:01 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Tue, 22 Nov 2011 20:26:01 -0800 (PST) Subject: First real-world SCADA attack in US In-Reply-To: <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> <4ECC295F.3020909@matthew.at> <1322002891.66700.YahooMailNeo@web162102.mail.bf1.yahoo.com> <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> Message-ID: <1322022361.3103.YahooMailNeo@web162109.mail.bf1.yahoo.com> "There is no evidence to support claims made in initial reports -- which were based on raw, unconfirmed data and subsequently leaked to the media."? http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html From what I'm seeing and hearing is the report by the fusion centre was private and facts were still being *fusioned* when somebody decided to leak to the media. What we had was a half baked report not ment for public consumption. What needs to be looked at is lockering out certain people who think its OK to leak reports from these state resources. Andrew From jay at west.net Tue Nov 22 22:29:46 2011 From: jay at west.net (Jay Hennigan) Date: Tue, 22 Nov 2011 20:29:46 -0800 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> References: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> Message-ID: <4ECC76BA.9090104@west.net> On 11/22/11 8:16 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> As in all cases, additional flexibility results in additional ability >> to make mistakes. Simple mechanical lockouts do not scale to the >> modern world. The benefits of these additional capabilities far >> outweigh the perceived risks of programming errors. > > The perceived risk in this case is "multiple high-speed traffic fatalities". > > I believe we rank that pretty high; it's entirely possible that a traffic > light controller is the most potentially dangerous artifact (in terms of > number of possible deaths) that the average citizen interacts with on a > daily basis. I'm familiar with this. The modern Safetran brand of traffic light controllers are indeed microprocessor based and networked for time sync, although they can also use local GPS. Network is typically radio or twisted pair modem. McCain, BiTran, etc. are similar. The master controllers do run IP so the risk is there that they can be either deliberately or accidentally exposed to the Internet. Before this they typically had a dial-up modem and could be accessed by anyone war-dialing with a VT-100 emulator and some password guessing. Many are still this way. Within each intersection controller is a PC board with a diode matrix called a "conflict monitor". It has inputs from all of the green and yellow phases including pedestrian walk signals, turn arrows, etc. It's the job of the traffic engineer installing the system to program the conflict monitor for that intersection. By default they're programmed for a simple North-South vs. East-West intersection of two-way streets with pedestrian controls. If anything different, the conflict monitor is reprogrammed in the field to match the intersection. In the event of a conflict, defined as green, yellow or walk signals that would cause conflicting traffic being allowed, the conflict monitor forces the intersection into red flashing in all directions and disconnects control from the microprocessor until manually reset on-site. If networked, it also sends a conflict alarm. If the conflict monitor is removed, the intersection goes to flash. Conflicting green is only possible if the conflict monitor is mis-programmed or the external connections to the signal heads are mis-wired. Even a short-circuit in the external wiring between two green phases would be detected unless the feed wires of the conflicting phases are cut to the signal box. In the real world, "Stuff happens". Trucks cut corners and turn the traffic heads to point the wrong way. Controllers get replaced with a stock unit after a failure or accident knocking down the signal box without being properly set up for that intersection. But, an external cracker even with full access won't be able to cause a conflict. Massive traffic jams by messing with the timing, short or long cycles, etc. but not a conflict. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From toddunder at gmail.com Wed Nov 23 06:03:21 2011 From: toddunder at gmail.com (Todd Underwood) Date: Wed, 23 Nov 2011 07:03:21 -0500 Subject: RIPE 64 Call for Presentations Message-ID: Fellow builders, operators, analyzers and ponderers of networks, I suspect that the following Call for Presentations may be a useful reminder for some of you to begin working on presentations for RIPE 64 next Spring. ------------------------------- RIPE 64: Call for Presentations RIPE 64 takes place on 16-20 April 2012 in Ljubljana, Slovenia. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the Plenary, BoF and tutorial sessions at RIPE 64. The PC seeks presentations covering topics of network engineering and operations, including but not limited to: ? IPv6 deployment ? Managing IPv4 scarcity in operations ? Commercial transactions of IPv4 addresses ? Data centre technologies ? Network and DNS operations ? Internet governance and regulatory practices ? Network and routing security * Content delivery * Internet peering and mobile data exchange Submissions ------------ Attendees of the RIPE meetings are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters who are proposing a panel or BOF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. Presenters should indicate how much time they will require (30 minutes is a common maximum duration, although some talks can be longer). Proposals for presentations must be submitted for full consideration no later than *3 February* using the online topic submission system at: http://meetings.ripe.net/pc/ Presentations submitted after this date will be considered on a space-available basis. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several timeslots for ?lightning talks? which are selected immediately before or during the conference. Lightning talks are short (10 mins maximum) and often involve more timely topics. Lightning talks will be announced shortly before the conference. If you are aware of a talk that might be interesting to the community, please provide us with the details and we will approach the potential speaker. If you have any questions or requests concerning content submissions, please email pc at ripe.net. For more information about RIPE 64, including how to register, visit: http://ripe64.ripe.net/ Kind regards, todd underwood, for the RIPE Programme Committee toddunder at gmail.com pc at ripe.net From mark at amplex.net Wed Nov 23 08:41:08 2011 From: mark at amplex.net (Mark Radabaugh) Date: Wed, 23 Nov 2011 09:41:08 -0500 Subject: Odd router brokenness Message-ID: <4ECD0604.6020203@amplex.net> Since this list likes to speculate with little facts on a regular basis (and I'll admit to being as guilty as anyone) I throw this one out for opinions : We were seeing very odd behavior on a Cogent circuit following a software upgrade to tol01.atlas. Two traceroutes: mark at angola-gw> traceroute 74.125.226.6 traceroute to 74.125.226.6 (74.125.226.6), 30 hops max, 40 byte packets 1 * * gi1-1.ccr01.tol01.atlas.cogentco.com (38.104.148.5) 110.315 ms 2 te4-2.ccr01.sbn01.atlas.cogentco.com (154.54.7.154) 139.520 ms 196.910 ms 5.728 ms 3 * * * 4 * te0-5-0-5.ccr21.ord03.atlas.cogentco.com (154.54.44.174) 8.310 ms te0-0-0-7.ccr21.ord03.atlas.cogentco.com (154.54.25.70) 8.752 ms 5 te0-0-0-0.ccr22.ord03.atlas.cogentco.com (154.54.24.214) 8.983 ms te0-1-0-0.ccr22.ord03.atlas.cogentco.com (66.28.4.66) 7.948 ms * 6 * * te-9-1.car4.Chicago1.Level3.net (4.68.127.129) 26.127 ms 7 GOOGLE-INC.car4.Chicago1.Level3.net (4.71.100.22) 38.132 ms 25.120 ms * 8 * * 209.85.254.122 (209.85.254.122) 24.539 ms 9 * 72.14.237.130 (72.14.237.130) 26.134 ms 72.14.237.108 (72.14.237.108) 25.021 ms MPLS Label=666803 CoS=4 TTL=1 S=1 10 216.239.46.161 (216.239.46.161) 31.816 ms 35.702 ms 32.249 ms 11 72.14.233.142 (72.14.233.142) 32.897 ms * * 12 * yyz06s05-in-f6.1e100.net (74.125.226.6) 33.319 ms * and a ping over the same path: --- www.l.google.com ping statistics --- 675 packets transmitted, 323 packets received, 52.1% packet loss round-trip min/avg/max/stddev = 12.834/28.831/129.743/28.987 ms and at the same time: mark at angola-gw> traceroute 38.100.128.10 traceroute to 38.100.128.10 (38.100.128.10), 30 hops max, 40 byte packets 1 gi1-1.ccr01.tol01.atlas.cogentco.com (38.104.148.5) 4.445 ms 1.841 ms 1.713 ms 2 te7-7.ccr02.cle04.atlas.cogentco.com (154.54.5.230) 5.318 ms te3-2.ccr02.cle04.atlas.cogentco.com (154.54.28.86) 4.755 ms te7-7.ccr02.cle04.atlas.cogentco.com (154.54.5.230) 4.982 ms 3 te4-2.ccr01.pit02.atlas.cogentco.com (154.54.30.10) 7.997 ms te3-2.ccr01.pit02.atlas.cogentco.com (154.54.30.6) 7.736 ms te4-2.ccr01.pit02.atlas.cogentco.com (154.54.30.10) 8.177 ms 4 te0-0-0-5.mpd21.dca01.atlas.cogentco.com (154.54.40.81) 17.197 ms te0-0-0-5.ccr22.dca01.atlas.cogentco.com (154.54.30.230) 16.907 ms te0-0-0-5.mpd21.dca01.atlas.cogentco.com (154.54.40.81) 17.008 ms 5 te0-1-0-0.mpd22.dca01.atlas.cogentco.com (154.54.2.193) 17.358 ms te0-0-0-0.mpd22.dca01.atlas.cogentco.com (154.54.31.38) 17.196 ms te0-1-0-0.mpd22.dca01.atlas.cogentco.com (154.54.2.193) 18.690 ms 6 te4-2.mpd01.iad03.atlas.cogentco.com (154.54.29.122) 17.885 ms * 18.537 ms 7 cogentco.com (38.100.128.10) 17.836 ms !<10> 17.918 ms !<10> 17.833 ms !<10> --- 38.100.128.10 ping statistics --- 236 packets transmitted, 236 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 22.717/27.942/128.011/12.236 ms sh-3.2# Works perfectly. There is no asymmetric routing in this scenario (only 1 BGP peer running during this test), and it is not due to traffic congestion. Initial speculation over the dropped packets in the trace to 74.125.226.6 was ICMP depriortization. The results are too consistent for that to make sense (I have dozens of traceroutes to the same destination - they all appear similar). I realize there is a long history of Cogent/L3 ugliness but I'm pretty sure that this issue has nothing to do with that subject. Traceroutes and pings from the control plane of tol01.atlas sourced from 38.104.148.5 do not show any odd behavior. Inbound traffic (to us) is not affected by this. Our workaround while resolving this issue was to change local-pref on the affected prefixes to send traffic out our other providers. The issue started after a software upgrade to tol01.atlas and resolved after a (reported) reboot of tol01.atlas. The question is: How does a router break in this manner? It appears to unintentionally be doing something different with traffic based on the source address, not the destination address. I realize this can be done intentionally - but that is not the case here (unless somebody isn't telling me something). -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From nicotine at warningg.com Wed Nov 23 08:54:33 2011 From: nicotine at warningg.com (Brandon Ewing) Date: Wed, 23 Nov 2011 08:54:33 -0600 Subject: Contact for Telefonica (AS12956) Message-ID: <20111123145433.GB2742@radiological.warningg.com> Greetings, Can someone put me in contact with someone with clue in the Telefonica backbone? One of their downstreams is hijacking a prefix of mine as a /24. I've also started advertising the /24 to my upstreams, but many Telefonica customers are still seeing the bad route. I tried to check the NOC list at puck.nether.net, but it appears to be down. -- 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 rubensk at gmail.com Wed Nov 23 09:54:32 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 23 Nov 2011 13:54:32 -0200 Subject: Contact for Telefonica (AS12956) In-Reply-To: <20111123145433.GB2742@radiological.warningg.com> References: <20111123145433.GB2742@radiological.warningg.com> Message-ID: On Wed, Nov 23, 2011 at 12:54 PM, Brandon Ewing wrote: > Greetings, > > Can someone put me in contact with someone with clue in the Telefonica > backbone? ?One of their downstreams is hijacking a prefix of mine as a /24. > I've also started advertising the /24 to my upstreams, but many Telefonica > customers are still seeing the bad route. > > I tried to check the NOC list at puck.nether.net, but it appears to be down cic.ipservices.tiws at telefonica.com if they haven't changed it. Rubens From Bryan at bryanfields.net Wed Nov 23 10:14:34 2011 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 23 Nov 2011 11:14:34 -0500 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <4ECC76BA.9090104@west.net> References: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> <4ECC76BA.9090104@west.net> Message-ID: <4ECD1BEA.5030204@bryanfields.net> On 11/22/2011 23:29, Jay Hennigan wrote: > But, an external cracker even with full access won't be able to cause a > conflict. Massive traffic jams by messing with the timing, short or > long cycles, etc. but not a conflict. So really all a hacker needs is a pair of dykes, some electrical tape, and an all black jumpsuit. At 3 am pry open the box and go to work. Bet if they trained at it they could be done in under 5 min. Thank god it's so much easier to just shoot the lights out if you want to be a vandal. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From bstengel at kinber.org Wed Nov 23 10:21:23 2011 From: bstengel at kinber.org (Brian Stengel) Date: Wed, 23 Nov 2011 11:21:23 -0500 Subject: Posting for network engineers and operators... Message-ID: Apologies if this is not appropriate for this list... but I'm looking to hire network engineers for our project and would like to hear what job boards are best for network engineering types to view. I'm not a recruiter. We are looking for positions in Pennsylvania. Dice? Monster? Linked-in? thanks, brian -- Brian Stengel KINBER Director of Operations bstengel at kinber.org M: 412.398.2333 GV: 412.254.3481 Skype: brian_stengel KINBER - Keystone Initiative for Network Based Education and Research - www.kinber.org PennREN - Pennsylvania's Research and Education Network From thomasmcrowe at gmail.com Wed Nov 23 10:20:48 2011 From: thomasmcrowe at gmail.com (Thomas Crowe) Date: Wed, 23 Nov 2011 08:20:48 -0800 Subject: Posting for network engineers and operators... In-Reply-To: References: Message-ID: <4ECD1D60.6090408@gmail.com> Craigslist if the most effective around here. On 11/23/2011 08:21 AM, Brian Stengel wrote: > Apologies if this is not appropriate for this list... but I'm looking to > hire network engineers for our project and would like to hear what job > boards are best for network engineering types to view. I'm not a > recruiter. We are looking for positions in Pennsylvania. Dice? Monster? > Linked-in? > > thanks, > brian > From Valdis.Kletnieks at vt.edu Wed Nov 23 10:23:24 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 23 Nov 2011 11:23:24 -0500 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: Your message of "Wed, 23 Nov 2011 11:14:34 EST." <4ECD1BEA.5030204@bryanfields.net> References: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> <4ECC76BA.9090104@west.net> <4ECD1BEA.5030204@bryanfields.net> Message-ID: <84566.1322065404@turing-police.cc.vt.edu> On Wed, 23 Nov 2011 11:14:34 EST, Bryan Fields said: > So really all a hacker needs is a pair of dykes, some electrical tape, and an > all black jumpsuit. Actually, you want a really dark blue jumpsuit. All-black creates a sillouette in all but the very darkest conditions. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From saku at ytti.fi Wed Nov 23 10:33:23 2011 From: saku at ytti.fi (Saku Ytti) Date: Wed, 23 Nov 2011 18:33:23 +0200 Subject: Odd router brokenness In-Reply-To: <4ECD0604.6020203@amplex.net> References: <4ECD0604.6020203@amplex.net> Message-ID: <20111123163323.GA19075@pob.ytti.fi> On (2011-11-23 09:41 -0500), Mark Radabaugh wrote: > The question is: How does a router break in this manner? It > appears to unintentionally be doing something different with traffic > based on the source address, not the destination address. I > realize this can be done intentionally - but that is not the case > here (unless somebody isn't telling me something). I don't think we can determine that it has anything to do with source address based on data shown. 38.104.148.5 could very well be 6500 and somehow broken adjacency to 74.125.226.6, perhaps hardware adjacency having MTU of 0B, causing punt which is rate-limited by different policer than TTL exceeded policer. -- ++ytti From keegan.holley at sungard.com Wed Nov 23 10:41:34 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Wed, 23 Nov 2011 11:41:34 -0500 Subject: Odd router brokenness In-Reply-To: <20111123163323.GA19075@pob.ytti.fi> References: <4ECD0604.6020203@amplex.net> <20111123163323.GA19075@pob.ytti.fi> Message-ID: 2011/11/23 Saku Ytti > On (2011-11-23 09:41 -0500), Mark Radabaugh wrote: > > > The question is: How does a router break in this manner? It > > appears to unintentionally be doing something different with traffic > > based on the source address, not the destination address. I > > realize this can be done intentionally - but that is not the case > > here (unless somebody isn't telling me something). > > I don't think we can determine that it has anything to do with source > address based on data shown. > 38.104.148.5 could very well be 6500 and somehow broken adjacency to > 74.125.226.6, perhaps hardware adjacency having MTU of 0B, causing punt > which is rate-limited by different policer than TTL exceeded policer. > > > Agree. I've seen similar effects with a different ISP who had one side of an ether-channel go south without the port showing down. Stuff hashed over the good like was fine, stuff hashed over the bad like wasn't. Led to some painful support calls from customers. I agree this list is a haven of speculation and OT comments. In order to avoid making a bad problem worse you should probably contact cogent. From mark at amplex.net Wed Nov 23 10:45:06 2011 From: mark at amplex.net (Mark Radabaugh) Date: Wed, 23 Nov 2011 11:45:06 -0500 Subject: Odd router brokenness In-Reply-To: <20111123163323.GA19075@pob.ytti.fi> References: <4ECD0604.6020203@amplex.net> <20111123163323.GA19075@pob.ytti.fi> Message-ID: <4ECD2312.3040005@amplex.net> On 11/23/11 11:33 AM, Saku Ytti wrote: > On (2011-11-23 09:41 -0500), Mark Radabaugh wrote: > >> The question is: How does a router break in this manner? It >> appears to unintentionally be doing something different with traffic >> based on the source address, not the destination address. I >> realize this can be done intentionally - but that is not the case >> here (unless somebody isn't telling me something). > I don't think we can determine that it has anything to do with source > address based on data shown. > 38.104.148.5 could very well be 6500 and somehow broken adjacency to > 74.125.226.6, perhaps hardware adjacency having MTU of 0B, causing punt > which is rate-limited by different policer than TTL exceeded policer. > I was told the router was reloaded to resolve a CEF issue. Not sure what was wrong with 'clear cef linecard'. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From mark at amplex.net Wed Nov 23 10:47:11 2011 From: mark at amplex.net (Mark Radabaugh) Date: Wed, 23 Nov 2011 11:47:11 -0500 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <84566.1322065404@turing-police.cc.vt.edu> References: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> <4ECC76BA.9090104@west.net> <4ECD1BEA.5030204@bryanfields.net> <84566.1322065404@turing-police.cc.vt.edu> Message-ID: <4ECD238F.8050904@amplex.net> On 11/23/11 11:23 AM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 23 Nov 2011 11:14:34 EST, Bryan Fields said: >> So really all a hacker needs is a pair of dykes, some electrical tape, and an >> all black jumpsuit. > Actually, you want a really dark blue jumpsuit. All-black creates a sillouette in > all but the very darkest conditions. White service truck, orange cone, jeans, heavy cotton shirt and an orange vest in the middle of the day is far less noticeable. -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From rs at seastrom.com Wed Nov 23 10:55:22 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 23 Nov 2011 11:55:22 -0500 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <4ECD238F.8050904@amplex.net> (Mark Radabaugh's message of "Wed, 23 Nov 2011 11:47:11 -0500") References: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> <4ECC76BA.9090104@west.net> <4ECD1BEA.5030204@bryanfields.net> <84566.1322065404@turing-police.cc.vt.edu> <4ECD238F.8050904@amplex.net> Message-ID: <86mxbmaidh.fsf@seastrom.com> Mark Radabaugh writes: > On 11/23/11 11:23 AM, Valdis.Kletnieks at vt.edu wrote: >> On Wed, 23 Nov 2011 11:14:34 EST, Bryan Fields said: >>> So really all a hacker needs is a pair of dykes, some electrical tape, and an >>> all black jumpsuit. >> Actually, you want a really dark blue jumpsuit. All-black creates a sillouette in >> all but the very darkest conditions. > White service truck, orange cone, jeans, heavy cotton shirt and an > orange vest in the middle of the day is far less noticeable. Don't forget the hard hat. Aluminum forms clipboard and Nextel phone complete the outfit but are optional. -r From andy at newslink.com Wed Nov 23 10:57:29 2011 From: andy at newslink.com (Andy Ringsmuth) Date: Wed, 23 Nov 2011 10:57:29 -0600 Subject: Postini or Google contact Message-ID: Any chance there's someone on this list from Google, or more specifically, the Postini portion? We're having some unusual mail blockages coming from one specific domain that Postini has been giving us headaches over for the past few weeks. I've got the logs to verify/help track down the problem, but I've confirmed it is within Postini. Much appreciated. ---- Andy Ringsmuth andy at newslink.com News Link ? Manager Technology 1845 S. 11th St., Lincoln, NE 68502 (402) 475-6397 (402) 304-0083 cellular From leigh.porter at ukbroadband.com Wed Nov 23 11:00:39 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Wed, 23 Nov 2011 17:00:39 +0000 Subject: Odd router brokenness In-Reply-To: <4ECD2312.3040005@amplex.net> References: <4ECD0604.6020203@amplex.net> <20111123163323.GA19075@pob.ytti.fi> <4ECD2312.3040005@amplex.net> Message-ID: > -----Original Message----- > From: Mark Radabaugh [mailto:mark at amplex.net] > Sent: 23 November 2011 16:53 > To: NANOG list > Subject: Re: Odd router brokenness > > On 11/23/11 11:33 AM, Saku Ytti wrote: > > On (2011-11-23 09:41 -0500), Mark Radabaugh wrote: > > > >> The question is: How does a router break in this manner? It > >> appears to unintentionally be doing something different with traffic > >> based on the source address, not the destination address. I > >> realize this can be done intentionally - but that is not the case > >> here (unless somebody isn't telling me something). > > I don't think we can determine that it has anything to do with source > > address based on data shown. > > 38.104.148.5 could very well be 6500 and somehow broken adjacency to > > 74.125.226.6, perhaps hardware adjacency having MTU of 0B, causing > punt > > which is rate-limited by different policer than TTL exceeded policer. > > > I was told the router was reloaded to resolve a CEF issue. Not sure > what was wrong with 'clear cef linecard'. Now *that* brings back memories! -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ From mark at amplex.net Wed Nov 23 11:01:32 2011 From: mark at amplex.net (Mark Radabaugh) Date: Wed, 23 Nov 2011 12:01:32 -0500 Subject: Odd router brokenness In-Reply-To: References: <4ECD0604.6020203@amplex.net> <20111123163323.GA19075@pob.ytti.fi> Message-ID: <4ECD26EC.8030307@amplex.net> On 11/23/11 11:41 AM, Keegan Holley wrote: > 2011/11/23 Saku Ytti > >> On (2011-11-23 09:41 -0500), Mark Radabaugh wrote: >> >>> The question is: How does a router break in this manner? It >>> appears to unintentionally be doing something different with traffic >>> based on the source address, not the destination address. I >>> realize this can be done intentionally - but that is not the case >>> here (unless somebody isn't telling me something). >> I don't think we can determine that it has anything to do with source >> address based on data shown. >> 38.104.148.5 could very well be 6500 and somehow broken adjacency to >> 74.125.226.6, perhaps hardware adjacency having MTU of 0B, causing punt >> which is rate-limited by different policer than TTL exceeded policer. >> >> >> Agree. I've seen similar effects with a different ISP who had one side of > an ether-channel go south without the port showing down. Stuff hashed over > the good like was fine, stuff hashed over the bad like wasn't. Led to some > painful support calls from customers. I agree this list is a haven of > speculation and OT comments. In order to avoid making a bad problem worse > you should probably contact cogent. It's fixed at this point. You are correct in that it was quite painful getting this escalated far enough to get it fixed. The tools that are available (at least that I know of) to try to prove the issue to level 1 and 2 support just doesn't get the job done. It's the eternal problem of convincing L1/2 support that you really have a problem not of your own making. Mark From saku at ytti.fi Wed Nov 23 11:05:19 2011 From: saku at ytti.fi (Saku Ytti) Date: Wed, 23 Nov 2011 19:05:19 +0200 Subject: Odd router brokenness In-Reply-To: <4ECD2312.3040005@amplex.net> References: <4ECD0604.6020203@amplex.net> <20111123163323.GA19075@pob.ytti.fi> <4ECD2312.3040005@amplex.net> Message-ID: <20111123170519.GA19117@pob.ytti.fi> On (2011-11-23 11:45 -0500), Mark Radabaugh wrote: > I was told the router was reloaded to resolve a CEF issue. Not sure > what was wrong with 'clear cef linecard'. Or just fixing the broken prefixes/adjacencies and opening CTAC case about what was wrong with them. http://www.quickmeme.com/meme/35cet6/ -- ++ytti From drais at icantclick.org Wed Nov 23 11:19:25 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 23 Nov 2011 12:19:25 -0500 (EST) Subject: Posting for network engineers and operators... In-Reply-To: References: Message-ID: On Wed, 23 Nov 2011, Brian Stengel wrote: > Apologies if this is not appropriate for this list... but I'm looking to > hire network engineers for our project and would like to hear what job > boards are best for network engineering types to view. I'm not a IME, anyway, none of them. If you're targeting a specific locality, eng/ops groups, linkedin, and craigslist are probably a good start. I dont believe that engineers looking for engineers is offtopic for nanog, either (though the rules may have changed over the years), though if you're open to a more global response. there is a nanog-jobs list, but it has had effectively zero traffic.... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From henry at AegisInfoSys.com Wed Nov 23 11:32:36 2011 From: henry at AegisInfoSys.com (Henry Yen) Date: Wed, 23 Nov 2011 12:32:36 -0500 Subject: Posting for network engineers and operators... In-Reply-To: References: Message-ID: <20111123173236.GG29174@nntp.AegisInfoSys.com> On Wed, Nov 23, 2011 at 11:21:23AM -0500, Brian Stengel wrote: > Apologies if this is not appropriate for this list... but I'm looking to > hire network engineers for our project and would like to hear what job > boards are best for network engineering types to view. I'm not a > recruiter. We are looking for positions in Pennsylvania. Dice? Monster? > Linked-in? Perhaps: List-Id: "This list is for posting job openings in the realm of data and voice networking." List-Help: -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From mikea at mikea.ath.cx Wed Nov 23 11:39:30 2011 From: mikea at mikea.ath.cx (Mike Andrews) Date: Wed, 23 Nov 2011 11:39:30 -0600 Subject: First real-world SCADA attack in US In-Reply-To: References: <26412679.3669.1321935374532.JavaMail.root@benjamin.baylink.com> <20111122135956.GA21368@panix.com> <4ECC295F.3020909@matthew.at> <1322002891.66700.YahooMailNeo@web162102.mail.bf1.yahoo.com> <9EB4F7637A0B42179D72B136488FC1DD@owner59e1f1502> Message-ID: <20111123173930.GA11116@mikea.ath.cx> On Tue, Nov 22, 2011 at 04:00:52PM -0800, Joe Hamelin wrote: > This might be of interest to those wishing to dive deeper into the subject. > > Telecommunications Handbook for Transportation Professionals: The Basics of > Telecommunications by the Federal Highway Administration. > > http://ops.fhwa.dot.gov/publications/telecomm_handbook/ > > I'm still digging through it to see what they say about network security. > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 They don't. Not at all. The most they do say is that on one system, one class of users has RW access to data, while another has RO access. This quote: "Firewall" - is a term used to describe a software application designed to prevent unauthorized access to the initial entry point of a system. is indicative of the level at which the doc is written, and of the intended audience. Worse yet, the dfn. is _*WRONG*_. I work for a state highway department; we take network security a whole lot more seriously than *that*. 73 DE -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From nallgood at telesphere.com Wed Nov 23 11:44:37 2011 From: nallgood at telesphere.com (Nick Allgood) Date: Wed, 23 Nov 2011 09:44:37 -0800 Subject: Posting for network engineers and operators... In-Reply-To: References: Message-ID: I *highly* suggest linkedin as well... myself and other coworkers/friends have gotten our past few jobs from there. The recruiters LOOOVE it and more often than not you're swatting them away more than you're looking for work. --- Nick -----Original Message----- From: david raistrick [mailto:drais at icantclick.org] Sent: Wednesday, November 23, 2011 10:19 AM To: Brian Stengel Cc: nanog at nanog.org Subject: Re: Posting for network engineers and operators... On Wed, 23 Nov 2011, Brian Stengel wrote: > Apologies if this is not appropriate for this list... but I'm looking to > hire network engineers for our project and would like to hear what job > boards are best for network engineering types to view. I'm not a IME, anyway, none of them. If you're targeting a specific locality, eng/ops groups, linkedin, and craigslist are probably a good start. I dont believe that engineers looking for engineers is offtopic for nanog, either (though the rules may have changed over the years), though if you're open to a more global response. there is a nanog-jobs list, but it has had effectively zero traffic.... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From james at freedomnet.co.nz Wed Nov 23 12:39:35 2011 From: james at freedomnet.co.nz (James Jones) Date: Wed, 23 Nov 2011 13:39:35 -0500 Subject: Posting for network engineers and operators... In-Reply-To: <20111123173236.GG29174@nntp.AegisInfoSys.com> References: <20111123173236.GG29174@nntp.AegisInfoSys.com> Message-ID: On Wed, Nov 23, 2011 at 12:32 PM, Henry Yen wrote: > On Wed, Nov 23, 2011 at 11:21:23AM -0500, Brian Stengel wrote: > > Apologies if this is not appropriate for this list... but I'm looking to > > hire network engineers for our project and would like to hear what job > > boards are best for network engineering types to view. I'm not a > > recruiter. We are looking for positions in Pennsylvania. Dice? Monster? > > Linked-in? > > Perhaps: > List-Id: "This list is for posting job openings in the > realm of data and voice networking." > List-Help: > > -- > Henry Yen Aegis Information Systems, > Inc. > Senior Systems Programmer Hicksville, New York > > +1 (I'm the moderator) From jra at baylink.com Wed Nov 23 16:45:08 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 23 Nov 2011 17:45:08 -0500 (EST) Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <4ECC76BA.9090104@west.net> Message-ID: <11179221.140.1322088308090.JavaMail.root@benjamin.baylink.com> > Within each intersection controller is a PC board with a diode matrix > called a "conflict monitor". It has inputs from all of the green and > yellow phases including pedestrian walk signals, turn arrows, etc. > > It's the job of the traffic engineer installing the system to program > the conflict monitor for that intersection. By default they're > programmed for a simple North-South vs. East-West intersection of > two-way streets with pedestrian controls. If anything different, the > conflict monitor is reprogrammed in the field to match the > intersection. > > In the event of a conflict, defined as green, yellow or walk signals > that would cause conflicting traffic being allowed, the conflict monitor > forces the intersection into red flashing in all directions and > disconnects control from the microprocessor until manually reset > on-site. If networked, it also sends a conflict alarm. If the > conflict monitor is removed, the intersection goes to flash. So, while "flash" isn't the default condition, which the controller is taken *out* of by the conflict monitor, that monitor is at least *static logic*, with essentially no moving parts? I can live with that, I guess. > Conflicting green is only possible if the conflict monitor is > mis-programmed or the external connections to the signal heads are > mis-wired. Even a short-circuit in the external wiring between two > green phases would be detected unless the feed wires of the > conflicting phases are cut to the signal box. Got it. > In the real world, "Stuff happens". Trucks cut corners and turn the > traffic heads to point the wrong way. Controllers get replaced with a > stock unit after a failure or accident knocking down the signal box > without being properly set up for that intersection. Yeah. But at least that's stuff you have a hope of managing. "Firmware underwent bit rot" is simply not visible -- unless there's, say, signature tracing through the main controller. > But, an external cracker even with full access won't be able to cause > a conflict. Massive traffic jams by messing with the timing, short or > long cycles, etc. but not a conflict. Which is what I was hoping for: a failure might cause that, but an attack has to be a) local and b) fairly knowledgable. 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 Wed Nov 23 16:52:32 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 23 Nov 2011 17:52:32 -0500 (EST) Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: Message-ID: <11741166.144.1322088752547.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > >> but that's not the only risk. When the traffic > >> signal is failing, even if it's failing with dark or red in every > >> direction, the intersection becomes more dangerous. Not as > >> dangerous as conflicting greens, > > > > By 2 or 3 orders of magnitude, usually; the second thing they teach > > you in driver ed is "a dark traffic signal is a 4-way stop". > > I'm not so sure that's true. (The 2-3 orders of magnitude part). When > I worked ambulance, we responded to a lot more collisions in 4-way > stop intersections and malfunctioning (dark or flashing red) signal > intersections than we did in intersections with conflicting greens. A > whole lot ore, like none of the conflicting greens and many of the > others. Well, sure: what's the *incidence* of conflicting greens? I wasn't suggesting that the incidence of accidents would be any different between conflicting greens and other types of failures (though my intuition is that it would be higher), but that's swamped by how often the condition actually occurs, which, appears to require someone physically running a truck into the control box, or a chain of 5 or 6 failures in cascade to occur, based on other postings on this thread. > As such, I'd say that the probability of a conflicting green occurring > and causing an injury accident is pretty low even with (relatively) > modern digital signal controllers. Yup, it does appear that's true. > >> but more dangerous than a properly operating > >> intersection. If we can eliminate 1000 failures without conflicting > >> greens, at the cost of one failure with a conflicting green, it > >> might be a net win in terms of safety. > > > > The underlying issue is trust, as it so often is. People assume (for > > very good reason) that crossing greens is completely impossible. The > > cost of a crossing-greens accident is *much* higher than might be > > imagined; think "new Coke". > > Sorry, I have trouble understanding how you draw a parallel between a > crossing greens accident and new coke. > > Yes, people assume a crossing greens situation is completely > impossible. People assume a lot of very unlikely things are completely > impossible. Many people think that winning the lottery is completely > impossible for them. A fraction of those people choose not to play on > that basis, rendering that belief basically true. Even with modern > software-controlled signaling, crossing greens events are extremely > uncommon. So much so that I have never actually encountered one. Me neither. This does not forbid me from speculating on it. :-) > I will say that the relative complexity of configuring the software > systems vs. wiring a relay based system to correctly protect a modern > complex intersection would make the relay system inherently > significantly less likely to have completely protected logic. In fact, > it might even be electrically impossible to completely protect the > logic in some modern intersection configurations because they don't > make relays with that many poles. That's a possibility, certainly. It seems an interesting masters project for an electrical engineer. How many zeros can you get into the p number? > Conversely, the software configuration interface is pretty well > abstracted to the level of essentially describing the intersection in > terms of source/destination pairs and paths crossed by each pair. > Short of a serious bug in the overall firmware or the configuration > compiler (for lack of a better term), I'd say that such gross errors > in the configuration of the conflict monitor are pretty unlikely. > Indeed, the history of traffic light malfunctions with digital > controllers would seem to bear this out. The safety record appears to > be pretty good. Yes, but I was aiming more for failure conditions than mis-programming conditions. > So rare, in fact, that traffic light malfunctions do not appear in a > list of traffic accident causes that totaled more than 99% of traffic > accidents when I added up the percentages. I can only assume that > since light malfunctions overall are not a statistically significant > fraction of accidents, conflicting greens must represent an even > smaller and more insignificant fraction. No kidding. That's pleasant to hear. 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 jay at west.net Wed Nov 23 17:16:48 2011 From: jay at west.net (Jay Hennigan) Date: Wed, 23 Nov 2011 15:16:48 -0800 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <11741166.144.1322088752547.JavaMail.root@benjamin.baylink.com> References: <11741166.144.1322088752547.JavaMail.root@benjamin.baylink.com> Message-ID: <4ECD7EE0.6020909@west.net> On 11/23/11 2:52 PM, Jay Ashworth wrote: > Well, sure: what's the *incidence* of conflicting greens? > > I wasn't suggesting that the incidence of accidents would be any different > between conflicting greens and other types of failures (though my intuition > is that it would be higher), but that's swamped by how often the condition > actually occurs, which, appears to require someone physically running a > truck into the control box, or a chain of 5 or 6 failures in cascade to > occur, based on other postings on this thread. Real-world scenario that actually happened: There is an intersection where a majority of the E/W traffic makes left turns to N/S. The signal there has three phases. N/S solid green, East solid green with left arrow (protected left turn) and West with solid green and left arrow. East and West are never green simultaneously, this would be a conflict due to the full phase protected left turns. At some time unknown the controller was replaced and a stock N/S vs. E/W conflict monitor wound up in the box. Nobody owned up to this. (Human error, sloppy procedure, and lack of audit trail.) The programming of the controller was OK, however and the intersection ran just fine. Time passed, probably months. Something glitched the controller and it crashed. This also put the intersection into four-way flash. A somewhat inexperienced technician arrived on scene rebooted the controller and it went back to factory defaults which are N/S vs. E/W. Had the conflict monitor (a circuit board with a diode array, hardware - not software) been correctly programmed for that intersection, it would have kicked back to flash. No problem. But it wasn't. And because the left turn arrows were hard-wired in the signal heads to the same wire as the solid green phase, there was a conflict. Fortunately the technician heard the blaring horns and witnessed a couple of near-misses before an accident occurred. He put the intersection back on flash, dug out the print for the conflict monitor and programming, called for help, and got it fixed. Normally sane defaults in a non-standard configuration, sloppy procedures, and human error coupled with a failure. >From a practical standpoint it is difficult for one person to observe more than one or possibly two phases, especially from the location of the controller which is typically placed a few feet away from the corner so that it gets run over less frequently. >> As such, I'd say that the probability of a conflicting green occurring >> and causing an injury accident is pretty low even with (relatively) >> modern digital signal controllers. > > Yup, it does appear that's true. But it happens. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jra at baylink.com Wed Nov 23 17:38:56 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 23 Nov 2011 18:38:56 -0500 (EST) Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <4ECD7EE0.6020909@west.net> Message-ID: <4141554.162.1322091536559.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Jay Hennigan" > A somewhat inexperienced technician arrived on scene rebooted the > controller and it went back to factory defaults which are N/S vs. E/W. > Had the conflict monitor (a circuit board with a diode array, hardware - > not software) been correctly programmed for that intersection, it > would have kicked back to flash. No problem. > > But it wasn't. > > And because the left turn arrows were hard-wired in the signal heads > to the same wire as the solid green phase, there was a conflict. Oops. > Fortunately the technician heard the blaring horns and witnessed a > couple of near-misses before an accident occurred. He put the > intersection back on flash, dug out the print for the conflict monitor > and programming, called for help, and got it fixed. IME, the near miss count is enough higher than the accident count (that I see; about 10:1 or more) to actually give me some faith in drivers. ;-) > Normally sane defaults in a non-standard configuration, sloppy > procedures, and human error coupled with a failure. Yes: but as Don Norman would ask: *where was the failure here*? You can't blame all of it on the field tech, even though he had the Last Clear Chance to avoid it, if the rest of the system wasn't designed to help protect him (procedures, labeling, packaging, etc...). > From a practical standpoint it is difficult for one person to observe > more than one or possibly two phases, especially from the location of > the controller which is typically placed a few feet away from the > corner so that it gets run over less frequently. This is actually easier these days, since they've started hanging a "red light on" bulb of about 25 watts *under* one fixture in each direction. > >> As such, I'd say that the probability of a conflicting green occurring > >> and causing an injury accident is pretty low even with (relatively) > >> modern digital signal controllers. > > > > Yup, it does appear that's true. > > But it happens. I sort've thought it might. I don't suppose that made the news, since there wasn't an actual collision? 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 jay at west.net Wed Nov 23 18:41:33 2011 From: jay at west.net (Jay Hennigan) Date: Wed, 23 Nov 2011 16:41:33 -0800 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <4141554.162.1322091536559.JavaMail.root@benjamin.baylink.com> References: <4141554.162.1322091536559.JavaMail.root@benjamin.baylink.com> Message-ID: <4ECD92BD.80007@west.net> On 11/23/11 3:38 PM, Jay Ashworth wrote: > Yes: but as Don Norman would ask: *where was the failure here*? You can't > blame all of it on the field tech, even though he had the Last Clear Chance > to avoid it, if the rest of the system wasn't designed to help protect him > (procedures, labeling, packaging, etc...). It, as with most cases of Things That go Horribly Wrong (tm) was not *a* failure but a series of them, none of which by itself would have been particularly significant. > I don't suppose that made the news, since there wasn't an actual collision? Not outside of the Public Works and Risk Management Departments, but it was pretty big news there. The incident resulted in a 100% city-wide audit of all controller and conflict monitor programming by a two-person team as well as the procedure that every conflict monitor board would have a distinctively colored label placed on it with the name of the intersection, the date it was programmed, the name of the person who programmed it, and the name of the person who inspected the programming. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From james.harr at gmail.com Wed Nov 23 19:36:57 2011 From: james.harr at gmail.com (James Harr) Date: Wed, 23 Nov 2011 19:36:57 -0600 Subject: automated config backups for SFTOS In-Reply-To: References: Message-ID: Second rancid. If SFTOS supports per-command authorization (via RADIUS/TACACS), you can limit the script account to only be able to use 'show run' and whatever else it needs (even when it logs in). That said, if you're looking for on-the-cheap, I haven't seen a free TACACS+ server that does authorization and was stable, so you'll probably have to compromise and give your script more permissions than it needs just to get the job done. On Tue, Nov 22, 2011 at 1:40 PM, Jason Biel wrote: > Deploy RANCID? > > On Tue, Nov 22, 2011 at 1:35 PM, Jon Heise wrote: > > > Does anyone know of a method of automating config backups for force10 > > switches running SFTOS ? I've got an python expect script that works on > our > > routers running FTOS, it uses a role account that can show the running > > configs without having to use the enable password. i could expand the > > script to use the enable password but i'm hesitant to have it lying > around > > in a script > > > > Jon Heise > > > > > > -- > Jason > -- ^[:wq^M From rbf+nanog at panix.com Wed Nov 23 19:59:31 2011 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Wed, 23 Nov 2011 19:59:31 -0600 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <11179221.140.1322088308090.JavaMail.root@benjamin.baylink.com> References: <4ECC76BA.9090104@west.net> <11179221.140.1322088308090.JavaMail.root@benjamin.baylink.com> Message-ID: <20111124015931.GA24906@panix.com> On Wed, Nov 23, 2011 at 05:45:08PM -0500, Jay Ashworth wrote: > > Yeah. But at least that's stuff you have a hope of managing. "Firmware > underwent bit rot" is simply not visible -- unless there's, say, signature > tracing through the main controller. I can't speak to traffic light controllers directly, but at least some vital logical controllers do check signatures of their firmware and programming and will fail into a safe configuration if the signatures don't validate. -- Brett From tmaufer at gmail.com Wed Nov 23 20:41:58 2011 From: tmaufer at gmail.com (Thomas Maufer) Date: Wed, 23 Nov 2011 18:41:58 -0800 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <20111124015931.GA24906@panix.com> References: <4ECC76BA.9090104@west.net> <11179221.140.1322088308090.JavaMail.root@benjamin.baylink.com> <20111124015931.GA24906@panix.com> Message-ID: <376A1F3D-49A5-480C-8FA6-4CB28508CA6D@gmail.com> I have to jump in on this thread. Traffic light controllers are a fun category of technical artifacts. The weatherproof boxes that the relays used to live in have stayed the same size for decades, but now the controllers just take a teeny tiny circuit board rattling around in this comparatively huge box. And it's full of software, dontcha know? So why not have lots of newfangled features? Curiously, the people who make the insides of the box have a WHOLE DIFFERENT way of thinking about "what a traffic light controller should do?" - the "insider" people are in the 21st century, while the "outsider" people are in the early 20th century. Lemme splain. A particular traffic light controller that I tested in 2007 had an FTP server inside it. I have no idea why. So I tried fuzzing it. 5 minutes into the test, the test aborted because the DuT wouldn't restart anymore. Upon investigation, we discovered that a particular FTP sequence had triggered a bug that had a rather unfortunate (side-)effect: The flash file system of the traffic light controller was formatted or erased. As a bonus, the device also had crashed and it was awaiting a ZMODEM file download since it didn't have a boot image any more. We couldn't test anything else because we didn't have the special serial cable to (re-)install the OS. Fail-safe? Not hardly: Not when it has no software! It's a lump of highly refined sand, in a plastic case. There are many lessons here, not least of which is: Ship the device with the smallest possible attack surface! Why the heck was FTP enabled? Clearly this device had never been subjected to any negative testing. And these devices are meant to be networked, so that FTP bug will be tickled someday, I just don't know when. Yes, it was reported to the vendor, and no, I have no idea if they ever fixed it. Also, in this thread I have seen several references to "fail-safe" or "redundancy" features. In my experience, those are often some of the weakest aspects of some systems. In one case, I my testing rendered a multi-million-dollar highly redundant VoIP soft switch useless by constantly causing the primary to fail - and while the secondary was being activated, there was a quiet period of 2-3 seconds during which time no calls went through. Shortly after the secondary had become the primary, it failed again, continuing the cycle. Literally traffic amounting to one packet (about 100 bytes, IIRC) per second of carefully crafted SIP INVITES could make this switch completely useless. The bug I found involved SIP INVITE messages that could not be filtered?unless you didn't want to accept VoIP phone calls at all, which calls into question your purchase of the multi-million-dollar highly redundant soft switch. That bug was fixed. Software is tricky stuff. The number of ways it can fail is practically infinite, but there is generally only a small number of ways for it to work correctly. Networked software is particularly challenging to write because the software engineers don't get to control their inputs. The intervening network can (does) fold, spindle, mutilate, truncate, drop, reorder or duplicate packets and your code on the receiving end has to try to understand what was intended by the sender. Oh, and the sender might be following an older version of the standard (if one even exists) or simply have included some bugs of their own. Because the coders are so focused on making their code do what the MRD/PRD required - on a tight schedule! - they have little time to imagine all the possible ways their code might fail. Their error-handling routines are simply never imaginative enough to handle real-world brokenness. It *is* possible to test this stuff, but time pressures in release schedules don't leave a lot of breathing room for developers to take on whole new classes of tasks that are outside their expertise (security testing). So you end up with a traffic light controller that erases its own flash file system when it receives a slightly strange but completely legal FTP command, or a highly redundant VoIP soft switch that is only good at ping-ponging from primary to secondary CPUs. Don't even get me started on problems I have found in carrier-class routers. I don't need to name names: All software has bugs (except possibly the code in the main computers on the Space Shuttle). Every engineer I have ever known has tried to write their code well, but automated negative testing has only recently caught up to where the engineers and QA staff can focus on what they do best (write and test code that implements features that someone can buy), and let purpose-built tools do the negative testing for them, so their error-handling routines can be robust, too. Fixing bugs is generally straightforward. Finding them has always been the challenge. ~tom On 23 Nov 2011, at 17:59 , Brett Frankenberger wrote: > On Wed, Nov 23, 2011 at 05:45:08PM -0500, Jay Ashworth wrote: >> >> Yeah. But at least that's stuff you have a hope of managing. "Firmware >> underwent bit rot" is simply not visible -- unless there's, say, signature >> tracing through the main controller. > > I can't speak to traffic light controllers directly, but at least some > vital logical controllers do check signatures of their firmware and > programming and will fail into a safe configuration if the > signatures don't validate. > > -- Brett > From hmurray at megapathdsl.net Wed Nov 23 21:02:36 2011 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 23 Nov 2011 19:02:36 -0800 Subject: First real-world SCADA attack in US Message-ID: <20111124030236.CD927800037@ip-64-139-1-69.sjc.megapath.net> > Like any of the decades largest breaches this could have been avoided by > following BCP's. In addition SCADA networks are easily protected via > behavioral and signature based security technologies. Is there a BCP that covers security for SCADA? Note that Google for "BCP SCADA" finds BS-25999 Business Continuity Plan Implementation Checklist ... ---------- Suppose a friend of yours was a low-level geek working for either a user/operator of a SCADA system or a vendor of software/hardware for that market. If he asked you for info about security, where would you send him? (Assume he knows all about SCADA but little about networks or security.) For that matter, is there any good security info for small to medium sized businesses? Say a local store, travel agency, or doctor/dentist. -- These are my opinions, not necessarily my employer's. I hate spam. From tvhawaii at shaka.com Wed Nov 23 22:13:12 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Wed, 23 Nov 2011 18:13:12 -1000 Subject: First real-world SCADA attack in US References: <20111124030236.CD927800037@ip-64-139-1-69.sjc.megapath.net> Message-ID: <8A3BC9130F5448F18D01A8330B42A823@owner59e1f1502> Hal Murray wrote: >> Like any of the decades largest breaches this could have been avoided by >> following BCP's. In addition SCADA networks are easily protected via >> behavioral and signature based security technologies. > > Is there a BCP that covers security for SCADA? > > Note that Google for "BCP SCADA" finds > BS-25999 Business Continuity Plan Implementation Checklist ... > > ---------- > > Suppose a friend of yours was a low-level geek working for either a > user/operator of a SCADA system or a vendor of software/hardware for that > market. If he asked you for info about security, where would you send him? > (Assume he knows all about SCADA but little about networks or security.) > > For that matter, is there any good security info for small to medium sized > businesses? Say a local store, travel agency, or doctor/dentist. I'd tell them to go here: http://www.securityfocus.com/ And subscribe to, at least, the Security Basics list and ask their question (s) there. " Security-Basics This list is intended for the discussion of various security issues, all for the security beginner. It is a place to learn the ropes in a non-intimidating environment, and even a place for people who may be experts in one particular field but are looking to increase their knowledge in other areas of information security. The Security-Basics mailing list is meant to assist those responsible for securing individual systems (including their own home computer) and small LANs. This includes but is not limited to small companies, home-based businesses, and home users. This list is designed for people who are not necessarily security experts. As such, it is also an excellent resource for the beginner who wants a non-threatening place to learn the ropes." From Jonathon.Exley at kordia.co.nz Wed Nov 23 22:41:01 2011 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Thu, 24 Nov 2011 04:41:01 +0000 Subject: Network device command line interfaces Message-ID: Does anyone else despair at the CLIs produced by networking vendors? Real routers use a CLI that is command based, like IOS, TiMOS or Junos. These interfaces work well over low bandwidth connections (unlike web interfaces), can work with config backup systems like RANCID, have a (mostly) consistent structure and good show commands. However vendors of low cost routers/switches/muxes seem to take a stab in the dark and produce some really nasty stuff. I have a personal hate of text based menus and binary config backup files. Doe this p*** off anyone else? The business part of the company says "This device is great! It's cheap and does everything." However the poor sap who is given the task to make it work has to wrestle with a badly designed user interface and illogical syntax. Maybe the vendors need some sort of best practices guide for what manageability features their kit needs to support to make them acceptable to the market. Does anyone know if there is anything along these lines? Jonathon. 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 regnauld at nsrc.org Wed Nov 23 22:53:51 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 24 Nov 2011 15:53:51 +1100 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: <20111124045351.GJ33241@macbook.bluepipe.net> Jonathon Exley (Jonathon.Exley) writes: > However vendors of low cost routers/switches/muxes Hi Jonathon, have you ever tried to work with a Catalyst Express 500 ? A good example of a fully functional IOS device, where the vendor went out of their way to disable Telnet/SSH, and force one to run CLI commands via the a Web UI. You can do everything, but even "vty 0 x" and "transport input telnet" won't give access. > seem to take a stab in the dark and produce some really nasty stuff. Cisco isn't exactly low cost, but the point here is exactly that: take away CLI and tools that make automation easier, so that customers will feel compelled to buy the more expensive stuff if they want the fancy stuff (which, in this case, is actually LESS fancy). It's not incompetence, it's called crippleware, and it's a business model :) > Maybe the vendors need some sort > of best practices guide for what manageability features their kit > needs to support to make them acceptable to the market. Does anyone > know if there is anything along these lines? Yes, don't buy the cheap stuff :) Phil From rdobbins at arbor.net Wed Nov 23 22:51:41 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 24 Nov 2011 04:51:41 +0000 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: On Nov 24, 2011, at 11:41 AM, Jonathon Exley wrote: > I have a personal hate of text based menus and binary config backup files. So, the obvious solution is to buy the products of vendors whose CLIs one finds least offensive, is it not? ;> ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From eyeronic.design at gmail.com Wed Nov 23 23:02:38 2011 From: eyeronic.design at gmail.com (Mike Hale) Date: Wed, 23 Nov 2011 21:02:38 -0800 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: If only it were that simple. Try explaining the difference between the blinky lights on a 3750 and the netgear switch to a CFO who has little tech background. On Wed, Nov 23, 2011 at 8:51 PM, Dobbins, Roland wrote: > > On Nov 24, 2011, at 11:41 AM, Jonathon Exley wrote: > > > I have a personal hate of text based menus and binary config backup > files. > > So, the obvious solution is to buy the products of vendors whose CLIs one > finds least offensive, is it not? > > ;> > > ----------------------------------------------------------------------- > Roland Dobbins // > > The basis of optimism is sheer terror. > > -- Oscar Wilde > > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From aftab.siddiqui at gmail.com Wed Nov 23 23:04:30 2011 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Thu, 24 Nov 2011 10:04:30 +0500 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: > However vendors of low cost routers/switches/muxes seem to take a stab in > the dark and produce some really nasty stuff. I have a personal hate of > text based menus and binary config backup files. > Not necessarily it has to be cheap to have text based menus and binary config backups, it can be damn expensive... mmmm remember Alcatel PSAX even their old PABX series.. In our recent encounters with real cheap stuff (switches m routers) the CLI is so much friendly :). Regards, Aftab A. Siddiqui From pelzi at pelzi.net Wed Nov 23 23:11:45 2011 From: pelzi at pelzi.net (Jussi Peltola) Date: Thu, 24 Nov 2011 07:11:45 +0200 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: <20111124051145.GN21062@pokute.pelzi.net> On Thu, Nov 24, 2011 at 04:41:01AM +0000, Jonathon Exley wrote: > Does anyone else despair at the CLIs produced by networking vendors? Yes. > Doe this p*** off anyone else? The business part of the company says > "This device is great! It's cheap and does everything." However the > poor sap who is given the task to make it work has to wrestle with a > badly designed user interface and illogical syntax. Use whatever scaremongering tactics and other necessary creativity to enact a security policy that requires RANCID and anything else you need. Then only purchase equipment that meets said policy. Or just live with it and write perl to get through the worst. Disabling the web UIs completely is not out of the question, then the CLI has to work. Using a web UI without a proper SSL cert is obviously horribly insecure and completely out of the question. SSH has a different model so it is ok. (just spent a morning diffing Fortigate configs. Love their abominable configs that are not really much more useful than a binary blob. Even the interface ordering in the config seems to be random between devices...) From eyeronic.design at gmail.com Wed Nov 23 23:11:56 2011 From: eyeronic.design at gmail.com (Mike Hale) Date: Wed, 23 Nov 2011 21:11:56 -0800 Subject: Posting for network engineers and operators... In-Reply-To: References: <20111123173236.GG29174@nntp.AegisInfoSys.com> Message-ID: I've found craigslist to be a really good source, but be prepared for a terrible signal to noise ratio. The amount of ridiculous apps is crazy. Dice and Monster are good as well, depending on your budget. I've actually been pleasantly surprised by LinkedIn's job postings as well. Find a few good network groups and post the ads there...you should have some decent responses. On Wed, Nov 23, 2011 at 10:39 AM, James Jones wrote: > On Wed, Nov 23, 2011 at 12:32 PM, Henry Yen > wrote: > > > On Wed, Nov 23, 2011 at 11:21:23AM -0500, Brian Stengel wrote: > > > Apologies if this is not appropriate for this list... but I'm looking > to > > > hire network engineers for our project and would like to hear what job > > > boards are best for network engineering types to view. I'm not a > > > recruiter. We are looking for positions in Pennsylvania. Dice? > Monster? > > > Linked-in? > > > > Perhaps: > > List-Id: "This list is for posting job openings in the > > realm of data and voice networking." > > List-Help: > > > > -- > > Henry Yen Aegis Information > Systems, > > Inc. > > Senior Systems Programmer Hicksville, New York > > > > > > +1 (I'm the moderator) > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From mmcbride7 at gmail.com Wed Nov 23 23:17:09 2011 From: mmcbride7 at gmail.com (Mike McBride) Date: Wed, 23 Nov 2011 21:17:09 -0800 Subject: Network device command line interfaces In-Reply-To: <20111124045351.GJ33241@macbook.bluepipe.net> References: <20111124045351.GJ33241@macbook.bluepipe.net> Message-ID: > Yes, don't buy the cheap stuff :) Until we do, the other stuff remains expensive. mike On Wed, Nov 23, 2011 at 8:53 PM, Phil Regnauld wrote: > Jonathon Exley (Jonathon.Exley) writes: >> However vendors of low cost routers/switches/muxes > > ? ? ? ?Hi Jonathon, have you ever tried to work with a Catalyst Express 500 ? > ? ? ? ?A good example of a fully functional IOS device, where the vendor went > ? ? ? ?out of their way to disable Telnet/SSH, and force one to run CLI > ? ? ? ?commands via the a Web UI. ?You can do everything, but even "vty 0 x" > ? ? ? ?and "transport input telnet" won't give access. > >> seem to take a stab in the dark and produce some really nasty stuff. > > ? ? ? ?Cisco isn't exactly low cost, but the point here is exactly that: > ? ? ? ?take away CLI and tools that make automation easier, so that customers > ? ? ? ?will feel compelled to buy the more expensive stuff if they want > ? ? ? ?the fancy stuff (which, in this case, is actually LESS fancy). > > ? ? ? ?It's not incompetence, it's called crippleware, and it's a business > ? ? ? ?model :) > >> Maybe the vendors need some sort >> of best practices guide for what manageability features their kit >> needs to support to make them acceptable to the market. Does anyone >> know if there is anything along these lines? > > ? ? ? ?Yes, don't buy the cheap stuff :) > > ? ? ? ?Phil > > From paul4004 at gmail.com Thu Nov 24 01:06:10 2011 From: paul4004 at gmail.com (PC) Date: Thu, 24 Nov 2011 00:06:10 -0700 Subject: Posting for network engineers and operators... In-Reply-To: References: <20111123173236.GG29174@nntp.AegisInfoSys.com> Message-ID: The SNR on craigslist goes both ways, for both the applicant and the employer. There are also lots of terrible job ads, and a large tendency for employers to not list their identity. Sure, some are just recruiters hiding their client's identity, but the mandatory identifying fields aren't there like the other job sites. I always want to know who the employer is before I apply. Additionally, in certain cities, there's some really bad employers who post there because they can't afford to post anywhere else, and it shows in the job offers. I think CL can work well if you write a complete and proper job ad like you find on most of the pay boards. Any hey it's free! However, other avenues (such as Linkedin), generally charge some minimal price for admission, and to the applicant this means the company is at least serious in their recruiting and not just testing the waters. On Wed, Nov 23, 2011 at 10:11 PM, Mike Hale wrote: > I've found craigslist to be a really good source, but be prepared for a > terrible signal to noise ratio. The amount of ridiculous apps is crazy. > > Dice and Monster are good as well, depending on your budget. > > I've actually been pleasantly surprised by LinkedIn's job postings as > well. Find a few good network groups and post the ads there...you should > have some decent responses. > On Wed, Nov 23, 2011 at 10:39 AM, James Jones >wrote: > > > On Wed, Nov 23, 2011 at 12:32 PM, Henry Yen > > wrote: > > > > > On Wed, Nov 23, 2011 at 11:21:23AM -0500, Brian Stengel wrote: > > > > Apologies if this is not appropriate for this list... but I'm looking > > to > > > > hire network engineers for our project and would like to hear what > job > > > > boards are best for network engineering types to view. I'm not a > > > > recruiter. We are looking for positions in Pennsylvania. Dice? > > Monster? > > > > Linked-in? > > > > > > Perhaps: > > > List-Id: "This list is for posting job openings in the > > > realm of data and voice networking." > > > List-Help: ?subject=help> > > > > > > -- > > > Henry Yen Aegis Information > > Systems, > > > Inc. > > > Senior Systems Programmer Hicksville, New York > > > > > > > > > > +1 (I'm the moderator) > > > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > From morrowc.lists at gmail.com Thu Nov 24 11:03:25 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 24 Nov 2011 12:03:25 -0500 Subject: automated config backups for SFTOS In-Reply-To: References: Message-ID: On Wed, Nov 23, 2011 at 8:36 PM, James Harr wrote: > Second rancid. +3 > If SFTOS supports per-command authorization (via RADIUS/TACACS), you can it does > limit the script account to only be able to use 'show run' and whatever > else it needs (even when it logs in). > you can > That said, if you're looking for on-the-cheap, I haven't seen a free > TACACS+ server that does authorization and was stable, so you'll probably > have to compromise and give your script more permissions than it needs just > to get the job done. the cisco tacplus src server is a basic example... shrubbery.net's tacplus server is quite workable (and heasley keeps the code working/clean/adding-features) a simple config for 'just permit show run' is certainly possible with the shrubbery.net server... if you want example config pipe up. -chris > On Tue, Nov 22, 2011 at 1:40 PM, Jason Biel wrote: > >> Deploy RANCID? >> >> On Tue, Nov 22, 2011 at 1:35 PM, Jon Heise wrote: >> >> > Does anyone know of a method of automating config backups for force10 >> > switches running SFTOS ? I've got an python expect script that works on >> our >> > routers running FTOS, it uses a role account that can show the running >> > configs without having to use the enable password. ?i could expand the >> > script to use the enable password but i'm hesitant to have it lying >> around >> > in a script >> > >> > Jon ?Heise >> > >> >> >> >> -- >> Jason >> > > > > -- > ^[:wq^M > From morrowc.lists at gmail.com Thu Nov 24 11:04:45 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 24 Nov 2011 12:04:45 -0500 Subject: automated config backups for SFTOS In-Reply-To: References: Message-ID: On Thu, Nov 24, 2011 at 12:03 PM, Christopher Morrow wrote: > On Wed, Nov 23, 2011 at 8:36 PM, James Harr wrote: >> Second rancid. > > +3 > >> If SFTOS supports per-command authorization (via RADIUS/TACACS), you can > > it does > >> limit the script account to only be able to use 'show run' and whatever >> else it needs (even when it logs in). >> > > you can > >> That said, if you're looking for on-the-cheap, I haven't seen a free >> TACACS+ server that does authorization and was stable, so you'll probably >> have to compromise and give your script more permissions than it needs just >> to get the job done. > > the cisco tacplus src server is a basic example... > shrubbery.net's tacplus server is quite workable (and heasley keeps > the code working/clean/adding-features) > > a simple config for 'just permit show run' is certainly possible with > the shrubbery.net server... if you want example config pipe up. I should have included: and there are some decent example configs available (I think john payne had some posted/updated, this query seems to show a bunch of positive results: > -chris > >> On Tue, Nov 22, 2011 at 1:40 PM, Jason Biel wrote: >> >>> Deploy RANCID? >>> >>> On Tue, Nov 22, 2011 at 1:35 PM, Jon Heise wrote: >>> >>> > Does anyone know of a method of automating config backups for force10 >>> > switches running SFTOS ? I've got an python expect script that works on >>> our >>> > routers running FTOS, it uses a role account that can show the running >>> > configs without having to use the enable password. ?i could expand the >>> > script to use the enable password but i'm hesitant to have it lying >>> around >>> > in a script >>> > >>> > Jon ?Heise >>> > >>> >>> >>> >>> -- >>> Jason >>> >> >> >> >> -- >> ^[:wq^M >> > From Jonathon.Exley at kordia.co.nz Thu Nov 24 13:58:01 2011 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Thu, 24 Nov 2011 19:58:01 +0000 Subject: Network device command line interfaces In-Reply-To: References: , Message-ID: That's the problem - as a propellorhead I don't make the purchasing decisions. I can recommend products but low cost speaks more loudly than "this gear is a dog to work with". I don't really believe that manufacturers make crippleware user interfaces for thier products to encourage people to buy a more expensive range. I am more inclined to think that the software developers didn't have a good requirements spec to work from and made it up off thier own back. With the wealth of experience of people using these devices in this forum, maybe we could collate some good advice on what features of a UI are really important. Hopefully there are some manufactures listening who can take the advice on board for the next product they develop. Jonathon On 24/11/2011, at 18:04, "Mike Hale" wrote: > If only it were that simple. > > Try explaining the difference between the blinky lights on a 3750 and the > netgear switch to a CFO who has little tech background. > On Wed, Nov 23, 2011 at 8:51 PM, Dobbins, Roland wrote: > >> >> On Nov 24, 2011, at 11:41 AM, Jonathon Exley wrote: >> >>> I have a personal hate of text based menus and binary config backup >> files. >> >> So, the obvious solution is to buy the products of vendors whose CLIs one >> finds least offensive, is it not? >> >> ;> >> >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> The basis of optimism is sheer terror. >> >> -- Oscar Wilde >> >> >> > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 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 joelja at bogus.com Thu Nov 24 14:09:09 2011 From: joelja at bogus.com (Joel jaeggli) Date: Thu, 24 Nov 2011 12:09:09 -0800 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4ECEA465.1060606@bogus.com> On 11/21/11 14:18 , Nathan Eisenberg wrote: >> Look at the number that are refusing to make generous prefix >> allocations >> to residential end users and limiting them to /56, /60, or even worse, >> /64. > > Owen, > > What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? prefix delegation to a downstream device via dhcp-pd > Nathan > > > From seth.mos at dds.nl Thu Nov 24 14:37:49 2011 From: seth.mos at dds.nl (Seth Mos) Date: Thu, 24 Nov 2011 21:37:49 +0100 Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <4ECEA465.1060606@bogus.com> References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> <4ECEA465.1060606@bogus.com> Message-ID: <85B193CD-CE25-431E-9E52-A93F74053E34@dds.nl> Hi, Op 24 nov 2011, om 21:09 heeft Joel jaeggli het volgende geschreven: > On 11/21/11 14:18 , Nathan Eisenberg wrote: >>> Look at the number that are refusing to make generous prefix >>> allocations >>> to residential end users and limiting them to /56, /60, or even worse, >>> /64. >> >> Owen, >> >> What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? > > prefix delegation to a downstream device via dhcp-pd Joe Sixpack might not even realize that his device even does this. I actually added a dhcpv6 server that can do just this. Still considering if it should do that automatically. Contrary to proper networking, I frequently see double nat routers because they purchased a new wifi routers which is then daisy chained to the old one. Or they had a non-wifi model and plugged in the port labeled (internet) of the new wifi router into the existing one. Which is more common. With dhcp-pd in each, you could daisy chain a few times before it gives out. You know what, let's just build that because I can, it's a few hours of coding, but nothing too serious. Most hooks are already in place. I just didn't start a dhcpdv6 automatically yet. In a nutshell. Yes, Please. Regards, Seth From dougb at dougbarton.us Thu Nov 24 15:06:27 2011 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 24 Nov 2011 13:06:27 -0800 Subject: Network device command line interfaces In-Reply-To: References: , Message-ID: <4ECEB1D3.2070207@dougbarton.us> On 11/24/2011 11:58, Jonathon Exley wrote: > That's the problem - as a propellorhead I don't make the purchasing decisions. I can recommend products but low cost speaks more loudly than "this gear is a dog to work with". That's where you get a chance to impress the business folks by using terms like "total cost of ownership." You make the case that while product X may have a higher capex, that's a one-time expense that can be amortized and/or depreciated. Whereas the opex for product Y is going to be higher for the life of the thing. Make sure to tart up your estimate by including the developer costs of the tools you will need to verify that changes are correct and/or disaster recovery because everyone is human, and the horrible UI magnifies the likelihood of an "innocent" fat-finger mistake turning into a complete meltdown (or worse, a security hole that no one sees until it's too late). Of course I'm just throwing stuff against the wall here since I don't know exactly what tools you're talking about, but if your PHBs have any clue at all they will understand your point if you can put it into their language. Look at it this way. Think of how hard you have to fight the urge to wince in pain when one of your PHBs start describing the wonders of some new technological marvel ... "We simply must have this new widget I read about in AAdvantage magazine." That's exactly how they feel most of the time when we try to talk to them about why product Y is "better" even though it's more expensive. hth, Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From rs at seastrom.com Thu Nov 24 18:16:33 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 24 Nov 2011 19:16:33 -0500 Subject: Network device command line interfaces In-Reply-To: <4ECEB1D3.2070207@dougbarton.us> (Doug Barton's message of "Thu, 24 Nov 2011 13:06:27 -0800") References: <4ECEB1D3.2070207@dougbarton.us> Message-ID: <868vn5f44e.fsf@seastrom.com> Doug Barton writes: > On 11/24/2011 11:58, Jonathon Exley wrote: >> That's the problem - as a propellorhead I don't make the purchasing decisions. I can recommend products but low cost speaks more loudly than "this gear is a dog to work with". > > That's where you get a chance to impress the business folks by using > terms like "total cost of ownership." You make the case that while > product X may have a higher capex, that's a one-time expense that can be > amortized and/or depreciated. Whereas the opex for product Y is going to > be higher for the life of the thing. Make sure to tart up your estimate > by including the developer costs of the tools you will need to verify > that changes are correct and/or disaster recovery because everyone is > human, and the horrible UI magnifies the likelihood of an "innocent" > fat-finger mistake turning into a complete meltdown (or worse, a > security hole that no one sees until it's too late). What Doug said. Also, don't forget the value of letting the decision makers know the worst-case. It's not really FUD if you're just opening their eyes to the consequences of their buying decisions. For instance, if you can't back the config of the device up in a human-readable/mergeable format (or worse yet, can't back it up _at all_), consider the cost per hour of downtime on a 24 port switch with a bunch of random office workers connected whose fully loaded hourly cost (including cost of office space, health insurance, employer part of FICA, etc) is, um, let's be cheap and say $40/hour. Funny how this puts the cost of both CLI-based stuff *and on-site spares* in perspective. "We can't buy it if I can't back it up with RANCID because of the negative impact it has on our business continuity" is a good way to put this into terms that the folks who hold the purse strings can understand. -r From keegan.holley at sungard.com Thu Nov 24 21:12:06 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 24 Nov 2011 22:12:06 -0500 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: I may have a different opinion here, but I not sure I'd call any CLI easy to work with. Cisco's training machine is so efficient that some learn IOS before leaving high school, so the fact that we all consider IOS easy to work with is relative. Just look at the "router" command. Most of us know that this is cisco's way of enabling protocols, but I would hardly call this intuitive if I didn't know it already. Then it's different for each protocol. So "router BGP #" starts the BGP process and sets your local AS number (very important). "router eigrp #" starts eigrp and sets a different AS number that doesn't really count (also important). "router ospf #" just sets a process ID in case you want to run multiple instances. There's also a config mode autonomous-system command but that only counts if your running EGP which is still in the CLI but isn't supported and doesn't start. Then there's all the different things you can/must do with access-lists because they were too lazy to code a different sort of filter. Remember CBAC? Did I mention this is the CLI we like? I don't mind wrestling with a new CLI because it's all relative. Most have read at least one cisco book and probably one juniper book so those CLI's are considered standard and all their sins are forgiven. Most of us have not gone through, training with extreme, enterasys, 3COM, netgear, foundry, fortigate, etc. etc. etc. So those become the PITA CLI's and suddenly non-standard commands and bad help menus become a crime again. I do find text-based menus obnoxious, unless it's a linux box and the text menu is a curses interface. In that case it's super-cool and I'm even willing to play games with text based menus. 2011/11/23 Jonathon Exley > Does anyone else despair at the CLIs produced by networking vendors? > Real routers use a CLI that is command based, like IOS, TiMOS or Junos. > These interfaces work well over low bandwidth connections (unlike web > interfaces), can work with config backup systems like RANCID, have a > (mostly) consistent structure and good show commands. > However vendors of low cost routers/switches/muxes seem to take a stab in > the dark and produce some really nasty stuff. I have a personal hate of > text based menus and binary config backup files. > Doe this p*** off anyone else? The business part of the company says "This > device is great! It's cheap and does everything." However the poor sap who > is given the task to make it work has to wrestle with a badly designed user > interface and illogical syntax. > Maybe the vendors need some sort of best practices guide for what > manageability features their kit needs to support to make them acceptable > to the market. Does anyone know if there is anything along these lines? > > > Jonathon. > > > 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 tkapela at gmail.com Thu Nov 24 21:26:09 2011 From: tkapela at gmail.com (Anton Kapela) Date: Thu, 24 Nov 2011 21:26:09 -0600 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: Message-ID: On Sun, Nov 20, 2011 at 8:40 PM, Tyler Haske wrote: > I'm looking for a mentor who can help me focus my career so eventually I > wind up working at one of the Tier I ISPs as a senior tech. I want to > handle the big pipes that hold everyone's data. Replying on-list, as I think a route for this desired target can be neatly summarized (oh, networking term!) in the following list: 1) be 2) do 3) have First, start by being the sort of person that might work at these places. Don't know how or who they "are?" -- meet a few, interview them, ask about their life, attent NANOG (student rate: $100/meeting) and have a drink or three with them, etc. Next, do the things they do--this may take a while. Finally, you can 'have' whatever they are having once you've traversed 1) and 2), assuming there's a spot on the far-side of this bet. You can thank Janet Plato (a great ex-Ann Arbor/ANS person) for this method. I hope she doesn't mind my paraphrasing here. Best, -Tk From Jonathon.Exley at kordia.co.nz Thu Nov 24 22:38:23 2011 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Fri, 25 Nov 2011 04:38:23 +0000 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: Yeah, I guess Cisco IOS isn't that good an example of a consistent syntax. Others do it better - Junos sets the ASN with the 'routing-options autonomous-system' command, and TiMOS uses 'router autonomous-system' My rant wasn't about having to deal with new CLIs but about the lack of CLIs in those devices that seem to prefer menu based UIs (text or web), and CLIs that have nasty commands. Check this out: add flow fid-5-5 EVC-30600-Data codefault enable multi swap 99968000 100032000 1024 1024 5000 ctag push 15-0 stag none Now what does that string of numbers mean? It's the Adva 825 way of specifying the CIR and EIR for a flow but I can never remember what each position represents. Compare this to TiMOS: sap-ingress 93 create description "Test LNS" queue 1 create rate 2000 mbs 25 kilobytes exit This creates a queue with max rate 2000 kbit/s and a max burst size of 25 kB. It's much easier to read than the Adva config, because each parameter is labelled. The Adva CLI isn't actually all that bad, but it's possible that had their developers had some sort of usability guide when they wrote the OS then they might have done things better. I was hoping that there was already some sort of usability guide around that could be shown to the manufacturers with a "please read this" note attached. Is anyone aware of such a thing? Jonathon. From: Keegan Holley [mailto:keegan.holley at sungard.com] Sent: Friday, 25 November 2011 4:12 p.m. To: Jonathon Exley Cc: nanog at nanog.org Subject: Re: Network device command line interfaces I may have a different opinion here, but I not sure I'd call any CLI easy to work with. Cisco's training machine is so efficient that some learn IOS before leaving high school, so the fact that we all consider IOS easy to work with is relative. Just look at the "router" command. Most of us know that this is cisco's way of enabling protocols, but I would hardly call this intuitive if I didn't know it already. Then it's different for each protocol. So "router BGP #" starts the BGP process and sets your local AS number (very important). "router eigrp #" starts eigrp and sets a different AS number that doesn't really count (also important). "router ospf #" just sets a process ID in case you want to run multiple instances. There's also a config mode autonomous-system command but that only counts if your running EGP which is still in the CLI but isn't supported and doesn't start. Then there's all the different things you can/must do with access-lists because they were too lazy to code a different sort of filter. Remember CBAC? Did I mention this is the CLI we like? I don't mind wrestling with a new CLI because it's all relative. Most have read at least one cisco book and probably one juniper book so those CLI's are considered standard and all their sins are forgiven. Most of us have not gone through, training with extreme, enterasys, 3COM, netgear, foundry, fortigate, etc. etc. etc. So those become the PITA CLI's and suddenly non-standard commands and bad help menus become a crime again. I do find text-based menus obnoxious, unless it's a linux box and the text menu is a curses interface. In that case it's super-cool and I'm even willing to play games with text based menus. 2011/11/23 Jonathon Exley > Does anyone else despair at the CLIs produced by networking vendors? Real routers use a CLI that is command based, like IOS, TiMOS or Junos. These interfaces work well over low bandwidth connections (unlike web interfaces), can work with config backup systems like RANCID, have a (mostly) consistent structure and good show commands. However vendors of low cost routers/switches/muxes seem to take a stab in the dark and produce some really nasty stuff. I have a personal hate of text based menus and binary config backup files. Doe this p*** off anyone else? The business part of the company says "This device is great! It's cheap and does everything." However the poor sap who is given the task to make it work has to wrestle with a badly designed user interface and illogical syntax. Maybe the vendors need some sort of best practices guide for what manageability features their kit needs to support to make them acceptable to the market. Does anyone know if there is anything along these lines? Jonathon. 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). 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 keegan.holley at sungard.com Thu Nov 24 22:51:05 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Thu, 24 Nov 2011 23:51:05 -0500 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: <36E5E019-9FA7-49B1-8FDD-15ED17D09B80@sungard.com> That's kinda what I was talking about. That command isn't that bad actually. MQC and juniper firewall filters (in set mode) are no simpler. The annoying part is the obscurity. Sent from my iPhone On Nov 24, 2011, at 11:38 PM, Jonathon Exley wrote: > Yeah, I guess Cisco IOS isn't that good an example of a consistent syntax. Others do it better - Junos sets the ASN with the 'routing-options autonomous-system' command, and TiMOS uses 'router autonomous-system' > > My rant wasn't about having to deal with new CLIs but about the lack of CLIs in those devices that seem to prefer menu based UIs (text or web), and CLIs that have nasty commands. Check this out: > > add flow fid-5-5 EVC-30600-Data codefault enable multi swap 99968000 100032000 1024 1024 5000 ctag push 15-0 stag none > > Now what does that string of numbers mean? It's the Adva 825 way of specifying the CIR and EIR for a flow but I can never remember what each position represents. > > Compare this to TiMOS: > > > sap-ingress 93 create > > description "Test LNS" > > queue 1 create > > rate 2000 > > mbs 25 kilobytes > > exit > > This creates a queue with max rate 2000 kbit/s and a max burst size of 25 kB. It's much easier to read than the Adva config, because each parameter is labelled. > > The Adva CLI isn't actually all that bad, but it's possible that had their developers had some sort of usability guide when they wrote the OS then they might have done things better. > > I was hoping that there was already some sort of usability guide around that could be shown to the manufacturers with a "please read this" note attached. Is anyone aware of such a thing? > > > Jonathon. > > > From: Keegan Holley [mailto:keegan.holley at sungard.com] > Sent: Friday, 25 November 2011 4:12 p.m. > To: Jonathon Exley > Cc: nanog at nanog.org > Subject: Re: Network device command line interfaces > > I may have a different opinion here, but I not sure I'd call any CLI easy to work with. Cisco's training machine is so efficient that some learn IOS before leaving high school, so the fact that we all consider IOS easy to work with is relative. Just look at the "router" command. Most of us know that this is cisco's way of enabling protocols, but I would hardly call this intuitive if I didn't know it already. Then it's different for each protocol. So "router BGP #" starts the BGP process and sets your local AS number (very important). "router eigrp #" starts eigrp and sets a different AS number that doesn't really count (also important). "router ospf #" just sets a process ID in case you want to run multiple instances. There's also a config mode autonomous-system command but that only counts if your running EGP which is still in the CLI but isn't supported and doesn't start. Then there's all the different things you can/must do with access-lists because they were too lazy to code a different sort of filter. Remember CBAC? Did I mention this is the CLI we like? I don't mind wrestling with a new CLI because it's all relative. Most have read at least one cisco book and probably one juniper book so those CLI's are considered standard and all their sins are forgiven. Most of us have not gone through, training with extreme, enterasys, 3COM, netgear, foundry, fortigate, etc. etc. etc. So those become the PITA CLI's and suddenly non-standard commands and bad help menus become a crime again. I do find text-based menus obnoxious, unless it's a linux box and the text menu is a curses interface. In that case it's super-cool and I'm even willing to play games with text based menus. > > 2011/11/23 Jonathon Exley > > Does anyone else despair at the CLIs produced by networking vendors? > Real routers use a CLI that is command based, like IOS, TiMOS or Junos. These interfaces work well over low bandwidth connections (unlike web interfaces), can work with config backup systems like RANCID, have a (mostly) consistent structure and good show commands. > However vendors of low cost routers/switches/muxes seem to take a stab in the dark and produce some really nasty stuff. I have a personal hate of text based menus and binary config backup files. > Doe this p*** off anyone else? The business part of the company says "This device is great! It's cheap and does everything." However the poor sap who is given the task to make it work has to wrestle with a badly designed user interface and illogical syntax. > Maybe the vendors need some sort of best practices guide for what manageability features their kit needs to support to make them acceptable to the market. Does anyone know if there is anything along these lines? > > > Jonathon. > > > 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). > > 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 bonomi at mail.r-bonomi.com Thu Nov 24 23:01:21 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 24 Nov 2011 23:01:21 -0600 (CST) Subject: Network device command line interfaces In-Reply-To: Message-ID: <201111250501.pAP51LVT015635@mail.r-bonomi.com> Jonathon Exley wrote; > > That's the problem - as a propellorhead I don't make the purchasing decisi > ons. I can recommend products but low cost speaks more loudly than "this g > ear is a dog to work with". > I don't really believe that manufacturers make crippleware user interfaces > for thier products to encourage people to buy a more expensive range. I a > m more inclined to think that the software developers didn't have a good r > eq uirements spec to work from and made it up off thier own back. > With the wealth of experience of people using these devices in this forum, > maybe we could collate some good advice on what features of a UI are real > ly important. > Hopefully there are some manufactures listening who can take the advice on > board for the next product they develop. > The trick to deailing with this as a propellorhead[sic] is to include a *monetized* estimate of the increased manpower OPEX of using the 'dog to work with' box. And a TCOS figure over the projected lifetime of the units. No need to 'fight' with management about it, just understand 'how' they make the decisions, and give them the informatin they need to make the decision come out 'your way'. Aside -- on your other point, there are *many* _documented_ cases of manufactuers deliberately crippling certain features so as to not cannibalize the sales of higher-riced units. IBM was medium-notorious for this. The original IBM-PC keyboard had 'non- standard' positioning for several keys (the extra key between 'z' and 'left shift', the location of 'caps lock', and the bastardized shape/position of 'enter') -- *expressly* to discourage using a PC in place of a dedicated higher-priced IBM 'word processor' (the Displaaywriter ??). Also, the PCjr used the _same_ floppy-controller chip as it's big brothers, *BUT* the interrupt line was not connected, and _extra_ hardware had to be included in the to compensate for the failure to use the interrupt. This was done exprerssly to cripple performance -- so it was useful only for hobby/game use, and not for any 'real' work (i.e. couldn't do serial I/O _while_ any floppy I/O was in prgress. To do file transfers, it took custom code that would 'suspend' the serial port operation while reading/writing the floppy, and then 'resume' it after the floppy operation was complete. There is absolutely no doubt that this was a deliberate 'crippleware' design, given that they had to -add- extra hardware, vs doing it the 'compatible' way. Yup, they deliberately spent extra money to make it 'incompatible'. From mohacsi at niif.hu Fri Nov 25 02:37:20 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 25 Nov 2011 09:37:20 +0100 (CET) Subject: Dynamic (changing) IPv6 prefix delegation In-Reply-To: <85B193CD-CE25-431E-9E52-A93F74053E34@dds.nl> References: <4ECA6C97.6030208@dds.nl> <77E49D81-4651-40ED-8565-ED8498E56652@delong.com> <8C26A4FDAE599041A13EB499117D3C286B5FCF0C@ex-mb-1.corp.atlasnetworks.us> <4ECEA465.1060606@bogus.com> <85B193CD-CE25-431E-9E52-A93F74053E34@dds.nl> Message-ID: On Thu, 24 Nov 2011, Seth Mos wrote: > Hi, > > Op 24 nov 2011, om 21:09 heeft Joel jaeggli het volgende geschreven: > >> On 11/21/11 14:18 , Nathan Eisenberg wrote: >>>> Look at the number that are refusing to make generous prefix >>>> allocations >>>> to residential end users and limiting them to /56, /60, or even worse, >>>> /64. >>> >>> Owen, >>> >>> What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? >> >> prefix delegation to a downstream device via dhcp-pd > > Joe Sixpack might not even realize that his device even does this. I actually added a dhcpv6 server that can do just this. Still considering if it should do that automatically. > > Contrary to proper networking, I frequently see double nat routers > because they purchased a new wifi routers which is then daisy chained to > the old one. Or do bridging. > > Or they had a non-wifi model and plugged in the port labeled (internet) > of the new wifi router into the existing one. Which is more common. > > With dhcp-pd in each, you could daisy chain a few times before it gives > out. You know what, let's just build that because I can, it's a few > hours of coding, but nothing too serious. Most hooks are already in > place. I just didn't start a dhcpdv6 automatically yet. > > In a nutshell. Yes, Please. > > Regards, > > Seth > From jcdill.lists at gmail.com Fri Nov 25 09:54:38 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 25 Nov 2011 08:54:38 -0700 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> Message-ID: <4ECFBA3E.1020403@gmail.com> On 22/11/11 10:46 AM, Matthew Petach wrote: > And then start experimenting and breaking things--some of your best > understanding is going to come from breaking your setup when > experimenting, and then figuring out why it broke, and how to get it > working again in the way you want. Debugging dual-stack networks is > going to be required knowledge by the time you hit the industry; no > reason not to start learning and using the information today, to > really get comfortable with it.) I know I'm days late replying into this thread, but I wanted to highlight and emphasize this comment. IMHO, the people who are most in demand are those who know how to fix stuff when someone else does something bone-headed and then can't fix it themselves and it gets bumped up the ladder to someone with super debugging skills who can fix it. So don't hesitate to do bone-headed things to break your setup, and then figure out how to fix it. +2 on working with dual-stacks and knowing everything you can about ipv6. From the questions we see here on nanog it's clear that there are a whole lot of people who should know more about how ipv6 works (and how to integrate it into an ipv4 network) but don't. When you graduate and are looking for that first job, you will likely come across a hiring manager who should know more about ipv6 but doesn't yet, and if you can position yourself as the person who can help with solving the ipv6 knowledge gap in that organization it could put you above other candidates with more "experience" but who don't know anything about ipv6, and get you that job. jc From jmaslak at antelope.net Fri Nov 25 10:15:28 2011 From: jmaslak at antelope.net (Joel Maslak) Date: Fri, 25 Nov 2011 11:15:28 -0500 Subject: Network device command line interfaces In-Reply-To: <201111250501.pAP51LVT015635@mail.r-bonomi.com> References: <201111250501.pAP51LVT015635@mail.r-bonomi.com> Message-ID: On Fri, Nov 25, 2011 at 12:01 AM, Robert Bonomi wrote: > The trick to deailing with this as a propellorhead[sic] is to include a > *monetized* estimate of the increased manpower OPEX of using the 'dog to > work with' box. And a TCOS figure over the projected lifetime of the > units. No need to 'fight' with management about it, just understand > 'how' they make the decisions, and give them the informatin they need > to make the decision come out 'your way'. > I'd say that the ethical thing to do is to give them the information they need to make a decision, not to get it your way. I see, for instance, people buying local closet switches from brand A when brand B is much, much cheaper (but lacks the prestige of brand A), had a perfectly workable management interface, and will perform identically, with similar support offered by both vendors. But they are an ACNA or whatever, or they've just heard of (insert brand here), so they buy it. Because it's easy and familiar. It's also possible that a web managed switch (which I despise) might actually be the right choice for a business - because factors other than a technologist's distaste might be important. Part of being ethical (and NOT like the business people we might all despise!) is to be honest. So we don't compare brand A to brand B unfairly. We don't inflate the cost of brand B by adding brand B's management infrastructure to the cost when we darn well know we just will need a minor tweak to our scripts that can already manage brand A. That sort of thing. I generally agree with what Robert said: It's about what makes sense to the business. If operating expenses will increase ("Well have to grow headcount by 3 to support this"), then bring that up. A caution though: "Takes less effort to run" doesn't equate to dollars (the question a former manager would ask me when I tried that line was, "So who do you think we should lay off then to get the dollar savings?" Fortunately he was a good manager who wasn't serious, but was rather trying to get me to think about what I'm saying). I like paychecks, which is why I work for a living - it's about the dollars. So it's not unreasonable for my management to also care about the money (since it's a key motivation for myself, after all!). Yes, I'm fortunate to do a job I love and get paid for it at the same time. I can say, for a CUI interface, operations over low-speed links (wireless VPN when I'm away from the office and in a bad cell zone, for instance) is likely important. So is ability to script common tasks to allow people like the help desk to do their jobs at low risk. Flexibility is also important - when I'm stuck with this piece of gear (which is shiny today) in 5-7 years, when it's not so shiny, is it going to have flexibility to last a bit longer if the business needs to conserve cash - or will a minor change in how we do business make this thing functionally obsolete? Relating to the discussion on the tier 1 mentor thread, someone who wants to go far in networking won't be married to a particular vendor or way of doing things. They'll excel and find ways to overcome challenges, including less than perfect equipment, that they might have to deal with. They'll do so in a way that makes the customer and their own management happy. A highly paid network engineer who complains about work being difficult probably won't do that. One that finds a $500 replacement for a $5000 router probably will stick around, provided they can actually deliver what they promised (the guy that puts the $500 replacement in only to have to replace it in a year with a $5000 router again won't go far, so be careful! And you better have figured in the real costs of running a network with $500 routers, not just the cost of the router). From cscora at apnic.net Fri Nov 25 13:19:07 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 Nov 2011 05:19:07 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201111251919.pAPJJ7RZ001830@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, 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 26 Nov, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 383171 Prefixes after maximum aggregation: 167108 Deaggregation factor: 2.29 Unique aggregates announced to Internet: 188188 Total ASes present in the Internet Routing Table: 39373 Prefixes per ASN: 9.73 Origin-only ASes present in the Internet Routing Table: 32422 Origin ASes announcing only one prefix: 15459 Transit ASes present in the Internet Routing Table: 5298 Transit-only ASes present in the Internet Routing Table: 137 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN (48687) 24 Prefixes from unregistered ASNs in the Routing Table: 1776 Unregistered ASNs in the Routing Table: 904 Number of 32-bit ASNs allocated by the RIRs: 1995 Number of 32-bit ASNs visible in the Routing Table: 1653 Prefixes from 32-bit ASNs in the Routing Table: 3905 Special use prefixes present in the Routing Table: 2 Prefixes being announced from unallocated address space: 85 Number of addresses announced to Internet: 2493814272 Equivalent to 148 /8s, 164 /16s and 150 /24s Percentage of available address space announced: 67.3 Percentage of allocated address space announced: 67.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 91.6 Total number of prefixes smaller than registry allocations: 161781 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 95482 Total APNIC prefixes after maximum aggregation: 31239 APNIC Deaggregation factor: 3.06 Prefixes being announced from the APNIC address blocks: 91934 Unique aggregates announced from the APNIC address blocks: 38658 APNIC Region origin ASes present in the Internet Routing Table: 4601 APNIC Prefixes per ASN: 19.98 APNIC Region origin ASes announcing only one prefix: 1253 APNIC Region transit ASes present in the Internet Routing Table: 713 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 18 Number of APNIC region 32-bit ASNs visible in the Routing Table: 109 Number of APNIC addresses announced to Internet: 630811232 Equivalent to 37 /8s, 153 /16s and 106 /24s Percentage of available APNIC address space announced: 80.0 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-132095, 132096-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: 145956 Total ARIN prefixes after maximum aggregation: 74537 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 118222 Unique aggregates announced from the ARIN address blocks: 48634 ARIN Region origin ASes present in the Internet Routing Table: 14758 ARIN Prefixes per ASN: 8.01 ARIN Region origin ASes announcing only one prefix: 5635 ARIN Region transit ASes present in the Internet Routing Table: 1565 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 12 Number of ARIN addresses announced to Internet: 803548096 Equivalent to 47 /8s, 229 /16s and 43 /24s Percentage of available ARIN address space announced: 63.9 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: 92793 Total RIPE prefixes after maximum aggregation: 51275 RIPE Deaggregation factor: 1.81 Prefixes being announced from the RIPE address blocks: 84982 Unique aggregates announced from the RIPE address blocks: 54491 RIPE Region origin ASes present in the Internet Routing Table: 16128 RIPE Prefixes per ASN: 5.27 RIPE Region origin ASes announcing only one prefix: 7973 RIPE Region transit ASes present in the Internet Routing Table: 2549 Average RIPE Region AS path length visible: 4.8 Max RIPE Region AS path length visible: 33 Number of RIPE region 32-bit ASNs visible in the Routing Table: 1151 Number of RIPE addresses announced to Internet: 492677440 Equivalent to 29 /8s, 93 /16s and 169 /24s Percentage of available RIPE address space announced: 79.4 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 196608-198655 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: 36535 Total LACNIC prefixes after maximum aggregation: 7956 LACNIC Deaggregation factor: 4.59 Prefixes being announced from the LACNIC address blocks: 35946 Unique aggregates announced from the LACNIC address blocks: 18739 LACNIC Region origin ASes present in the Internet Routing Table: 1554 LACNIC Prefixes per ASN: 23.13 LACNIC Region origin ASes announcing only one prefix: 442 LACNIC Region transit ASes present in the Internet Routing Table: 285 Average LACNIC Region AS path length visible: 4.5 Max LACNIC Region AS path length visible: 18 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 377 Number of LACNIC addresses announced to Internet: 93623936 Equivalent to 5 /8s, 148 /16s and 150 /24s Percentage of available LACNIC address space announced: 62.0 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: 8328 Total AfriNIC prefixes after maximum aggregation: 2027 AfriNIC Deaggregation factor: 4.11 Prefixes being announced from the AfriNIC address blocks: 6387 Unique aggregates announced from the AfriNIC address blocks: 2014 AfriNIC Region origin ASes present in the Internet Routing Table: 499 AfriNIC Prefixes per ASN: 12.80 AfriNIC Region origin ASes announcing only one prefix: 156 AfriNIC Region transit ASes present in the Internet Routing Table: 107 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: 4 Number of AfriNIC addresses announced to Internet: 27874816 Equivalent to 1 /8s, 169 /16s and 86 /24s Percentage of available AfriNIC address space announced: 41.5 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 2516 11105 973 Korea Telecom (KIX) 17974 1636 511 36 PT TELEKOMUNIKASI INDONESIA 7545 1626 303 86 TPG Internet Pty Ltd 4755 1513 376 168 TATA Communications formerly 7552 1384 1064 7 Vietel Corporation 9829 1166 989 28 BSNL National Internet Backbo 9583 1095 80 494 Sify Limited 4808 1081 2072 311 CNCGROUP IP network: China169 24560 966 343 218 Bharti Airtel Ltd., Telemedia 18101 953 119 149 Reliance Infocom Ltd Internet 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 3479 3814 217 bellsouth.net, inc. 7029 2909 1016 199 Windstream Communications Inc 18566 2093 383 177 Covad Communications 1785 1849 680 121 PaeTec Communications, Inc. 4323 1613 1078 389 Time Warner Telecom 20115 1600 1546 624 Charter Communications 22773 1502 2909 104 Cox Communications, Inc. 30036 1440 258 676 Mediacom Communications Corp 19262 1387 4683 401 Verizon Global Networks 7018 1314 7030 860 AT&T WorldNet Services 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 1587 480 15 Corbina telecom 6830 651 1927 412 UPC Distribution Services 34984 612 114 193 BILISIM TELEKOM 20940 557 186 439 Akamai Technologies European 3320 512 8168 389 Deutsche Telekom AG 12479 498 603 18 Uni2 Autonomous System 3292 478 2106 406 TDC Tele Danmark 8866 463 133 26 Bulgarian Telecommunication C 8551 416 366 45 Bezeq International 31148 412 22 116 FreeNet ISP 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 1700 315 179 TVCABLE BOGOTA 28573 1515 1045 71 NET Servicos de Comunicao S.A 8151 1448 2973 342 UniNet S.A. de C.V. 7303 1238 751 173 Telecom Argentina Stet-France 27947 609 72 86 Telconet S.A 22047 581 322 17 VTR PUNTO NET S.A. 6503 553 434 68 AVANTEL, S.A. 7738 553 1050 31 Telecomunicacoes da Bahia S.A 3816 545 236 87 Empresa Nacional de Telecomun 11172 528 85 95 Servicios Alestra S.A de C.V 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 897 446 12 TEDATA 24863 781 146 36 LINKdotNET AS number 3741 281 939 230 The Internet Solution 15706 242 32 6 Sudatel Internet Exchange Aut 33776 240 13 8 Starcomms Nigeria Limited 6713 235 519 14 Itissalat Al-MAGHRIB 29571 218 17 13 Ci Telecom Autonomous system 12258 196 28 57 Vodacom Internet Company 24835 192 80 8 RAYA Telecom - Egypt 16637 157 664 83 MTN Network Solutions 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 3479 3814 217 bellsouth.net, inc. 7029 2909 1016 199 Windstream Communications Inc 4766 2516 11105 973 Korea Telecom (KIX) 18566 2093 383 177 Covad Communications 1785 1849 680 121 PaeTec Communications, Inc. 10620 1700 315 179 TVCABLE BOGOTA 17974 1636 511 36 PT TELEKOMUNIKASI INDONESIA 7545 1626 303 86 TPG Internet Pty Ltd 4323 1613 1078 389 Time Warner Telecom 20115 1600 1546 624 Charter Communications 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 2909 2710 Windstream Communications Inc 18566 2093 1916 Covad Communications 1785 1849 1728 PaeTec Communications, Inc. 17974 1636 1600 PT TELEKOMUNIKASI INDONESIA 8402 1587 1572 Corbina telecom 4766 2516 1543 Korea Telecom (KIX) 7545 1626 1540 TPG Internet Pty Ltd 10620 1700 1521 TVCABLE BOGOTA 28573 1515 1444 NET Servicos de Comunicao S.A 22773 1502 1398 Cox Communications, Inc. 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 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 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 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 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 41.222.79.0/24 37345 MEDALLION Communications 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 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:12 /10:27 /11:81 /12:236 /13:465 /14:809 /15:1434 /16:12028 /17:6089 /18:10141 /19:20013 /20:27720 /21:27902 /22:38036 /23:35600 /24:199083 /25:1163 /26:1365 /27:775 /28:165 /29:3 /30:0 /31:0 /32:5 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2538 2909 Windstream Communications Inc 6389 2123 3479 bellsouth.net, inc. 18566 2042 2093 Covad Communications 10620 1595 1700 TVCABLE BOGOTA 8402 1562 1587 Corbina telecom 30036 1400 1440 Mediacom Communications Corp 11492 1118 1155 Cable One 1785 1058 1849 PaeTec Communications, Inc. 7011 1050 1167 Citizens Utilities 22773 962 1502 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:421 2:487 4:15 5:1 6:3 8:358 12:1952 13:1 14:555 15:11 16:3 17:7 20:9 23:68 24:1694 27:1036 31:684 32:66 33:2 34:2 36:4 38:767 39:1 40:109 41:2868 42:64 43:1 44:3 46:1098 47:3 49:296 50:450 52:13 55:6 56:2 57:49 58:928 59:486 60:360 61:1167 62:916 63:1966 64:4080 65:2309 66:4345 67:2011 68:1172 69:3148 70:904 71:359 72:1814 74:2650 75:430 76:320 77:897 78:891 79:461 80:1145 81:839 82:523 83:520 84:471 85:1149 86:401 87:908 88:353 89:1596 90:246 91:4287 92:537 93:1438 94:1322 95:1126 96:396 97:285 98:771 99:37 101:247 103:513 106:7 107:97 108:86 109:1201 110:679 111:812 112:363 113:503 114:630 115:714 116:907 117:722 118:876 119:1289 120:353 121:669 122:1562 123:1027 124:1357 125:1354 128:269 129:184 130:174 131:633 132:155 133:21 134:224 135:54 136:212 137:145 138:285 139:122 140:494 141:250 142:379 143:400 144:498 145:66 146:476 147:220 148:641 149:275 150:163 151:191 152:449 153:172 154:7 155:379 156:208 157:360 158:156 159:488 160:333 161:215 162:365 163:175 164:518 165:381 166:540 167:448 168:828 169:145 170:826 171:87 172:4 173:1752 174:581 175:435 176:332 177:403 178:1127 180:1174 181:39 182:664 183:247 184:394 185:1 186:1464 187:783 188:994 189:1160 190:5222 192:5933 193:5057 194:3540 195:3112 196:1277 197:170 198:3614 199:4227 200:5527 201:1701 202:8557 203:8523 204:4308 205:2410 206:2655 207:2837 208:4024 209:3583 210:2741 211:1471 212:2012 213:1803 214:784 215:91 216:4921 217:1478 218:575 219:341 220:1253 221:523 222:327 223:280 End of report From joelja at bogus.com Fri Nov 25 13:34:47 2011 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 25 Nov 2011 11:34:47 -0800 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> References: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> Message-ID: <4ECFEDD7.6040505@bogus.com> On 11/22/11 08:16 , Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> As in all cases, additional flexibility results in additional ability >> to make mistakes. Simple mechanical lockouts do not scale to the >> modern world. The benefits of these additional capabilities far >> outweigh the perceived risks of programming errors. > > The perceived risk in this case is "multiple high-speed traffic fatalities". > > I believe we rank that pretty high; it's entirely possible that a traffic > light controller is the most potentially dangerous artifact (in terms of > number of possible deaths) that the average citizen interacts with on a > daily basis. Cars generically cause at lot more deaths than faulty traffic controllers 13.2 per 100,000 population in the US annually. From jay at west.net Fri Nov 25 14:02:22 2011 From: jay at west.net (Jay Hennigan) Date: Fri, 25 Nov 2011 12:02:22 -0800 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <4ECFEDD7.6040505@bogus.com> References: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> <4ECFEDD7.6040505@bogus.com> Message-ID: <4ECFF44E.5050502@west.net> On 11/25/11 11:34 AM, Joel jaeggli wrote: > Cars generically cause at lot more deaths than faulty traffic > controllers 13.2 per 100,000 population in the US annually. The cars don't (often) cause them. The drivers do. Yes, there are the rare mechanical failures but the most likely cause is wetware. Ditto airplane crashes. A mild example: http://www.ntsb.gov/aviationquery/brief.aspx?ev_id=20001212X18632 -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From joelja at bogus.com Fri Nov 25 14:08:07 2011 From: joelja at bogus.com (Joel jaeggli) Date: Fri, 25 Nov 2011 12:08:07 -0800 Subject: OT: Traffic Light Control (was Re: First real-world SCADA attack in US) In-Reply-To: <4ECFF44E.5050502@west.net> References: <32105601.3727.1321978614923.JavaMail.root@benjamin.baylink.com> <4ECFEDD7.6040505@bogus.com> <4ECFF44E.5050502@west.net> Message-ID: <4ECFF5A7.5060806@bogus.com> On 11/25/11 12:02 , Jay Hennigan wrote: > On 11/25/11 11:34 AM, Joel jaeggli wrote: > >> Cars generically cause at lot more deaths than faulty traffic >> controllers 13.2 per 100,000 population in the US annually. > > The cars don't (often) cause them. The drivers do. Yes, there are the > rare mechanical failures but the most likely cause is wetware. Ditto > airplane crashes. A mild example: while they may well have otherwise been runover by an oxcart in the absence of automobiles, if they we're behind the wheel of a complex 2 ton machine there would be no accident. > http://www.ntsb.gov/aviationquery/brief.aspx?ev_id=20001212X18632 > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service - http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > From frnkblk at iname.com Fri Nov 25 15:09:07 2011 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 25 Nov 2011 15:09:07 -0600 Subject: NANOG Internet predictions for 2010 Message-ID: <001901ccabb6$7802aaa0$6807ffe0$@iname.com> On this slower-than-normal day I was cleaning up my office and found this article from 2006 making predictions for 2010. It's now a year later, and while many of these did not happen, some of them did and for others we are a step closer. Frank http://bpastudio.csudh.edu/fac/lpress/471/hout/nanog2010.htm Hi - At a content forum and NANOG in June 2006 I led some discussions involving predictions for what the Internet might look like in 2010. What makes this so interesting is that so many perspectives highlighted so many potential futures that others had not considered. When you then discuss the implications of such varying futures, again with a diverse crowd, you end up with a lively discussion and, well, some potential futures you may not have considered. I've tried to list some of these predictions from the Content Provider crowd and the ISP NANOG crowd here. Content Provider Predictions for 2010 ------------------------------------------------------ Here is the question I put to a group of Content Providers at a content forum: "We are sitting around this table in 2010 and we are commenting how remarkable the last few years have been, specifically that:" 1. Video streaming volume has grown 100 fold 2. Last mile wireless replaced local loop 3. Botnets (DDOS attacks) are still an issue 4. Non-mechanical (i.e. Flash) Drives replaced internal hard drives on laptops 5. 10% of all cell phones are now video phones 6. We have cell phones that we actually like 7. The U.S. is insignificant traffic wise relative to the rest of the world 8. Most popular question discussed around the table: 'How do we operate business in China?' 9. No online privacy. And the gov't watches everything 10. 18-25 demographic is best reached w/ads on the Internet 11. Next Gen 3D on-line Social Networks are so successful 12. No physical network interfaces are needed 13. We will big brother ourselves (video cams 'who scraped my car?') 14. So many special purpose Internet apps - in car google maps, live traffic updates, etc. 15. So much of our personal information is on the net 16. Video IM emerged as a dominant app 17. P2P will emerge for non-pirated videos - DRM in place and embraced 18. Voice calls are free, bundled with other things [some additional notable predictions from this group, but did not = receive simple majority validation] IPTV replaces cable TV IPv6 is adopted = Massive Internet Collapse - Metcalfe regurgitates his column Flexible screen deployment SPAM is no longer a problem in 2010 Windows embraces = distributed computing Net is not Neutral Powerline Broadband emerges FTTH massive deployment Internet Service Providers Predictions for 2010 ------------------------------------------------------------------ We didn't get to do this at the Peering BOF at NANOG, but I did some = table discussions outside in the hallways. There there was no voting so I am listing a subset of the predictions that seemed to resonate among a = couple dozen or so folks at the hallway tables where question was discussed: "We are sitting around this table in 2010 at NANOG and we are commenting = how remarkable the last few years have been, specifically that:" 1. We have 10G network interface(s) on laptops (I assumed wired, but someone else might have been thinking wireless) 2. $5/mbps is the common/standard price of transit (other prediction was $30/mbps) 3. Internet traffic is now so heavily localized (as in 75% of telephone calls are across town type of thing but for the Internet) 4. Ad revenue will cover the cost/or subsidize significantly of DSL 5. 90% of Internet bits will be video traffic 6. VoIP traffic exceeds the PSTN traffic 7. Private networks predominantly migrate to overlays over the Internet 8. Wireless Internet Service Providers (WISPs) are serious competitive threat to DSL and Cable Internet 9. Sprint is bought by Time Warner 10. Cable companies form cabal & hookup with Sprint or Level 3 11. Government passes Net Neutrality Law of some flavor 12. Earthlink successfully reinvents themselves as Wireless Metro player in Response to ATT and Verizon 13. 40% paid or subscription as opposed to Content Click Ads. Like Cable Company channel packages, folks will flock to subscriptions for Internet Content packages. 14. RIAA proposes surcharge on network access (like Canada tax on blank CDs) 15. NetFlix conversion to Internet delivery of movies to Tivo or PC, or open source set top box 16. ISPs will be in pain 17. Last mile (fiber, wireless, .) in metro will be funded by municipal bonds 18. Death of TV ads, Death of broadcast TV, Tivo & Tivo like appliances all use the Internet with emergence of targeted ads based on demographic profiles of viewer 19. Google in charge of 20% of ALL ads (TV, Radio, Billboards, .) 20. Ubiquitous wifi in every metro with wifi roaming agreements 21. Congestion issues drive selective customer acceptance of partial transit offerings 22. IPTV fully embraced by cable cos - VOD - no need for VDR and ala carte video services replace analog frequency 23. Near simultaneous release of movies to the theaters, DVDs for the home, PPV, and Internet download to meet needs of different = demographics. (Some get dressed up for theater, others have kids and can't leave home, others wantto watch on the flight to Tokyo - all watch the new release = movie at about the same time) Video Peering -------------------- For what it is worth, some of this resonates with the Peering BOF Video Peering discussion. With YouTube pushing 20Gbps after only one year in existance, and with the 30+ companies that often chase a high profile = market such as theirs, we have a potential additional Internet load approaching 600Gbps! YouTube at the BOF said that their traffic is growing at about = 20% per month, so it may be reasonable to expect their traffic to double a couple times over the next year. Even if you discount the competitors traffic flows, video still appears as a *massive* traffic volume coming into the Peering Ecosystem over the next bunch of months. And yes, they are willing to peer the traffic for free so you eyeball networks and they (YouTube) don't have to pay transit fees on the = traffic. Bill //------------------------------------------------ // William B. Norton ------------------------------------- Bill.St.Arnaud at canarie.ca www.canarie.ca/~bstarn skype: pocketpro SkypeIn: +1 614 441-9603 From bill at herrin.us Fri Nov 25 15:28:37 2011 From: bill at herrin.us (William Herrin) Date: Fri, 25 Nov 2011 16:28:37 -0500 Subject: NANOG Internet predictions for 2010 In-Reply-To: <001901ccabb6$7802aaa0$6807ffe0$@iname.com> References: <001901ccabb6$7802aaa0$6807ffe0$@iname.com> Message-ID: On Fri, Nov 25, 2011 at 4:09 PM, Frank Bulk wrote: > On this slower-than-normal day I was cleaning up my office and found this > article from 2006 making predictions for 2010. ?It's now a year later, and > while many of these did not happen, some of them did and for others we are a > step closer. > > http://bpastudio.csudh.edu/fac/lpress/471/hout/nanog2010.htm > > Content Provider Predictions for 2010 > Internet Service Providers Predictions for 2010 I observe that the content providers had more than double the hit rate of the ISPs. From cidr-report at potaroo.net Fri Nov 25 16:00:01 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Nov 2011 22:00:01 GMT Subject: BGP Update Report Message-ID: <201111252200.pAPM01tT080748@wattle.apnic.net> BGP Update Report Interval: 17-Nov-11 -to- 24-Nov-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS29049 79965 2.6% 207.2 -- DELTA-TELECOM-AS Delta Telecom LTD. 2 - AS9829 49222 1.6% 90.5 -- BSNL-NIB National Internet Backbone 3 - AS8402 41347 1.3% 18.3 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS34875 33439 1.1% 227.5 -- YANFES OJSC "Uralsviazinform" 5 - AS5434 31214 1.0% 251.7 -- NURSAT-ALA-AS Nursat-Almaty 6 - AS19743 29751 0.9% 4958.5 -- 7 - AS7552 27656 0.9% 19.8 -- VIETEL-AS-AP Vietel Corporation 8 - AS41440 25577 0.8% 216.8 -- SIBIRTELECOM-AS OJSC Rostelecom 9 - AS32528 24172 0.8% 4834.4 -- ABBOTT Abbot Labs 10 - AS9198 22845 0.7% 83.1 -- KAZTELECOM-AS JSC Kazakhtelecom 11 - AS20632 21072 0.7% 540.3 -- PETERSTAR-AS PeterStar 12 - AS6828 20101 0.6% 223.3 -- USI Uralsviazinform 13 - AS12772 19947 0.6% 127.1 -- ENFORTA-AS Enforta Autonomous System 14 - AS21487 18021 0.6% 212.0 -- SAKHATELECOM-AS OJSC Rostelecom 15 - AS27738 16872 0.5% 49.6 -- Ecuadortelecom S.A. 16 - AS24689 16727 0.5% 223.0 -- ROSINTEL-AS Rosintel Network 17 - AS12332 16581 0.5% 221.1 -- PRIMORYE-AS OJSC Rostelecom 18 - AS15723 16072 0.5% 206.1 -- AZERONLINE Azeronline Information Services 19 - AS3 15463 0.5% 213.0 -- GUGIK Glowny Urzad Geodezji i Kartografii 20 - AS31148 14783 0.5% 35.9 -- FREENET-AS FreeNet ISP TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS19743 29751 0.9% 4958.5 -- 2 - AS32528 24172 0.8% 4834.4 -- ABBOTT Abbot Labs 3 - AS16916 7281 0.2% 3640.5 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 4 - AS38528 3476 0.1% 3476.0 -- LANIC-AS-AP Lao National Internet Committee 5 - AS17408 3301 0.1% 3301.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 6 - AS38960 2827 0.1% 2827.0 -- INGBANK-UKRAINE Joint-stock bank ING BANK UKRAINE 7 - AS42041 2093 0.1% 2093.0 -- INGOUA-AS CJSC Joint Stock Insurance Company INGO Ukraine 8 - AS11943 909 0.0% 909.0 -- GLOBE - Globe Wireless 9 - AS21271 858 0.0% 858.0 -- SOTELMABGP 10 - AS19223 10937 0.3% 781.2 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 11 - AS6072 10164 0.3% 726.0 -- UNISYS-6072 For routing issues, email hostmaster at unisys.com 12 - AS37115 675 0.0% 675.0 -- TMP-UG 13 - AS57405 655 0.0% 655.0 -- MIHAN-NOC2 MIHAN COMMUNICATION SYSTEMS CO.,LTD 14 - AS48068 567 0.0% 567.0 -- VISONIC Visonic Ltd 15 - AS52140 562 0.0% 562.0 -- UNHCR-IR-AS United Nations High Commissioner for Refugees 16 - AS20632 21072 0.7% 540.3 -- PETERSTAR-AS PeterStar 17 - AS57282 498 0.0% 498.0 -- SOPREX-AS SOPREX D.o.o. 18 - AS52196 487 0.0% 487.0 -- TREC-AS Tehran Regional Electricity Joint Stock Company 19 - AS53362 465 0.0% 465.0 -- MIXIT-AS - Mixit, Inc. 20 - AS10445 1792 0.1% 448.0 -- HTG - Huntleigh Telcom TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 84.204.132.0/24 19391 0.6% AS20632 -- PETERSTAR-AS PeterStar 2 - 130.36.35.0/24 12080 0.4% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.34.0/24 12079 0.4% AS32528 -- ABBOTT Abbot Labs 4 - 67.97.156.0/24 10812 0.3% AS19223 -- NTEGRATED-SOLUTIONS - Ntegrated Solutions 5 - 66.248.104.0/21 10779 0.3% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 6 - 202.92.235.0/24 10070 0.3% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 7 - 206.80.93.0/24 7271 0.2% AS16916 -- NETLOGIC-WEST - INFINIPLEX LLC DBA NETLOGIC 8 - 65.122.196.0/24 6944 0.2% AS19743 -- 9 - 72.164.144.0/24 4567 0.1% AS19743 -- 10 - 66.238.91.0/24 4560 0.1% AS19743 -- 11 - 65.162.204.0/24 4560 0.1% AS19743 -- 12 - 66.89.98.0/24 4560 0.1% AS19743 -- 13 - 65.163.182.0/24 4560 0.1% AS19743 -- 14 - 203.110.64.0/20 3476 0.1% AS38528 -- LANIC-AS-AP Lao National Internet Committee 15 - 202.153.174.0/24 3301 0.1% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 16 - 195.144.28.0/24 2827 0.1% AS38960 -- INGBANK-UKRAINE Joint-stock bank ING BANK UKRAINE 17 - 213.16.48.0/24 2743 0.1% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 18 - 85.223.211.0/24 2093 0.1% AS42041 -- INGOUA-AS CJSC Joint Stock Insurance Company INGO Ukraine 19 - 14.102.50.0/24 1677 0.1% AS18002 -- WORLDPHONE-IN AS Number for Interdomain Routing 20 - 217.52.130.0/24 1478 0.1% AS15475 -- NOL AS36992 -- ETISALAT-MISR 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 Nov 25 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Nov 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201111252200.pAPM00ga080741@wattle.apnic.net> This report has been generated at Fri Nov 25 21:12:35 2011 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 18-11-11 384382 225289 19-11-11 384737 225361 20-11-11 384631 225219 21-11-11 384703 225139 22-11-11 384864 225632 23-11-11 385042 225870 24-11-11 384967 226037 25-11-11 385336 226282 AS Summary 39470 Number of ASes in routing system 16606 Number of ASes announcing only one prefix 3479 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108833792 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'). --- 25Nov11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 385375 226321 159054 41.3% All ASes AS6389 3479 220 3259 93.7% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS18566 2093 406 1687 80.6% COVAD - Covad Communications Co. AS4766 2520 996 1524 60.5% KIXS-AS-KR Korea Telecom AS7029 2950 1495 1455 49.3% WINDSTREAM - Windstream Communications Inc AS22773 1502 113 1389 92.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1510 242 1268 84.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS4323 1614 391 1223 75.8% TWTC - tw telecom holdings, inc. AS28573 1515 383 1132 74.7% NET Servicos de Comunicao S.A. AS1785 1852 781 1071 57.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 1387 401 986 71.1% VZGNI-TRANSIT - Verizon Online LLC AS7552 1383 412 971 70.2% VIETEL-AS-AP Vietel Corporation AS10620 1700 737 963 56.6% Telmex Colombia S.A. AS7303 1238 360 878 70.9% Telecom Argentina S.A. AS18101 954 150 804 84.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1451 675 776 53.5% Uninet S.A. de C.V. AS30036 1440 682 758 52.6% MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communications Corp AS4808 1081 342 739 68.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7545 1625 946 679 41.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS17974 1635 960 675 41.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS8402 1567 893 674 43.0% CORBINA-AS OJSC "Vimpelcom" AS3356 1106 457 649 58.7% LEVEL3 Level 3 Communications AS24560 966 351 615 63.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 671 71 600 89.4% GIGAINFRA Softbank BB Corp. AS20115 1600 1026 574 35.9% CHARTER-NET-HKY-NC - Charter Communications AS4804 660 95 565 85.6% MPX-AS Microplex PTY LTD AS22561 931 376 555 59.6% DIGITAL-TELEPORT - Digital Teleport Inc. AS22047 581 33 548 94.3% VTR BANDA ANCHA S.A. AS3549 955 421 534 55.9% GBLX Global Crossing Ltd. AS17488 928 402 526 56.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS7011 1167 645 522 44.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 44061 15462 28599 64.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- 41.222.79.0/24 AS37345 MEDALLION 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 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 69.6.80.0/24 AS13442 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 80.88.10.0/24 AS33774 DJAWEB 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 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 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 164.215.112.0/20 AS30764 PODA-AS PODA s.r.o. 172.45.1.0/24 AS29571 CITelecom-AS 172.45.2.0/24 AS29571 CITelecom-AS 172.45.3.0/24 AS29571 CITelecom-AS 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 176.221.16.0/20 AS39308 ASK-AS Andishe Sabz Khazar Autonomous System 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 200.6.93.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.94.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.6.95.0/24 AS6400 Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL 200.23.84.0/24 AS8151 Uninet S.A. de C.V. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 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 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 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.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.160.152.0/22 AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 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.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company 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 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 216.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 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 jra at baylink.com Fri Nov 25 21:14:11 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 25 Nov 2011 22:14:11 -0500 (EST) Subject: Water Utility SCADA 'Attack': The, um, washout Message-ID: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> Not an attack: an already failing pump, and an employee of a contractor to the utility who was ... wait for it ... traveling in Russia on personal business. WaPo via Lauren @ Privacy: http://j.mp/rrvMXR 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 Sat Nov 26 01:35:05 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 26 Nov 2011 07:35:05 +0000 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> Message-ID: <7CFCA993-1F26-4AD2-BE0B-47776EA621D9@arbor.net> On Nov 26, 2011, at 10:14 AM, Jay Ashworth wrote: > traveling in Russia on personal business. I've noticed that in general, when there isn't an actual attack taking place, but rather some kind of misconfiguration or other issue, there's all too often a tendency to run around shouting about the 133t h4x0rs; and when there's really an attack taking place, it's the last thing to be considered, if ever, heh. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From andrew.wallace at rocketmail.com Sat Nov 26 06:51:47 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 26 Nov 2011 04:51:47 -0800 (PST) Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> Message-ID: <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> My comment about a certain person leaking public-private sector correspondence to the media still applies then. https://plus.google.com/114359738470992181937/posts/DSnJfKqrJK1 Andrew ________________________________ From: Jay Ashworth To: NANOG Sent: Saturday, November 26, 2011 3:14 AM Subject: Water Utility SCADA 'Attack': The, um, washout Not an attack: an already failing pump, and an employee of a contractor to the utility who was ... wait for it ... traveling in Russia on personal business. WaPo via Lauren @ Privacy:? http://j.mp/rrvMXR 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 jeff.richmond at gmail.com Sat Nov 26 12:28:03 2011 From: jeff.richmond at gmail.com (Jeff Richmond) Date: Sat, 26 Nov 2011 10:28:03 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <20111121143253.BA43DBAD@resin13.mta.everyone.net> Message-ID: <1CC70AF4-B568-4939-979B-A066A6CFE05C@gmail.com> All excellent advice, but let me point out something else. I manage a team of backbone engineers and still do quite a bit of engineering work myself. When I interview, I never get caught up on certs or degrees. Now, do I ignore them? No, of course not. They do mean something and I know I worked hard for my JNCIE, so they add value. However, what I want to see is someone that is energetic and has a drive to learn, but the most important piece of my interviews once I am confident they meet my technical needs is the personality evaluation. I know my team works crappy hours, gets pulled 100 different directions and just really have a tough job sometimes. What I can't have is a toxic person added to the mix, no matter how ridiculously smart or qualified they might be. So there have been times I have turned away more qualified candidates just because I was not comfortable with their attitude or vibe. Hiring and firing is extremely difficult to correct if you make the wrong choice, and I have learned a thing or two over the years in this regard. That said, there is something else to consider too. In most large companies, the managers don't always have a lot of power when it comes to salaries and in some cases, even promotions. So, without specific experience and a salary history, you may be artificially held down due to HR policies no matter how well you do. I know that has happened a number of times at various places I have worked, and it is frustrating both for the candidate and the manager. There are many places where it is better to actually leave the company and come back to get around the HR constraints regarding salary augments from internal promotions. So, just be aware that even though you are working hard and going above and beyond, you might not always get initially rewarded for it. However, in time it will almost always correct itself, but even so, keeping a positive attitude and having a desire to learn will always benefit you in the end one way or another. Of course, once you get to the point of being in the industry for a long time like most of us here, you'll look back and say what the heck was I thinking, I should have been an accountant. Heh :) Best of luck, -Jeff On Nov 22, 2011, at 3:52 AM, David Swafford wrote: > Scott's point is very true! Motivation will help you go very far, > much farther than certs/knowledge alone. As a soon to be > college-grad, be ready for the initial disappointment, :-), even > though you'll have your CCNP, you have no real experience, so you'll > start at the entry level. That's not a bad thing, but you might see > it as such. The reason it is good, is that while at the entry level > (networking that is, I'm not talking about a helpdesk), you'll get to > touch and interact with a lot of different things with very little > "total" responsibility. > > As you impress your peers, this will trickle up towards management, > and eventually work it's way out into better tasks and larger > responsibilities (try to not get caught up in "the title"). I'm > speaking from experience here, I'm a senior network engineer for a $2 > B company, yet only 25 years old, currently working on my R/S CCIE > purely for the learning experience. It took me nearly 4 years to move > from an associate to a senior in my company, which is not common in > that short of a time-frame for my employer, but that's where the > motivation piece comes in -- expressing true passion, and learning > things because "they are cool/interest you" will take you far. > Learning on paper is what you're taught in college and it only works > so far, but learning from hand-on, like the lab you've got built, is > where you attain the knowledge/troubleshooting/experience that will > help you succeed. > > A comment earlier in the thread mentioned "should I learn active > directory/exchange"? I hear this a lot from our fellow associate's on > the team.... and to be honest, if you are learning something just to > add it to your resume, that will be a waste of your time. But, if you > are learning it because you find it interesting or just want to > explore, then by all means go deep into it. I personally go by the > motto "go full in or don't go at all". So if I'm going to learn > something, I'll get as deep as I can into it, and focus on just it for > a little while, then I'll move to something else, and focus on just > that. If you try to focus on too many separate things, you'll become > this odd ball of knowledge that can't really hold you own -- a tip in > the industry that will get you far: be able to take ownership, and > fully run/own what you're working on. Regardless of level/title/role, > a person who takes initive (within the scope/dynamic of their > position), will go far. > > Best of luck to you, > David. > > > On Mon, Nov 21, 2011 at 5:32 PM, Scott Weeks wrote: >> >> >> --- tyler.haske at gmail.com wrote: >> From: Tyler Haske >> >> I'd love to have varied experience with a bunch of different companies, but >> first I'm trying to guarantee my first network engineering job out of >> college. >> ----------------------------------------------- >> >> >> You've already taken the first step. That step being you becoming more motivated than many of the other soon-to-be-graduates around you. This motivation will carry you a long way in your career. Who knows, you may be applying to someone here on this list one day... >> >> scott >> >> > From Valdis.Kletnieks at vt.edu Sat Nov 26 12:40:06 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 26 Nov 2011 13:40:06 -0500 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: Your message of "Sat, 26 Nov 2011 10:28:03 PST." <1CC70AF4-B568-4939-979B-A066A6CFE05C@gmail.com> References: <20111121143253.BA43DBAD@resin13.mta.everyone.net> <1CC70AF4-B568-4939-979B-A066A6CFE05C@gmail.com> Message-ID: <240275.1322332806@turing-police.cc.vt.edu> On Sat, 26 Nov 2011 10:28:03 PST, Jeff Richmond said: > Of course, once you get to the point of being in the industry for a long > time like most of us here, you'll look back and say what the heck was I > thinking, I should have been an accountant. Heh :) It's the rare accountant indeed that gets a phone call at 2AM saying that the books are on fire. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lostinmoscow at gmail.com Sat Nov 26 12:43:54 2011 From: lostinmoscow at gmail.com (Quinn Kuzmich) Date: Sat, 26 Nov 2011 11:43:54 -0700 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <20111121143253.BA43DBAD@resin13.mta.everyone.net> Message-ID: There are more than a few people out there that will look down on you for your efforts - ignore them. "The people who want you to give up are jealous because you're better than them. The people who are already better than you don't care about you because you're not as good as them." Q On Tue, Nov 22, 2011 at 4:52 AM, David Swafford wrote: > Scott's point is very true! Motivation will help you go very far, > much farther than certs/knowledge alone. As a soon to be > college-grad, be ready for the initial disappointment, :-), even > though you'll have your CCNP, you have no real experience, so you'll > start at the entry level. That's not a bad thing, but you might see > it as such. The reason it is good, is that while at the entry level > (networking that is, I'm not talking about a helpdesk), you'll get to > touch and interact with a lot of different things with very little > "total" responsibility. > > From bmanning at vacation.karoshi.com Sat Nov 26 13:46:49 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 26 Nov 2011 19:46:49 +0000 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <20111121143253.BA43DBAD@resin13.mta.everyone.net> Message-ID: <20111126194649.GA5586@vacation.karoshi.com.> and then there are the people who are excited to have one more person join the network of engineers. and (IMHO) the sentiments quoted by Quinn are signs of short-sighted people. Everyone is better at some things and worse at others. Don't ignore anyone, don't look down on anyone - you will find there are things to learn from everyone and you have something to teach everyone. as mentioned earlier - a good team player is hard to find. /bill On Sat, Nov 26, 2011 at 11:43:54AM -0700, Quinn Kuzmich wrote: > There are more than a few people out there that will look down on you for > your efforts - ignore them. > > "The people who want you to give up are jealous because you're better than > them. The people who are already better than you don't care about you > because you're not as good as them." > > Q > > On Tue, Nov 22, 2011 at 4:52 AM, David Swafford wrote: > > > Scott's point is very true! Motivation will help you go very far, > > much farther than certs/knowledge alone. As a soon to be > > college-grad, be ready for the initial disappointment, :-), even > > though you'll have your CCNP, you have no real experience, so you'll > > start at the entry level. That's not a bad thing, but you might see > > it as such. The reason it is good, is that while at the entry level > > (networking that is, I'm not talking about a helpdesk), you'll get to > > touch and interact with a lot of different things with very little > > "total" responsibility. > > > > From jared at puck.nether.net Sat Nov 26 14:14:47 2011 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 26 Nov 2011 15:14:47 -0500 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> Message-ID: +1 This isn't the pentagon papers. Those found leaking should face the legal consequences for sbu information leakage. One can't have every email/memo leaked as it makes it unfeasible to perform ones job. Jared Mauch On Nov 26, 2011, at 7:51 AM, "andrew.wallace" wrote: > My comment about a certain person leaking public-private sector correspondence to the media still applies then. > > https://plus.google.com/114359738470992181937/posts/DSnJfKqrJK1 > > > Andrew > > > > ________________________________ > From: Jay Ashworth > To: NANOG > Sent: Saturday, November 26, 2011 3:14 AM > Subject: Water Utility SCADA 'Attack': The, um, washout > > Not an attack: an already failing pump, and an employee of a contractor to the > utility who was ... wait for it ... > > traveling in Russia on personal business. > > WaPo via Lauren @ Privacy: http://j.mp/rrvMXR > > 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 andrew.wallace at rocketmail.com Sat Nov 26 16:18:05 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 26 Nov 2011 14:18:05 -0800 (PST) Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> Message-ID: <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> These reports are ment for private sector eyes only. I suggest new secrecy legislation, for fusion centres. Andrew ________________________________ From: Jared Mauch To: andrew.wallace Cc: Jay Ashworth ; "nanog at nanog.org" Sent: Saturday, November 26, 2011 8:14 PM Subject: Re: Water Utility SCADA 'Attack': The, um, washout +1 This isn't the pentagon papers. Those found leaking should face the legal consequences for sbu information leakage. One can't have every email/memo leaked as it makes it unfeasible to perform ones job. Jared Mauch On Nov 26, 2011, at 7:51 AM, "andrew.wallace" wrote: > My comment about a certain person leaking public-private sector correspondence to the media still applies then. > > https://plus.google.com/114359738470992181937/posts/DSnJfKqrJK1 > > > Andrew > > > > ________________________________ > From: Jay Ashworth > To: NANOG > Sent: Saturday, November 26, 2011 3:14 AM > Subject: Water Utility SCADA 'Attack': The, um, washout > > Not an attack: an already failing pump, and an employee of a contractor to the > utility who was ... wait for it ... > > traveling in Russia on personal business. > > WaPo via Lauren @ Privacy:? http://j.mp/rrvMXR > > 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 jared at puck.nether.net Sat Nov 26 16:38:55 2011 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 26 Nov 2011 17:38:55 -0500 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> Message-ID: <6E081202-9ED7-4798-B8BD-B899A352C514@puck.nether.net> On Nov 26, 2011, at 5:18 PM, andrew.wallace wrote: > These reports are ment for private sector eyes only. I suggest new secrecy legislation, for fusion centres. It already exists :) People may be subject to prosecution for leaking this to the public. It's that simple. Problem is it can't be undone, so it's not an interesting case in some regards... - Jared From andrew.wallace at rocketmail.com Sat Nov 26 16:52:59 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 26 Nov 2011 14:52:59 -0800 (PST) Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: <6E081202-9ED7-4798-B8BD-B899A352C514@puck.nether.net> References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> <6E081202-9ED7-4798-B8BD-B899A352C514@puck.nether.net> Message-ID: <1322347979.95029.YahooMailNeo@web162106.mail.bf1.yahoo.com> I expect to see Joe Bloggs arrested next week then, it won't happen though. Andrew ________________________________ From: Jared Mauch To: andrew.wallace Cc: "nanog at nanog.org" Sent: Saturday, November 26, 2011 10:38 PM Subject: Re: Water Utility SCADA 'Attack': The, um, washout On Nov 26, 2011, at 5:18 PM, andrew.wallace wrote: > These reports are ment for private sector eyes only. I suggest new secrecy legislation, for fusion centres. It already exists :) People may be subject to prosecution for leaking this to the public.? It's that simple.? Problem is it can't be undone, so it's not an interesting case in some regards... - Jared From Valdis.Kletnieks at vt.edu Sat Nov 26 18:40:12 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 26 Nov 2011 19:40:12 -0500 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: Your message of "Sat, 26 Nov 2011 17:38:55 EST." <6E081202-9ED7-4798-B8BD-B899A352C514@puck.nether.net> References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> <6E081202-9ED7-4798-B8BD-B899A352C514@puck.nether.net> Message-ID: <970.1322354412@turing-police.cc.vt.edu> On Sat, 26 Nov 2011 17:38:55 EST, Jared Mauch said: > > I suggest new secrecy legislation, for fusion centres. > It already exists :) > People may be subject to prosecution for leaking this to the public. > It's that simple. Problem is it can't be undone, so it's not an > interesting case in some regards... Actually, it's *not* that simple - it's complicated enough that a quick knee-jerk "There should be a law against it" reaction is probably a bad idea. (In fact, I'll go out on a limb and say that one-sentence "there should be a law agains it" reactios are almost always a bad idea). After all, fusion centers were originally created because too many agencies had laws and regulations banning the sharing of information. We saw a decade ago just how well *that* worked out for us. So it's not at all clear that "new" laws making things *more* classified are a good idea in this case. Nor is it obvious how to code useful laws to prohibit the dissemination of data from a group set up for the express purpose of mining data and disseminating the results. Sure you can tighten things down, but if a fusion center can't release something quickly, it's not a lot of use, is it? (We've more than once gotten stuff from various TLA's stamped with a default "No Foreign Nationals" that ended up being totally unusable because we've got foreign nationals all over the place, and had to wait for a second copy that had gotten kicked down to "FOUO" so we could use it - loads of fun) So the last thing we need is people who don't even know what laws already exist calling for the creation of *new* laws. And quite frankly, which way do you want these things to fail? Do you want an early alert that says "evil packets may be coming in from Russia", or do you want it to wait till they've verified it's a contractor's employee ssh'ing in while on vacation? Sure, a few people have some egg on their faces and now have a really good bar story. But let's keep in mind that it took several days to sort this one out - coincidentally, just about the same number of day that it took Sony to come out and say that PSN got whacked. You really can't have it both ways. Which do you want, false positives or false negatives? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mansaxel at besserwisser.org Sun Nov 27 01:24:29 2011 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 27 Nov 2011 08:24:29 +0100 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> Message-ID: <20111127072428.GH4243@besserwisser.org> Subject: Re: Water Utility SCADA 'Attack': The, um, washout Date: Sat, Nov 26, 2011 at 03:14:47PM -0500 Quoting Jared Mauch (jared at puck.nether.net): > +1 > > This isn't the pentagon papers. > > Those found leaking should face the legal consequences for sbu information leakage. > > One can't have every email/memo leaked as it makes it unfeasible to perform ones job. Your work email inbox is public record in Sweden, if you are a public employee. If you want something secret, you'll have to work hard for it to be so. Same goes for any file that is not a work-in-progress. (Official notes from a meeting for instance.) It works. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Th' MIND is the Pizza Palace of th' SOUL -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jerry at jdixon.com Sun Nov 27 06:41:37 2011 From: jerry at jdixon.com (Jerry Dixon) Date: Sun, 27 Nov 2011 07:41:37 -0500 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> Message-ID: <0F9A1B38-9DA1-434E-820B-930EF5E6A830@jdixon.com> There is already a law on the books called Protected Critical Infrastructure Information (PCII). It has stiff penalties for leaking the information. The reporting critical infrastructure company has to request the information or report be protected under PCII. In most cases the companies also use their own NDA as well for added recourse if the info gets leaked. Also the fusion center or DHS could of offered this option up since most companies do not know this option/law is on the books. For a State Fusion center to leverage this law they have to get a delegation from DHS or at a minimum bring the executive agent in to declare the info PCII since it's a federal law. The PCII designator works and has been used in past incidents. Sensitive but unclassified does not work and has widely varying meanings from agency to agency. If it's that sensitive use PCII or classify as SECRET. Regarding this incident, I was skeptical from the get go. The fog of war around any incident is usually pretty thick at the initial stage. This has been shown even in national level cyber exercises time and time again. FBI/USSS/US-CERT are routinely engaged and investigating cyber incidents and nothing new here. People acted as if that was outside the norm when it was not. Jerry Jerry at jdixon.com On Nov 26, 2011, at 3:14 PM, Jared Mauch wrote: > +1 > > This isn't the pentagon papers. > > Those found leaking should face the legal consequences for sbu information leakage. > > One can't have every email/memo leaked as it makes it unfeasible to perform ones job. > > Jared Mauch > > On Nov 26, 2011, at 7:51 AM, "andrew.wallace" wrote: > >> My comment about a certain person leaking public-private sector correspondence to the media still applies then. >> >> https://plus.google.com/114359738470992181937/posts/DSnJfKqrJK1 >> >> >> Andrew >> >> >> >> ________________________________ >> From: Jay Ashworth >> To: NANOG >> Sent: Saturday, November 26, 2011 3:14 AM >> Subject: Water Utility SCADA 'Attack': The, um, washout >> >> Not an attack: an already failing pump, and an employee of a contractor to the >> utility who was ... wait for it ... >> >> traveling in Russia on personal business. >> >> WaPo via Lauren @ Privacy: http://j.mp/rrvMXR >> >> 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 nixon at nsc.liu.se Mon Nov 28 03:43:05 2011 From: nixon at nsc.liu.se (Leif Nixon) Date: Mon, 28 Nov 2011 10:43:05 +0100 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> (andrew wallace's message of "Sat, 26 Nov 2011 14:18:05 -0800 (PST)") References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> Message-ID: "andrew.wallace" writes: > These reports are ment for private sector eyes only. I suggest new secrecy legislation, for fusion centres. Making it harder to share information on incidents and vulnerabilities is not the best of ideas. Over the last ten years I have seen much, much, MUCH more damage resulting from information *not* being shared than from information being improperly shared. -- Leif Nixon - Security officer National Supercomputer Centre - Swedish National Infrastructure for Computing Nordic Data Grid Facility - European Grid Infrastructure From owen at delong.com Mon Nov 28 04:31:11 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Nov 2011 02:31:11 -0800 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> Message-ID: <547E8B2E-0498-4A92-99E6-2CC905A6A40C@delong.com> On Nov 28, 2011, at 1:43 AM, Leif Nixon wrote: > "andrew.wallace" writes: > >> These reports are ment for private sector eyes only. I suggest new secrecy legislation, for fusion centres. > > Making it harder to share information on incidents and vulnerabilities > is not the best of ideas. > > Over the last ten years I have seen much, much, MUCH more damage > resulting from information *not* being shared than from information > being improperly shared. > > -- > Leif Nixon - Security officer > National Supercomputer Centre - Swedish National Infrastructure for Computing > Nordic Data Grid Facility - European Grid Infrastructure Generally, I agree with you, but, FUD is not information. Spreading FUD (as is the case in this incident more than information) is more harmful than good. Making it harder to spread misinformation and FUD is good. Making it harder to share information is bad. Information is the anti-FUD. Owen From rdobbins at arbor.net Mon Nov 28 04:40:04 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Nov 2011 10:40:04 +0000 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: <547E8B2E-0498-4A92-99E6-2CC905A6A40C@delong.com> References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> <547E8B2E-0498-4A92-99E6-2CC905A6A40C@delong.com> Message-ID: <83C94D35-F418-4C23-BDDB-0114AFA0C1D6@arbor.net> On Nov 28, 2011, at 5:31 PM, Owen DeLong wrote: > Making it harder to spread misinformation and FUD is good. > Making it harder to share information is bad. Unfortunately, it's often quite difficult to distinguish between the two when formulating policies, regulations, legislation, and so forth. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From owen at delong.com Mon Nov 28 04:52:55 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Nov 2011 02:52:55 -0800 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: <83C94D35-F418-4C23-BDDB-0114AFA0C1D6@arbor.net> References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> <547E8B2E-0498-4A92-99E6-2CC905A6A40C@delong.com> <83C94D35-F418-4C23-BDDB-0114AFA0C1D6@arbor.net> Message-ID: <743833A1-96A6-4929-8139-3C056E6E7CF7@delong.com> On Nov 28, 2011, at 2:40 AM, Dobbins, Roland wrote: > > On Nov 28, 2011, at 5:31 PM, Owen DeLong wrote: > >> Making it harder to spread misinformation and FUD is good. >> Making it harder to share information is bad. > > Unfortunately, it's often quite difficult to distinguish between the two when formulating policies, regulations, legislation, and so forth. That might be because FUD is usually the main ingredient in policies, regulations, legislation, etc. for the last 2 decades at least. Politicians seem to be addicted to FUD like a baby born on crystal meth. At least in the US. Owen From doctorchd at gmail.com Mon Nov 28 05:37:16 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Mon, 28 Nov 2011 13:37:16 +0200 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? Message-ID: Hello everybody, It is commonly agreed that /64 is maximal length for LANs because if we use longer prefix we introduce conflict with stateless address autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used in DOCSIS networks. So there seems to be no objections to use smaller networks per cable interfaces of CMTS. I was not able to find any recommendations anywhere including Cable Labs specs for using prefixes not greater then /64 in DOCSIS networks. Some tech from ISP assumed that DHCPv6 server may generate interface ID part of IPv6 address similarly to EUI-64 so MAC address of the device can easily be obtained from its IPv6 address, but this does not seem like convincing argument. What do you think? Dmitry Cherkasov From luispalmaster at gmail.com Mon Nov 28 07:39:42 2011 From: luispalmaster at gmail.com (Luis Palma) Date: Mon, 28 Nov 2011 10:39:42 -0300 Subject: Bandwidth prediction tool? Message-ID: Hi, Does anyone know a good Bandwidth Prediction tool?. We have a DPI solution based on SCE8000 + SM/CM from Cisco and we are looking a tool that can take a data from Collector Manager Database and make traffic Bandwidth prediction and customer behavior prediction. Any idea will be welcome. Regards, From rps at maine.edu Mon Nov 28 09:29:11 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 28 Nov 2011 10:29:11 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: Message-ID: It's a good practice to reserve a 64-bit prefix for each network. That's a good general rule. For point to point or link networks you can use something as small as a 126-bit prefix (we do). When it comes to implementation, though, it's not as simple as a yes or no answer. The actual use of 64-bit prefixes is not something I would currently recommend for large-scale deployments due to the denial of service attack vector it opens up (neighbor table exhaustion). Not using 64-bit prefixes tosses SLAAC out the window; but for many networks SLAAC may not be desirable anyway due to the lack of control it presents. Once vendors come out with routers that are able to protect against neighbor table exhaustion, moving to a 64-bit prefix (which you hopefully reserved) will allow you to be more flexible in what addressing methods are used. On Mon, Nov 28, 2011 at 6:37 AM, Dmitry Cherkasov wrote: > Hello everybody, > > It is commonly agreed that /64 is maximal length for LANs because if > we use longer prefix we introduce conflict with stateless address > autoconfiguration (SLAAC) based on EUI-64 spec. But ?SLAAC is not used > in DOCSIS networks. So there seems to be no objections to use smaller > networks per cable interfaces of CMTS. I was not able to find any > recommendations anywhere including Cable Labs specs for using > prefixes not greater then /64 in DOCSIS networks. Some tech from ISP > assumed that DHCPv6 server may generate interface ID part of IPv6 > address similarly to EUI-64 so MAC address of the device can easily be > obtained from its IPv6 address, but this does not seem like convincing > argument. What do you think? > > > Dmitry Cherkasov > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From kyle.creyts at gmail.com Mon Nov 28 10:36:04 2011 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Mon, 28 Nov 2011 11:36:04 -0500 Subject: Water Utility SCADA 'Attack': The, um, washout In-Reply-To: <970.1322354412@turing-police.cc.vt.edu> References: <10641490.396.1322277251136.JavaMail.root@benjamin.baylink.com> <1322311907.72664.YahooMailNeo@web162116.mail.bf1.yahoo.com> <1322345885.11575.YahooMailNeo@web162101.mail.bf1.yahoo.com> <6E081202-9ED7-4798-B8BD-B899A352C514@puck.nether.net> <970.1322354412@turing-police.cc.vt.edu> Message-ID: I would actually carry this to another level, and say this "leak" could be considered evidence that the fusion centers are working quite well. The fact is that a fusion center, in this case, enabled the community to: 1)respond to an event (together); 2)know where to contribute any coordinating information, now or in the future; 3)be on the lookout for similar events; 4)raise awareness about a perceived problem that doesn't seem to be getting better; 5)perceive a measure of transparency in the operation and utility of these fusion centers. >From where I stand this disclosure being dubbed a "leak" is improper. Perhaps it was a leak, perhaps it was an intentional disclosure. Either way, it showed that fusion centers are working to escalate the attention given to potentially serious issues, with a defined benefit to the community they serve, while operating with an appropriate degree of cooperation between TLAs. And while there was media FUD early on, the final output was clear, concise, and non-speculative. On Sat, Nov 26, 2011 at 7:40 PM, wrote: > On Sat, 26 Nov 2011 17:38:55 EST, Jared Mauch said: > > > > I suggest new secrecy legislation, for fusion centres. > > > It already exists :) > > > People may be subject to prosecution for leaking this to the public. > > It's that simple. Problem is it can't be undone, so it's not an > > interesting case in some regards... > > Actually, it's *not* that simple - it's complicated enough that a quick > knee-jerk "There should be a law against it" reaction is probably a bad > idea. > (In fact, I'll go out on a limb and say that one-sentence "there should be > a > law agains it" reactios are almost always a bad idea). > > After all, fusion centers were originally created because too many > agencies had > laws and regulations banning the sharing of information. We saw a decade > ago > just how well *that* worked out for us. So it's not at all clear that "new" > laws making things *more* classified are a good idea in this case. Nor is > it > obvious how to code useful laws to prohibit the dissemination of data from > a > group set up for the express purpose of mining data and disseminating the > results. Sure you can tighten things down, but if a fusion center can't > release something quickly, it's not a lot of use, is it? > > (We've more than once gotten stuff from various TLA's stamped with a > default > "No Foreign Nationals" that ended up being totally unusable because we've > got > foreign nationals all over the place, and had to wait for a second copy > that > had gotten kicked down to "FOUO" so we could use it - loads of fun) > > So the last thing we need is people who don't even know what laws already > exist > calling for the creation of *new* laws. > > And quite frankly, which way do you want these things to fail? Do you > want an > early alert that says "evil packets may be coming in from Russia", or do > you > want it to wait till they've verified it's a contractor's employee ssh'ing > in > while on vacation? Sure, a few people have some egg on their faces and now > have > a really good bar story. But let's keep in mind that it took several days > to > sort this one out - coincidentally, just about the same number of day that > it > took Sony to come out and say that PSN got whacked. > > You really can't have it both ways. Which do you want, false positives or > false negatives? > > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From scg at gibbard.org Mon Nov 28 11:47:34 2011 From: scg at gibbard.org (Steve Gibbard) Date: Mon, 28 Nov 2011 09:47:34 -0800 Subject: Network device command line interfaces In-Reply-To: References: <201111250501.pAP51LVT015635@mail.r-bonomi.com> Message-ID: What this really comes down to, I think, is figuring out how your "gut level" concerns fit into the big picture, and to then put that into terms that the people responsible for the big picture can use to make a good decision. Finances do matter. Getting your employer to spend money it doesn't have to on network equipment generally means there's less money available to spend on other things that might matter, like making your network bigger, hiring people to help you, or even keeping you employed. If you want to spend more on equipment than the bare minimum, you ought to have a reason. To get anybody else to come to the same conclusion, you ought to be able to explain that reason. That said, I think it's valid to buy something because you're comfortable with it, and valid to not buy something because you're not comfortable with it. "I don't want to buy new device X because I don't want to have to learn how to use it" sounds lazy, but most of us are busy, and if the device you're comfortable with will do the job for an affordable price, it's generally good not to create extra work for yourself. Saying "we shouldn't do that because I don't know how" is hard. It may be because something is new and complicated, and nobody has experience with it. Or it may be because you're not familiar with it when lots of other people are. You may have a different specialty, or it may be because you're less experienced than the people they could have hired if they'd paid or shopped around more. But, your expertise or lack thereof is a legitimate thing to take into account when making decisions, as is the likely expertise of people who will have to manage the system in the future. Unfamiliar network equipment is expensive to manage, whether the CLI is well done or not. Even in a one person shop, you won't yet have encountered the device's pitfalls -- its easily circumventable bugs, the configurations that seem intuitive but aren't, etc. It's going to take you longer to design and configure your networks, and you're going to create problems by doing the wrong thing more often. You're probably going cause some outages, or even buy equipment and then find that you missed something and need to buy something else. If you work with a large team, and maybe even have NOC people working the night shift in another location supporting the thing, it gets worse. All those people have to be trained on the new device, and come up to speed on it. It's also good to understand the reliability requirements for something you're building. We don't have licensing requirements for Network Engineers, but some other more established engineering professions do. If a structural engineer signs off on a building despite being unfamiliar with some aspect of the construction technology and the building collapses, that can be career ending. Internet networks that have become pretty important too. If you're building a network where a failure will cause a heart attack victim to not be able to call 911 from their VOIP phone, it isn't good enough to say "I've never seen this piece of equipment but I don't have any reason to think it won't work." If you're building a network to connect some office PCs, the stakes are probably lower. And, of course, there's also the option of learning about unfamiliar technology. Play with it in your lab. Put it in a peripheral site that can fail without causing too many problems. Get your NOC staff familiar with it. And maybe, in the end, you'll find that you actually like it. That it does something your old hardware doesn't. That cheap hardware lets you afford a level of redundancy, and thus reliability, that was simply unaffordable with you're previously preferred equipment. But that testing and familiarity has a cost, just as buying expensive equipment does, and just as running unfamiliar equipment does. It's a matter of balancing it all out, and coming to an agreement with your management on what the best strategy is. -Steve On Nov 25, 2011, at 8:15 AM, Joel Maslak wrote: > On Fri, Nov 25, 2011 at 12:01 AM, Robert Bonomi wrote: > > >> The trick to deailing with this as a propellorhead[sic] is to include a >> *monetized* estimate of the increased manpower OPEX of using the 'dog to >> work with' box. And a TCOS figure over the projected lifetime of the >> units. No need to 'fight' with management about it, just understand >> 'how' they make the decisions, and give them the informatin they need >> to make the decision come out 'your way'. >> > > I'd say that the ethical thing to do is to give them the information they > need to make a decision, not to get it your way. I see, for instance, > people buying local closet switches from brand A when brand B is much, much > cheaper (but lacks the prestige of brand A), had a perfectly workable > management interface, and will perform identically, with similar support > offered by both vendors. But they are an ACNA or whatever, or they've just > heard of (insert brand here), so they buy it. Because it's easy and > familiar. > > It's also possible that a web managed switch (which I despise) might > actually be the right choice for a business - because factors other than a > technologist's distaste might be important. > > Part of being ethical (and NOT like the business people we might all > despise!) is to be honest. So we don't compare brand A to brand B > unfairly. We don't inflate the cost of brand B by adding brand B's > management infrastructure to the cost when we darn well know we just will > need a minor tweak to our scripts that can already manage brand A. That > sort of thing. > > I generally agree with what Robert said: It's about what makes sense to the > business. If operating expenses will increase ("Well have to grow > headcount by 3 to support this"), then bring that up. A caution though: > "Takes less effort to run" doesn't equate to dollars (the question a former > manager would ask me when I tried that line was, "So who do you think we > should lay off then to get the dollar savings?" Fortunately he was a good > manager who wasn't serious, but was rather trying to get me to think about > what I'm saying). I like paychecks, which is why I work for a living - > it's about the dollars. So it's not unreasonable for my management to also > care about the money (since it's a key motivation for myself, after all!). > Yes, I'm fortunate to do a job I love and get paid for it at the same time. > > I can say, for a CUI interface, operations over low-speed links (wireless > VPN when I'm away from the office and in a bad cell zone, for instance) is > likely important. So is ability to script common tasks to allow people > like the help desk to do their jobs at low risk. Flexibility is also > important - when I'm stuck with this piece of gear (which is shiny today) > in 5-7 years, when it's not so shiny, is it going to have flexibility to > last a bit longer if the business needs to conserve cash - or will a minor > change in how we do business make this thing functionally obsolete? > > Relating to the discussion on the tier 1 mentor thread, someone who wants > to go far in networking won't be married to a particular vendor or way of > doing things. They'll excel and find ways to overcome challenges, > including less than perfect equipment, that they might have to deal with. > They'll do so in a way that makes the customer and their own management > happy. A highly paid network engineer who complains about work being > difficult probably won't do that. One that finds a $500 replacement for a > $5000 router probably will stick around, provided they can actually deliver > what they promised (the guy that puts the $500 replacement in only to have > to replace it in a year with a $5000 router again won't go far, so be > careful! And you better have figured in the real costs of running a network > with $500 routers, not just the cost of the router). From rps at maine.edu Mon Nov 28 12:25:21 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 28 Nov 2011 13:25:21 -0500 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: One of the biggest benefits to a CLI is the ability to easily script tasks. In a Cisco environment I can roll out major changes to hundreds of switches in seconds, for example. A lot of network vendors have been trying to make network devices more simple and easier to use while the complexity of networking has gone up. Seems like the wrong direction to me. If someone wants a managed switch, they probably intend to manage it. I think a big key to the success of Cisco (and Juniper, etc) has been that they "get it" in this respect. Even companies like Vyatta have invested time in a Web UI rather than expanding the core functionality offered (multicast routing support, for example), which doesn't seem like the best idea. On Wed, Nov 23, 2011 at 11:41 PM, Jonathon Exley < Jonathon.Exley at kordia.co.nz> wrote: > Does anyone else despair at the CLIs produced by networking vendors? > Real routers use a CLI that is command based, like IOS, TiMOS or Junos. > These interfaces work well over low bandwidth connections (unlike web > interfaces), can work with config backup systems like RANCID, have a > (mostly) consistent structure and good show commands. > However vendors of low cost routers/switches/muxes seem to take a stab in > the dark and produce some really nasty stuff. I have a personal hate of > text based menus and binary config backup files. > Doe this p*** off anyone else? The business part of the company says "This > device is great! It's cheap and does everything." However the poor sap who > is given the task to make it work has to wrestle with a badly designed user > interface and illogical syntax. > Maybe the vendors need some sort of best practices guide for what > manageability features their kit needs to support to make them acceptable > to the market. Does anyone know if there is anything along these lines? > > > Jonathon. > > > 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). > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From james at freedomnet.co.nz Mon Nov 28 12:32:03 2011 From: james at freedomnet.co.nz (James Jones) Date: Mon, 28 Nov 2011 13:32:03 -0500 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: On Mon, Nov 28, 2011 at 1:25 PM, Ray Soucy wrote: > One of the biggest benefits to a CLI is the ability to easily script tasks. > In a Cisco environment I can roll out major changes to hundreds of > switches in seconds, for example. > > A lot of network vendors have been trying to make network devices more > simple and easier to use while the complexity of networking has gone up. > Seems like the wrong direction to me. If someone wants a managed switch, > they probably intend to manage it. > > I think a big key to the success of Cisco (and Juniper, etc) has been that > they "get it" in this respect. > > Even companies like Vyatta have invested time in a Web UI rather than > expanding the core functionality offered (multicast routing support, for > example), which doesn't seem like the best idea. > > On Wed, Nov 23, 2011 at 11:41 PM, Jonathon Exley < > Jonathon.Exley at kordia.co.nz> wrote: > > > Does anyone else despair at the CLIs produced by networking vendors? > > Real routers use a CLI that is command based, like IOS, TiMOS or Junos. > > These interfaces work well over low bandwidth connections (unlike web > > interfaces), can work with config backup systems like RANCID, have a > > (mostly) consistent structure and good show commands. > > However vendors of low cost routers/switches/muxes seem to take a stab in > > the dark and produce some really nasty stuff. I have a personal hate of > > text based menus and binary config backup files. > > Doe this p*** off anyone else? The business part of the company says > "This > > device is great! It's cheap and does everything." However the poor sap > who > > is given the task to make it work has to wrestle with a badly designed > user > > interface and illogical syntax. > > Maybe the vendors need some sort of best practices guide for what > > manageability features their kit needs to support to make them acceptable > > to the market. Does anyone know if there is anything along these lines? > > > > > > Jonathon. > > > > > > 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). > > > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > Well said. I write scripts all day long to perform automation on networking equipment. A device needs to have a CLI, but if you have a GUI too make for darn sure that I can access all features in either one. From jra at baylink.com Mon Nov 28 12:32:02 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 28 Nov 2011 13:32:02 -0500 (EST) Subject: Network device command line interfaces In-Reply-To: Message-ID: <32875795.632.1322505122248.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Ray Soucy" > If someone wants a managed switch, they probably intend to manage it. And that's all there is to be said about that. Nicely played, Ray. 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 a.harrowell at gmail.com Mon Nov 28 12:32:53 2011 From: a.harrowell at gmail.com (Alex Harrowell) Date: Mon, 28 Nov 2011 18:32:53 +0000 Subject: Network device command line interfaces In-Reply-To: References: Message-ID: <9d41aecd-dd12-44b9-bf27-c7553121b7e7@email.android.com> Ray Soucy wrote: >One of the biggest benefits to a CLI is the ability to easily script >tasks. > In a Cisco environment I can roll out major changes to hundreds of >switches in seconds, for example. > >A lot of network vendors have been trying to make network devices more >simple and easier to use while the complexity of networking has gone >up. >Seems like the wrong direction to me. If someone wants a managed >switch, >they probably intend to manage it. > >I think a big key to the success of Cisco (and Juniper, etc) has been >that >they "get it" in this respect. > >Even companies like Vyatta have invested time in a Web UI rather than >expanding the core functionality offered (multicast routing support, >for >example), which doesn't seem like the best idea. > >On Wed, Nov 23, 2011 at 11:41 PM, Jonathon Exley < >Jonathon.Exley at kordia.co.nz> wrote: > >> Does anyone else despair at the CLIs produced by networking vendors? >> Real routers use a CLI that is command based, like IOS, TiMOS or >Junos. >> These interfaces work well over low bandwidth connections (unlike web >> interfaces), can work with config backup systems like RANCID, have a >> (mostly) consistent structure and good show commands. >> However vendors of low cost routers/switches/muxes seem to take a >stab in >> the dark and produce some really nasty stuff. I have a personal hate >of >> text based menus and binary config backup files. >> Doe this p*** off anyone else? The business part of the company says >"This >> device is great! It's cheap and does everything." However the poor >sap who >> is given the task to make it work has to wrestle with a badly >designed user >> interface and illogical syntax. >> Maybe the vendors need some sort of best practices guide for what >> manageability features their kit needs to support to make them >acceptable >> to the market. Does anyone know if there is anything along these >lines? >> >> >> Jonathon. >> >> >> 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). >> > > > >-- >Ray Soucy > >Epic Communications Specialist > >Phone: +1 (207) 561-3526 > >Networkmaine, a Unit of the University of Maine System >http://www.networkmaine.net/ If you've done a proper CLI, you can easily do a good REST API. If you've done that a good Web GUI is possible. It doesn't work the other way round. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From Valdis.Kletnieks at vt.edu Mon Nov 28 12:47:19 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 28 Nov 2011 13:47:19 -0500 Subject: Network device command line interfaces In-Reply-To: Your message of "Mon, 28 Nov 2011 13:25:21 EST." References: Message-ID: <8790.1322506039@turing-police.cc.vt.edu> On Mon, 28 Nov 2011 13:25:21 EST, Ray Soucy said: > Even companies like Vyatta have invested time in a Web UI rather than > expanding the core functionality offered (multicast routing support, for > example), which doesn't seem like the best idea. Compare the number of customers that insist on a web-gui interface to the number of customers that are insisting on multicast routing support. (Having said that, a sane CLI provides a good basis for a web interface, so is good engineering whether or not you need multicast ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jra at baylink.com Mon Nov 28 13:03:12 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 28 Nov 2011 14:03:12 -0500 (EST) Subject: Network device command line interfaces In-Reply-To: Message-ID: <852264.640.1322506992510.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "James Jones" > Well said. I write scripts all day long to perform automation on networking > equipment. A device needs to have a CLI, but if you have a GUI too make for > darn sure that I can access all features in either one. It is a relatively well established (though not always *followed*) principle of software design that you should build a CLI that can do everything, and then *build your GUI on top of that*. Among other things, this design pattern makes it easy to capture the commands generated by a GUI session, and script them for later use. 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 rps at maine.edu Mon Nov 28 14:35:40 2011 From: rps at maine.edu (Ray Soucy) Date: Mon, 28 Nov 2011 15:35:40 -0500 Subject: Network device command line interfaces In-Reply-To: <9d41aecd-dd12-44b9-bf27-c7553121b7e7@email.android.com> References: <9d41aecd-dd12-44b9-bf27-c7553121b7e7@email.android.com> Message-ID: > If you've done a proper CLI, you can easily do a good REST API. If you've done that a good Web GUI is possible. This. I would love a good REST API for everything; I would almost be willing to give up the CLI for it (almost). -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From james at freedomnet.co.nz Mon Nov 28 14:48:27 2011 From: james at freedomnet.co.nz (James Jones) Date: Mon, 28 Nov 2011 15:48:27 -0500 Subject: Network device command line interfaces In-Reply-To: References: <9d41aecd-dd12-44b9-bf27-c7553121b7e7@email.android.com> Message-ID: Would love to a good open source TR69 interface. On Mon, Nov 28, 2011 at 3:35 PM, Ray Soucy wrote: > > If you've done a proper CLI, you can easily do a good REST API. If > you've done that a good Web GUI is possible. > > This. > > I would love a good REST API for everything; I would almost be willing > to give up the CLI for it (almost). > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > > From owen at delong.com Mon Nov 28 15:43:37 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Nov 2011 13:43:37 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: Message-ID: <3729C1E0-D8AF-479F-A50B-18EFE4407543@delong.com> You can probably do it, but, what do you gain by doing so? Owen On Nov 28, 2011, at 3:37 AM, Dmitry Cherkasov wrote: > Hello everybody, > > It is commonly agreed that /64 is maximal length for LANs because if > we use longer prefix we introduce conflict with stateless address > autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used > in DOCSIS networks. So there seems to be no objections to use smaller > networks per cable interfaces of CMTS. I was not able to find any > recommendations anywhere including Cable Labs specs for using > prefixes not greater then /64 in DOCSIS networks. Some tech from ISP > assumed that DHCPv6 server may generate interface ID part of IPv6 > address similarly to EUI-64 so MAC address of the device can easily be > obtained from its IPv6 address, but this does not seem like convincing > argument. What do you think? > > > Dmitry Cherkasov From owen at delong.com Mon Nov 28 15:51:52 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Nov 2011 13:51:52 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: Message-ID: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: > It's a good practice to reserve a 64-bit prefix for each network. > That's a good general rule. For point to point or link networks you > can use something as small as a 126-bit prefix (we do). > Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring. Owen From smb at cs.columbia.edu Mon Nov 28 16:00:14 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 28 Nov 2011 17:00:14 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> Message-ID: <7ECD6B0E-D104-4B10-8729-79F1AD7363BD@cs.columbia.edu> On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote: > > On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: > >> It's a good practice to reserve a 64-bit prefix for each network. >> That's a good general rule. For point to point or link networks you >> can use something as small as a 126-bit prefix (we do). >> > > Technically, absent buggy {firm,soft}ware, you can use a /127. There's no > actual benefit to doing anything longer than a /64 unless you have > buggy *ware (ping pong attacks only work against buggy *ware), > and there can be some advantages to choosing addresses other than > ::1 and ::2 in some cases. If you're letting outside packets target your > point-to-point links, you have bigger problems than neighbor table > attacks. If not, then the neighbor table attack is a bit of a red-herring. > The context is DOCSIS, i.e., primarily residential cable modem users, and the cable company ISPs do not want to spend time on customer care and hand-holding. How are most v6 machines configured by default? That is, what did Microsoft do for Windows Vista and Windows 7? If they're set for stateless autoconfig, I strongly suspect that most ISPs will want to stick with that and hand out /64s to each network. (That's apart from the larger question of why they should want to do anything else...) --Steve Bellovin, https://www.cs.columbia.edu/~smb From John_Brzozowski at Cable.Comcast.com Mon Nov 28 16:30:57 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Mon, 28 Nov 2011 22:30:57 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: Message-ID: Dmitry, You could consider the use of prefixes longer than the /64 on CMTS interfaces, however, it is not clear to me why this would be done. Further, most DHCPv6 implementations do not require that the generated IPv6 address be eui-64 based. A randomized algorithm could also be used. Another consideration is what happens after IPv6 is used for addressing cable modems. What happens when you want to address CPE or CPE routers? You are right back to /64 or shorter depending on the type of device being provisioned. FWIW - we have found that there are distinct benefits to using IPv6 beyond the amount of addresses that are available. The use of /64 is tightly coupled with these benefits. Can you elaborate as to why one would want to or need to use prefixes longer than /64? John On 11/28/11 6:37 AM, "Dmitry Cherkasov" wrote: >Hello everybody, > >It is commonly agreed that /64 is maximal length for LANs because if >we use longer prefix we introduce conflict with stateless address >autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used >in DOCSIS networks. So there seems to be no objections to use smaller >networks per cable interfaces of CMTS. I was not able to find any >recommendations anywhere including Cable Labs specs for using >prefixes not greater then /64 in DOCSIS networks. Some tech from ISP >assumed that DHCPv6 server may generate interface ID part of IPv6 >address similarly to EUI-64 so MAC address of the device can easily be >obtained from its IPv6 address, but this does not seem like convincing >argument. What do you think? > > >Dmitry Cherkasov > From John_Brzozowski at Cable.Comcast.com Mon Nov 28 16:33:41 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Mon, 28 Nov 2011 22:33:41 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: Message-ID: On 11/28/11 10:29 AM, "Ray Soucy" wrote: >It's a good practice to reserve a 64-bit prefix for each network. >That's a good general rule. For point to point or link networks you >can use something as small as a 126-bit prefix (we do). [jjmb] for point to point I agree with this point. If a /64 is reserved one has greater flexibility as far as what is configured on the interfaces. > >When it comes to implementation, though, it's not as simple as a yes >or no answer. > >The actual use of 64-bit prefixes is not something I would currently >recommend for large-scale deployments due to the denial of service >attack vector it opens up (neighbor table exhaustion). [jjmb] not sure I agree, this depends on where the prefix is being installed in the network. > >Not using 64-bit prefixes tosses SLAAC out the window; but for many >networks SLAAC may not be desirable anyway due to the lack of control >it presents. > >Once vendors come out with routers that are able to protect against >neighbor table exhaustion, moving to a 64-bit prefix (which you >hopefully reserved) will allow you to be more flexible in what >addressing methods are used. > >On Mon, Nov 28, 2011 at 6:37 AM, Dmitry Cherkasov >wrote: >> Hello everybody, >> >> It is commonly agreed that /64 is maximal length for LANs because if >> we use longer prefix we introduce conflict with stateless address >> autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used >> in DOCSIS networks. So there seems to be no objections to use smaller >> networks per cable interfaces of CMTS. I was not able to find any >> recommendations anywhere including Cable Labs specs for using >> prefixes not greater then /64 in DOCSIS networks. Some tech from ISP >> assumed that DHCPv6 server may generate interface ID part of IPv6 >> address similarly to EUI-64 so MAC address of the device can easily be >> obtained from its IPv6 address, but this does not seem like convincing >> argument. What do you think? >> >> >> Dmitry Cherkasov >> >> > > > >-- >Ray Soucy > >Epic Communications Specialist > >Phone: +1 (207) 561-3526 > >Networkmaine, a Unit of the University of Maine System >http://www.networkmaine.net/ > From John_Brzozowski at Cable.Comcast.com Mon Nov 28 16:38:35 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Mon, 28 Nov 2011 22:38:35 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <7ECD6B0E-D104-4B10-8729-79F1AD7363BD@cs.columbia.edu> Message-ID: I mentioned this in an earlier reply. CM vs CPE vs CPE router are all different use cases. From a CPE or CPE router point of view SLAAC will likely not be used to provisioned devices, stateful DHCPv6 is required. As such Vista/7 machines that are directly connected to cable modems will receive an IPv6 address and configuration options via stateful DHCPv6. The same now applies to OSX Lion. I do agree that many host implementations have been built around /64 assumptions and departures from the same at this time will seemingly introduce more problems that benefits. John On 11/28/11 5:00 PM, "Steven Bellovin" wrote: > >On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote: > >> >> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: >> >>> It's a good practice to reserve a 64-bit prefix for each network. >>> That's a good general rule. For point to point or link networks you >>> can use something as small as a 126-bit prefix (we do). >>> >> >> Technically, absent buggy {firm,soft}ware, you can use a /127. There's >>no >> actual benefit to doing anything longer than a /64 unless you have >> buggy *ware (ping pong attacks only work against buggy *ware), >> and there can be some advantages to choosing addresses other than >> ::1 and ::2 in some cases. If you're letting outside packets target your >> point-to-point links, you have bigger problems than neighbor table >> attacks. If not, then the neighbor table attack is a bit of a >>red-herring. >> > >The context is DOCSIS, i.e., primarily residential cable modem users, and >the cable company ISPs do not want to spend time on customer care and >hand-holding. How are most v6 machines configured by default? That is, >what did Microsoft do for Windows Vista and Windows 7? If they're set for >stateless autoconfig, I strongly suspect that most ISPs will want to stick >with that and hand out /64s to each network. (That's apart from the >larger >question of why they should want to do anything else...) > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > From John_Brzozowski at Cable.Comcast.com Mon Nov 28 16:39:13 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Mon, 28 Nov 2011 22:39:13 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <7ECD6B0E-D104-4B10-8729-79F1AD7363BD@cs.columbia.edu> Message-ID: I mentioned this in an earlier reply. CM vs CPE vs CPE router are all different use cases. From a CPE or CPE router point of view SLAAC will likely not be used to provisioned devices, stateful DHCPv6 is required. As such Vista/7 machines that are directly connected to cable modems will receive an IPv6 address and configuration options via stateful DHCPv6. The same now applies to OSX Lion. I do agree that many host implementations have been built around /64 assumptions and departures from the same at this time will seemingly introduce more problems that benefits. John On 11/28/11 5:00 PM, "Steven Bellovin" wrote: > >On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote: > >> >> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: >> >>> It's a good practice to reserve a 64-bit prefix for each network. >>> That's a good general rule. For point to point or link networks you >>> can use something as small as a 126-bit prefix (we do). >>> >> >> Technically, absent buggy {firm,soft}ware, you can use a /127. There's >>no >> actual benefit to doing anything longer than a /64 unless you have >> buggy *ware (ping pong attacks only work against buggy *ware), >> and there can be some advantages to choosing addresses other than >> ::1 and ::2 in some cases. If you're letting outside packets target your >> point-to-point links, you have bigger problems than neighbor table >> attacks. If not, then the neighbor table attack is a bit of a >>red-herring. >> > >The context is DOCSIS, i.e., primarily residential cable modem users, and >the cable company ISPs do not want to spend time on customer care and >hand-holding. How are most v6 machines configured by default? That is, >what did Microsoft do for Windows Vista and Windows 7? If they're set for >stateless autoconfig, I strongly suspect that most ISPs will want to stick >with that and hand out /64s to each network. (That's apart from the >larger >question of why they should want to do anything else...) > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > From fred at cisco.com Mon Nov 28 17:13:51 2011 From: fred at cisco.com (Fred Baker) Date: Mon, 28 Nov 2011 15:13:51 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: Message-ID: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> Basically, if the address used by a host is allocated using RFC 3971/4861/4941, the host assumes a /64 from the router and concocts a 64 bit EID as specified. If the address used by the host is allocated using DHCP/DHCPv6, it is the 128 bit number assigned by the DHCP server. I see no reason you couldn't use a /127 prefix if the link was point to point. As you note, there is significant deployment of ND, and insignificant deployment of DHCPv6. However, any network that is in control of all of its hosts should be able to specify the use of DHCPv6. On Nov 28, 2011, at 2:39 PM, Brzozowski, John wrote: > I mentioned this in an earlier reply. CM vs CPE vs CPE router are all > different use cases. From a CPE or CPE router point of view SLAAC will > likely not be used to provisioned devices, stateful DHCPv6 is required. > As such Vista/7 machines that are directly connected to cable modems will > receive an IPv6 address and configuration options via stateful DHCPv6. > The same now applies to OSX Lion. > > > I do agree that many host implementations have been built around /64 > assumptions and departures from the same at this time will seemingly > introduce more problems that benefits. > > John > > On 11/28/11 5:00 PM, "Steven Bellovin" wrote: > >> >> On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote: >> >>> >>> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: >>> >>>> It's a good practice to reserve a 64-bit prefix for each network. >>>> That's a good general rule. For point to point or link networks you >>>> can use something as small as a 126-bit prefix (we do). >>>> >>> >>> Technically, absent buggy {firm,soft}ware, you can use a /127. There's >>> no >>> actual benefit to doing anything longer than a /64 unless you have >>> buggy *ware (ping pong attacks only work against buggy *ware), >>> and there can be some advantages to choosing addresses other than >>> ::1 and ::2 in some cases. If you're letting outside packets target your >>> point-to-point links, you have bigger problems than neighbor table >>> attacks. If not, then the neighbor table attack is a bit of a >>> red-herring. >>> >> >> The context is DOCSIS, i.e., primarily residential cable modem users, and >> the cable company ISPs do not want to spend time on customer care and >> hand-holding. How are most v6 machines configured by default? That is, >> what did Microsoft do for Windows Vista and Windows 7? If they're set for >> stateless autoconfig, I strongly suspect that most ISPs will want to stick >> with that and hand out /64s to each network. (That's apart from the >> larger >> question of why they should want to do anything else...) >> >> >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >> >> >> >> >> >> > > From John_Brzozowski at Cable.Comcast.com Mon Nov 28 17:22:52 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Mon, 28 Nov 2011 23:22:52 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> Message-ID: On 11/28/11 6:13 PM, "Fred Baker" wrote: >Basically, if the address used by a host is allocated using RFC >3971/4861/4941, the host assumes a /64 from the router and concocts a 64 >bit EID as specified. If the address used by the host is allocated using >DHCP/DHCPv6, it is the 128 bit number assigned by the DHCP server. I see >no reason you couldn't use a /127 prefix if the link was point to point. [jjmb] How would this address be assigned? Statically? Practically, I do not see how this would be useful. I do agree it is possible. > >As you note, there is significant deployment of ND, and insignificant >deployment of DHCPv6. However, any network that is in control of all of >its hosts should be able to specify the use of DHCPv6. [jjmb] I do not agree about the insignificance of DHCPv6 deployment, ND support is certainly greater. Having control over hosts ie an enterprise environment, creates the opportunity to mandate DHCPv6, it does not always it should be required. Again this depends on the deployment scenario. > >On Nov 28, 2011, at 2:39 PM, Brzozowski, John wrote: > >> I mentioned this in an earlier reply. CM vs CPE vs CPE router are all >> different use cases. From a CPE or CPE router point of view SLAAC will >> likely not be used to provisioned devices, stateful DHCPv6 is required. >> As such Vista/7 machines that are directly connected to cable modems >>will >> receive an IPv6 address and configuration options via stateful DHCPv6. >> The same now applies to OSX Lion. >> >> >> I do agree that many host implementations have been built around /64 >> assumptions and departures from the same at this time will seemingly >> introduce more problems that benefits. >> >> John >> >> On 11/28/11 5:00 PM, "Steven Bellovin" wrote: >> >>> >>> On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote: >>> >>>> >>>> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: >>>> >>>>> It's a good practice to reserve a 64-bit prefix for each network. >>>>> That's a good general rule. For point to point or link networks you >>>>> can use something as small as a 126-bit prefix (we do). >>>>> >>>> >>>> Technically, absent buggy {firm,soft}ware, you can use a /127. There's >>>> no >>>> actual benefit to doing anything longer than a /64 unless you have >>>> buggy *ware (ping pong attacks only work against buggy *ware), >>>> and there can be some advantages to choosing addresses other than >>>> ::1 and ::2 in some cases. If you're letting outside packets target >>>>your >>>> point-to-point links, you have bigger problems than neighbor table >>>> attacks. If not, then the neighbor table attack is a bit of a >>>> red-herring. >>>> >>> >>> The context is DOCSIS, i.e., primarily residential cable modem users, >>>and >>> the cable company ISPs do not want to spend time on customer care and >>> hand-holding. How are most v6 machines configured by default? That >>>is, >>> what did Microsoft do for Windows Vista and Windows 7? If they're set >>>for >>> stateless autoconfig, I strongly suspect that most ISPs will want to >>>stick >>> with that and hand out /64s to each network. (That's apart from the >>> larger >>> question of why they should want to do anything else...) >>> >>> >>> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>> >>> >>> >>> >>> >>> >> >> > From jsw at inconcepts.biz Mon Nov 28 23:15:02 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 29 Nov 2011 00:15:02 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> Message-ID: On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong wrote: > Technically, absent buggy {firm,soft}ware, you can use a /127. There's no > actual benefit to doing anything longer than a /64 unless you have > buggy *ware (ping pong attacks only work against buggy *ware), > and there can be some advantages to choosing addresses other than > ::1 and ::2 in some cases. If you're letting outside packets target your > point-to-point links, you have bigger problems than neighbor table > attacks. If not, then the neighbor table attack is a bit of a red-herring. Owen and I have discussed this in great detail off-list. Nearly every time this topic comes up, he posts in public that neighbor table exhaustion is a non-issue. I thought I'd mention that his plan for handling neighbor table attacks against his networks is whack-a-mole. That's right, wait for customer services to break, then have NOC guys attempt to clear tables, filter traffic, or disable services; and repeat that if the attacker is determined or going after his network rather than one of his downstream customers. I hate to drag a frank, private discussion like that into the public list; but every time Owen says this is a non-issue, you should keep in mind that his own plan is totally unacceptable for any production service. Only one of the following things can be true: either 1) Owen thinks it is okay for services to break repeatedly and require operator intervention to fix them if subjected to a trivial attack; or 2) he is lieing. Take that as you will. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From Valdis.Kletnieks at vt.edu Tue Nov 29 00:43:04 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 29 Nov 2011 01:43:04 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: Your message of "Tue, 29 Nov 2011 00:15:02 EST." References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> Message-ID: <16429.1322548984@turing-police.cc.vt.edu> On Tue, 29 Nov 2011 00:15:02 EST, Jeff Wheeler said: > Owen and I have discussed this in great detail off-list. Nearly every > time this topic comes up, he posts in public that neighbor table > exhaustion is a non-issue. I thought I'd mention that his plan for > handling neighbor table attacks against his networks is whack-a-mole. > That's right, wait for customer services to break, then have NOC guys > attempt to clear tables, filter traffic, or disable services; and > repeat that if the attacker is determined or going after his network > rather than one of his downstream customers. It's worked for us since 1997. We've had bigger problems with IPv4 worms that decided to probe in multicast address space for their next target, causing CPU exhaustion on routers as they try to set up zillions of multicast groups. Sure, it's a consideration. But how many sites are *actually* getting hit with this, compared to all the *other* DDOS stuff that's going on? I'm willing to bet a large pizza with everything but anchovies that out in the *real* world, 50-75 times as many (if not more) sites are getting hit with IPv4 DDoS attacks that they weren't prepared for than are seeing this one particular neighbor table exhaustion attack. Any of the guys with actual DDoS numbers want to weigh in? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jof at thejof.com Tue Nov 29 01:20:44 2011 From: jof at thejof.com (Jonathan Lassoff) Date: Mon, 28 Nov 2011 23:20:44 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <16429.1322548984@turing-police.cc.vt.edu> References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> <16429.1322548984@turing-police.cc.vt.edu> Message-ID: On Mon, Nov 28, 2011 at 10:43 PM, wrote: > On Tue, 29 Nov 2011 00:15:02 EST, Jeff Wheeler said: > > > Owen and I have discussed this in great detail off-list. Nearly every > > time this topic comes up, he posts in public that neighbor table > > exhaustion is a non-issue. I thought I'd mention that his plan for > > handling neighbor table attacks against his networks is whack-a-mole. > > That's right, wait for customer services to break, then have NOC guys > > attempt to clear tables, filter traffic, or disable services; and > > repeat that if the attacker is determined or going after his network > > rather than one of his downstream customers. > > It's worked for us since 1997. We've had bigger problems with IPv4 worms > that > decided to probe in multicast address space for their next target, causing > CPU > exhaustion on routers as they try to set up zillions of multicast groups. > > Sure, it's a consideration. But how many sites are *actually* getting hit > with this, compared to all the *other* DDOS stuff that's going on? I'm > willing > to bet a large pizza with everything but anchovies that out in the *real* > world, 50-75 times as many (if not more) sites are getting hit with IPv4 > DDoS attacks that they weren't prepared for than are seeing this one > particular neighbor table exhaustion attack. > > Any of the guys with actual DDoS numbers want to weigh in? > Agreed. While I don't have any good numbers that I can publicly offer up, it also intuitively makes sense that there's a greater proportion of IPv4 DDOS and resource exhaustion attacks vs IPv6 ones. Especially on the "distributed" part; there's a heck of lot more v4-only hosts to be 0wned and botnet'ed than dual-stacked ones. That said, I think the risk of putting a /64 on a point-to-point link is much greater than compared to a (incredibly wasteful) v4 /24 on a point-to-point. Instead of ~254 IPs one can destinate traffic towards (to cause a ARP neighbor discovery process), there's now ~18446744073709551614 addresses one can cause a router to start sending ICMPv6 messages for. For links that will only ever be point-to-point, there's no good reason (that I know of) to not use a /127. For peering LANs or places that have a handful of routers, /112's are cute, but I would think the risk is then comparable to a /64 (which has the added benefit of SLAAC). I imagine the mitigation strategies are similar for both cases though: just rate-limit how often your router will attempt neighbor discovery. Are there other methods? Cheers, jof From fweimer at bfk.de Tue Nov 29 02:09:47 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 29 Nov 2011 08:09:47 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: (Dmitry Cherkasov's message of "Mon, 28 Nov 2011 13:37:16 +0200") References: Message-ID: <82aa7ftkms.fsf@mid.bfk.de> * Dmitry Cherkasov: > It is commonly agreed that /64 is maximal length for LANs because if > we use longer prefix we introduce conflict with stateless address > autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used > in DOCSIS networks. So there seems to be no objections to use smaller > networks per cable interfaces of CMTS. As far as I understan the IPv6 address architecture, if the network prefix is longer than /64, you're not running Unicast IPv6. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From jsw at inconcepts.biz Tue Nov 29 02:23:04 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 29 Nov 2011 03:23:04 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <16429.1322548984@turing-police.cc.vt.edu> References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> <16429.1322548984@turing-police.cc.vt.edu> Message-ID: On Tue, Nov 29, 2011 at 1:43 AM, wrote: > It's worked for us since 1997. ?We've had bigger problems with IPv4 worms That's not a reason to deny that the problem exists. It's even fixable. I'd prefer that vendors fixed it *before* there were massive botnet armies with IPv6 connectivity, but in case they don't, I do not deploy /64. On Tue, Nov 29, 2011 at 2:20 AM, Jonathan Lassoff wrote: > Agreed. While I don't have any good numbers that I can publicly offer up, it > also intuitively makes sense that there's a greater proportion of IPv4 DDOS > and resource exhaustion attacks vs IPv6 ones. Of course. There are comparably few hosts with IPv6 connectivity. Bad guys aren't that familiar with IPv6 yet. Even if they are, their armies of compromised desktops probably can't launch an effective IPv6 attack yet. Lack of sources, no way to get nasty IPv6 packets to the target, or the target has different infrastructure for IPv4 and IPv6 anyway, and taking out the IPv6 one only isn't that beneficial (Happy Eyeballs features and such.) Further, the victim can just turn off IPv6 when they start getting attacked in this way. And that is exactly what sites will end up doing, turning off IPv6 because vendors aren't addressing issues like these. That doesn't help anyone. > I imagine the mitigation strategies are similar for both cases though: just > rate-limit how often your router will attempt neighbor discovery. Are there > other methods? Simply rate-limiting the data-plane events that trigger ND resolution is not good enough. One very popular platform that is offered with cards in horizontal or vertical orientation uses the same policer for ARP and NDP. That means when you do eventually start getting ND attacks, it will break your IPv4 services also. If you want to learn more about this, I have some slides: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From doctorchd at gmail.com Tue Nov 29 05:46:39 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Tue, 29 Nov 2011 13:46:39 +0200 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <3729C1E0-D8AF-479F-A50B-18EFE4407543@delong.com> References: <3729C1E0-D8AF-479F-A50B-18EFE4407543@delong.com> Message-ID: Owen, Currently I research on IPv6 provisioning systems and I need to decide whether the ability to use longer then /64 prefixes should be supported in them or not. If we restrict user to using /64 per network we need to have convincing reasons for this. Best practice and common sense stand for using /64 but this may be not sufficient for some people. Dmitry Cherkasov 2011/11/28 Owen DeLong : > You can probably do it, but, what do you gain by doing so? > > Owen > > On Nov 28, 2011, at 3:37 AM, Dmitry Cherkasov wrote: > >> Hello everybody, >> >> It is commonly agreed that /64 is maximal length for LANs because if >> we use longer prefix we introduce conflict with stateless address >> autoconfiguration (SLAAC) based on EUI-64 spec. But ?SLAAC is not used >> in DOCSIS networks. So there seems to be no objections to use smaller >> networks per cable interfaces of CMTS. I was not able to find any >> recommendations anywhere including Cable Labs specs for using >> prefixes not greater then /64 in DOCSIS networks. Some tech from ISP >> assumed that DHCPv6 server may generate interface ID part of IPv6 >> address similarly to EUI-64 so MAC address of the device can easily be >> obtained from its IPv6 address, but this does not seem like convincing >> argument. What do you think? >> >> >> Dmitry Cherkasov > From doctorchd at gmail.com Tue Nov 29 05:59:53 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Tue, 29 Nov 2011 13:59:53 +0200 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: Message-ID: John, I am determining technical requirements to IPv6 provisioning system for DOCSIS networks and I am deciding if it is worth to restrict user to use not less then /64 networks on cable interface. It is obvious that no true economy of IP addresses can be achieved with increasing prefix length above 64 bits. As for using EUI-64, unlike random or sequential generation it provides predictable results that may be desired, e.g. for tracking some device migration between different networks. Dmitry Cherkasov 2011/11/29 Brzozowski, John : > Dmitry, > > > You could consider the use of prefixes longer than the /64 on CMTS > interfaces, however, it is not clear to me why this would be done. > Further, most DHCPv6 implementations do not require that the generated > IPv6 address be eui-64 based. ?A randomized algorithm could also be used. > Another consideration is what happens after IPv6 is used for addressing > cable modems. ?What happens when you want to address CPE or CPE routers? > You are right back to /64 or shorter depending on the type of device being > provisioned. > > FWIW - we have found that there are distinct benefits to using IPv6 beyond > the amount of addresses that are available. ?The use of /64 is tightly > coupled with these benefits. > > Can you elaborate as to why one would want to or need to use prefixes > longer than /64? > > John > > On 11/28/11 6:37 AM, "Dmitry Cherkasov" wrote: > >>Hello everybody, >> >>It is commonly agreed that /64 is maximal length for LANs because if >>we use longer prefix we introduce conflict with stateless address >>autoconfiguration (SLAAC) based on EUI-64 spec. But ?SLAAC is not used >>in DOCSIS networks. So there seems to be no objections to use smaller >>networks per cable interfaces of CMTS. I was not able to find any >>recommendations anywhere including Cable Labs specs for using >>prefixes not greater then /64 in DOCSIS networks. Some tech from ISP >>assumed that DHCPv6 server may generate interface ID part of IPv6 >>address similarly to EUI-64 so MAC address of the device can easily be >>obtained from its IPv6 address, but this does not seem like convincing >>argument. What do you think? >> >> >>Dmitry Cherkasov >> > From doctorchd at gmail.com Tue Nov 29 06:09:24 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Tue, 29 Nov 2011 14:09:24 +0200 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <7ECD6B0E-D104-4B10-8729-79F1AD7363BD@cs.columbia.edu> References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> <7ECD6B0E-D104-4B10-8729-79F1AD7363BD@cs.columbia.edu> Message-ID: Steven, SLAAC is prohibited for using in DOCSIS networks, router advertisements that allow SLAAC must be ignored by end-devices, therefore DHCPv6 is the only way of configuring (if not talking about statical assignment). I have seen at least Windows7 handling this properly in its default configuration: it starts DHCPv6 negotiation instead of auto-configuration. Dmitry Cherkasov 2011/11/29 Steven Bellovin : > > On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote: > >> >> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: >> >>> It's a good practice to reserve a 64-bit prefix for each network. >>> That's a good general rule. ?For point to point or link networks you >>> can use something as small as a 126-bit prefix (we do). >>> >> >> Technically, absent buggy {firm,soft}ware, you can use a /127. There's no >> actual benefit to doing anything longer than a /64 unless you have >> buggy *ware (ping pong attacks only work against buggy *ware), >> and there can be some advantages to choosing addresses other than >> ::1 and ::2 in some cases. If you're letting outside packets target your >> point-to-point links, you have bigger problems than neighbor table >> attacks. If not, then the neighbor table attack is a bit of a red-herring. >> > > The context is DOCSIS, i.e., primarily residential cable modem users, and > the cable company ISPs do not want to spend time on customer care and > hand-holding. ?How are most v6 machines configured by default? ?That is, > what did Microsoft do for Windows Vista and Windows 7? ?If they're set for > stateless autoconfig, I strongly suspect that most ISPs will want to stick > with that and hand out /64s to each network. ?(That's apart from the larger > question of why they should want to do anything else...) > > > ? ? ? ? ? ? ? ?--Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > From tore.anderson at redpill-linpro.com Tue Nov 29 06:13:51 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Tue, 29 Nov 2011 13:13:51 +0100 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: Message-ID: <4ED4CC7F.6090802@redpill-linpro.com> * Dmitry Cherkasov > I am determining technical requirements to IPv6 provisioning system > for DOCSIS networks and I am deciding if it is worth to restrict user > to use not less then /64 networks on cable interface. It is obvious > that no true economy of IP addresses can be achieved with increasing > prefix length above 64 bits. I am not familiar with DOCSIS networks, but I thought I'd note that in order to comply with the RIPE policies, you must assign at least a /64 or shorter to each end user: http://www.ripe.net/ripe/docs/ripe-523#assignment_size -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From doctorchd at gmail.com Tue Nov 29 06:32:25 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Tue, 29 Nov 2011 14:32:25 +0200 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> <16429.1322548984@turing-police.cc.vt.edu> Message-ID: I suppose router operating as proxy ND (similarly to local proxy ARP in IPv4) can mitigate the threat as well. it is mentioned in 'DOCSIS 3.0 Requirements for IPv6 support' (http://tools.ietf.org/html/draft-mule-cablelabs-docsis3-ipv6-00). Dmitry Cherkasov 2011/11/29 Jonathan Lassoff : > On Mon, Nov 28, 2011 at 10:43 PM, wrote: > >> On Tue, 29 Nov 2011 00:15:02 EST, Jeff Wheeler said: >> >> > Owen and I have discussed this in great detail off-list. ?Nearly every >> > time this topic comes up, he posts in public that neighbor table >> > exhaustion is a non-issue. ?I thought I'd mention that his plan for >> > handling neighbor table attacks against his networks is whack-a-mole. >> > That's right, wait for customer services to break, then have NOC guys >> > attempt to clear tables, filter traffic, or disable services; and >> > repeat that if the attacker is determined or going after his network >> > rather than one of his downstream customers. >> >> It's worked for us since 1997. ?We've had bigger problems with IPv4 worms >> that >> decided to probe in multicast address space for their next target, causing >> CPU >> exhaustion on routers as they try to set up zillions of multicast groups. >> >> Sure, it's a consideration. ?But how many sites are *actually* getting hit >> with this, compared to all the *other* DDOS stuff that's going on? ?I'm >> willing >> to bet a large pizza with everything but anchovies that out in the *real* >> world, 50-75 times as many (if not more) sites are getting hit with IPv4 >> DDoS attacks that they weren't prepared for than are seeing this one >> particular neighbor table exhaustion attack. >> >> Any of the guys with actual DDoS numbers want to weigh in? >> > > Agreed. While I don't have any good numbers that I can publicly offer up, > it also intuitively makes sense that there's a greater proportion of IPv4 > DDOS and resource exhaustion attacks vs IPv6 ones. > Especially on the "distributed" part; there's a heck of lot more v4-only > hosts to be 0wned and botnet'ed than dual-stacked ones. > > That said, I think the risk of putting a /64 on a point-to-point link is > much greater than compared to a (incredibly wasteful) v4 /24 on a > point-to-point. Instead of ~254 IPs one can destinate traffic towards (to > cause a ARP neighbor discovery process), there's now ~18446744073709551614 > addresses one can cause a router to start sending ICMPv6 messages for. > > For links that will only ever be point-to-point, there's no good reason > (that I know of) to not use a /127. For peering LANs or places that have a > handful of routers, /112's are cute, but I would think the risk is then > comparable to a /64 (which has the added benefit of SLAAC). > > I imagine the mitigation strategies are similar for both cases though: just > rate-limit how often your router will attempt neighbor discovery. Are there > other methods? > > Cheers, > jof From doctorchd at gmail.com Tue Nov 29 06:40:00 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Tue, 29 Nov 2011 14:40:00 +0200 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <4ED4CC7F.6090802@redpill-linpro.com> References: <4ED4CC7F.6090802@redpill-linpro.com> Message-ID: Tore, To comply with this policy we delegate at least /64 to end-users gateways. But this policy does not cover the network between WAN interfaces of CPE and ISP access gateway. Dmitry Cherkasov 2011/11/29 Tore Anderson : > * Dmitry Cherkasov > >> I am determining technical requirements to IPv6 provisioning system >> for DOCSIS networks and I am deciding if it is worth to restrict user >> to use not less then /64 networks on cable interface. It is obvious >> that no true economy of IP addresses can be achieved with increasing >> prefix length above 64 bits. > > I am not familiar with DOCSIS networks, but I thought I'd note that in > order to comply with the RIPE policies, you must assign at least a /64 > or shorter to each end user: > > http://www.ripe.net/ripe/docs/ripe-523#assignment_size > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com From doctorchd at gmail.com Tue Nov 29 06:58:15 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Tue, 29 Nov 2011 14:58:15 +0200 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <4ED4CC7F.6090802@redpill-linpro.com> Message-ID: Thanks to everybody participating in the discussion. I try to summarize. 1) There is no any obvious benefit of using longer prefixes then /64 in DOCSIS networks yet there are no definite objections to use them except that it violates best practices and may lead to some problems in the future 2) DHCPv6 server can use any algorithm to generate interface ID part of the address, and EUI-64 may be just one of them that can be useful for keeping correspondence between MAC and IPv6 addresses. Yet if we use EUI-64 we definitely need to use /64 prefix 3) Using /64 networks possesses potential security threat related to neighbor tables overflow. This is wide IPv6 problem and not related to DOCSIS only There were also notes about address usage on link networks. Though this was out of the scope of original question it is agreed that using /64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links) can be mentioned here. Dmitry Cherkasov 2011/11/29 Dmitry Cherkasov : > Tore, > > To comply with this policy we delegate at least /64 to end-users > gateways. But this policy does not cover the network between WAN > interfaces of CPE and ISP access gateway. > > Dmitry Cherkasov > > > > 2011/11/29 Tore Anderson : >> * Dmitry Cherkasov >> >>> I am determining technical requirements to IPv6 provisioning system >>> for DOCSIS networks and I am deciding if it is worth to restrict user >>> to use not less then /64 networks on cable interface. It is obvious >>> that no true economy of IP addresses can be achieved with increasing >>> prefix length above 64 bits. >> >> I am not familiar with DOCSIS networks, but I thought I'd note that in >> order to comply with the RIPE policies, you must assign at least a /64 >> or shorter to each end user: >> >> http://www.ripe.net/ripe/docs/ripe-523#assignment_size >> >> -- >> Tore Anderson >> Redpill Linpro AS - http://www.redpill-linpro.com From denys at visp.net.lb Tue Nov 29 07:06:15 2011 From: denys at visp.net.lb (Denys Fedoryshchenko) Date: Tue, 29 Nov 2011 15:06:15 +0200 Subject: DNS 8.8.8.8 was down Message-ID: <3686cc1353930b49c5897c7db5b4ceee@visp.net.lb> Google DNS was down few minutes, at least for few European locations Here is sample traceroute: 4 213.242.116.25 (213.242.116.25) 39.692 ms 39.776 ms 39.774 ms 5 ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238) 50.933 ms 50.792 ms 50.793 ms 6 ae-47-47.ebr1.London1.Level3.net (4.69.143.109) 57.353 ms ae-45-45.ebr1.London1.Level3.net (4.69.143.101) 57.580 ms ae-48-48.ebr1.London1.Level3.net (4.69.143.113) 57.582 ms 7 ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.577 ms ae-58-113.csw1.London1.Level3.net (4.69.153.122) 57.693 ms ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.817 ms 8 ae-1-51.edge3.London1.Level3.net (4.69.139.73) 57.654 ms 57.631 ms 57.768 ms 9 unknown.Level3.net (212.113.15.186) 57.958 ms 57.531 ms 57.643 ms 10 209.85.255.78 (209.85.255.78) 57.732 ms 57.598 ms 57.573 ms 11 209.85.253.92 (209.85.253.92) 58.300 ms 209.85.253.196 (209.85.253.196) 57.941 ms 209.85.253.94 (209.85.253.94) 58.002 ms 12 72.14.232.134 (72.14.232.134) 63.726 ms 66.249.95.173 (66.249.95.173) 63.614 ms 72.14.232.134 (72.14.232.134) 63.699 ms After this hop it was dead, now it is working, but seems still there is minor problems 14 216.239.46.117 (216.239.46.117) 64.171 ms * * 15 google-public-dns-a.google.com (8.8.8.8) 63.749 ms 63.729 ms 63.680 ms --- System administrator Denys Fedoryshchenko Virtual ISP S.A.L. From gary.steers at sharedband.com Tue Nov 29 07:11:04 2011 From: gary.steers at sharedband.com (Gary Steers) Date: Tue, 29 Nov 2011 13:11:04 -0000 Subject: DNS 8.8.8.8 was down In-Reply-To: <3686cc1353930b49c5897c7db5b4ceee@visp.net.lb> References: <3686cc1353930b49c5897c7db5b4ceee@visp.net.lb> Message-ID: We also observed this issue... # traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets 1 r1.ldn.uk.sharedband.net (109.68.192.1) 0.480 ms 0.515 ms 0.523 ms 2 195.66.224.125 (195.66.224.125) 0.451 ms 0.453 ms 0.445 ms 3 64.233.175.27 (64.233.175.27) 0.708 ms 0.702 ms 64.233.175.25 (64.233.175.25) 0.387 ms 4 209.85.253.92 (209.85.253.92) 13.737 ms 209.85.253.90 (209.85.253.90) 1.434 ms 209.85.253.196 (209.85.253.196) 1.010 ms 5 72.14.232.134 (72.14.232.134) 6.553 ms 66.249.95.173 (66.249.95.173) 6.549ms 72.14.232.134 (72.14.232.134) 6.404 ms 6 * * * 7 * * * 8 * * * Looks like it was Google (72.14.232.134) Gary Steers Sharedband NOC/3rd Line Support -----Original Message----- From: Denys Fedoryshchenko [mailto:denys at visp.net.lb] Sent: 29 November 2011 13:06 To: NANOG Subject: DNS 8.8.8.8 was down Google DNS was down few minutes, at least for few European locations Here is sample traceroute: 4 213.242.116.25 (213.242.116.25) 39.692 ms 39.776 ms 39.774 ms 5 ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238) 50.933 ms 50.792 ms 50.793 ms 6 ae-47-47.ebr1.London1.Level3.net (4.69.143.109) 57.353 ms ae-45-45.ebr1.London1.Level3.net (4.69.143.101) 57.580 ms ae-48-48.ebr1.London1.Level3.net (4.69.143.113) 57.582 ms 7 ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.577 ms ae-58-113.csw1.London1.Level3.net (4.69.153.122) 57.693 ms ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.817 ms 8 ae-1-51.edge3.London1.Level3.net (4.69.139.73) 57.654 ms 57.631 ms 57.768 ms 9 unknown.Level3.net (212.113.15.186) 57.958 ms 57.531 ms 57.643 ms 10 209.85.255.78 (209.85.255.78) 57.732 ms 57.598 ms 57.573 ms 11 209.85.253.92 (209.85.253.92) 58.300 ms 209.85.253.196 (209.85.253.196) 57.941 ms 209.85.253.94 (209.85.253.94) 58.002 ms 12 72.14.232.134 (72.14.232.134) 63.726 ms 66.249.95.173 (66.249.95.173) 63.614 ms 72.14.232.134 (72.14.232.134) 63.699 ms After this hop it was dead, now it is working, but seems still there is minor problems 14 216.239.46.117 (216.239.46.117) 64.171 ms * * 15 google-public-dns-a.google.com (8.8.8.8) 63.749 ms 63.729 ms 63.680 ms --- System administrator Denys Fedoryshchenko Virtual ISP S.A.L. From froztbyte at froztbyte.net Tue Nov 29 07:12:12 2011 From: froztbyte at froztbyte.net (JP Viljoen) Date: Tue, 29 Nov 2011 15:12:12 +0200 Subject: DNS 8.8.8.8 was down In-Reply-To: <3686cc1353930b49c5897c7db5b4ceee@visp.net.lb> References: <3686cc1353930b49c5897c7db5b4ceee@visp.net.lb> Message-ID: <08465045d06fbbd89525b4d5446384b8@froztbyte.net> On Tue, 29 Nov 2011 15:06:15 +0200, Denys Fedoryshchenko wrote: > Google DNS was down few minutes, at least for few European locations > > Here is sample traceroute: > > 4 213.242.116.25 (213.242.116.25) 39.692 ms 39.776 ms 39.774 ms > 5 ae-7-7.ebr1.Paris1.Level3.net (4.69.143.238) 50.933 ms 50.792 > ms 50.793 ms > 6 ae-47-47.ebr1.London1.Level3.net (4.69.143.109) 57.353 ms > ae-45-45.ebr1.London1.Level3.net (4.69.143.101) 57.580 ms > ae-48-48.ebr1.London1.Level3.net (4.69.143.113) 57.582 ms > 7 ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.577 ms > ae-58-113.csw1.London1.Level3.net (4.69.153.122) 57.693 ms > ae-57-112.csw1.London1.Level3.net (4.69.153.118) 57.817 ms > 8 ae-1-51.edge3.London1.Level3.net (4.69.139.73) 57.654 ms 57.631 > ms 57.768 ms > 9 unknown.Level3.net (212.113.15.186) 57.958 ms 57.531 ms 57.643 > ms > 10 209.85.255.78 (209.85.255.78) 57.732 ms 57.598 ms 57.573 ms > 11 209.85.253.92 (209.85.253.92) 58.300 ms 209.85.253.196 > (209.85.253.196) 57.941 ms 209.85.253.94 (209.85.253.94) 58.002 ms > 12 72.14.232.134 (72.14.232.134) 63.726 ms 66.249.95.173 > (66.249.95.173) 63.614 ms 72.14.232.134 (72.14.232.134) 63.699 ms > > After this hop it was dead, now it is working, but seems still there > is minor problems > 14 216.239.46.117 (216.239.46.117) 64.171 ms * * > 15 google-public-dns-a.google.com (8.8.8.8) 63.749 ms 63.729 ms > 63.680 ms Some people saw it from .za as well, although apparently 8.8.4.4 is unaffected. From victor.kuarsingh at gmail.com Tue Nov 29 07:17:35 2011 From: victor.kuarsingh at gmail.com (Victor Kuarsingh) Date: Tue, 29 Nov 2011 08:17:35 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: Message-ID: Dmitry et al, I found Jeff's following comments to be quite insightful for general practices. http://www.networkcomputing.com/ipv6-tech-center/231600717 http://www.networkcomputing.com/ipv6-tech-center/231700160 As for using 127s on P2P links.... He discussed reasoning behind using /64s, concerns related to "waste", ND exploits and other points as noted in RFC6164. - directed Regards, Victor K On 11-11-29 7:58 AM, "Dmitry Cherkasov" wrote: >Thanks to everybody participating in the discussion. >I try to summarize. > >1) There is no any obvious benefit of using longer prefixes then /64 >in DOCSIS networks yet there are no definite objections to use them >except that it violates best practices and may lead to some problems >in the future > >2) DHCPv6 server can use any algorithm to generate interface ID part >of the address, and EUI-64 may be just one of them that can be useful >for keeping correspondence between MAC and IPv6 addresses. Yet if we >use EUI-64 we definitely need to use /64 prefix > >3) Using /64 networks possesses potential security threat related to >neighbor tables overflow. This is wide IPv6 problem and not related to >DOCSIS only > >There were also notes about address usage on link networks. Though >this was out of the scope of original question it is agreed that using >/64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes >on Inter-Router Links) can be mentioned here. > > >Dmitry Cherkasov > > > >2011/11/29 Dmitry Cherkasov : >> Tore, >> >> To comply with this policy we delegate at least /64 to end-users >> gateways. But this policy does not cover the network between WAN >> interfaces of CPE and ISP access gateway. >> >> Dmitry Cherkasov >> >> >> >> 2011/11/29 Tore Anderson : >>> * Dmitry Cherkasov >>> >>>> I am determining technical requirements to IPv6 provisioning system >>>> for DOCSIS networks and I am deciding if it is worth to restrict user >>>> to use not less then /64 networks on cable interface. It is obvious >>>> that no true economy of IP addresses can be achieved with increasing >>>> prefix length above 64 bits. >>> >>> I am not familiar with DOCSIS networks, but I thought I'd note that in >>> order to comply with the RIPE policies, you must assign at least a /64 >>> or shorter to each end user: >>> >>> http://www.ripe.net/ripe/docs/ripe-523#assignment_size >>> >>> -- >>> Tore Anderson >>> Redpill Linpro AS - http://www.redpill-linpro.com > From doctorchd at gmail.com Tue Nov 29 07:43:01 2011 From: doctorchd at gmail.com (Dmitry Cherkasov) Date: Tue, 29 Nov 2011 15:43:01 +0200 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: Message-ID: And here is another useful resource: http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf, particularly chapter 6.1.3 Vulnerabilities in IPv6. Dmitry Cherkasov 2011/11/29 Victor Kuarsingh : > Dmitry et al, > > I found Jeff's following comments to be quite insightful for general > practices. > > http://www.networkcomputing.com/ipv6-tech-center/231600717 > > http://www.networkcomputing.com/ipv6-tech-center/231700160 > > As for using 127s on P2P links.... > > He discussed reasoning behind using /64s, concerns related to "waste", ND > exploits and > other points as noted in RFC6164. - directed > > Regards, > > Victor K > > On 11-11-29 7:58 AM, "Dmitry Cherkasov" wrote: > >>Thanks to everybody participating in the discussion. >>I try to summarize. >> >>1) There is no any obvious benefit of using longer prefixes then /64 >>in DOCSIS networks yet there are no definite objections to use them >>except that it violates best practices and may lead to some problems >>in the future >> >>2) DHCPv6 server can use any algorithm to generate interface ID part >>of the address, and EUI-64 may be just one of them that can be useful >>for keeping correspondence between MAC and IPv6 addresses. Yet if we >>use EUI-64 we definitely need to use /64 prefix >> >>3) Using /64 networks possesses potential security threat related to >>neighbor tables overflow. This is wide IPv6 problem and not related to >>DOCSIS only >> >>There were also notes about address usage on link networks. Though >>this was out of the scope of original question it is agreed that using >>/64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes >>on Inter-Router Links) can be mentioned here. >> >> >>Dmitry Cherkasov >> >> >> >>2011/11/29 Dmitry Cherkasov : >>> Tore, >>> >>> To comply with this policy we delegate at least /64 to end-users >>> gateways. But this policy does not cover the network between WAN >>> interfaces of CPE and ISP access gateway. >>> >>> Dmitry Cherkasov >>> >>> >>> >>> 2011/11/29 Tore Anderson : >>>> * Dmitry Cherkasov >>>> >>>>> I am determining technical requirements to IPv6 provisioning system >>>>> for DOCSIS networks and I am deciding if it is worth to restrict user >>>>> to use not less then /64 networks on cable interface. It is obvious >>>>> that no true economy of IP addresses can be achieved with increasing >>>>> prefix length above 64 bits. >>>> >>>> I am not familiar with DOCSIS networks, but I thought I'd note that in >>>> order to comply with the RIPE policies, you must assign at least a /64 >>>> or shorter to each end user: >>>> >>>> http://www.ripe.net/ripe/docs/ripe-523#assignment_size >>>> >>>> -- >>>> Tore Anderson >>>> Redpill Linpro AS - http://www.redpill-linpro.com >> > > From Valdis.Kletnieks at vt.edu Tue Nov 29 10:28:57 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 29 Nov 2011 11:28:57 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: Your message of "Tue, 29 Nov 2011 03:23:04 EST." References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> <16429.1322548984@turing-police.cc.vt.edu> Message-ID: <34192.1322584137@turing-police.cc.vt.edu> On Tue, 29 Nov 2011 03:23:04 EST, Jeff Wheeler said: > On Tue, Nov 29, 2011 at 1:43 AM, wrote: > > It's worked for us since 1997. We've had bigger problems with IPv4 worms > > That's not a reason to deny that the problem exists. It's even > fixable. I'd prefer that vendors fixed it *before* there were massive > botnet armies with IPv6 connectivity, but in case they don't, I do not > deploy /64. Umm.. Jeff? I never *tried* to deny the problem exists. But if you have an eyeball-heavy network, it's hard to not deploy /64s (currently, we do SLAAC to get the basic config, and DNS/etc is still via dhcp4/IPv4). We just see the business danger of waiting to start deploying IPv6 till the vendors are perfect as being a bigger danger than the ND exhaustion issue. (How many years did we go with ARP and DHCP spoofing being well-known issues before vendors fixed that? Yeah, exactly.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rps at maine.edu Tue Nov 29 10:39:06 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 29 Nov 2011 11:39:06 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <7ECD6B0E-D104-4B10-8729-79F1AD7363BD@cs.columbia.edu> References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> <7ECD6B0E-D104-4B10-8729-79F1AD7363BD@cs.columbia.edu> Message-ID: Windows (Vista and later) and OS X (as of Lion) now have mature IPv6 implementations and support DHCPv6 for address allocation. Furthermore, they correctly let the network decide which method is used and only provide the user with the option of "Manual" or "Automatic", where Automatic will make use of SLAAC, DHCPv6, or both, depending on the flags set in the IPv6 RA. We run both systems, in production, using DHCPv6 on prefixes much smaller than 64-bit (typically 120 or 119; we mirror whatever the IPv4 prefix length is). There is functionality (current and future) that the use of a 64-bit prefix provides; so it's a good idea to reserve that space for any LAN network, even if you implement it as a 120-bit prefix on the router. Just to be clear, I don't recommend not reserving a 64-bit prefix per network. That said; neighbor table exhaustion is a real problem. A few lines of C can kill IPv6 on enterprise- and carrier-grade routers. It's a problem that has gone largely ignored because people are still in a private address space mindset. We use 126-bit prefixes for link networks (we would have used 127, but the arguments against them in RFC 3627 were compelling enough to avoid them; after all we don't have a lack of space). There are a few reasons for this: 1. It let's us keep link address short by using the beginning of our allocation (e.g. you'll see things like 2610:48::66 in traceroutes to us), which are easily memorized in the event of DNS failure (face it; there are still some addresses you'll memorize; even if they are IPv6). 2. We know that the number of hosts on these networks is finite; it will always be 2, so using a 64-bit prefix isn't useful in any way; and until we see routers hardened against neighbor table exhaustion, they're actually harmful. 3. We have thousands of link networks; giving them all a 64-bit prefix seems rather wasteful. We've been running IPv6 in production since 2009, and when we first jumped into it I was in the same camp of being a purist; thinking SLAAC was the best; that DHCPv6 wasn't needed; that every network should always be a 64-bit prefix; etc. A few years of experience with using IPv6 in an operational environment has taught me otherwise. I'm not saying posts on list about not using anything but a 64-bit prefix are wrong; but it's a little more complicated than one-size-fits-all networking. It is perfectly valid to make use of prefixes other than 64-bit; so long as you understand the implications of doing so. SLAAC is a great bootstrapping mechanism for ad-hoc networking; and the link-local scope (allowing all IPv6 traffic to happen over IPv6; even neighbor discovery). Just because it's a neat and useful way of addressing doesn't mean it's the best way for every network. Different strokes for different blokes and all that. To those who noticed me and Owen seem to have this argument on-list a few times a year, sorry for the recycled content. ;-) On Mon, Nov 28, 2011 at 5:00 PM, Steven Bellovin wrote: > > On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote: > >> >> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: >> >>> It's a good practice to reserve a 64-bit prefix for each network. >>> That's a good general rule. ?For point to point or link networks you >>> can use something as small as a 126-bit prefix (we do). >>> >> >> Technically, absent buggy {firm,soft}ware, you can use a /127. There's no >> actual benefit to doing anything longer than a /64 unless you have >> buggy *ware (ping pong attacks only work against buggy *ware), >> and there can be some advantages to choosing addresses other than >> ::1 and ::2 in some cases. If you're letting outside packets target your >> point-to-point links, you have bigger problems than neighbor table >> attacks. If not, then the neighbor table attack is a bit of a red-herring. >> > > The context is DOCSIS, i.e., primarily residential cable modem users, and > the cable company ISPs do not want to spend time on customer care and > hand-holding. ?How are most v6 machines configured by default? ?That is, > what did Microsoft do for Windows Vista and Windows 7? ?If they're set for > stateless autoconfig, I strongly suspect that most ISPs will want to stick > with that and hand out /64s to each network. ?(That's apart from the larger > question of why they should want to do anything else...) > > > ? ? ? ? ? ? ? ?--Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From smart.gophy at gmail.com Tue Nov 29 10:39:09 2011 From: smart.gophy at gmail.com (Guofei Gu) Date: Tue, 29 Nov 2011 10:39:09 -0600 (CST) Subject: Computer Networks Special Issue on Botnets: Deadline Extended to Dec. 19 Message-ID: <20111129163909.4E1E31902CF@smtp.cs.tamu.edu> CFP: Special Issue of COMPUTER NETWORS (ELSEVIER) on "Botnet Activity: Analysis, Detection and Shutdown" Apologies for multiple copies of this announcement. ------------------------- Dear Colleagues, Please consider the following opportunity to submit and publish original scientific results to a SPECIAL ISSUE of COMPUTER NETWORKS (ELSEVIER journal) on "Botnet Activity: Analysis, Detection and Shutdown". The submission deadline is extended to December 19, 2011. http://ees.elsevier.com/comnet/ A pdf version of this CFP is available at http://faculty.cse.tamu.edu/guofei/CFP_COMNET-Botnets.pdf Please help distribute. Thanks! ------------------------- Large scale attacks and criminal activities experienced in recent years have exposed the Internet to serious security breaches, and alarmed the world regarding cyber crime. In the center of this problem are the so called botnets -- collections of infected zombie machines (bots) controlled by the botmaster to perpetrate malicious activities and massive attacks. Some recent botnets are composed of millions of infected machines, making use of this attack vector inevitably harmfully. Hence, it is paramount to detect, analyze and shutdown such overlay networks before they become active. Research on botnet activity is mostly related to detection and disruption. Detection of botnets has focused on monitoring bot activities, especially during the spread of malicious software to infect new hosts (initial infection phase) and the communication messages exchanged between bots and botmasters (rallying and updating phases). Some behavioral aspects are common: bots have to signal the botmaster informing they are alive, each time their hosts are started; bots send messages whenever connecting and joining with the botnet; the botmaster has to send commands to each zombie machine before initiating malicious activities. This special issue of Computer Networks is intended to foster the dissemination of high quality research in all aspects regarding botnet activity, detection and countermeasures. The objective of this special issue is to publish papers presenting detection algorithms, traffic monitoring and identification, protocols and architectures, as well as botnet modeling, behavior, simulation, statistics, dissemination, analysis, preventive procedures and possible countermeasures. Only technical papers describing previously unpublished, original, state-of-the-art research, and not currently under review by a conference or journal will be considered. We solicit papers in a variety of topics related to botnet research including, but not limited to: - Traffic Monitoring and Detection Algorithms - Data Collection, Statistics and Analysis - Modeling Behavior and Simulation - Protocols and Architectures (IRC, HTTP, P2P, etc) - Firewalls and IDS - Cyber Crime Case Studies - Reverse Engineering and Automated Analysis of Bots - Honeypots and Honeynets - New Platforms: Cellular and Wireless networks, Mobile devices, TV, etc. - Legal Issues and Countermeasures - Underground Markets, Vulnerability Markets and Zero-day Economics - Mini-Botnets Guest Editors Ronaldo Salles Military Institute of Engineering Pra??General Tib?? 80, 22290-270, R.J. ?? Brazil salles at ieee.org Guofei Gu Texas A&M University 3112 TAMU, HRBB College Station, TX 77843-3112 ?? USA guofei at cse.tamu.edu Thorsten Holz Ruhr-University Bochum Universitatsstrasse 150, 44780 Bochum ?? Germany thorsten.holz at rub.de Morton Swimmer Trend Micro Deutschland, GmbH Zeppelinstr. 1 85399 Hallbergmoos - Germany swimmer at acm.org Paper submission: 19th Dec 2011 Acceptance notification: 19th Mar 2012 Final papers: 19th May 2012 Submission format The submitted papers must be clearly written in excellent English and describe original research which is not published nor currently under review by other journals or conferences. Author guidelines for preparation of manuscript can be found at www.elsevier.com/locate/comnet/ Submission Guideline All manuscripts and any supplementary material should be submitted through the Elsevier Editorial System (EES). The authors must select "Special Issue: Botnets" when they reach the ??Article Type?? step in the submission process. The EES website is located at: http://ees.elsevier.com/comnet/ Guide for Authors This site will guide you stepwise through the creation and uploading of you article. The guide for Authors can be found on the journal homepage (www.elsevier.com/comnet/). From bicknell at ufp.org Tue Nov 29 10:46:49 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 29 Nov 2011 08:46:49 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> <7ECD6B0E-D104-4B10-8729-79F1AD7363BD@cs.columbia.edu> Message-ID: <20111129164649.GA48593@ussenterprise.ufp.org> In a message written on Tue, Nov 29, 2011 at 11:39:06AM -0500, Ray Soucy wrote: > We run both systems, in production, using DHCPv6 on prefixes much > smaller than 64-bit (typically 120 or 119; we mirror whatever the IPv4 > prefix length is). Can you explain a bit more about how this works? My understanding of the current DHCPv6 implementations is that they had a hard assumption of a /64 prefix and the ability to do SLAAC and hear a valid RA in order to do DHCPv6. Are you doing anything special to make this happen with smaller subnets? -- 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 keegan.holley at sungard.com Tue Nov 29 10:47:37 2011 From: keegan.holley at sungard.com (Keegan Holley) Date: Tue, 29 Nov 2011 11:47:37 -0500 Subject: Equinix Message-ID: Assuming it's not owned by the NSA does anyone know the address of the equnix colo in the Denver area? I'm working on pricing access circuits into it. A contact from equinix would be helpful as well. We haven't gotten a response to our queries. Regards, Keegan From bret at getjive.com Tue Nov 29 10:51:28 2011 From: bret at getjive.com (Bret Palsson) Date: Tue, 29 Nov 2011 09:51:28 -0700 Subject: Equinix In-Reply-To: References: Message-ID: <2A17A6F8-040A-4576-B62D-A3BC14949EB1@getjive.com> They have been real slow to respond to me in the past 14 days. They say it's a 24 hour turn around after calling their marketing line, I'm still waiting a call back and I've left 3 messages. I guess they don't want to lease a cab in TX? On Nov 29, 2011, at 9:47 AM, Keegan Holley wrote: > Assuming it's not owned by the NSA does anyone know the address of the > equnix colo in the Denver area? I'm working on pricing access circuits > into it. A contact from equinix would be helpful as well. We haven't > gotten a response to our queries. > > Regards, > > Keegan From Gabriel.McCall at thyssenkrupp.com Tue Nov 29 11:00:42 2011 From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel) Date: Tue, 29 Nov 2011 12:00:42 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> Message-ID: Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most. -----Original Message----- From: Fred Baker [mailto:fred at cisco.com] ... I see no reason you couldn't use a /127 prefix if the link was point to point. ... From nathan at atlasnetworks.us Tue Nov 29 11:06:04 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 29 Nov 2011 17:06:04 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B60D016@ex-mb-1.corp.atlasnetworks.us> > Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 > suggests using /112 for router links, or /126 at the very most. Of potential interest, since you bring up RFC3627, is the following draft, and RFC6164: http://tools.ietf.org/html/draft-george-6man-3627-historic-01 http://tools.ietf.org/html/rfc6164 Nathan Eisenberg From rps at maine.edu Tue Nov 29 11:06:26 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 29 Nov 2011 12:06:26 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <20111129164649.GA48593@ussenterprise.ufp.org> References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> <7ECD6B0E-D104-4B10-8729-79F1AD7363BD@cs.columbia.edu> <20111129164649.GA48593@ussenterprise.ufp.org> Message-ID: We have an in-house IPAM system that's built on top of ISC DHCPd. As far as DHCPd configuration is concerned we only ever hand out static assignments; we have a different process that monitors un-responded requests coming in; allocates an address from the database (if permitted by the logic), and then dynamically updates DHCPd via omapi with the [dynamic] static assignment. It's a little more involved than that; but on a basic level, we only hand out addresses (IPv4 or IPv6) to "registered" hosts in the database. A dhcpd.conf for IPv6 would look something like: ----8<---- subnet6 2001:db8:100:1442::/120 {option dhcp6.name-servers 2001:db8:100:820::b,2001:db8:100:482::7;} host example-hostname.net.maine.edu {hardware ethernet 78:2b:cb:98:ab:cd; fixed-address6 2001:db8:100:1442::13;} ----8<---- An example using the DUID: "host-identifier option dhcp6.client-id 00:01:00:01:11:ee:71:12:00:1a:a0:aa:aa:7f;" Note that with newer versions of ISC DHCPd you can specify a MAC address instead of a DUID; and if the DUID is based on that MAC it will match. Still waiting on ISC to allow us to also specify the IAID, as it would be an issue if a host had multiple NICs in use, since the DUID is shared, though, but there is always manual configuration for that special case until then. Using DHCPv6 to only hand out addresses to hosts we want to have an address has allowed us to make IPv6 ubiquitous across our 7 member universities, and participants in our R&E network. Attempts to roll out IPv6 with SLAAC was a non-starter politically; people don't like the idea of every host on a subnet grabbing an IPv6 address unless configured not to do so; especially when you consider security concerns, and potential bugs with older IPv6 implementations (RHEL 3 and kernel panic when IPv6 connection is received, for example). On Tue, Nov 29, 2011 at 11:46 AM, Leo Bicknell wrote: > In a message written on Tue, Nov 29, 2011 at 11:39:06AM -0500, Ray Soucy wrote: >> We run both systems, in production, using DHCPv6 on prefixes much >> smaller than 64-bit (typically 120 or 119; we mirror whatever the IPv4 >> prefix length is). > > Can you explain a bit more about how this works? ?My understanding > of the current DHCPv6 implementations is that they had a hard > assumption of a /64 prefix and the ability to do SLAAC and hear a > valid RA in order to do DHCPv6. ?Are you doing anything special to > make this happen with smaller subnets? > > -- > ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440 > ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/ > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Tue Nov 29 11:09:00 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 29 Nov 2011 12:09:00 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> Message-ID: Yes and no; RFC6164 is attempting to make that more acceptable. Although; the only thing that pushed us from /30 to /31 in IPv4 was the address space crunch; that doesn't exist in the IPv6 world; so using /127 instead of /126 really doesn't seem to buy us much. On Tue, Nov 29, 2011 at 12:00 PM, McCall, Gabriel wrote: > Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most. > > -----Original Message----- > From: Fred Baker [mailto:fred at cisco.com] > ... > I see no reason you couldn't use a /127 prefix if the link was point to point. > ... > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From edward.dore at freethought-internet.co.uk Tue Nov 29 11:09:00 2011 From: edward.dore at freethought-internet.co.uk (Edward J. Dore) Date: Tue, 29 Nov 2011 17:09:00 -0000 (GMT) Subject: Equinix In-Reply-To: Message-ID: Is Equinix Denver the old Switch and Data site at 9706 East Easter Avenue, Suite 160, Englewood, Colorado, 80112? Edward Dore Freethought Internet ----- Original Message ----- From: "Keegan Holley" To: "NANOG" Sent: Tuesday, 29 November, 2011 4:47:37 PM Subject: Equinix Assuming it's not owned by the NSA does anyone know the address of the equnix colo in the Denver area? I'm working on pricing access circuits into it. A contact from equinix would be helpful as well. We haven't gotten a response to our queries. Regards, Keegan From owen at delong.com Tue Nov 29 11:21:13 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Nov 2011 09:21:13 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <4ED4CC7F.6090802@redpill-linpro.com> Message-ID: <8F6E2EC1-3E3D-47B1-A2C6-7892F2FC6565@delong.com> On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote: > Thanks to everybody participating in the discussion. > I try to summarize. > > 1) There is no any obvious benefit of using longer prefixes then /64 > in DOCSIS networks yet there are no definite objections to use them > except that it violates best practices and may lead to some problems > in the future > > 2) DHCPv6 server can use any algorithm to generate interface ID part > of the address, and EUI-64 may be just one of them that can be useful > for keeping correspondence between MAC and IPv6 addresses. Yet if we > use EUI-64 we definitely need to use /64 prefix > > 3) Using /64 networks possesses potential security threat related to > neighbor tables overflow. This is wide IPv6 problem and not related to > DOCSIS only > 99% of which can be easily mitigated by ACLs, especially in the context you are describing. > There were also notes about address usage on link networks. Though > this was out of the scope of original question it is agreed that using > /64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes > on Inter-Router Links) can be mentioned here. > I don't agree that using /64 on link networks is not reasonable. It's perfectly fine and there is no policy against it. There are risks (buggy router code having ping pong attack exposure, ND table overflow attacks if not protected by ACL), but, otherwise, there's nothing wrong with it. Owen > > Dmitry Cherkasov > > > > 2011/11/29 Dmitry Cherkasov : >> Tore, >> >> To comply with this policy we delegate at least /64 to end-users >> gateways. But this policy does not cover the network between WAN >> interfaces of CPE and ISP access gateway. >> >> Dmitry Cherkasov >> >> >> >> 2011/11/29 Tore Anderson : >>> * Dmitry Cherkasov >>> >>>> I am determining technical requirements to IPv6 provisioning system >>>> for DOCSIS networks and I am deciding if it is worth to restrict user >>>> to use not less then /64 networks on cable interface. It is obvious >>>> that no true economy of IP addresses can be achieved with increasing >>>> prefix length above 64 bits. >>> >>> I am not familiar with DOCSIS networks, but I thought I'd note that in >>> order to comply with the RIPE policies, you must assign at least a /64 >>> or shorter to each end user: >>> >>> http://www.ripe.net/ripe/docs/ripe-523#assignment_size >>> >>> -- >>> Tore Anderson >>> Redpill Linpro AS - http://www.redpill-linpro.com From owen at delong.com Tue Nov 29 11:30:50 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Nov 2011 09:30:50 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> Message-ID: <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> I believe those have been obsoleted, but, /64 remains the best choice, IMHO. Owen On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote: > Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most. > > -----Original Message----- > From: Fred Baker [mailto:fred at cisco.com] > ... > I see no reason you couldn't use a /127 prefix if the link was point to point. > ... > From rps at maine.edu Tue Nov 29 11:46:45 2011 From: rps at maine.edu (Ray Soucy) Date: Tue, 29 Nov 2011 12:46:45 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <8F6E2EC1-3E3D-47B1-A2C6-7892F2FC6565@delong.com> References: <4ED4CC7F.6090802@redpill-linpro.com> <8F6E2EC1-3E3D-47B1-A2C6-7892F2FC6565@delong.com> Message-ID: Could you provide an example of such an ACL that can prevent neighbor table exhaustion while maintaining a usable 64-bit prefix? I am intrigued. On Tue, Nov 29, 2011 at 12:21 PM, Owen DeLong wrote: > > On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote: > >> Thanks to everybody participating in the discussion. >> I try to summarize. >> >> 1) There is no any obvious benefit of using longer prefixes then /64 >> in DOCSIS networks yet there are no definite objections to use them >> except that it violates best practices and may lead to some problems >> in the future >> >> 2) DHCPv6 server can use any algorithm to generate interface ID part >> of the address, and EUI-64 may be just one of them that can be useful >> for keeping correspondence between MAC and IPv6 addresses. Yet if we >> use EUI-64 we definitely need to use /64 prefix >> >> 3) Using /64 networks possesses potential security threat related to >> neighbor tables overflow. This is wide IPv6 problem and not related to >> DOCSIS only >> > 99% of which can be easily mitigated by ACLs, especially in the context > you are describing. > >> There were also notes about address usage on link networks. Though >> this was out of the scope of original question it is agreed that using >> /64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes >> on Inter-Router Links) can be mentioned here. >> > > I don't agree that using /64 on link networks is not reasonable. It's perfectly > fine and there is no policy against it. There are risks (buggy router code > having ping pong attack exposure, ND table overflow attacks if not > protected by ACL), but, otherwise, there's nothing wrong with it. > > Owen > >> >> Dmitry Cherkasov >> >> >> >> 2011/11/29 Dmitry Cherkasov : >>> Tore, >>> >>> To comply with this policy we delegate at least /64 to end-users >>> gateways. But this policy does not cover the network between WAN >>> interfaces of CPE and ISP access gateway. >>> >>> Dmitry Cherkasov >>> >>> >>> >>> 2011/11/29 Tore Anderson : >>>> * Dmitry Cherkasov >>>> >>>>> I am determining technical requirements to IPv6 provisioning system >>>>> for DOCSIS networks and I am deciding if it is worth to restrict user >>>>> to use not less then /64 networks on cable interface. It is obvious >>>>> that no true economy of IP addresses can be achieved with increasing >>>>> prefix length above 64 bits. >>>> >>>> I am not familiar with DOCSIS networks, but I thought I'd note that in >>>> order to comply with the RIPE policies, you must assign at least a /64 >>>> or shorter to each end user: >>>> >>>> http://www.ripe.net/ripe/docs/ripe-523#assignment_size >>>> >>>> -- >>>> Tore Anderson >>>> Redpill Linpro AS - http://www.redpill-linpro.com > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From joelja at bogus.com Tue Nov 29 12:11:31 2011 From: joelja at bogus.com (Joel jaeggli) Date: Tue, 29 Nov 2011 10:11:31 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> Message-ID: <4ED52053.5040102@bogus.com> On 11/29/11 09:30 , Owen DeLong wrote: > I believe those have been obsoleted, but, /64 remains the best choice, IMHO. operational practice has moved on. http://tools.ietf.org/html/rfc6164 > Owen > > On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote: > >> Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most. >> >> -----Original Message----- >> From: Fred Baker [mailto:fred at cisco.com] >> ... >> I see no reason you couldn't use a /127 prefix if the link was point to point. >> ... >> > > > From comptech at kc.rr.com Tue Nov 29 20:17:00 2011 From: comptech at kc.rr.com (comptech at kc.rr.com) Date: Wed, 30 Nov 2011 2:17:00 +0000 Subject: ATT GigE issue on 11/19 in Kansas City Message-ID: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> We lost several of our GigE links to AT&T for 6 hours on 11/19, anyone else see this and get a root cause from AT&T? All I can get is that they believe a change caused the issue. From owen at delong.com Mon Nov 28 23:42:05 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Nov 2011 21:42:05 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> Message-ID: <3B06EBD9-7663-425B-BB57-888631D03858@delong.com> On Nov 28, 2011, at 9:15 PM, Jeff Wheeler wrote: > On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong wrote: >> Technically, absent buggy {firm,soft}ware, you can use a /127. There's no >> actual benefit to doing anything longer than a /64 unless you have >> buggy *ware (ping pong attacks only work against buggy *ware), >> and there can be some advantages to choosing addresses other than >> ::1 and ::2 in some cases. If you're letting outside packets target your >> point-to-point links, you have bigger problems than neighbor table >> attacks. If not, then the neighbor table attack is a bit of a red-herring. > > Owen and I have discussed this in great detail off-list. Nearly every > time this topic comes up, he posts in public that neighbor table > exhaustion is a non-issue. I thought I'd mention that his plan for > handling neighbor table attacks against his networks is whack-a-mole. > That's right, wait for customer services to break, then have NOC guys > attempt to clear tables, filter traffic, or disable services; and > repeat that if the attacker is determined or going after his network > rather than one of his downstream customers. > That's _NOT_ a fair characterization of what I said above, nor is it a fair characterization of my approach to dealing with neighbor table attacks. What I said above is that if you allow random traffic aimed at your point to point links, you're doing something dumb. If you don't allow random traffic, you don't have a neighbor table exhaustion attack reaching your point to point interfaces. It's that simple. That's what I said above. As to my actual plan for dealing with it, what I said was that if we ever see a neighbor table attack start causing problems with services, we'd address it at that time. Likely we would address it more globally and not through a whack-a-mole process. I did not give details of all of our mitigation strategies, nor can I. What I can say is that we do have several /64s that could be attacked such that we'd notice the attack. Most likely the attack wouldn't break anything that is a production service before we could mitigate it. In more than a decade of running production IPv6 networks, we have yet to see a neighbor table attack. Further, when you consider that most attacks have a purpose, neighbor table attacks are both more difficult and less effective than other attack vectors that are readily available. As such, I think they are less attractive to would-be attackers. > I hate to drag a frank, private discussion like that into the public > list; but every time Owen says this is a non-issue, you should keep in > mind that his own plan is totally unacceptable for any production > service. Only one of the following things can be true: either 1) Owen > thinks it is okay for services to break repeatedly and require > operator intervention to fix them if subjected to a trivial attack; or > 2) he is lieing. Take that as you will. > No, there is a third possibility. I don't mind you taking a frank private discussion public (though it's not very courteous), but, I do object to you misquoting me and misconstruing the nature and substance of what I said. I do not think it is OK for services to break repeatedly. I do think that the probability of an attacker finding ND attacks useful combined with the effort required to carry one out against a well-defended target make them far less likely than you characterize them to be. As such, I'm willing to limit the mitigation efforts to the steps we've already taken until they prove inadequate. IF they prove inadequate (whether that proof comes in the form of a service breakage or not), then we will address mitigation more broadly. However, investing infinite resources in preventing an unlikely and not particularly effective attack strikes me as a poor use of resources. Yes, ND attacks are possible if you leave your /64 wide open to external traffic. However, if you're using your /64 to provide services, chances are it's pretty easy to cluster your server in a much smaller range of addresses. A simple ACL that only permits packets to that range (or even twice or 4 times that range) will effectively block any meaningful ND attack. For example, let's say you use 2001:db8:fe37:57::1000:0 to 2001:db8:fe37:57:1000:01ff as the IPv6 range for a set of servers. Let's say there are 200 servers in that range. That's 200/512 good ND records for servers and 312 slots where you can put additional servers. That gives you a total attack surface of 312 incomplete ND records. This was part of my frank private discussion with Jeff, but, he seems to have forgotten it. In my mind, if your ACL only permits those 512 addresses to be reached from the outside (potentially attacking) world, then, your router isn't likely to fall over from those 312 incomplete ND entries. Maybe Jeff tries to run production services on something smaller than a LInksys WRT54G. I don't know. I certainly don't. Anything larger should be able to handle a few hundred incomplete NDs that don't belong without incident. If you have networks that you don't protect with ACLs, then, you're asking for other troubles regardless of the protocol anyway. Owen From jsw at inconcepts.biz Tue Nov 29 22:12:51 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 29 Nov 2011 23:12:51 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <3B06EBD9-7663-425B-BB57-888631D03858@delong.com> References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> <3B06EBD9-7663-425B-BB57-888631D03858@delong.com> Message-ID: On Tue, Nov 29, 2011 at 12:42 AM, Owen DeLong wrote: > That's _NOT_ a fair characterization of what I said above, nor is it > a fair characterization of my approach to dealing with neighbor table > attacks. Here are some direct quotes from our discussion: > Since we have relatively few customers per aggregation router, I don't > think you'd be nearly as successful as you think you would. > On the platforms we use, it won't spill over into IPv4 breakage. Additionally, > it will break fewer than 50 other dedicated servers and no other customers. > This will be tolerated for about 5 minutes while our support department > receives the alarm and looks into the cause, then, your dedicated server > won't have power any more and the problem will go away along with your > account. At no time did you ever suggest you had any idea how to systemically solve this problem. Now you are claiming that you have a "more global" approach, but this is another of your lies. > All of our support guys have enough clue to get to this quickly enough > and our monitoring systems would detect the abnormally large > neighbor table fairly early in the process. Your monitoring systems keep an eye on the size of your ND tables? How can this be true if you believe that ND attacks are not an issue? Did you just throw resources at monitoring this for no reason? Do you really even poll or alert on this data, or were you simply telling another lie? > Additionally, we have a network engineer on duty 24x7, so, even > if the support guys don't figure it out correctly, there's backup with > clue right behind them in the same room. That is exactly "NOC whack-a-mole." > What I said above is that if you allow random traffic aimed at your > point to point links, you're doing something dumb. If your network has nothing but point-to-point links, it is easy to defend. Sadly that is not how you or I interface with many of our customers. In addition, you don't actually practice what you preach. Hurricane Electric uses /126 networks in its backbone. Why are you not rushing to change these to /64? After all, you regularly tell us about the supposed disadvantages of /126 on point-to-point links. What are these disadvantages? > As to my actual plan for dealing with it, what I said was that if we > ever see a neighbor table attack start causing problems with services, > we'd address it at that time. Likely we would address it more globally > and not through a whack-a-mole process. No, this is not what you said. Again, you are simply telling lies. > I did not give details of all of our mitigation strategies, nor can I. Yes you did. Your "strategy" is whack-a-mole. > What I can say is that we do have several /64s that could be attacked > such that we'd notice the attack. Most likely the attack wouldn't break > anything that is a production service before we could mitigate it. Breaking about 50 customers for as long as it takes your support staff or NOC to troubleshoot, in your mind, muts not be "breaking anything that is a production service," or else "before we could mitigate it" means you have figured out how to travel through time. > In more than a decade of running production IPv6 networks, we have > yet to see a neighbor table attack. Further, when you consider that > most attacks have a purpose, neighbor table attacks are both more > difficult and less effective than other attack vectors that are readily > available. As such, I think they are less attractive to would-be attackers. Again, the "bad guys" don't have much motive (yet) since few services of interest share common IPv4 and IPv6 infrastructure today. That will change. > No, there is a third possibility. > > I don't mind you taking a frank private discussion public (though > it's not very courteous), but, I do object to you misquoting me > and misconstruing the nature and substance of what I said. It's disingenuous of you to continue to lie every time this topic comes up on the mailing list. > Yes, ND attacks are possible if you leave your /64 wide open to > external traffic. However, if you're using your /64 to provide services, > chances are it's pretty easy to cluster your server in a much smaller > range of addresses. A simple ACL that only permits packets to > that range (or even twice or 4 times that range) will effectively > block any meaningful ND attack. > > For example, let's say you use 2001:db8:fe37:57::1000:0 > to 2001:db8:fe37:57:1000:01ff as the IPv6 range for a > set of servers. > > Let's say there are 200 servers in that range. > > That's 200/512 good ND records for servers and 312 slots > where you can put additional servers. That gives you a total > attack surface of 312 incomplete ND records. > > This was part of my frank private discussion with Jeff, but, > he seems to have forgotten it. Since I've re-read our earlier discussion (unlike you) I can state with certainty that it was not part of our earlier discussion. If it was, I would be happy to tell everyone that your plan for deploying IPv6 to your customers includes blocking the use of the majority of the /64, such that it would function better if it were simply a longer subnet anyway. Again, your solution makes no sense. > In my mind, if your ACL only permits those 512 addresses > to be reached from the outside (potentially attacking) > world, then, your router isn't likely to fall over from those > 312 incomplete ND entries. Maybe Jeff tries to run > production services on something smaller than a > LInksys WRT54G. I don't know. I certainly don't. If you have a small layer-3 switch with 50 users, as you do, ~512 possible ND entries per user gets you to ~25k total, if the attacker decides they want to take advantage of it. 25k is larger than the IPv6 ND table on all(?) layer-3 ToR switches. Without throttling of ND punts per destination address (which is not possible if the table is exhausted, even if the data plane has this feature otherwise) then either the ND function for legitimate traffic will be broken, or the control-plane will fail in a worse way. I think my characterization of our earlier discussion is quite fair. My characterization of our current one is very simple: you are telling some pretty big lies. Feel free to demonstrate how I am mistaken. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From owen at delong.com Tue Nov 29 22:19:17 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Nov 2011 20:19:17 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <03168C8F-5F29-4596-B835-3104B1B17530@delong.com> <7ECD6B0E-D104-4B10-8729-79F1AD7363BD@cs.columbia.edu> Message-ID: <3FBF6BCE-7120-4E24-8612-E1885F9790CF@delong.com> > That said; neighbor table exhaustion is a real problem. A few lines > of C can kill IPv6 on enterprise- and carrier-grade routers. It's a > problem that has gone largely ignored because people are still in a > private address space mindset. > Only if you don't have rational ACLs in place or you are compromised from within. If you're compromised from within, this attack makes it easy to identify and resolve the compromised boxes, so, it's a net win. > We use 126-bit prefixes for link networks (we would have used 127, but > the arguments against them in RFC 3627 were compelling enough to avoid > them; after all we don't have a lack of space). There are a few > reasons for this: > That's obsolete and only applies to buggy routers that have implementations that comply with an RFC deprecated more than 5 years ago. > 1. It let's us keep link address short by using the beginning of our > allocation (e.g. you'll see things like 2610:48::66 in traceroutes to > us), which are easily memorized in the event of DNS failure (face it; > there are still some addresses you'll memorize; even if they are > IPv6). > Doing this with /64s out of the first /xx of your allocation/assignment can work equally well. For /32s, I usually suggest reserving the first /48, for example. Scale according to your particular networks needs. There's not a whole lot of difference between remembering 2610:48:0:66::1 vs. 2610:48::66. If you wanted to get really cute about it, you could even go with 2610:48:0:66:1:: using the 2610:48:0:66:2:: for the other end of the link. (yes, those are both valid /64 static addresses). > 2. We know that the number of hosts on these networks is finite; it > will always be 2, so using a 64-bit prefix isn't useful in any way; > and until we see routers hardened against neighbor table exhaustion, > they're actually harmful. > You can easily harden against this in a variety of ways. Yes, vendors should provide additional features in this area. But until they do, you can take out 99% of the attack surface with very simple ACLs. > 3. We have thousands of link networks; giving them all a 64-bit prefix > seems rather wasteful. > So I have to ask... What do you do with all those prefixes you didn't use? You can waste them in a router or you can waste them on a shelf. Either way, they're idle addresses not being used. > We've been running IPv6 in production since 2009, and when we first > jumped into it I was in the same camp of being a purist; thinking > SLAAC was the best; that DHCPv6 wasn't needed; that every network > should always be a 64-bit prefix; etc. > I think SLAAC and DHCPv6 both have their issues. Primarily because a bunch of purists from both camps spent all their time in the IETF damaging the other camp's protocol instead of perfecting their own. Hopefully now that the IETF is starting to get some additional input from actual operators this will eventually get corrected (on both sides). > A few years of experience with using IPv6 in an operational > environment has taught me otherwise. Are you saying you've seen actual ND attacks actually attack your production network other than deliberate tests? So far, I haven't seen or heard of an actual ND attack in the wild. > I'm not saying posts on list about not using anything but a 64-bit > prefix are wrong; but it's a little more complicated than > one-size-fits-all networking. Agreed. However, there's a lot to be said for one-size-fits-all and if you just mitigate the ND attack issue with simple ACLs, you're back to a place where one-size-fits-all works pretty well. > It is perfectly valid to make use of prefixes other than 64-bit; so > long as you understand the implications of doing so. Absolutely. It's more likely to cause you harm than do you any good, but, you can run your network however you see fit. > SLAAC is a great bootstrapping mechanism for ad-hoc networking; and > the link-local scope (allowing all IPv6 traffic to happen over IPv6; > even neighbor discovery). Just because it's a neat and useful way of > addressing doesn't mean it's the best way for every network. > Different strokes for different blokes and all that. You'll have a link-local with at least a /64 anyway on every link. (Technically link-local is supposed to be a /10) > To those who noticed me and Owen seem to have this argument on-list a > few times a year, sorry for the recycled content. ;-) And yet you still don't just accept that I'm right and move on. ;-) But at least it gives us a break from those that think NAT is somehow relevant to security. Owen From owen at delong.com Tue Nov 29 22:22:45 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Nov 2011 20:22:45 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> Message-ID: A /112 is almost as bad for the ND attacks as a /64, so, I don't see any reason to use a /112 at all. IMHO, the preferred link network sizes for IPv6 are, in order, /64, /127, /126, /112. Since there's no downside to the first one so long as you take proper precautions about ND attacks, most environments can stop there. If you are actually worried about ND, then consider /127. The only reason to avoid it is if you have routers with code implementing RFCs that have been deprecated for more than 5 years. Better to update your code, but, if you can't, move to /126. It's a silly number, but, at least it's a little less silly than /112. Owen On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote: > Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most. > > -----Original Message----- > From: Fred Baker [mailto:fred at cisco.com] > ... > I see no reason you couldn't use a /127 prefix if the link was point to point. > ... > From owen at delong.com Tue Nov 29 22:28:32 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Nov 2011 20:28:32 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <4ED4CC7F.6090802@redpill-linpro.com> <8F6E2EC1-3E3D-47B1-A2C6-7892F2FC6565@delong.com> Message-ID: <5889F2F1-02AE-4A66-9322-3E4F3E99B79A@delong.com> On Nov 29, 2011, at 9:46 AM, Ray Soucy wrote: > Could you provide an example of such an ACL that can prevent neighbor > table exhaustion while maintaining a usable 64-bit prefix? I am > intrigued. > For a point-to-point link... Sure... Router A: 2001:db8:0:0:1:: Router B: 2001:db8:0:0:2:: permit ipv6 any 2001:db8:0:0:3:: 0000:0000:0000:0000:0003:0000:0000:0000 Or, if you prefer: Router A: 2001:db8::1 Router B: 2001:db8::2 permit ipv6 any 2001:db8::3 0000:0000:0000:0000:0000:0000:0000:0003 Owen > On Tue, Nov 29, 2011 at 12:21 PM, Owen DeLong wrote: >> >> On Nov 29, 2011, at 4:58 AM, Dmitry Cherkasov wrote: >> >>> Thanks to everybody participating in the discussion. >>> I try to summarize. >>> >>> 1) There is no any obvious benefit of using longer prefixes then /64 >>> in DOCSIS networks yet there are no definite objections to use them >>> except that it violates best practices and may lead to some problems >>> in the future >>> >>> 2) DHCPv6 server can use any algorithm to generate interface ID part >>> of the address, and EUI-64 may be just one of them that can be useful >>> for keeping correspondence between MAC and IPv6 addresses. Yet if we >>> use EUI-64 we definitely need to use /64 prefix >>> >>> 3) Using /64 networks possesses potential security threat related to >>> neighbor tables overflow. This is wide IPv6 problem and not related to >>> DOCSIS only >>> >> 99% of which can be easily mitigated by ACLs, especially in the context >> you are describing. >> >>> There were also notes about address usage on link networks. Though >>> this was out of the scope of original question it is agreed that using >>> /64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes >>> on Inter-Router Links) can be mentioned here. >>> >> >> I don't agree that using /64 on link networks is not reasonable. It's perfectly >> fine and there is no policy against it. There are risks (buggy router code >> having ping pong attack exposure, ND table overflow attacks if not >> protected by ACL), but, otherwise, there's nothing wrong with it. >> >> Owen >> >>> >>> Dmitry Cherkasov >>> >>> >>> >>> 2011/11/29 Dmitry Cherkasov : >>>> Tore, >>>> >>>> To comply with this policy we delegate at least /64 to end-users >>>> gateways. But this policy does not cover the network between WAN >>>> interfaces of CPE and ISP access gateway. >>>> >>>> Dmitry Cherkasov >>>> >>>> >>>> >>>> 2011/11/29 Tore Anderson : >>>>> * Dmitry Cherkasov >>>>> >>>>>> I am determining technical requirements to IPv6 provisioning system >>>>>> for DOCSIS networks and I am deciding if it is worth to restrict user >>>>>> to use not less then /64 networks on cable interface. It is obvious >>>>>> that no true economy of IP addresses can be achieved with increasing >>>>>> prefix length above 64 bits. >>>>> >>>>> I am not familiar with DOCSIS networks, but I thought I'd note that in >>>>> order to comply with the RIPE policies, you must assign at least a /64 >>>>> or shorter to each end user: >>>>> >>>>> http://www.ripe.net/ripe/docs/ripe-523#assignment_size >>>>> >>>>> -- >>>>> Tore Anderson >>>>> Redpill Linpro AS - http://www.redpill-linpro.com >> >> >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ From owen at delong.com Tue Nov 29 22:31:35 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 29 Nov 2011 20:31:35 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <4ED52053.5040102@bogus.com> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> Message-ID: <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> On Nov 29, 2011, at 10:11 AM, Joel jaeggli wrote: > On 11/29/11 09:30 , Owen DeLong wrote: >> I believe those have been obsoleted, but, /64 remains the best choice, IMHO. > > operational practice has moved on. > > http://tools.ietf.org/html/rfc6164 > RFC 6164 does not say anything bad about using /64. Owen >> Owen >> >> On Nov 29, 2011, at 9:00 AM, McCall, Gabriel wrote: >> >>> Note that /127 is strongly discouraged in RFC5375 and RFC3627. 3627 suggests using /112 for router links, or /126 at the very most. >>> >>> -----Original Message----- >>> From: Fred Baker [mailto:fred at cisco.com] >>> ... >>> I see no reason you couldn't use a /127 prefix if the link was point to point. >>> ... >>> >> >> >> From mysidia at gmail.com Tue Nov 29 23:28:36 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 29 Nov 2011 23:28:36 -0600 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> Message-ID: On Tue, Nov 29, 2011 at 10:31 PM, Owen DeLong wrote: > On Nov 29, 2011, at 10:11 AM, Joel jaeggli wrote: >> On 11/29/11 09:30 , Owen DeLong wrote: >>> I believe those have been obsoleted, but, /64 remains the best choice, IMHO. >> operational practice has moved on. >> http://tools.ietf.org/html/rfc6164 > RFC 6164 does not say anything bad about using /64. > Owen RFC 6164 does not define operational practice or a recommended way of designing your network or configuring your router(s). All RFC 6164 says is essentially that some networks do want to use longer than 64-bit prefixes and there are some valid reasons, explains what motivates some operators to do so, and adds recommendations that routers must allow assignment of /127 prefixes on P-t-P inter-router links and disable subnet-router anycast when in use. In other words... if you are implementing an IPv6 router, RFC 6164 will assist you by giving you technical recommendations that you implement the capability for /127 prefixes on your router, with motiviations listed that will help you decide whether to include support for /127 inter-router links or not. -- -JH From randy at psg.com Wed Nov 30 00:30:08 2011 From: randy at psg.com (Randy Bush) Date: Wed, 30 Nov 2011 15:30:08 +0900 Subject: Bandwidth prediction tool? In-Reply-To: References: Message-ID: > Does anyone know a good Bandwidth Prediction tool?. yes. times 1.5-2.0 every year From frnkblk at iname.com Wed Nov 30 06:59:02 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 30 Nov 2011 06:59:02 -0600 Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days In-Reply-To: <0C6A4A8DD60DBF4A99C300DDA771BFAB01E8192746C7@server3.MUTUALTEL.MTCNET.NET> References: <000001cc5d68$93fc01d0$bbf40570$@iname.com> <0C6A4A8DD60DBF4A99C300DDA771BFAB01E8192746C7@server3.MUTUALTEL.MTCNET.NET> Message-ID: <008701ccaf5f$d59382f0$80ba88d0$@iname.com> Well, sometime yesterday www.centurylink.com removed it AAAA record(s). www.qwest.com still has them. Frank -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Monday, October 24, 2011 1:47 PM To: 'nanog at nanog.org' Subject: RE: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days Good news: access to the v6 version of www.qwest.com came up at 12:30 pm today -- it redirects to www.centurylink.com, but at least it's working. Only www.savvis.com remains in my list of service provider websites that have non-working IPv6. Frank -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Thursday, August 18, 2011 12:35 AM To: nanog at nanog.org Subject: IPv6 version of www.qwest.com/www.centurylink.com has been down for 10 days The IPv6 version of www.qwest.com has been down for 10 days. Wget shows a 301 to www.centurylink.com, but that also fails. Emails to the nocs at both companies have gone unanswered. Unless HE is deployed in a web browser, this behavior leads to a bad end-user experience. If anyone can prod either of these two companies that would be much appreciated. Frank nagios:/home/fbulk# wget -6 www.qwest.com --2011-08-18 00:32:40-- http://www.qwest.com/ Resolving www.qwest.com... 2001:428:b21:1::20 Connecting to www.qwest.com|2001:428:b21:1::20|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://www.centurylink.com/ [following] --2011-08-18 00:32:40-- http://www.centurylink.com/ Resolving www.centurylink.com... 2001:428:b21:1::22 Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. --2011-08-18 00:33:02-- (try: 2) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. --2011-08-18 00:33:25-- (try: 3) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. --2011-08-18 00:33:49-- (try: 4) http://www.centurylink.com/ Connecting to www.centurylink.com|2001:428:b21:1::22|:80... failed: Connection timed out. Retrying. Etc... From bdflemin at gmail.com Wed Nov 30 08:21:13 2011 From: bdflemin at gmail.com (Brad Fleming) Date: Wed, 30 Nov 2011 08:21:13 -0600 Subject: ATT GigE issue on 11/19 in Kansas City In-Reply-To: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> Message-ID: <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> On Nov 29, 2011, at 8:17 PM, wrote: > We lost several of our GigE links to AT&T for 6 hours on 11/19, anyone else see this and get a root cause from AT&T? All I can get is that they believe a change caused the issue. > We lost several (but not all) of our Optiman circuits on 11/19 at about 10:20am. We were told the root issue was that all VLANs in one of their switches had been accidentally deleted / removed. We were never able to get any additional detail (like "how") but services were restored about 16:45. From rps at maine.edu Wed Nov 30 08:48:49 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 30 Nov 2011 09:48:49 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> Message-ID: Yikes, Owen. That's a lot of responses... Saying you can mitigate neighbor table exhaustion with a "simple ACL" is misleading (and you're not the only one who has tried to make that claim). You can mitigate it by: 1. Using a stateful firewall (not an ACL) outside the router responsible for the 64-bit prefix. This doesn't scale, and is not a design many would find acceptable (it has almost all the problems of an ISP running NAT) 2. Using a "simple ACL" that drops traffic to any address not in use. This has the inherent problem that for it to be successful, it either needs to: a) dynamically update (e.g. some sort of captive portal system, where hosts have to register to get access to the outside), or b) defined as a subset of a 64-bit prefix (e.g. only allow a /126 of the prefix). I would put forward the argument that if you're going to call it a "simple ACL" it's not a dynamic ACL (NAC), so you must be talking about the second option. If you're going to create a network that is a /64 and then create an ACL that only allows traffic to a subset of that prefix; then you can't use SLAAC, privacy addressing, or any other features that a /64 would provide; what you do get is increased demand on routing infrastructure to be running many, many, many, ACLs to avoid a problem that could be avoided by using a longer prefix. So I'm not really seeing your argument here. The fact that you apply the ACL breaks the functionality you're claiming to preserve; and adds more overhead to your infrastructure in the process. I could be wrong, but I don't think ACL performance would scale well if you were doing this dynamically, either. All traffic having to traverse an ACL with thousands of statements every packet; it might be fine for a FCC "broadband" connection of 768K, but if you're providing people with actual broadband (Gigabit or greater) the cost becomes very high. I personally don't want my latency or bandwidth affected because of excessive use of ACLs and a "drop everything by default" policy. As for never seeing an neighbor table exhaustion attack "in the wild". I haven't experienced it for IPv6, but I have experienced it for IPv4, for sites that chose to use a 16-bit prefix for every internal network (even though they only needed a hundred host addresses). The only thing preventing it from being an external attack was the fact that it was safely behind NAT. With IPv6 that same problem is exposed to external attacks. I didn't buy it either until I sat down and was able to quickly reproduce it. Does that mean I'm going to attack a network just to prove a point? Of course not. The fact that it hasn't happened yet (or the people its happened to haven't realized it is what has happened; which is a bigger issue) doesn't mean it's a non-issue. DoS attacks are typically targeted at disrupting highly visible services; since the vast majority of users on the Internet don't have IPv6 access; and what IPv6 access is out there is unstable enough on its own (thanks to people throwing up firewalls that drop all ICMPv6 traffic), it's not exactly a vector anyone cares about right now. But that will change as adoption grows. I think the point is that you can easily avoid this attack vector today by using longer prefixes for now; and growing a prefix from a /120 to a /64 is a very easy change. The opposite is just not true; even if that is accomplished with an ACL rather than changing the prefix on the router. Once you have hosts using addresses, it's not something you can take away easily without being disruptive (plenty of experience with such situations as we use public IPv4 for the majority of our networks; not NAT). You keep talking about "purists" as if it's a dirty word, but then proceed to go on about how every network should be a 64-bit prefix, absolutely. You've gotta see the humor in that. ;-) Before we spun this out of control, the OP was asking if there was any problem using prefixes longer than 64-bit in a DOCSIS environment. There is no problem using a prefix-length other than 64. We do it in production and have not actually encountered a single issue as a result. You don't get SLAAC, but SLAAC isn't really desirable for a lot of the networks we're talking about (link networks, enterprise LAN networks, etc). Client systems with mature and stable IPv6 stacks (which are the only systems we care about giving IPv6 to) "just work", even when using DHCPv6 and 120-bit prefixes. If you make use of a prefix longer than 64, but reserve the full 64-bit prefix in your allocation schema, then you can easily migrate from something like a 120 or 126 to a 64; the same is not true for the reverse. If your DOCSIS system has some sort of dynamic ACL system in place already that is able to open up "registered" connections; then you're immune from the attacks discussed. If it doesn't you'll want to find a way to address that (pun intended). -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From netfortius at gmail.com Wed Nov 30 08:53:34 2011 From: netfortius at gmail.com (Stefan) Date: Wed, 30 Nov 2011 08:53:34 -0600 Subject: ATT GigE issue on 11/19 in Kansas City In-Reply-To: <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> Message-ID: On Wed, Nov 30, 2011 at 8:21 AM, Brad Fleming wrote: > On Nov 29, 2011, at 8:17 PM, wrote: > >> We lost several of our GigE links to AT&T for 6 hours on 11/19, anyone else see this and get a root cause from AT&T? All I can get is that they believe a change caused the issue. >> > We lost several (but not all) of our Optiman circuits on 11/19 at about 10:20am. We were told the root issue was that all VLANs in one of their switches had been accidentally deleted / removed. We were never able to get any additional detail (like "how") but services were restored about 16:45. +1 to the above - we received the following RFO, from the their NOC: "All impacted VLANS were rebuilt to restore service. It is believed there were some configuration changes that caused the VLAN troubles. A case has been opened with Cisco to further investigate the root cause." ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From blake at ispn.net Wed Nov 30 09:51:00 2011 From: blake at ispn.net (Blake Hudson) Date: Wed, 30 Nov 2011 09:51:00 -0600 Subject: ATT GigE issue on 11/19 in Kansas City In-Reply-To: References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> Message-ID: <4ED650E4.3050705@ispn.net> Stefan wrote the following on 11/30/2011 8:53 AM: > On Wed, Nov 30, 2011 at 8:21 AM, Brad Fleming wrote: >> On Nov 29, 2011, at 8:17 PM, wrote: >> >>> We lost several of our GigE links to AT&T for 6 hours on 11/19, anyone else see this and get a root cause from AT&T? All I can get is that they believe a change caused the issue. >>> >> We lost several (but not all) of our Optiman circuits on 11/19 at about 10:20am. We were told the root issue was that all VLANs in one of their switches had been accidentally deleted / removed. We were never able to get any additional detail (like "how") but services were restored about 16:45. > +1 to the above - we received the following RFO, from the their NOC: > > "All impacted VLANS were rebuilt to restore service. It is believed > there were some configuration changes that caused the VLAN troubles. A > case has been opened with Cisco to further investigate the root > cause." > Sounds like a VTP mishap. From tayeb.meftah at gmail.com Tue Nov 29 08:23:06 2011 From: tayeb.meftah at gmail.com (Meftah Tayeb) Date: Tue, 29 Nov 2011 16:23:06 +0200 Subject: PPPOE dialer issue on Cisco C2811 Message-ID: <4F53383E6A2A46F8A914BC8118108584@work> Hey folks please can someone see this issue i'm veery stuck on that: i have a C2811 with ADSL line created a dialer interface assigned to a fast ethernet (fe0/0) connected sucsessfully nated my lan network (172.28.0.0/24) the dialer is outside and my fe0/1 is inside but i can access (ONLY) google services! i guess is that a MTU issue? if yes what should i use ? tried 1492 1480 1500 and 1504 same hell at all. here's my config: Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __________ Information from ESET NOD32 Antivirus, version of virus signature database 6671 (20111130) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------- next part -------------- A non-text attachment was scrubbed... Name: c2800-confg Type: application/octet-stream Size: 2529 bytes Desc: not available URL: From mysidia at gmail.com Wed Nov 30 10:13:56 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 30 Nov 2011 10:13:56 -0600 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> Message-ID: On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy wrote: > Saying you can mitigate neighbor table exhaustion with a "simple ACL" > is misleading (and you're not the only one who has tried to make that > claim). It's true, though, you can. But you can also mitigate neighbor table exhaustion by using a long prefix /126; you create an upper bound on the number of neighbor table entries that are possible, and that bound is less than your device's memory capacity for neighbor table entries. This is a more reliable mitigation than an ACL; it is also simpler and less likely for an operator to mistake to render the mitigation useless, or cause other issues. >From a pure security POV, it's easy to reject ACL mitigation in favor of inherent designed-in mitigation / non-vulnerability. >From a network design POV, there may still be reasons to prefer the ACL method. They better be good reasons, such as a requirement for SLAAC on a large LAN. -- -JH From leland at taranta.discpro.org Wed Nov 30 10:32:18 2011 From: leland at taranta.discpro.org (Leland Vandervort) Date: Wed, 30 Nov 2011 17:32:18 +0100 Subject: Recent DNS attacks from China? Message-ID: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> Hi All, I am wondering if anyone else is seeing a sudden increase in DNS attacks emanating from chinese IP addresses? Over the past 24 hours we've seen a sudden rash of chinese IPs attacking our DNS servers in the order of 5 to 10 million PPS for periods of 5 to 10 mins, repeated every 20 to 30 minutes. This anomalous traffic started roughly 24 hours ago, and while we've had occasions of anomalous chinese traffic, never anything of this type. Anyone else? Regards, Leland From jsw at inconcepts.biz Wed Nov 30 10:39:52 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 30 Nov 2011 11:39:52 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> Message-ID: On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy wrote: > 1. Using a stateful firewall (not an ACL) outside the router > responsible for the 64-bit prefix. ?This doesn't scale, and is not a > design many would find acceptable (it has almost all the problems of > an ISP running NAT) Owen has suggested "stateful firewall" as a solution to me in the past. There is not currently any firewall with the necessary features to do this. We sometimes knee-jerk and think "stateful firewall has gobs of memory and can spend more CPU time on each packet, so it is a more likely solution." In this case that does not matter. You can't have 2^64 bits of memory. You could make a firewall with the needed features (or a layer-3 switch), but it would have to be the layer-3 gateway of the subnets you are protecting (not an upstream device) and it would need knowledge of all addresses in use on the subnet, which must fit within its ND table limits. Only DHCP snooping can do this and customers are not exactly keen on receiving DHCP-assigned addresses in mixed datacenter environments, even if the addresses are static ones. Once you do that, you need to limit the number of addresses that can be leased to each customer to far less than a /64 anyway. All you gain by having all that complexity is the appearance of bigger subnets, when in reality, they are non-functional except for the limited number of addresses which are actively leased out. Again the arguments for /64 are not promising. It is much less complicated to simply deploy a longer subnet. On Wed, Nov 30, 2011 at 11:13 AM, Jimmy Hess wrote: > On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy wrote: >> Saying you can mitigate neighbor table exhaustion with a "simple ACL" >> is misleading (and you're not the only one who has tried to make that >> claim). > > It's true, though, you can. > > From a network design POV, there may still be reasons to prefer the ACL method. > They better be good reasons, such as a requirement for SLAAC on a large LAN. No, Jimmy, you can't do that with SLAAC. I do not think you understand the problem. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From rsk at gsp.org Wed Nov 30 10:51:17 2011 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 30 Nov 2011 11:51:17 -0500 Subject: Used your smartphone to log into your network? Message-ID: <20111130165116.GA3224@gsp.org> If so, this might be a good time to change passwords, and to review what other information has transited your phone. (Note: androidsecuritytest.com appears to be slashdotted at the moment.) November 16: initial reports of Carrier IQ spyware surface: CarrierIQ: Most Phones Ship With "Rootkit" http://yro.slashdot.org/story/11/11/16/1517248/carrieriq-most-phones-ship-with-rootkit The Rookit of All Evil http://www.xda-developers.com/android/the-rootkit-of-all-evil-ciq/ More on CarrierIQ http://www.xda-developers.com/android/more-on-carrier-iq/ all of which reference the research presented here: Carrier IQ http://androidsecuritytest.com/features/logs-and-services/loggers/carrieriq/ November 22: Carrier IQ threatens security researcher Trevor Eckhart: CarrierIQ Tries To Silence Security Researcher http://mobile.slashdot.org/story/11/11/23/0032233/carrieriq-tries-to-silence-security-researcher Mobile Rootkit Maker Tries to Silence Critical Android Dev http://www.wired.com/threatlevel/2011/11/rootkit-brouhaha/ November 24: Carrier IQ backs off its threats, says that it doesn't track Android users Carrier IQ Relents, Apologizes http://yro.slashdot.org/story/11/11/24/1852213/carrier-iq-relents-apologizes Carrier IQ retracts cease and desist letter sent to security researcher, says it doesn't track Android users http://www.theverge.com/2011/11/23/2583862/carrier-iq-retracts-cease-and-desist-letter-sent-to-xda-developers November 29: Further research by Trevor Eckhart shows Carrier IQ spyware logs ALL keystrokes Android Dev Demonstrates CarrierIQ Phone Logging Software On Video http://yro.slashdot.org/story/11/11/30/0423256/android-dev-demonstrates-carrieriq-phone-logging-software-on-video Researcher's Video Shows Secret Software on Millions of Phones Logging Everything http://www.wired.com/threatlevel/2011/11/secret-software-logging-video The Storm Is Not Over Yet -- Lets Talk About #CIQ http://www.xda-developers.com/android/the-storm-is-not-over-yet-lets-talk-about-ciq/ all of which reference this research: Carrier IQ Part 2 http://androidsecuritytest.com/features/logs-and-services/loggers/carrieriq/carrieriq-part2/ ---rsk From John_Brzozowski at Cable.Comcast.com Wed Nov 30 10:54:10 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Wed, 30 Nov 2011 16:54:10 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: Message-ID: >From a requirements point of view I am not sure I would enforce these sort of restrictions. John On 11/29/11 6:59 AM, "Dmitry Cherkasov" wrote: >John, > >I am determining technical requirements to IPv6 provisioning system >for DOCSIS networks and I am deciding if it is worth to restrict user >to use not less then /64 networks on cable interface. It is obvious >that no true economy of IP addresses can be achieved with increasing >prefix length above 64 bits. > >As for using EUI-64, unlike random or sequential generation it >provides predictable results that may be desired, e.g. for tracking >some device migration between different networks. > >Dmitry Cherkasov > > > >2011/11/29 Brzozowski, John : >> Dmitry, >> >> >> You could consider the use of prefixes longer than the /64 on CMTS >> interfaces, however, it is not clear to me why this would be done. >> Further, most DHCPv6 implementations do not require that the generated >> IPv6 address be eui-64 based. A randomized algorithm could also be >>used. >> Another consideration is what happens after IPv6 is used for addressing >> cable modems. What happens when you want to address CPE or CPE routers? >> You are right back to /64 or shorter depending on the type of device >>being >> provisioned. >> >> FWIW - we have found that there are distinct benefits to using IPv6 >>beyond >> the amount of addresses that are available. The use of /64 is tightly >> coupled with these benefits. >> >> Can you elaborate as to why one would want to or need to use prefixes >> longer than /64? >> >> John >> >> On 11/28/11 6:37 AM, "Dmitry Cherkasov" wrote: >> >>>Hello everybody, >>> >>>It is commonly agreed that /64 is maximal length for LANs because if >>>we use longer prefix we introduce conflict with stateless address >>>autoconfiguration (SLAAC) based on EUI-64 spec. But SLAAC is not used >>>in DOCSIS networks. So there seems to be no objections to use smaller >>>networks per cable interfaces of CMTS. I was not able to find any >>>recommendations anywhere including Cable Labs specs for using >>>prefixes not greater then /64 in DOCSIS networks. Some tech from ISP >>>assumed that DHCPv6 server may generate interface ID part of IPv6 >>>address similarly to EUI-64 so MAC address of the device can easily be >>>obtained from its IPv6 address, but this does not seem like convincing >>>argument. What do you think? >>> >>> >>>Dmitry Cherkasov >>> >> > From jamie at photon.com Wed Nov 30 10:55:07 2011 From: jamie at photon.com (Jamie Bowden) Date: Wed, 30 Nov 2011 11:55:07 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> Message-ID: <275FEA2949B48341A3B46F424B613D8511C36E@WDC-MX.photon.com> > -----Original Message----- > From: Jimmy Hess [mailto:mysidia at gmail.com] > Sent: Wednesday, November 30, 2011 11:14 AM > To: Ray Soucy > Cc: NANOG > Subject: Re: IPv6 prefixes longer then /64: are they possible in DOCSIS > networks? > > On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy wrote: > > Saying you can mitigate neighbor table exhaustion with a "simple ACL" > > is misleading (and you're not the only one who has tried to make that > > claim). > > It's true, though, you can. > But you can also mitigate neighbor table exhaustion by using a long > prefix /126; > you create an upper bound on the number of neighbor table entries that > are possible, > and that bound is less than your device's memory capacity for neighbor > table entries. > > This is a more reliable mitigation than an ACL; it is also simpler > and less likely for an > operator to mistake to render the mitigation useless, or cause other > issues. > > From a pure security POV, it's easy to reject ACL mitigation in favor > of inherent > designed-in mitigation / non-vulnerability. > > From a network design POV, there may still be reasons to prefer the ACL > method. > They better be good reasons, such as a requirement for SLAAC on a large > LAN. Or maybe the IETF could, you know, decouple SLAAC from a particular netmask and make the world a better place for all of us who aren't backbone providers. Do we have to recreate the mistakes from v4 all over again? Jamie From John_Brzozowski at Cable.Comcast.com Wed Nov 30 10:56:58 2011 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Wed, 30 Nov 2011 16:56:58 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: Message-ID: Technically this is not true. SLAAC is not prohibited, it does come with side affects that complicate the deployment of IPv6. It is technically feasible to use SLAAC, it is just not practical in most cases. Stateful DHCPv6 is the preferred mechanism for address and configuration assignment. Prefix delegation requires the use of stateful DHCPv6 in DOCSIS networks. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= On 11/29/11 7:09 AM, "Dmitry Cherkasov" wrote: >Steven, > >SLAAC is prohibited for using in DOCSIS networks, router >advertisements that allow SLAAC must be ignored by end-devices, >therefore DHCPv6 is the only way of configuring (if not talking about >statical assignment). I have seen at least Windows7 handling this >properly in its default configuration: it starts DHCPv6 negotiation >instead of auto-configuration. > >Dmitry Cherkasov > > > >2011/11/29 Steven Bellovin : >> >> On Nov 28, 2011, at 4:51 52PM, Owen DeLong wrote: >> >>> >>> On Nov 28, 2011, at 7:29 AM, Ray Soucy wrote: >>> >>>> It's a good practice to reserve a 64-bit prefix for each network. >>>> That's a good general rule. For point to point or link networks you >>>> can use something as small as a 126-bit prefix (we do). >>>> >>> >>> Technically, absent buggy {firm,soft}ware, you can use a /127. There's >>>no >>> actual benefit to doing anything longer than a /64 unless you have >>> buggy *ware (ping pong attacks only work against buggy *ware), >>> and there can be some advantages to choosing addresses other than >>> ::1 and ::2 in some cases. If you're letting outside packets target >>>your >>> point-to-point links, you have bigger problems than neighbor table >>> attacks. If not, then the neighbor table attack is a bit of a >>>red-herring. >>> >> >> The context is DOCSIS, i.e., primarily residential cable modem users, >>and >> the cable company ISPs do not want to spend time on customer care and >> hand-holding. How are most v6 machines configured by default? That is, >> what did Microsoft do for Windows Vista and Windows 7? If they're set >>for >> stateless autoconfig, I strongly suspect that most ISPs will want to >>stick >> with that and hand out /64s to each network. (That's apart from the >>larger >> question of why they should want to do anything else...) >> >> >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >> >> >> >> >> >> > From Rob.Vercouteren at kpn.com Wed Nov 30 10:59:03 2011 From: Rob.Vercouteren at kpn.com (Rob.Vercouteren at kpn.com) Date: Wed, 30 Nov 2011 17:59:03 +0100 Subject: Recent DNS attacks from China? Message-ID: <3454EA54E9F18A4993A4B99F07A01D9D014D53F62F93@W2055.kpnnl.local> Hello Leland, Yes we do see the same behavior! regards, Rob Vercouteren From rps at maine.edu Wed Nov 30 11:10:21 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 30 Nov 2011 12:10:21 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> Message-ID: Owen and I have gone back and fourth over the year(s) as well. I think it really comes down to Owen's adamant belief that _every_ network should be a 64-bit prefix, and that SLAAC should be used for addressing, because it's simple and people will only adopt IPv6 if it's simple. The whole neighbor table exhaustion problem undermines that case he's trying to make, so he tries to dismiss it as a non-issue. It's nothing specific to Owen, it's basic human behavior. I've always held the view that telling people IPv6 is simple is a lie and harmful to IPv6 adoption for a few reasons: If people think IPv6 is simple, they don't bother investing time to plan out adoption and a phased deployment; they assume that when they need it they can just turn it on. If IPv6 isn't at least as flexible as IPv4, and can't fit in the same operational model used for IPv4 today; then it will never be adopted. Saying it's simple and "redesign your network" makes most people turn away from IPv6 and hope that something better will come along. The future of IPv6 for most organizations will include: DHCPv6 for stateful address assignment. NPT (Network Prefix Translation) and ULA address space internally (not NAT, but operationally identical); with load balancing between public allocations much like "dual WAN" SMB firewalls available for IPv4 (after all, having every SMB in the BGP table is not something that any of us want to see). Eventual use of NAT-PT and ALG for providing access to the legacy IPv4 Internet without having to operate a dual-stack network internally (once there is enough IPv6-enabled content so that you're only breaking some things by doing so). We won't see widespread adoption of IPv6 until we have a product people can buy in appliance form that can do these things, along with providing the typical functionality of an SMB firewall. Period. It seems a little silly that we're still having arguments about using 64-bit prefix lengths instead of focusing on how to move IPv6 to a position where it can be operationally identical to the way networks are run today and then promote adoption. You just can't tell people to turn on IPv6, ignore the security concerns, ignore the operational differences, and suck it up and forklift their network. It's not going to happen. On Wed, Nov 30, 2011 at 11:39 AM, Jeff Wheeler wrote: > On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy wrote: >> 1. Using a stateful firewall (not an ACL) outside the router >> responsible for the 64-bit prefix. ?This doesn't scale, and is not a >> design many would find acceptable (it has almost all the problems of >> an ISP running NAT) > > Owen has suggested "stateful firewall" as a solution to me in the > past. ?There is not currently any firewall with the necessary features > to do this. ?We sometimes knee-jerk and think "stateful firewall has > gobs of memory and can spend more CPU time on each packet, so it is a > more likely solution." ?In this case that does not matter. ?You can't > have 2^64 bits of memory. > > You could make a firewall with the needed features (or a layer-3 > switch), but it would have to be the layer-3 gateway of the subnets > you are protecting (not an upstream device) and it would need > knowledge of all addresses in use on the subnet, which must fit within > its ND table limits. ?Only DHCP snooping can do this and customers are > not exactly keen on receiving DHCP-assigned addresses in mixed > datacenter environments, even if the addresses are static ones. ?Once > you do that, you need to limit the number of addresses that can be > leased to each customer to far less than a /64 anyway. ?All you gain > by having all that complexity is the appearance of bigger subnets, > when in reality, they are non-functional except for the limited number > of addresses which are actively leased out. > > Again the arguments for /64 are not promising. ?It is much less > complicated to simply deploy a longer subnet. > > On Wed, Nov 30, 2011 at 11:13 AM, Jimmy Hess wrote: >> On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy wrote: >>> Saying you can mitigate neighbor table exhaustion with a "simple ACL" >>> is misleading (and you're not the only one who has tried to make that >>> claim). >> >> It's true, though, you can. >> >> From a network design POV, there may still be reasons to prefer the ACL method. >> They better be good reasons, such as a requirement for SLAAC on a large LAN. > > No, Jimmy, you can't do that with SLAAC. ?I do not think you > understand the problem. > > -- > Jeff S Wheeler > Sr Network Operator? /? Innovative Network Concepts > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From bhmccie at gmail.com Wed Nov 30 11:13:31 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 30 Nov 2011 11:13:31 -0600 Subject: Recent DNS attacks from China? In-Reply-To: <3454EA54E9F18A4993A4B99F07A01D9D014D53F62F93@W2055.kpnnl.local> References: <3454EA54E9F18A4993A4B99F07A01D9D014D53F62F93@W2055.kpnnl.local> Message-ID: <4ED6643B.70902@gmail.com> There was a new BIND vulnerability announced... http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4313 -Hammer- "I was a normal American nerd" -Jack Herer On 11/30/2011 10:59 AM, Rob.Vercouteren at kpn.com wrote: > Hello Leland, > > Yes we do see the same behavior! > > regards, > Rob Vercouteren > > From bdflemin at gmail.com Wed Nov 30 11:37:18 2011 From: bdflemin at gmail.com (Brad Fleming) Date: Wed, 30 Nov 2011 11:37:18 -0600 Subject: ATT GigE issue on 11/19 in Kansas City In-Reply-To: <4ED650E4.3050705@ispn.net> References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> <4ED650E4.3050705@ispn.net> Message-ID: On Nov 30, 2011, at 9:51 AM, Blake Hudson wrote: > Stefan wrote the following on 11/30/2011 8:53 AM: >> On Wed, Nov 30, 2011 at 8:21 AM, Brad Fleming wrote: >>> On Nov 29, 2011, at 8:17 PM, wrote: >>> >>>> We lost several of our GigE links to AT&T for 6 hours on 11/19, anyone else see this and get a root cause from AT&T? All I can get is that they believe a change caused the issue. >>>> >>> We lost several (but not all) of our Optiman circuits on 11/19 at about 10:20am. We were told the root issue was that all VLANs in one of their switches had been accidentally deleted / removed. We were never able to get any additional detail (like "how") but services were restored about 16:45. >> +1 to the above - we received the following RFO, from the their NOC: >> >> "All impacted VLANS were rebuilt to restore service. It is believed >> there were some configuration changes that caused the VLAN troubles. A >> case has been opened with Cisco to further investigate the root >> cause." >> > > Sounds like a VTP mishap. > That was my first thought as well.. it would just surprise me if a huge provider like AT&T was using VTP instead of using a provisioning tool that automates the manual pruning process to avoid issues like this. In either case I'm a customer and will likely never be told what went wrong. I'm OK with that so long as it doesn't happen again! From drc at virtualized.org Wed Nov 30 11:40:04 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 30 Nov 2011 09:40:04 -0800 Subject: Recent DNS attacks from China? In-Reply-To: <4ED6643B.70902@gmail.com> References: <3454EA54E9F18A4993A4B99F07A01D9D014D53F62F93@W2055.kpnnl.local> <4ED6643B.70902@gmail.com> Message-ID: <3A4C5126-D504-4308-B27B-F706C23B853C@virtualized.org> On Nov 30, 2011, at 9:13 AM, -Hammer- wrote: > There was a new BIND vulnerability announced... > > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4313 > I strongly suspect the BIND vulnerability is unrelated. These attacks appear to be simple (if large) DDoSes. Regards, -drc From drais at icantclick.org Wed Nov 30 11:42:29 2011 From: drais at icantclick.org (david raistrick) Date: Wed, 30 Nov 2011 12:42:29 -0500 (EST) Subject: Recent DNS attacks from China? In-Reply-To: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> Message-ID: On Wed, 30 Nov 2011, Leland Vandervort wrote: > I am wondering if anyone else is seeing a sudden increase in DNS attacks emanating from chinese IP addresses? Over the past 24 hours we've seen a sudden rash of chinese IPs attacking our DNS servers in the order of 5 to 10 million PPS for periods of 5 to 10 mins, repeated every 20 to 30 minutes. > > This anomalous traffic started roughly 24 hours ago, and while we've had occasions of anomalous chinese traffic, never anything of this type. That might explain akamai.net hostnames not resolving intermittently since Tue Nov 29 20:20:02 2011 UTC... I don't run any authoritative or exposed caches at the moment, and the aka NXDOMAINs are the only thing we've been seeing dropouts on for the past ~48 hours, but we did see NXDOMAINs from a bunch of amazonaws hostnames over the holidays... -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From bhmccie at gmail.com Wed Nov 30 11:43:30 2011 From: bhmccie at gmail.com (-Hammer-) Date: Wed, 30 Nov 2011 11:43:30 -0600 Subject: Recent DNS attacks from China? In-Reply-To: <3A4C5126-D504-4308-B27B-F706C23B853C@virtualized.org> References: <3454EA54E9F18A4993A4B99F07A01D9D014D53F62F93@W2055.kpnnl.local> <4ED6643B.70902@gmail.com> <3A4C5126-D504-4308-B27B-F706C23B853C@virtualized.org> Message-ID: <4ED66B42.2080405@gmail.com> Just offering it up. It's not a 0day or anything but it is recently published. I am not receiving the DoS so I haven't had a chance to observe the traffic. -Hammer- "I was a normal American nerd" -Jack Herer On 11/30/2011 11:40 AM, David Conrad wrote: > On Nov 30, 2011, at 9:13 AM, -Hammer- wrote: > >> There was a new BIND vulnerability announced... >> >> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4313 >> >> > I strongly suspect the BIND vulnerability is unrelated. These attacks appear to be simple (if large) DDoSes. > > Regards, > -drc > > From jmaimon at ttec.com Wed Nov 30 11:45:55 2011 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 30 Nov 2011 12:45:55 -0500 Subject: ATT GigE issue on 11/19 in Kansas City In-Reply-To: References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> <4ED650E4.3050705@ispn.net> Message-ID: <4ED66BD3.3050603@ttec.com> Brad Fleming wrote: >> > In either case I'm a customer and will likely never be told what went wrong. I'm OK with that so long as it doesn't happen again! > > Does being told what happened somehow prevent it from happening it again? What is the utilitarian value in an RFO? Joe From bdflemin at gmail.com Wed Nov 30 11:58:09 2011 From: bdflemin at gmail.com (Brad Fleming) Date: Wed, 30 Nov 2011 11:58:09 -0600 Subject: ATT GigE issue on 11/19 in Kansas City In-Reply-To: <4ED66BD3.3050603@ttec.com> References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> <4ED650E4.3050705@ispn.net> <4ED66BD3.3050603@ttec.com> Message-ID: <7BE0B126-8F07-43C5-8081-1AC0CFB0DF0F@gmail.com> >>> >> In either case I'm a customer and will likely never be told what went wrong. I'm OK with that so long as it doesn't happen again! >> > Does being told what happened somehow prevent it from happening it again? Nope. But if this same issue crops up again we'll have to "work the system" harder and demand calls with knowledgeable people; not an easy task for a customer my size (I'm not Starbucks with thousands of sites). A single outage can be understood, seeing repeated issues means I want to know what's going wrong. If the issue is something simply mitigated and the service provider hasn't taken steps, I need to start looking for a different service provider. Everything has a little downtime every now and again and I can live with it on lower speed circuits. > > What is the utilitarian value in an RFO? To determine whether its an honest mistake or a more systemic issue that should push me toward another option. From msoni at virtela.net Wed Nov 30 12:00:56 2011 From: msoni at virtela.net (Soni, Miraaj) Date: Wed, 30 Nov 2011 11:00:56 -0700 Subject: ATT GigE issue on 11/19 in Kansas City In-Reply-To: <4ED66BD3.3050603@ttec.com> References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> <4ED650E4.3050705@ispn.net> <4ED66BD3.3050603@ttec.com> Message-ID: <2D0FB9CAC171884DA2A06140CD4688AF0C9CA8@posthausxi.virtela.cc> No. It doesn't prevent it from happening again. But at least you can have them check for that same issue when it happens next time. I guess the RFO gives the customer the feeling that the vendor was able to isolate the issue and fix it; as opposed to "issue was resolved before isolation". - Miraaj Soni -----Original Message----- From: Joe Maimon [mailto:jmaimon at ttec.com] Sent: Wednesday, November 30, 2011 10:46 AM To: Brad Fleming Cc: nanog at nanog.org Subject: Re: ATT GigE issue on 11/19 in Kansas City Brad Fleming wrote: >> > In either case I'm a customer and will likely never be told what went wrong. I'm OK with that so long as it doesn't happen again! > > Does being told what happened somehow prevent it from happening it again? What is the utilitarian value in an RFO? Joe From cmadams at hiwaay.net Wed Nov 30 12:13:46 2011 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 30 Nov 2011 12:13:46 -0600 Subject: Recent DNS attacks from China? In-Reply-To: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> Message-ID: <20111130181346.GG27751@hiwaay.net> Once upon a time, Leland Vandervort said: > I am wondering if anyone else is seeing a sudden increase in DNS attacks emanating from chinese IP addresses? Over the past 24 hours we've seen a sudden rash of chinese IPs attacking our DNS servers in the order of 5 to 10 million PPS for periods of 5 to 10 mins, repeated every 20 to 30 minutes. > > This anomalous traffic started roughly 24 hours ago, and while we've had occasions of anomalous chinese traffic, never anything of this type. I'm seeing something similar. The requests are to our authoritative servers, and appear to be mostly for a small number of domains at a time (they are all domains we are authoritative for). They are all ANY queries, often repeated for the same domain rapidly. The requests come from one IP at a time, but move to another IP in a minute or two. This does NOT appear to be related to the recent BIND vulnerability. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From andrew.wallace at rocketmail.com Wed Nov 30 12:24:21 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Wed, 30 Nov 2011 10:24:21 -0800 (PST) Subject: Recent DNS attacks from China? In-Reply-To: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> Message-ID: <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> Before we see knee-jerk conclusions about who to blame, these attacks could be carried out by anyone. Is country even relevant in the cyberscape? Andrew ________________________________ From: Leland Vandervort To: nanog at nanog.org Cc: Leland Vandervort Sent: Wednesday, November 30, 2011 4:32 PM Subject: Recent DNS attacks from China? Hi All, I am wondering if anyone else is seeing a sudden increase in DNS attacks emanating from chinese IP addresses?? Over the past 24 hours we've seen a sudden rash of chinese IPs attacking our DNS servers in the order of 5 to 10 million PPS for periods of 5 to 10 mins, repeated every 20 to 30 minutes. This anomalous traffic started roughly 24 hours ago, and while we've had occasions of anomalous chinese traffic, never anything of this type. Anyone else? Regards, Leland From Valdis.Kletnieks at vt.edu Wed Nov 30 12:42:58 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 30 Nov 2011 13:42:58 -0500 Subject: Recent DNS attacks from China? In-Reply-To: Your message of "Wed, 30 Nov 2011 10:24:21 PST." <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> Message-ID: <14643.1322678578@turing-police.cc.vt.edu> On Wed, 30 Nov 2011 10:24:21 PST, "andrew.wallace" said: > Before we see knee-jerk conclusions about who to blame, these attacks could > be carried out by anyone. Is country even relevant in the cyberscape? Reading comprehension, Andrew. Leland never said the Chinese were behind it, he never even said the packets came from China. He said the packet origins were from Chinese IP addresses. And yes, country *is* relevant in the cyberscape. For starters, it defines how much cooperation you'll get in tracking, arresting, and prosecuting the offenders. The US has had a lot more success in apprehending Gary McKinnon than the perpetrators of Titan Rain. It's almost certainly due to the fact that McKinnon was in Glasgow and the Titan Rain people weren't. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From richard.barnes at gmail.com Wed Nov 30 12:51:21 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 30 Nov 2011 13:51:21 -0500 Subject: Recent DNS attacks from China? In-Reply-To: <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> Message-ID: An attack originating from somewhere indicates the presence of either an attacker or a compromised host. A particular density of either in a particular geographical area would seem like an interesting data point. --Richard On Wed, Nov 30, 2011 at 1:24 PM, andrew.wallace wrote: > Before we see knee-jerk conclusions about who to blame, these attacks could be carried out by anyone. > > > Is country even relevant in the cyberscape? > > > Andrew > > > > ________________________________ > ?From: Leland Vandervort > To: nanog at nanog.org > Cc: Leland Vandervort > Sent: Wednesday, November 30, 2011 4:32 PM > Subject: Recent DNS attacks from China? > > > Hi All, > > I am wondering if anyone else is seeing a sudden increase in DNS attacks emanating from chinese IP addresses?? Over the past 24 hours we've seen a sudden rash of chinese IPs attacking our DNS servers in the order of 5 to 10 million PPS for periods of 5 to 10 mins, repeated every 20 to 30 minutes. > > This anomalous traffic started roughly 24 hours ago, and while we've had occasions of anomalous chinese traffic, never anything of this type. > > Anyone else? > > > Regards, > > > Leland From jsahala at gmail.com Wed Nov 30 12:53:10 2011 From: jsahala at gmail.com (joshua sahala) Date: Wed, 30 Nov 2011 11:53:10 -0700 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: <4ed14249.c22ce70a.5c71.ffff8105SMTPIN_ADDED@mx.google.com> References: <20111121143253.BA43DBAD@resin13.mta.everyone.net> <4ed14249.c22ce70a.5c71.ffff8105SMTPIN_ADDED@mx.google.com> Message-ID: tyler, some additional "soft" skills that will help you distinguish yourself from others: - learn to write well: take some creative writing classes in addition to technical writing. being able to efficiently write clear, concise, and effective documentation is a skill that is necessary, and i daresay, required, especially for senior-level staff. - learn how to present/speak: join the local toastermasters. grok tufte's 'visual display of quantitative information' (or something similar -- this goes back to writing effective and concise documentation) - in addition to business and finance, learn negotiation techniques. 'getting to yes' is a good book; there are many others - learn time/task/project management: you should be able to accurately guage how long things take, task interdepence, and how to structure a (simple) project. try a few different methods to find one that works for you, and then build and rebuild your home lab using your project plan. this is also a good time to practise documentation ;) - get involved: join/start local users groups, go to a conference or two, subscribe to/read mailing lists on topics which interest you, or which are relevant to something you are studying/playing with - to reiterate what others have said: learn to troubleshoot. learn to troubleshoot. learn to troubleshoot. - develop an efficient, comprehensive methodology, and stick to it (a checklist can be helpful) - learn to take notes as you work through your procedure (what you did, what was the result: this will aid in writing both root-cause reports and operational procedures -- more documentation practise) - as you gain experience, re-evaluate and optimise, but be consistent in your approach - be able to explain and justify your procedure(s); teaching and learning from others makes you both better. mentoring will be an extremely valuable skill to your hiring manager/team (and will better position you for leadership roles) - learn how to use $favourite_search_engine in order to find answers you might also consider getting a juniper j-series box (or running bird on a *nix box, or three). a ccnp will teach you cisco's way, but most provider networks are heterogenous, and the ability to understand a non-cisco device (and moreover, a non-cisco-style cli/config), will benefit you long-term (imho). above all, have fun with what you are doing. this industry can be a lot of fun, but it is also stressful, and if you aren't enjoying what you are learning/doing, it might be time to re-evaluate your focus/priorities. hth /joshua From dholmes at mwdh2o.com Wed Nov 30 12:56:37 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Wed, 30 Nov 2011 10:56:37 -0800 Subject: ATT GigE issue on 11/19 in Kansas City In-Reply-To: <7BE0B126-8F07-43C5-8081-1AC0CFB0DF0F@gmail.com> References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> <4ED650E4.3050705@ispn.net> <4ED66BD3.3050603@ttec.com> <7BE0B126-8F07-43C5-8081-1AC0CFB0DF0F@gmail.com> Message-ID: <922ACC42D498884AA02B3565688AF995340255F31F@USEXMBS01.mwd.h2o> What I have seen lately with telco's building and operating Metro Ethernet Forum (MEF) based Ethernet networks is that relatively inexperienced telco staff are in charge of configuring and operating the networks, where telco operational staff are unaware of layer 2 Ethernet network nuances, nuances that in an Enterprise environment network engineers must know, or else. I have seen numerous instances of telco MEF layer 2 outages of 20-30 seconds where my layer 3 routing keep-alives time out. Subsequent telco root cause analysis has determined that spanning tree convergence brought down multiple links in the telco MEF network. One telco technician, assigned to Ethernet switch configuration, told me that a 20-30 second network hang is not really a big deal. -----Original Message----- From: Brad Fleming [mailto:bdflemin at gmail.com] Sent: Wednesday, November 30, 2011 9:58 AM To: Joe Maimon Cc: nanog at nanog.org Subject: Re: ATT GigE issue on 11/19 in Kansas City >>> >> In either case I'm a customer and will likely never be told what went wrong. I'm OK with that so long as it doesn't happen again! >> > Does being told what happened somehow prevent it from happening it again? Nope. But if this same issue crops up again we'll have to "work the system" harder and demand calls with knowledgeable people; not an easy task for a customer my size (I'm not Starbucks with thousands of sites). A single outage can be understood, seeing repeated issues means I want to know what's going wrong. If the issue is something simply mitigated and the service provider hasn't taken steps, I need to start looking for a different service provider. Everything has a little downtime every now and again and I can live with it on lower speed circuits. > > What is the utilitarian value in an RFO? To determine whether its an honest mistake or a more systemic issue that should push me toward another option. This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system. From MatlockK at exempla.org Wed Nov 30 12:57:23 2011 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Wed, 30 Nov 2011 11:57:23 -0700 Subject: Recent DNS attacks from China? References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org> Except in this case it's a DNS attack, which implies UDP based and easily spoofed. The source IP may or may not actually be accurate. Ken ________________________________ From: Richard Barnes [mailto:richard.barnes at gmail.com] Sent: Wed 11/30/2011 11:51 AM To: andrew.wallace Cc: nanog at nanog.org; Leland Vandervort Subject: Re: Recent DNS attacks from China? An attack originating from somewhere indicates the presence of either an attacker or a compromised host. A particular density of either in a particular geographical area would seem like an interesting data point. --Richard On Wed, Nov 30, 2011 at 1:24 PM, andrew.wallace wrote: > Before we see knee-jerk conclusions about who to blame, these attacks could be carried out by anyone. > > > Is country even relevant in the cyberscape? > > > Andrew *** Exempla 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. *** Exempla Confidentiality Notice *** From mike at mikejones.in Wed Nov 30 13:35:57 2011 From: mike at mikejones.in (Mike Jones) Date: Wed, 30 Nov 2011 19:35:57 +0000 Subject: ATT GigE issue on 11/19 in Kansas City In-Reply-To: <4ED66BD3.3050603@ttec.com> References: <20111130021700.BDLG8.157079.root@hrndva-web07-z01> <56C0B9C7-937A-465B-B8C4-65D9E690EDB6@gmail.com> <4ED650E4.3050705@ispn.net> <4ED66BD3.3050603@ttec.com> Message-ID: On 30 November 2011 17:45, Joe Maimon wrote: > > > Brad Fleming wrote: > >>> >> In either case I'm a customer and will likely never be told what went >> wrong. I'm OK with that so long as it doesn't happen again! >> >> > > > Does being told what happened somehow prevent it from happening it again? > > What is the utilitarian value in an RFO? > "The outage was caused by an engineer turning off the wrong router, it has been turned back on and service restored" "The outage appears to have been caused by a bug in the routers firmware, we are working with the vendor on a fix" "There was an outage, now service is back up again" A brief isolated incident in any case you probably don't care enough to change providers (if you care about outages that much, you just divert traffic to your other redundant connections), but say you've had 2 outages in a week with that given as the explanation, which one makes you feel more concerned about going shopping for another provider? Technically the first provider knows the causes of the outages and it has been fixed while the second one doesn't know for sure what the problem is and they might have fixed it or might not, however I suspect most people would probably not agree with that interpretation. The third provider I don't think there's any way to interpret it to make them look good. >From a utilitarian point of view the more detail customers get the less angry they normally are, and I believe "less angry" is a generally accepted form of "happier" in the ISP world (at least some ISPs seem to think so). Therefore for utilitarian reasons you should write nice long details reports, unless the cause is incompetence then you should probably just shut up and let people assume incompetence instead of confirming it, as confirming it might make them less happy. Although one could also argue that by being honest about incompetence your customers will likely change providers sooner, causing an overall increase in their level of happiness. This utilitarian thing is complicated. - Mike From mysidia at gmail.com Wed Nov 30 13:41:49 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 30 Nov 2011 13:41:49 -0600 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> Message-ID: On Wed, Nov 30, 2011 at 10:39 AM, Jeff Wheeler wrote: > On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy wrote: > Owen has suggested "stateful firewall" as a solution to me in the > past. ?There is not currently any firewall with the necessary features > to do this. ?We sometimes knee-jerk and think "stateful firewall has > gobs of memory and can spend more CPU time on each packet, so it is a > more likely solution." ?In this case that does not matter. ?You can't > have 2^64 bits of memory. In principle, a firewall doesn't need 2^64 bits of memory. You can have a single tree node that tells you "OK, all the interface IDs in the range 0x0000000000000000 through 0x000000000007ffff on Interface/network X are in state X; there comes a point where you can discard stale data long before it gets close to 2^64 bits. That's all well and good that in theory you could construct a stateful firewall to protect some /126 inter-router links, but seriously.. Why should you? Stateful firewalls are not free; neither is making a stateful firewall that can do that. What's the overwhelming benefit of forcing in a /126 on your P-t-P inter-router links if it has risks and complicates matters so much? -- -JH From bicknell at ufp.org Wed Nov 30 13:44:33 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 30 Nov 2011 11:44:33 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> Message-ID: <20111130194433.GA19779@ussenterprise.ufp.org> In a message written on Wed, Nov 30, 2011 at 01:41:49PM -0600, Jimmy Hess wrote: > What's the overwhelming benefit of forcing in a /126 on your P-t-P > inter-router links if it has risks and complicates matters so much? Making Owen happy. :) -- 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 Rob.Vercouteren at kpn.com Wed Nov 30 14:05:18 2011 From: Rob.Vercouteren at kpn.com (Rob.Vercouteren at kpn.com) Date: Wed, 30 Nov 2011 21:05:18 +0100 Subject: Recent DNS attacks from China? In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org> References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org> Message-ID: <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local> Yes it is, but the problem is that our servers are "attacking" the so called source address. All the answers are going back to the "source". It is huge amplification attacks. (some sort of smurf if you want) The ip addresses are spoofed (We did a capture and saw all different ttl's so coming from behind different hops) And yes we saw the ANY queries for all the domains. I still wonder how it is still possible that ip addresses can be spoofed nowadays Rob ============================ -----Oorspronkelijk bericht----- Van: Matlock, Kenneth L [mailto:MatlockK at exempla.org] Verzonden: woensdag 30 november 2011 19:57 Aan: Richard Barnes; andrew.wallace CC: nanog at nanog.org; Leland Vandervort Onderwerp: RE: Recent DNS attacks from China? Except in this case it's a DNS attack, which implies UDP based and easily spoofed. The source IP may or may not actually be accurate. Ken ________________________________ From: Richard Barnes [mailto:richard.barnes at gmail.com] Sent: Wed 11/30/2011 11:51 AM To: andrew.wallace Cc: nanog at nanog.org; Leland Vandervort Subject: Re: Recent DNS attacks from China? An attack originating from somewhere indicates the presence of either an attacker or a compromised host. A particular density of either in a particular geographical area would seem like an interesting data point. --Richard On Wed, Nov 30, 2011 at 1:24 PM, andrew.wallace wrote: > Before we see knee-jerk conclusions about who to blame, these attacks could be carried out by anyone. > > > Is country even relevant in the cyberscape? > > > Andrew *** Exempla 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. *** Exempla Confidentiality Notice *** From drew.weaver at thenap.com Wed Nov 30 14:12:09 2011 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 30 Nov 2011 15:12:09 -0500 Subject: Recent DNS attacks from China? In-Reply-To: <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local> References: <02F7D865-8803-4662-818C-9332163730F1@taranta.discpro.org> <1322677461.68582.YahooMailNeo@web162104.mail.bf1.yahoo.com> <4288131ED5E3024C9CD4782CECCAD2C70B53079D@LMC-MAIL2.exempla.org> <3454EA54E9F18A4993A4B99F07A01D9D014D53F62FC5@W2055.kpnnl.local> Message-ID: -----Original Message----- From: Rob.Vercouteren at kpn.com [mailto:Rob.Vercouteren at kpn.com] Sent: Wednesday, November 30, 2011 3:05 PM To: MatlockK at exempla.org; richard.barnes at gmail.com; andrew.wallace at rocketmail.com Cc: nanog at nanog.org; leland at taranta.discpro.org Subject: RE: Recent DNS attacks from China? Yes it is, but the problem is that our servers are "attacking" the so called source address. All the answers are going back to the "source". It is huge amplification attacks. (some sort of smurf if you want) The ip addresses are spoofed (We did a capture and saw all different ttl's so coming from behind different hops) And yes we saw the ANY queries for all the domains. I still wonder how it is still possible that ip addresses can be spoofed nowadays ================= Rob, Transit providers can bill for the denial of service traffic and they claim it's too expensive to run URPF because of the extra lookup. -Drew From rps at maine.edu Wed Nov 30 14:14:07 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 30 Nov 2011 15:14:07 -0500 Subject: IPv6 NPT and NAT for Linux Message-ID: For those who missed it, Linux is adding NAT for IPv6 to netfilter: http://www.spinics.net/lists/netfilter-devel/msg19979.html Along with tradition SNAT, and DNAT targets most of us are familiar with, a new NETMAP target is included that implements NPT (network prefix translation). I for one am happy to see this; despite not wanting to see people NAT IPv6 as the norm, having the NETMAP target will largely replace the use of SNAT and MASQUERADE for many deployments, while keeping those tools for the times when traditional NAT is desirable. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Wed Nov 30 14:13:30 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 30 Nov 2011 12:13:30 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> Message-ID: <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote: > Owen and I have gone back and fourth over the year(s) as well. > > I think it really comes down to Owen's adamant belief that _every_ > network should be a 64-bit prefix, and that SLAAC should be used for > addressing, because it's simple and people will only adopt IPv6 if > it's simple. The whole neighbor table exhaustion problem undermines > that case he's trying to make, so he tries to dismiss it as a > non-issue. It's nothing specific to Owen, it's basic human behavior. > I've never said SLAAC should be used for addressing. I have said that SLAAC is useful in many situations and can be a good tool. I have consistently said that administrators should be free to choose the addressing mechanism that work best for their environments. I do believe that there is no benefit to longer prefixes than /64. Nobody has provided any convincing evidence to the contrary. There are better ways to mitigate ND than longer prefixes. > I've always held the view that telling people IPv6 is simple is a lie > and harmful to IPv6 adoption for a few reasons: > > If people think IPv6 is simple, they don't bother investing time to > plan out adoption and a phased deployment; they assume that when they > need it they can just turn it on. > I don't believe I've said IPv6 is simple. I've said that IPv6 is easier than IPv4. It is. You don't have to worry about many of the common difficulties with IPv4 (NAT, address conservation, subnet rightsizing, etc.). > If IPv6 isn't at least as flexible as IPv4, and can't fit in the same > operational model used for IPv4 today; then it will never be adopted. I would argue that IPv6 is more flexible than IPv4, but, it does require changes to some IPv4 operational models. IP didn't fit the same operational model as IPX, yet we made the transition from IPX to IPv4, so, I don't buy into your idea that it won't be adopted if it doesn't fit the same operational models. Some operational models for IPv4 are obsoleted by IPv6. Such is the nature of protocol change. > Saying it's simple and "redesign your network" makes most people turn > away from IPv6 and hope that something better will come along. > I wouldn't say redesign your network so much as design your IPv6 network. In some cases, keeping in mind your IPv4 topology is useful. In some cases, moving beyond the limitations under which your IPv4 topology was constructed is very beneficial in IPv6. For example, common scenario in enterprise IPv4 is a single link with half a dozen or so /28s on it as the server farm grew. There's no reason not to make that a single IPv6 /64 while still leaving all those different IPv4 networks in place. There's no benefit whatsoever to allocating half a dozen IPv6 prefixes or sizing them to some /120 or whatever. > The future of IPv6 for most organizations will include: > > DHCPv6 for stateful address assignment. I've never argued against DHCP usage. > NPT (Network Prefix Translation) and ULA address space internally (not > NAT, but operationally identical); with load balancing between public > allocations much like "dual WAN" SMB firewalls available for IPv4 > (after all, having every SMB in the BGP table is not something that > any of us want to see). I'm not as convinced as you are of this. > Eventual use of NAT-PT and ALG for providing access to the legacy IPv4 > Internet without having to operate a dual-stack network internally > (once there is enough IPv6-enabled content so that you're only > breaking some things by doing so). Remains to be seen whether it will be NAT-PT, NAT64, NAT444, IVI, or something else for this. I'm not convinced that the enterprise will be where IPv4 is deprecated first. In fact, I suspect it is likely to be one of the last places to move from dual-stack to IPv6-only as you describe. > We won't see widespread adoption of IPv6 until we have a product > people can buy in appliance form that can do these things, along with > providing the typical functionality of an SMB firewall. Time will tell. I suspect that if no such product is made available, it will not prevent widespread deployment of IPv6. > It seems a little silly that we're still having arguments about using > 64-bit prefix lengths instead of focusing on how to move IPv6 to a > position where it can be operationally identical to the way networks > are run today and then promote adoption. Some of us don't want to do that kind of damage to IPv6. As such, I prefer to deploy IPv6 as it is today and resolve the bugs and the security issues along the way (much like we did with IPv4). IPv6 can be operationally similar, but, making it operationally identical would take away many of its benefits. > You just can't tell people to turn on IPv6, ignore the security > concerns, ignore the operational differences, and suck it up and > forklift their network. It's not going to happen. I've never said forklift your network or ignore the operational differences. In fact, I've said embrace the operational differences and celebrate the fact that you don't have to deal with NAT any more. Enjoy simplified address planning with massive headroom. I haven't said that security issues should be ignored, either. Just that they should be viewed in a proper context and assessed with a realistic evaluation of the magnitude of the risk and the difficulty of mitigation. The magnitude of risk is defined in terms of the probability of an event combined with the damage caused by such an event. What has also been lost here is that my description of the various mitigation tactics for ND exhaustion attacks depends on the type of network being protected. Strategies that work for point-to-point links (simple ACLs at the borders in most environments, for example) are not the same as strategies that work to protect client LANs (stateful firewalls with default deny inbound) or strategies necessary to protect server LANs (slightly more complex ACLs and other tactics). Owen From bicknell at ufp.org Wed Nov 30 14:24:45 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 30 Nov 2011 12:24:45 -0800 Subject: IPv6 NPT and NAT for Linux In-Reply-To: References: Message-ID: <20111130202445.GA21263@ussenterprise.ufp.org> In a message written on Wed, Nov 30, 2011 at 03:14:07PM -0500, Ray Soucy wrote: > I for one am happy to see this; despite not wanting to see people NAT > IPv6 as the norm, having the NETMAP target will largely replace the > use of SNAT and MASQUERADE for many deployments, while keeping those > tools for the times when traditional NAT is desirable. +1 Long overdue for many different reasons, be they political (stop the "nat doesn't exist in IPv6 nonsense") or practical, like the ability to translate IP based services to new addresses. For instance it might be nice to translate an old DNS server IPv6 address to a new working DNS server in some situations. NAT has many more applications than it's most popular RFC1918 PNAT to one IPv4 address, and IPv6 has been missing out on those other tools due to the regious nature of the "private address vrs public address" dogmas for that one, specific NAT application. -- 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 dwcarder at wisc.edu Wed Nov 30 14:29:54 2011 From: dwcarder at wisc.edu (Dale W. Carder) Date: Wed, 30 Nov 2011 14:29:54 -0600 Subject: IPv6 NPT and NAT for Linux In-Reply-To: References: Message-ID: On Nov 30, 2011, at 2:14 PM, Ray Soucy wrote: > For those who missed it, Linux is adding NAT for IPv6 to netfilter: > > http://www.spinics.net/lists/netfilter-devel/msg19979.html > > Along with tradition SNAT, and DNAT targets most of us are familiar > with, a new NETMAP target is included that implements NPT (network > prefix translation). > > I for one am happy to see this; despite not wanting to see people NAT > IPv6 as the norm, having the NETMAP target will largely replace the > use of SNAT and MASQUERADE for many deployments, while keeping those > tools for the times when traditional NAT is desirable. Regardless of what one thinks of v6 NAT, having a v6 REDIRECT target in linux is long overdue. (trying to do it with tproxy hackery is really a mess) Dale From hmurray at megapathdsl.net Wed Nov 30 14:31:29 2011 From: hmurray at megapathdsl.net (Hal Murray) Date: Wed, 30 Nov 2011 12:31:29 -0800 Subject: Recent DNS attacks from China? Message-ID: <20111130203129.63046800037@ip-64-139-1-69.sjc.megapath.net> > I am wondering if anyone else is seeing a sudden increase in DNS attacks > emanating from chinese IP addresses? Over the past 24 hours we've seen a > sudden rash of chinese IPs attacking our DNS servers in the order of 5 to 10 > million PPS for periods of 5 to 10 mins, repeated every 20 to 30 minutes. > This anomalous traffic started roughly 24 hours ago, and while we've had > occasions of anomalous chinese traffic, never anything of this type. I don't know if it's related, but at about the same time USNO reported an attack on their NTP servers. I could easily imagine a piece of malware with a bug that does massive retransmits on both DNS and NTP. ----------- From: Rich Newsgroups: comp.protocols.time.ntp Subject: NTP Denial of Service attack 29 November 2011 Date: Tue, 29 Nov 2011 12:44:44 -0800 (PST) Organization: http://groups.google.com NNTP-Posting-Host: 199.211.133.254 USNO is seeing an apparent coordinated denial of service attack on NTP originating with the following IPs: 220.117.53.67; 218.92.115.152; 114.40.28.224; 218.201.21.194. ---------- At 11 pm EST 29 Nov 2011 the Navy Cyber Defense Operations Command ordered USNO to take NTP servers in Washington, DC offline, and USNO complied. USNO serves more than 3 million clients. This is the first time in 17 years that we have ceased NTP operations. ---- NTP Service from USNO Washington was restored at 30.56 November 2011 UTC. No further information is available for dissemination at this time. -- These are my opinions, not necessarily my employer's. I hate spam. From jsw at inconcepts.biz Wed Nov 30 14:35:38 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 30 Nov 2011 15:35:38 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> Message-ID: On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong wrote: > As such, I prefer to deploy IPv6 as it is today and resolve the bugs > and the security issues along the way (much like we did with IPv4). Why is the Hurricane Electric backbone using /126 link-nets, not /64? You used to regularly claim there are significant disadvantages to longer subnets. At best, you are still claiming there are no advantages. These are lies. Please, Owen, tell us why you aren't practicing what you preach. > I haven't said that security issues should be ignored, either. Just that > they should be viewed in a proper context and assessed with a realistic > evaluation of the magnitude of the risk and the difficulty of mitigation. You repeatedly claim that ND exhaustion is a non-issue. You also claim you have secret sauce to mitigate attacks. This, after you previously claimed that you were using common ACLs to mitigate attacks, and I showed you how that cannot be true. Your understanding of this problem has rocketed from totally clueless to having secrets you can't discuss. Except it isn't, because you are also advocating ... denying all traffic to all subnets except the first few hundred addresses. What a stellar plan! Just stop telling lies about this, Owen. That's all I'm asking. You, personally, are part of the problem. If the guy who is supposed to be the public-facing technical outreach guy for the self-described leader in IPv6 transit/hosting/etc services continues to go around claiming this is a non-issue, when it very clearly is, that is destructive, not helpful. > What has also been lost here is that my description of the various > mitigation tactics for ND exhaustion attacks depends on the type > of network being protected. Strategies that work for point-to-point > links (simple ACLs at the borders in most environments, for > example) are not the same as strategies that work to protect > client LANs (stateful firewalls with default deny inbound) or > strategies necessary to protect server LANs (slightly more complex > ACLs and other tactics). You have no such "simple ACLs at the borders" on the Hurricane Electric network. In fact, your mitigation mechanism for the backbone is exactly what I recommend: deploy longer subnets. You don't have any mitigation mechanism for your hosting services, other than whack-a-mole. If anyone has trouble believing me, you can do what I did, and email Owen off-list. You can say, Owen, I'd like to subscribe to a Hurricane Electric dedicated server, get myself a /64, and DoS my own subnet, to see if that affects my box or any other nearby customers. The reply you'll get will be that your box will be powered off, because they have no mitigation strategy. Arguing in the abstract is all fun and games, but when you ask Owen to show you something that works in a real-world, production environment, he can't. That's because Owen's network design is not suitable for production use in his own environment with routers he claims to have selected in part based on their performance under ND attacks (another lie.) -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From sthaug at nethelp.no Wed Nov 30 14:45:11 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 30 Nov 2011 21:45:11 +0100 (CET) Subject: Recent DNS attacks from China? In-Reply-To: <20111130203129.63046800037@ip-64-139-1-69.sjc.megapath.net> References: <20111130203129.63046800037@ip-64-139-1-69.sjc.megapath.net> Message-ID: <20111130.214511.78711491.sthaug@nethelp.no> > > I am wondering if anyone else is seeing a sudden increase in DNS attacks > > emanating from chinese IP addresses? Over the past 24 hours we've seen a > > sudden rash of chinese IPs attacking our DNS servers in the order of 5 to 10 > > million PPS for periods of 5 to 10 mins, repeated every 20 to 30 minutes. > > > This anomalous traffic started roughly 24 hours ago, and while we've had > > occasions of anomalous chinese traffic, never anything of this type. > > I don't know if it's related, but at about the same time USNO reported an > attack on their NTP servers. > > I could easily imagine a piece of malware with a bug that does massive > retransmits on both DNS and NTP. I'm seeing DNS-based attacks on a regular basis, typically several per day. Often involving ANY isc.org or ANY ripe.net to get a good amplification. E.g. *right now* an amplification attack against 78.159.111.190. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From rps at maine.edu Wed Nov 30 15:10:33 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 30 Nov 2011 16:10:33 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> Message-ID: On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong wrote: > I do believe that there is no benefit to longer prefixes than /64. > Nobody has provided any convincing evidence to the contrary. > > There are better ways to mitigate ND than longer prefixes. Agree to disagree, I guess. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mark at exonetric.com Wed Nov 30 15:18:38 2011 From: mark at exonetric.com (Mark Blackman) Date: Wed, 30 Nov 2011 21:18:38 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> Message-ID: <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com> On 30 Nov 2011, at 21:10, Ray Soucy wrote: > On Wed, Nov 30, 2011 at 3:13 PM, Owen DeLong wrote: >> I do believe that there is no benefit to longer prefixes than /64. >> Nobody has provided any convincing evidence to the contrary. >> >> There are better ways to mitigate ND than longer prefixes. > > Agree to disagree, I guess. To be honest, I can't work out the point of preferring a /64 in the first place if you're not using SLAAC and I'm not sure why SLAAC wanted more than 48 bits. If you use broad ACLs to lock down to a /126 or /112 equivalent, why bother with the /64 in the first place? However, I'm new to the IPv6 business, so I'm sure I'll work it out eventually. - Mark From nathan at atlasnetworks.us Wed Nov 30 16:05:00 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 30 Nov 2011 22:05:00 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B60F4BF@ex-mb-1.corp.atlasnetworks.us> > To be honest, I can't work out the point of preferring a /64 in the > first place if > you're not using SLAAC and I'm not sure why SLAAC wanted more than 48 > bits. > > If you use broad ACLs to lock down to a /126 or /112 equivalent, why > bother with > the /64 in the first place? > > However, I'm new to the IPv6 business, so I'm sure I'll work it out > eventually. Or you might do what a lot of us have done: get sick of arguing with the evangelists about how /64's don't make sense for everyone in every scenario. Get sick of trying to argue that every home's CPE doesn't need a /48 delegated to it so that it can automatically subdelegate longer networks to devices which will in turn subdelegate even longer prefixes to devices which "something that hasn't been invented yet will use, and if you don't set it up this way, history will prove that you're an unimaginative fool". Get sick of hearing "It's a huge address space, so don't worry about being conservative - sitting 'on the shelf' or sitting unused in a network are the same thing" (I guess we'll migrate to an even bigger address space if we someday have other stellar bodies in our local star system to send packets to, despite the average home network utilizing far, far less than .00[...]01% of their address space... - add a lot more 0's if the /48 guys win out...) This new IPv6 world is full of lazy evangelists, who are so excited about same-sized subnets, stateless address configuration and globally unique and routable addresses for purposes that no one can quite imagine yet, that they cannot engage in a logical and rational discussion with the rest of us. Instead, we go back and forth over the same concerns, until the patience of the list has been utterly worn out - at which point, these individuals always throw their hands in the air, and exclaim: "You're wrong, and your customers will tell you that with their feet", and presume that they have then proven you wrong. As has been pointed out, there is a lot of human nature at work here: these individuals have made low-level emotional investments in their arguments, and divided the IPv6-think world into two categories: Us (right), and Not Us (wrong). When someone does this, it can take a significant amount of psychology to get the conversation to a rational place, and unless you have a real need to see eye to eye with them, it's often easier to move on. In any case, do the research and testing, and make sure that at least your own deployments have rational addressing policies (whatever you determine that might be). Nathan Eisenberg From nonobvious at gmail.com Wed Nov 30 16:46:05 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 30 Nov 2011 14:46:05 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <3729C1E0-D8AF-479F-A50B-18EFE4407543@delong.com> Message-ID: On Tue, Nov 29, 2011 at 3:46 AM, Dmitry Cherkasov wrote: > Currently I research on IPv6 provisioning systems and I need to decide > whether the ability to use longer then /64 prefixes should be > supported in them or not. If we restrict user to using /64 per network > we need to have convincing reasons for this. Best practice and common > sense stand for using /64 but this may be not sufficient for some > people. There's a very strong case to be made for "Be conservative in what you generate and liberal in what you accept" here. One of the primary reasons for using /64 everywhere is the fear that somebody somewhere in your network built some piece of equipment or software that you're using that doesn't let you use prefixes longer than /64, and you don't want to have to find them all the hard way. Please don't be that piece of software! My organization uses longer addresses for equipment we control because we have different ops folks handling routers, firewalls, load balancers, miscellaneous control boxes, etc. and it lets them keep track of who's in charge of what address space without requiring a /47 out of the customer's /48 network just for the management subnets for the equipment we manage for them. We've also found that in production networks, /126 usually is too long a prefix, because often we'll be doing high availability configurations with HSRP/VRRP, so it's cleaner to be /124 or shorter (plus nibble-aligned or byte-aligned address blocks make report generation less ugly.) -- ---- ? ? ? ? ? ?? Thanks;? ?? Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From dougb at dougbarton.us Wed Nov 30 16:50:41 2011 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 30 Nov 2011 14:50:41 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <3729C1E0-D8AF-479F-A50B-18EFE4407543@delong.com> Message-ID: <4ED6B341.7040606@dougbarton.us> On 11/30/2011 14:46, Bill Stewart wrote: > There's a very strong case to be made for "Be conservative in what you > generate and liberal in what you accept" here. I've been saying for years that your safest bet is to reserve a /64, regardless of how many bits you use out of it, or why. If you do that you're covered either way. And in the incredibly unlikely event that you run out, and can't get more, you can go back and chop up the /64s where it's proven safe to use longer prefixes. easy peasy, Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From nonobvious at gmail.com Wed Nov 30 17:02:09 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 30 Nov 2011 15:02:09 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com> Message-ID: On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman wrote: > ... and I'm not sure why SLAAC wanted more than 48 bits. One reason IPv6 addresses are 128 bits long instead of 40, 48, 64 or 80 is because converting from IPv4 to IPv6 is really painful and we don't want to ever have to do it again in the future. Eventually we will run out of 48-bit MAC addresses, because we'll run out of 24-bit manufacturer ID parts, and we'll transition to EUI-64 or something like it. It will be ugly and painful, and it will break many things, and if we used 48-bit MAC addresses for SLAAC, it would break IPv6 as well. Using EUI-64 instead of MAC means that all the breakage will live at Layer 2. It does break some things in IPv6 - we've spent a couple of years arguing about whether ISPs should give customers /48, /56, /60, or /64, instead of having the nice clean "64 bits for the network provider, 16 bits for subnet, 48 for MAC" that the earlier proposals adapted from Netware IPX, but that would probably have gotten us in trouble also. I can't explain why EUI-64 picked its particular ugly way to convert 48-bit MACs to 64-bit, but I won't rant about that here. -- ---- ? ? ? ? ? ?? Thanks;? ?? Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From mark at exonetric.com Wed Nov 30 17:33:51 2011 From: mark at exonetric.com (Mark Blackman) Date: Wed, 30 Nov 2011 23:33:51 +0000 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com> Message-ID: <193BA8AA-22C3-4682-954B-B0A25A762647@exonetric.com> On 30 Nov 2011, at 23:02, Bill Stewart wrote: > On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman wrote: >> ... and I'm not sure why SLAAC wanted more than 48 bits. > > One reason IPv6 addresses are 128 bits long instead of 40, 48, 64 or > 80 is because converting from IPv4 to IPv6 is really painful and we > don't want to ever have to do it again in the future. Sure, 128 bits I can see the point of. Rigid insistence on /64 subnets when no broadcast domain will ever have 2^64 devices on it seems like a less obvious choice. - Mark From nonobvious at gmail.com Wed Nov 30 17:39:17 2011 From: nonobvious at gmail.com (Bill Stewart) Date: Wed, 30 Nov 2011 15:39:17 -0800 Subject: Looking for a Tier 1 ISP Mentor for career advice. In-Reply-To: References: <48778.1321883369@turing-police.cc.vt.edu> <4ECAB566.5070408@blakjak.net> Message-ID: Another really useful skill is knowing what it looks like to be a customer / end user of one of those networks. Sure, it's fun to crank obscure BGP load-balancing techniques, but you also need to know where the industry as a whole is going technically and business-wise. Tier 1s sell to Tier 2s, big enterprises, content providers, and consumers, and they all need different things. How much is computing staying under the control of the companies that use it vs. migrating out to cloud providers and Something-As-A-Service? What happens to networks as broadcast TV gets replaced by consumers downloading content? What do you know about end-users from hanging out with other college students that the old folks running the ISPs don't understand yet? Some parts of the Tier 1 business depend on providing access to large end user locations, which is more of an issue of zoning, real estate, and geography; other parts want to scale to hundreds of thousands of smaller connections. When I had a job that was more in the field than my current position, something I saw happening all the time was that people who worked for a customer would get a job at one of their vendors, or people who worked for a vendor would get a job at one of their customers. In bigger companies, that may also be internal end users and service organizations in addition to external customers. It's a big way that you build the relationships that lead to getting jobs and to finding people to hire. And yeah, sometimes it means that you need to go learn technologies like Active Directory, either because you might end up working for an enterprise instead of a service provider, or just because your customers will be using it and you need to know how it'll affect their network needs. In addition to learning scripting languages, you really need to learn some basic VMware, because operationally just about everything that doesn't need custom silicon is migrating onto virtual machines. You don't need to have a whole VMsphere N+1 system at home, but at least install the free versions on a PC, build some VMs and some virtual switches and let them talk to each other, do some firewalls, etc. The certification business is useful for a couple of things - giving you some direction in your learning process, telling people who are trying to hire new coworkers something about your skills, and getting your resume past the HR department so the people who actually understand what the jobs are can see it (or at least keeping them from getting in the way if you've made the connections through people you know instead of through HR.) From rps at maine.edu Wed Nov 30 18:19:51 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 30 Nov 2011 19:19:51 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <193BA8AA-22C3-4682-954B-B0A25A762647@exonetric.com> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com> <193BA8AA-22C3-4682-954B-B0A25A762647@exonetric.com> Message-ID: I agree with pretty much everything Bill, Doug, and Nathan just said. Just remember "640K ought to be enough for anybody." ;-) It's usually unwise to make statements about "never needing more than" where technology is concerned. IPv6 is still in its "let's get people to use this" phase; I don't think any of us have a clue what kind of new innovation may or may not take place in a world where address space isn't a concern. I would say absolutely reserve 64-bit's per host network in your schema. Even though we talk about broadcast domains, IPv6 shifts the conversation to multicast (and can possibly do away with the need for L2 broadcasts at some point); eventually we might be able to scale these domains to much, much larger levels that previously imagined. 2^64 large? perhaps not, but several thousands or tens of thousands, probably. If we do see this kind of evolution; being able to easily bump your networks up to 64-bit will save you a lot of pain; in the meantime, if you don't need anything that a 64-bit prefix provides (e.g. SLAAC), then by all means, just use what you need. There is a lot of talk about "buggy" systems that are unable to handle prefixes longer than 64; but I've yet to encounter one. I imagine if I did it would be treated as a bug and fixed. So to the question of supporting different prefix lengths: Yes. You should support any valid IPv6 prefix length; it takes a few extra lines of code in the beginning; but will save you a lot of re-coding in the end. I think using DHCPv6 PD, and handing out 64-bit allocations for residential users, and even running SLAAC would work quite nicely. We have moved to a model where customers like having their own domain of control while keeping things simple, and this does that. At the same time; if an ISP wants to put all their customers in an area on a shared prefix, I'm not going to complain about that either. I'd rather have functional native IPv6 at my house than no IPv6 at this point (just let me have as many addresses as I need, please). The fear is that this will push consumers to continue the use of NAT instead of something more friendly like NPT; but if that's the way it is to be then so be it. Plenty of time for the different delivery models to compete and battle it out. I will say that people have gotten used to controlling their own security domain, and it might not be something they're OK with giving up, especially as the Home gets smarter (refrigerator, microwave, entertainment system, healing, lighting, etc. all with addresses). One thing I probably don't need to point out but will anyway, is that IPv6 as it is today is what we have to work with. It took 10 years to get mature OS support established, and likely another 10 to phase out the systems that don't support it. There are plenty of good debates to have on the number of bits for this and the number of nibblets for that; but you're not going to change the IPv6 implementation in any meaningful way at this point; so the debates over the fundamentals of the protocol aren't productive. We have a reasonable foundation to work with that should provide us with flexibility to grow over time, we just need to start implementing it (and developing the software systems to make it all easy). The tweaks will come over time; and vendors will be more inclined to care about them if it's actually being used. On a more productive note; now that we have the workings of IPv6 NAT, has anyone had a chance to play with it yet? I'm anxious to play with the NPT stuff, myself. I wonder how broken it is. ;-) On Wed, Nov 30, 2011 at 6:33 PM, Mark Blackman wrote: > > On 30 Nov 2011, at 23:02, Bill Stewart wrote: > >> On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman wrote: >>> ... and I'm not sure why SLAAC wanted more than 48 bits. >> >> One reason IPv6 addresses are 128 bits long instead of 40, 48, 64 or >> 80 is because converting from IPv4 to IPv6 is really painful and we >> don't want to ever have to do it again in the future. > > Sure, 128 bits I can see the point of. Rigid insistence on /64 subnets > when no broadcast domain will ever have 2^64 devices on it seems like > a less obvious choice. > > - Mark > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mysidia at gmail.com Wed Nov 30 18:55:56 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 30 Nov 2011 18:55:56 -0600 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> Message-ID: On Wed, Nov 30, 2011 at 2:13 PM, Owen DeLong wrote: > On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote: > I do believe that there is no benefit to longer prefixes than /64. > Nobody has provided any convincing evidence to the contrary. Yes they have, thoroughly; mitigation of this one particular issue, ND table overflow is a benefit. You simply don't have to worry about this issue in the most important place it arises if you implement long prefixes for all P-t-P links from the start. I do believe there is no benefit to prefixes shorter than /126 for P-t-P links. Nobody has provided convincing evidence to the contrary. > There are better ways to mitigate ND than longer prefixes. Please explain. What are the better ways that you would propose of mitigating ND table overflows? If you can show a rational alternative, then it would be persuasive as a better option. Keeping in mind we have already explained why stateful firewalls and ACLs are not good ways to mitigate ND overflow, they are very poor ways, because they are expensive, both up front, and continuously in the form of added maintenance work, and add a great amount of undesirable complexity. Neither of those methods pass as "better than using long prefixes". Until the "better ways" have been explained, use of long prefixes remains the best option. -- -JH From mark at viviotech.net Wed Nov 30 19:42:10 2011 From: mark at viviotech.net (Mark Keymer) Date: Wed, 30 Nov 2011 17:42:10 -0800 Subject: In need of a Microsoft Postmaster Message-ID: <4ED6DB72.406@viviotech.net> I am in great hopes that a Microsoft Postmaster could get in contact with me. This is dealing with a delisting of a banned IP "blocked using Blocklist 3, mail from IP banned" My client is e-mailing a vendor of theirs who's mail goes to "mail.messaging.microsoft.com" We have submitted a request to delist it but have not heard back from anyone for about 2 weeks now. Our client is up in arms and all that. There has been no know reasons for why the ban would have taken place. It is possible this is an old ban from before we had the IP space which we got 1-2 years ago. :( Sincerely, Mark Keymer CFO/COO Vivio Technologies From rps at maine.edu Wed Nov 30 19:53:28 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 30 Nov 2011 20:53:28 -0500 Subject: HP IPv6 RA Guard In-Reply-To: <477E7D8C-5C45-4010-8C86-B9E713AFC97B@indiana.edu> References: <477E7D8C-5C45-4010-8C86-B9E713AFC97B@indiana.edu> Message-ID: This is great news. I wonder if this is evidence that they plan to continue to develop the Procurve line and eventually abandon the 3Com line. Uncertainty of which line would win out has kept me (and others I'm sure) from wanting to invest in anything HP. On Wed, Nov 30, 2011 at 8:40 PM, Jason Mueller wrote: > All, > > I received HP code today that implements RA guard (K.15.07.0002). This is for the 5400, 8200, 3500 series switches. The feature blocks both RAs (ICMP type 134) and IPv6 redirects (ICMP type 137). > > Here is the CLI command syntax: > [no] ipv6 ra-guard ports [log] > > This should be included in their next general release of K.15 series code. > > No word on my request for IPv6 DHCP snooping. I generally get an HP drafted version of special feature requests, when they accept them for development. I don't have any record of that, so I sent a gentle reminder to HP tonight. > > -Jason > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mike at mikejones.in Wed Nov 30 20:15:49 2011 From: mike at mikejones.in (Mike Jones) Date: Thu, 1 Dec 2011 02:15:49 +0000 Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?) Message-ID: On 1 December 2011 00:55, Jimmy Hess wrote: > Please explain. ? ?What are the better ways that you would propose > of mitigating ND table overflows? > If you can show a rational alternative, then it would be persuasive as > a better option. > Link-Local? For "true" P-t-P links I guess you don't need any addresses on the interfaces (I don't on my 6in4 tunnels), but I assume most people are referring to ethernet type cross connects, so Link-Local addresses. As long as each device has at least 1 address assigned somewhere (loopback?) that it can use for management/packet generation purposes you don't need an address on every link like you used to do with IPv4. Now that there are plenty of addresses you don't need as many :) I suspect there are probably some practical issues with link-local on some kit and some network configurations due to lack of people doing it this way, but in theory there shouldn't be any reason that you couldn't use link-local for all your links then just have a /128 assigned to each routers loopback for management/packet generation purposes. This could remove overheads of worrying about address assignment for those links, you just need a single /128 per router. Depending on the network it might be better to statically set link locals rather than using automatic ones (fe80::1 and fe80::2 for 'upstream' and 'downstream' or whatever rules you currently use for deciding which end is 1 and which is 2) You could also do something similar for datacentres assigning blocks to customer servers, instead of configuring a /64 for each customer, or a /48 then giving customers blocks inside that to use, just configure a single /64 and give each customer a single address from that block with unassigned ones filtered, then route a /64 to them for any "extra addresses" they might want. Chances are if they need more than a couple of addresses they probably want them routed to them anyway rather than using ND for them all. The issue of dynamic assignments to end customers in a non-datacentre setting is a little more difficult, but I wonder how badly CPEs would break if you tried using DHCPv6 to give them back their link-local addresses, then DHCPv6-PD delegating by routing to their link local address, probably a lot worse than if you just used a /112 of global space. I don't think this area has too many issues though because DHCP ensures that the actual addresses on the links are all known, so this just needs to be used for filtering unknown addresses. Then there's just the question of what to do about the edge networks where SLAAC might be used and where you don't have such strict control over address assignment, i'll pass on that one for now. Link locals aren't as useful nearer to the edges, but for the backbones and datacentre networks they should be able to solve most of the biggest problems with ND attacks. The edge networks where just using link locals isn't really an option you can probably put a stateful firewall in quite easily, as these will be the edge default gateways that clients are sending their traffic directly to rather than needing to be done in the core. Although there really should be an option for users to open the firewall for inbound connections. Am I a complete idiot missing some obvious major issues with link locals, or am i just the only one not thinking IPv4-think? Opinions? :) - Mike From rps at maine.edu Wed Nov 30 20:22:48 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 30 Nov 2011 21:22:48 -0500 Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?) In-Reply-To: References: Message-ID: I for one get really irritated when my traceroutes and pings are broken and I need to troubleshoot things. ;-) But I guess something has to give. On Wed, Nov 30, 2011 at 9:15 PM, Mike Jones wrote: > On 1 December 2011 00:55, Jimmy Hess wrote: >> Please explain. ? ?What are the better ways that you would propose >> of mitigating ND table overflows? >> If you can show a rational alternative, then it would be persuasive as >> a better option. >> > > Link-Local? > > For "true" P-t-P links I guess you don't need any addresses on the > interfaces (I don't on my 6in4 tunnels), but I assume most people are > referring to ethernet type cross connects, so Link-Local addresses. > > As long as each device has at least 1 address assigned somewhere > (loopback?) that it can use for management/packet generation purposes > you don't need an address on every link like you used to do with IPv4. > Now that there are plenty of addresses you don't need as many :) > > I suspect there are probably some practical issues with link-local on > some kit and some network configurations due to lack of people doing > it this way, but in theory there shouldn't be any reason that you > couldn't use link-local for all your links then just have a /128 > assigned to each routers loopback for management/packet generation > purposes. This could remove overheads of worrying about address > assignment for those links, you just need a single /128 per router. > Depending on the network it might be better to statically set link > locals rather than using automatic ones (fe80::1 and fe80::2 for > 'upstream' and 'downstream' or whatever rules you currently use for > deciding which end is 1 and which is 2) > > You could also do something similar for datacentres assigning blocks > to customer servers, instead of configuring a /64 for each customer, > or a /48 then giving customers blocks inside that to use, just > configure a single /64 and give each customer a single address from > that block with unassigned ones filtered, then route a /64 to them for > any "extra addresses" they might want. Chances are if they need more > than a couple of addresses they probably want them routed to them > anyway rather than using ND for them all. > > The issue of dynamic assignments to end customers in a non-datacentre > setting is a little more difficult, but I wonder how badly CPEs would > break if you tried using DHCPv6 to give them back their link-local > addresses, then DHCPv6-PD delegating by routing to their link local > address, probably a lot worse than if you just used a /112 of global > space. I don't think this area has too many issues though because DHCP > ensures that the actual addresses on the links are all known, so this > just needs to be used for filtering unknown addresses. > > Then there's just the question of what to do about the edge networks > where SLAAC might be used and where you don't have such strict control > over address assignment, i'll pass on that one for now. > > Link locals aren't as useful nearer to the edges, but for the > backbones and datacentre networks they should be able to solve most of > the biggest problems with ND attacks. The edge networks where just > using link locals isn't really an option you can probably put a > stateful firewall in quite easily, as these will be the edge default > gateways that clients are sending their traffic directly to rather > than needing to be done in the core. Although there really should be > an option for users to open the firewall for inbound connections. > > Am I a complete idiot missing some obvious major issues with link > locals, or am i just the only one not thinking IPv4-think? Opinions? > :) > > - Mike > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From mike at mikejones.in Wed Nov 30 20:40:16 2011 From: mike at mikejones.in (Mike Jones) Date: Thu, 1 Dec 2011 02:40:16 +0000 Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?) In-Reply-To: References: Message-ID: On 1 December 2011 02:22, Ray Soucy wrote: > I for one get really irritated when my traceroutes and pings are > broken and I need to troubleshoot things. ;-) ?But I guess something > has to give. > My home connection gets IPv6 connectivity via a tunnelbroker tunnel, i didn't use the "tunnel interface" addresses in the instructions but configured it without addresses, traceroutes (in all directions) show up with the routers single assigned global address. Routers would still have a single global address assigned to loopback (or anywhere) for management/packet generation purposes so traceroutes should work fine, although rather than getting a per-interface address you'll get a per-router address. What addresses do you currently get in the real world? some routers give a loopback address, some give the ingress interface, some give the egress interface, all you can safely assume from the address is the router it hit. - Mike From rps at maine.edu Wed Nov 30 20:52:30 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 30 Nov 2011 21:52:30 -0500 Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?) In-Reply-To: References: Message-ID: I was half joking, but you know, you might be on to something there. I'll have to try it out and see what the implications are. I know that for our gear, it uses the interface address so we can map rDNS to something useful. The other thing to look into would be neighbor configuration for routing protocols, using a routable address does tend to make things a bit cleaner, but maybe those are worth giving up. The other option, of course, is to just use longer prefixes (e.g. 126), but just using Link-Local would save some effort in allocation of IPv6 networks for links between routers. I'd love to see someone like Randy Bush weigh in on it (poke poke, I know you're reading). The use of global IPv6 for link networks is something I never really questioned. On Wed, Nov 30, 2011 at 9:40 PM, Mike Jones wrote: > On 1 December 2011 02:22, Ray Soucy wrote: >> I for one get really irritated when my traceroutes and pings are >> broken and I need to troubleshoot things. ;-) ?But I guess something >> has to give. >> > > My home connection gets IPv6 connectivity via a tunnelbroker tunnel, i > didn't use the "tunnel interface" addresses in the instructions but > configured it without addresses, traceroutes (in all directions) show > up with the routers single assigned global address. > > Routers would still have a single global address assigned to loopback > (or anywhere) for management/packet generation purposes so traceroutes > should work fine, although rather than getting a per-interface address > you'll get a per-router address. What addresses do you currently get > in the real world? some routers give a loopback address, some give the > ingress interface, some give the egress interface, all you can safely > assume from the address is the router it hit. > > - Mike -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Wed Nov 30 20:55:54 2011 From: rps at maine.edu (Ray Soucy) Date: Wed, 30 Nov 2011 21:55:54 -0500 Subject: HP IPv6 RA Guard In-Reply-To: References: <477E7D8C-5C45-4010-8C86-B9E713AFC97B@indiana.edu> Message-ID: Comment can be appreciated but please remove the I2 WG address from responses unless it's something you want to blast to that community, I don't want them upset at me for filling their inbox with a 40 email NANOG thread (you know how this list can get). ;-) On Wed, Nov 30, 2011 at 9:52 PM, Brent Jones wrote: > > > On Wed, Nov 30, 2011 at 5:53 PM, Ray Soucy wrote: >> >> This is great news. >> >> I wonder if this is evidence that they plan to continue to develop the >> Procurve line and eventually abandon the 3Com line. ?Uncertainty of >> which line would win out has kept me (and others I'm sure) from >> wanting to invest in anything HP. >> > > > Some of us have chosen not to invest in anything HP for a long time > > > > -Brent Jones -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From Valdis.Kletnieks at vt.edu Wed Nov 30 21:10:19 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 30 Nov 2011 22:10:19 -0500 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: Your message of "Wed, 30 Nov 2011 19:19:51 EST." References: <8BE79149-2378-4B8D-AB4D-E2ECB6CF3E0E@cisco.com> <1A82EDD0-EB67-45FD-B601-1456ECC0BD5D@delong.com> <4ED52053.5040102@bogus.com> <36213AC7-884E-4673-BBF0-565958BAAB45@delong.com> <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com> <193BA8AA-22C3-4682-954B-B0A25A762647@exonetric.com> Message-ID: <4146.1322709019@turing-police.cc.vt.edu> On Wed, 30 Nov 2011 19:19:51 EST, Ray Soucy said: > There is a lot of talk about "buggy" systems that are unable to handle > prefixes longer than 64; but I've yet to encounter one. I imagine if > I did it would be treated as a bug and fixed. What year did Cisco first release IOS? What year did Cisco finally stamp the last vestiges of class A/B/C out of IOS? That's how many years it will take to get rid of the last buggy IPv6 that won't do a 64+ prefix. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bicknell at ufp.org Wed Nov 30 21:27:17 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 30 Nov 2011 19:27:17 -0800 Subject: IPv6 prefixes longer then /64: are they possible in DOCSIS networks? In-Reply-To: References: <77B5EFBB-FBD3-496B-8C7F-42BA1370075F@delong.com> <52B9067E-E0EA-41F8-A28E-8B5FE7321DD4@exonetric.com> <193BA8AA-22C3-4682-954B-B0A25A762647@exonetric.com> Message-ID: <20111201032717.GA35356@ussenterprise.ufp.org> In a message written on Wed, Nov 30, 2011 at 07:19:51PM -0500, Ray Soucy wrote: > There is a lot of talk about "buggy" systems that are unable to handle > prefixes longer than 64; but I've yet to encounter one. I imagine if This has been one of the first thing I tested with new router gear for, well, a decade or more now of IPv6 testing. I too have never encountered such a box, even in the early days of IPv6. I think if any such boxes were made they were likely prototypes and never sold in quantity. There was a different, but related problem early on. Platforms with 32-bit TCAM that had to be retrofitted for IPv6 had to do multiple lookups. Two lookups got you 64 bits, and since 64 bits was the "longest subnet" they did dumb things past that bit boundary. This could result in less than line rate performance of IPv6 frames. I'm honestly having trouble remembering which platforms had this issue, perhaps someone remembers better than I do. However, I do think my lack of memory is in part because I haven't encountered one in a network anytime recently... In short, a total non-issue in terms of IPv6 deployment today. -- 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 Gabriel.McCall at thyssenkrupp.com Wed Nov 30 22:33:59 2011 From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel) Date: Wed, 30 Nov 2011 23:33:59 -0500 Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?) In-Reply-To: References: Message-ID: Well, traceroutes and other ICMP functions would break. It is occasionally useful to be able to address a specific router interface from someplace other than its connected peer. -Gabriel -----Original Message----- From: Mike Jones [mailto:mike at mikejones.in] Sent: Wednesday, November 30, 2011 9:16 PM To: nanog at nanog.org Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?) ... Am I a complete idiot missing some obvious major issues with link locals, or am i just the only one not thinking IPv4-think? Opinions? :) - Mike From mysidia at gmail.com Wed Nov 30 23:32:37 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 30 Nov 2011 23:32:37 -0600 Subject: Link local for P-t-P links? (Was: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?) In-Reply-To: References: Message-ID: On Wed, Nov 30, 2011 at 10:33 PM, McCall, Gabriel wrote: > Well, traceroutes and other ICMP functions would break. It is occasionally useful to be able to address a specific router interface from someplace other than its connected peer. Unless your router always sources TTL exceeded from a loopback interface, breaking traceroute is a problem... breaking ICMP probing is even worse. I realize IPv6 is the utopian protocol we've all been waiting for, where routers failing, latency, packet loss, and hardware glitches are all going to be very distant memories, so the familiar troubleshooting tools can all go away and the minor performance/ status questions can be diagnosed using a SNMP status check, But in the unlikely event something did ever go slightly wrong, having link locals on routers would be a killer for the user. This definitely isn't better than using long prefixes on the P-t-P links. Regards, -- -JH From righa.shake at gmail.com Sat Nov 19 10:11:55 2011 From: righa.shake at gmail.com (Righa Shake) Date: Sat, 19 Nov 2011 16:11:55 -0000 Subject: Flapping POS Interface on Frame-relay between a Juniper and Cisco Message-ID: Hi, Am having a problem that is buffling. I recently changed a POS link encapsulation from PPP to Frame-relay. Since that time the POS interface keeps resetting from time to time. On my BGP session am receiving cease notifications from my upstream provider. The setup is such that we have a cisco on one end and a Juniper on the other. interface POS0/0/0 mtu 4474 no ip address no ip unreachables encapsulation frame-relay logging event link-status crc 32 pos scramble-atm frame-relay lmi-type ansi end ROUTERshow run int pos0/0/0.101 Building configuration... ! interface POS0/0/0.101 point-to-point ip address X.X.X.X 255.255.255.252 frame-relay interface-dlci 101 end ROUTER#show int pos0/0/0 POS0/0/0 is up, line protocol is up Hardware is SPA-2XOC12-POS MTU 4474 bytes, BW 622000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 6/255, rxload 38/255 Encapsulation FRAME-RELAY, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled LMI enq sent 81981, LMI stat recvd 77480, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE segmentation inactive FR SVC disabled, LAPF state down Broadcast queue 0/256, broadcasts sent/dropped 26/0, interface broadcasts 0 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 1w2d Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 94336000 bits/sec, 13151 packets/sec 5 minute output rate 16470000 bits/sec, 7049 packets/sec 12211574207 packets input, 10967607038364 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 6970870 runts, 2179 giants, 0 throttles 0 parity 892493293 input errors, 882184781 CRC, 0 frame, 0 overrun, 0 ignored, 3335463 abort 6379191154 packets output, 1614018181446 bytes, 0 underruns 0 output errors, 0 applique, 4 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions Any assistance on this will be greatly appreciated. Regards, Righa Shake From mtinka at globaltransit.net Thu Nov 24 11:45:13 2011 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 25 Nov 2011 01:45:13 +0800 Subject: APRICOT-2012: Call for Papers Message-ID: <201111250145.16961.mtinka@globaltransit.net> Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 21 February - 2 March 2012, New Delhi, India http://www.apricot2012.net CALL FOR PAPERS =============== The APRICOT 2012 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2012. We are looking for people and proposals that would: - Offer a technical tutorial on an appropriate topic; and/or - Participate in the technical conference sessions as a speaker; and/or - Convene and chair a Birds of a Feather (BOF) session. Please submit proposals on-line at: http://submission.apnic.net/ CONFERENCE MILESTONES --------------------- Call for Papers Opens: 22 November 2011 First Draft Program Published: 19 December 2011 Final Deadline for Submissions: 10 February 2012 Final Program Published: 17 February 2012 Final Slides Received: 25 February 2012 PROGRAM MATERIAL ---------------- The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. The APNIC Policy SIG and Annual Members Meeting will be held during the APRICOT conference. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv4 address runout / IPv6 deployment and transition technologies - Backbone operations - ISP and Carrier services - Network security issues (NSP-SEC, DDoS Anti-Spam, Anti-Malware) - Peering / IXPs - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including broadband deployment, Cable/DSL, wireless, WiMax, metro ethernet, fiber network, MPLS - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) CfP SUBMISSION -------------- All draft and complete slides must be submitted in PDF format only. Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. Final slides are to be provided by the specified deadline for publication on the APRICOT website. While the majority of speaking slots will be filled by the first submission deadline, a limited number of slots may be available up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at: http://submission.apnic.net/ Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka & Jonny Martin Co-Chairs, APRICOT Programme Committee program at apricot.net -------------- 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: