Re: NANOG70 tee shirt mystery
https://en.m.wikipedia.org/wiki/Ten_(Pearl_Jam_album) Pearl Jam are from Seattle... David Barak Sent from mobile device, please excuse autocorrection artifacts > On Jun 4, 2017, at 4:55 PM, Matthew Petach wrote: > > So, I've been staring at the NANOG70 tee shirt for > a bit now: > > https://flic.kr/p/VejX5y > > and I have to admit, I'm a bit stymied. > > Usually, the tee-shirts are somewhat referential > to the location or to a particular event; but this > one is leaving me scratching my head. > > Is it perhaps a shot of the network engineering > "Ooops (I broke the network again)" concert > tour? > > Or is there some other cultural reference at > play that I'm not aware of? > > Enquiring minds want to know!(tm). :) > > Matt
Re: Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization
On Dec 28, 2016, at 5:34 PM, Randy Bush wrote: >> An alternative multi-vendor approach is to use 1 vendor per stack layer, >> but alternate layer to layer. That is; Vendor A edge router, Vendor B >> firewall, Vendor A/C switches, Vendor D anti-SPAM software, etc. This >> doesn't address the bug impact issue as well as it alleviates the vendor >> "ownership" issue though... > > i think this is where i say that i hope my competitors do this. it > is a recipe for a complex set of delicate dependencies and great fun > debugging. > One of the more spectacular failures I've seen was a bug in a network core router that caused bad into to be carried by all of that same vendor's routers across the core to the edges (made by a different vendor) which promptly barfed and locked up. So I'd be cautious about saying "vendor X for one layer, vendor Y for adjacent layer" as a multi-vendor strategy. David Barak Sent from mobile device, please excuse autocorrection artifacts
Re: OSPF vs ISIS - Which do you prefer & why?
> On Nov 9, 2016, at 6:04 PM, Randy Bush wrote: > > vi users prefer ospf > emacs users prefer is-is > So that leaves EIGRP for the nano users? David Barak Sent from mobile device, please excuse autocorrection artifacts
Re: NFV Solution Evaluation Methodology
Simpler > complex *sometimes*. It turns out that sometimes the complexity is worth it (eg https://youtu.be/-iiXsbrEv3U ). Perhaps "as simple as possible, by no simpler" would be reasonable? David Barak Sent from mobile device, please excuse autocorrection artifacts > On Aug 2, 2016, at 7:08 PM, Ca By wrote > CB > > Ps. Also, simpler > complex. Lots of $ in this statement.
Re: cross connects and their pound of flesh
Gotta watch out for specifying T1 when you want Ethernet- they could just give you 4 wires on pins 1,2,4,5 :) I see the problem as misunderstanding what "physical" actually means: 4-wire twisted pair is different from 8-wire, is different from coax, is different from SMF etc. what gets run over it is nobody's business but the person controlling the end points. David Barak Sent from mobile device, please excuse autocorrection artifacts > On Jun 19, 2016, at 8:30 AM, Patrick W. Gilmore wrote: > > Actually, back in the T1/T3 days, colos frequently asked what you ran on the > cable and then charged you based on the capacity of the circuit - even when > it was the same exact cable. Of course, none of us would ever ask for T1 > xconn then run ethernet over it. > > Colo providers are absolutely worried about drops in xconn revenue. Look at > some large colo providers who are public and split out their numbers. You’ll > see that the percentage of their profit from xconns is usually more than > double the percentage of their revenue from xconns. Put another way, if xconn > revenue drops by 10%, their profit drops by over 20%. How many public > companies can shrug off a 20% drop in EPS? I submit: Not very many. > > This is not surprising. When you build your business on the ignorance of your > customers, you are in a world of hurt once your customers learn even a little > bit more. > > -- > TTFN, > patrick > >> On Jun 19, 2016, at 10:13 AM, jim deleskie wrote: >> >> I don't buy this. They sold you one cable before, they sell you cable now. >> Little difference then we moved customers from a T1 to T3 back in the >> 90's. If Colo's can't understand more then 20+ yrs of evolution its hardly >> right to blame it on the market. >> >> >> -jim >> Mimir Networks >> www.mimirnetworks.com >> >> >>> On Sun, Jun 19, 2016 at 11:07 AM, Mike Hammett wrote: >>> >>> Before 100G, you'd need ten cross connects to move 100G. Now you'd need >>> only one. That's a big drop in revenue. >>> >>> >>> >>> >>> - >>> Mike Hammett >>> Intelligent Computing Solutions >>> http://www.ics-il.com >>> >>> >>> >>> Midwest Internet Exchange >>> http://www.midwest-ix.com >>> >>> >>> - Original Message - >>> >>> From: "Brandon Butterworth" >>> To: br...@pobox.com, d...@temk.in >>> Cc: nanog@nanog.org >>> Sent: Sunday, June 19, 2016 8:55:57 AM >>> Subject: Re: cross connects and their pound of flesh >>> >>> Dave Temkin wrote: >>>> And as colo operators get freaked out over margin compression on the >>>> impending 10->100G conversion (which is happening exponentially faster >>> than >>>> 100->1G & 1G->10G) they'll need to move those levers of spend around >>>> regardless. >>> >>> If they've based their model on extracting profit proportional >>> to technology speed then they've misunderstood Moore's law >>> >>> brandon >
Re: phone fun, was GeoIP database issues and the real world consequences
> On Apr 15, 2016, at 3:09 PM, Mark Andrews wrote: > > Australia is about the area as the US and has always had caller > pays and seperate area codes for mobiles. Australia has fewer people than Texas, and is more than an order of magnitude smaller than the US by population. Effects of scale apply here in terms of path dependence for solutions. David Barak Sent from mobile device, please excuse autocorrection artifacts
Re: /27 the new /24
On Thu, 10/8/15, Mark Andrews wrote: > This is today's reality and ISP's are not meeting > today's needs. > It's not just about > having enough IPv4 addresses. It's about > providing the infrastructure to allow your > customers to connect to > everyone. I think you should s/everyone/everyone they care about/ That roughly explains why there is no particular consumer outcry (which isn't about speed/bandwidth or mobile coverage, anyway). David Barak
Re: IPv6 allocation plan, security, and 6-to-4 conversion
> On Jan 30, 2015, at 9:49 PM, Owen DeLong wrote: > > >> On Jan 30, 2015, at 18:07 , William Herrin wrote: >> How about this: when Verizon starts decommissioning its IPv4 >> infrastructure on the basis that IPv6 is widespread enough to no >> longer require the expense of dual-stack, IPv6 will have achieved >> ubiquity. > > Um, no. The judgment of one traditional telephone company is hardly where I > would look to contemplate the future of the internet. Then AT&T, Comcast, Cox, Level3, etc, could be reasonable examples? I think the general point is worth considering - when v4 gear is regularly being pulled out of commission by large carriers because "who needs it?" and replaced with v6 only gear, we will have achieved true ubiquity. I think you'll see v4 for quite a while. Heck, I still run across SNA, Token Ring, and other really old stuff occasionally... David Barak Sent from a mobile device, please forgive autocorrection.
Re: large scale ipsec
Hi Jan, Please define "large scale". Is that by number of endpoints, throughput, or some other metric? How big is big? David Barak
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
From: Owen DeLong >Dual stack is a (very) temporary solution while waiting for some others to >catch >up and deploy IPv6. Contemplating dual-stack as a permanent or long-term >solution ignores the extent to which IPv4 is utterly unsustainable at this >point. >Owen Owen, when do you think IPv4 is going to go away to the point that it will no longer be necessary to carry it? We may be using "long-term" to mean different things, so I'm curious to see what you mean by that. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Intermapper vs NetBrain vs some other for NMS
I like intermapper for monitoring: it's been very stable, and exports traps and notifications well. I also like netbrain for troubleshooting and mapmaking, because its visualization is engineer and manager-friendly. David Barak Sent from a mobile device, please forgive autocorrection and top posting. On Mar 8, 2013, at 8:38 AM, Ben Bartsch wrote: > Hi all: > > I'm looking for information anyone might have comparing Intermapper to > NetBrain for NMS. Stuff like devices up/down, interface utilization, > building maps for documentation, etc. IMO, Intermapper works great, when > it works. Tech support has been slow and often cannot fix the problems, > not to mention they release updates about once every other week. > > Anyone familiar with any similar products? We are presently evaluating > NetBrain and it seems really nice. We really like the Visio-like aspect of > it. > > Thanks! > > -Ben
Re: Network security on multiple levels (was Re: NYT covers China cyberthreat)
--- On Wed, 2/20/13, Jay Ashworth wrote:
> - Original Message -
> > From: "Owen DeLong"
> > The DACS question wasn't about DACS owned by the people
> using the
> > circuit, it was about DACS inside the circuit provider.
> When you buy a
> > DS1 that goes through more than one CO in between two
> points, you're
> > virtually guaranteed that it goes through one or more
> of {DS-3 Mux,
> > Fiber Mux, DACS, etc.}. All of these are under the
> control of the
> > circuit provider and not you.
>
> Correct, and they expand the attack surface in ways that
> even many
> network engineers may not consider unless prompted.
This is precisely the value of encryption on point to point links, preferably
at the link layer rather than at the IP layer. When coupled with decent
end-to-end application-layer encryption on top of that, the value proposition
for sniffing traffic from the network drops a whole lot.
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
Re: NYT covers China cyberthreat
Don't be lulled into complacency by a private network: all it takes is one thumb-drive or rogue AP and you have a back door. Private networks reduce but do not eliminate attackable surface. David Barak Sent from a mobile device, please forgive autocorrection. On Feb 20, 2013, at 2:04 AM, Warren Bailey wrote: > An Internet kill switch is a nightmare. We can't even figure out how to run a > relay radio system for national emergencies.. Now we are going to assume the > people who were owned can somehow shut off communications? > > We as Americans have plenty of things we have done halfass.. I hope an > Internet kill switch doesn't end up being one of them. Build your own private > networks, you can't get rooted if someone can't knock. Simple as that. > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > Original message > From: Zaid Ali Kahn > Date: 02/19/2013 10:44 PM (GMT-08:00) > To: Kyle Creyts > Cc: nanog@nanog.org > Subject: Re: NYT covers China cyberthreat > > > We have done our part to China as well along with other countries in state > sponsored "hacking". This is more of news amusement rather than news worthy. > Question here should be how much of this is another effort to get a "kill > switch" type bill back. > > Zaid > > On Feb 19, 2013, at 10:10 PM, Kyle Creyts wrote: > >> quite a bit of coverage lately from the media. >> >> http://online.wsj.com/article/SB10001424127887323764804578313101135258708.html >> http://www.bbc.co.uk/news/world-asia-pacific-21505803 >> http://www.npr.org/2013/02/19/172373133/report-links-cyber-attacks-on-u-s-to-chinas-military >> http://www.businessweek.com/articles/2013-02-14/a-chinese-hackers-identity-unmasked >> >> On Mon, Feb 18, 2013 at 7:23 PM, Jay Ashworth wrote: >>> >>> http://www.nytimes.com/2013/02/19/technology/chinas-army-is-seen-as-tied-to-hacking-against-us.html?pagewanted=all >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> >> >> >> -- >> Kyle Creyts >> >> Information Assurance Professional >> BSidesDetroit Organizer >> > > >
Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....
> Looking at http://mydeviceinfo.comcast.net you get a choice of wireless > or IPv6 in Arris. > I Wish they would ask which you want before install: I already have better wireless, and the Arris ones don't let you disable theirs :/ Thank you for the pointer - perhaps a swap is in order. David Barak Sent from a mobile device, please forgive autocorrection.
Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....
On Jan 30, 2013, at 7:52 PM, Mark Andrews wrote: > Firstly fix your mail client. What's this "'" garbage in text/plain? > That's yahoo web mail on an iPhone, sorry. > Deployment Update > > Published on Tuesday, October 23, 2012 > > IPv6 has been launched on all Arris DOCSIS 3.0 C4 CMTSes, covering > over 50% our network. We are targeting completion of the rest of > the network by mid-2013. Our progress has led to nearly 2.5% of our > Xfinity Internet customers actively using native dual stack. > Additionally, IPv6 traffic has increased 375% since World IPv6 Day > in June 2011. Following World IPv6 Launch in June 2012 Comcast > also observed that approximately 6% of the 2012 Olympics served > over YouTube to Comcast customers was over IPv6. > > http://www.comcast6.net > The update you sent is lovely, except I can tell you that the one (also an Arris, running DOCSIS 3.0) which was installed in late October in my house in Washington simply does not run v6 with the pre-installed load. Now, is there some firmware upgrade which could fix this? Maybe, but it sure would be nice if the folks who answer the phone in support could direct me to someone who has heard of this technology. So no, as I said before, Comcast has *not* removed the v6 barrier here. I'd like it to "just work", please. David Barak Sent from a mobile device, please forgive autocorrection.
Re: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....
Comcast removed the "no IPv6" excuse? That removal somehow skipped my house in Washington DC where they installed (last October) a router which does not even support it (an Arrus voice gateway- the one where you can't turn of the crummy 2.4g wireless radio) and none of the folks I've spoken to on the phone can tell me when or if it will be coming. I look forward to Comcast giving me native v6 at home. David Barak
Re: Suggestions for the future on your web site: (was cookies, and
--- On Thu, 1/24/13, Andrew Sullivan wrote: > Lately, AFAICT, most CAPTCHAs have > been so > successfully attacked by wgetters that they're quite easy > for machines > to break, but difficult for humans to use. For > example, I can testify > that I now fail about 25% of the reCAPTCHA challenges I > perform, > because the images are so distorted I just can't make them > out (it's > much worse on my mobile, given the combination if its small > screen and > my middle-aged eyes). > > So it's now more like airport security: a big hassle for > the > legitimate users but not really much of a barrier for a > real > attacker. A poor trade-off. +1000 I routinely fail CAPTCHAs, and am certainly less accurate than a decent machine at the OCR required. Those of us whose eyes don't correct to 20/20 would greatly appreciate some other form of "slow down the spammers" than this. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Blocking MX query
On Sep 4, 2012, at 11:45 PM, Suresh Ramasubramanian wrote: > > So - now with ipv6 you're going to see "hi, my toto highly > computerized toilet is trying to make outbound port 25 connections to > gmail" > > http://www.telecoms.com/48734/vodafone-and-ibm-team-up-on-connected-home-appliances/ > > -- > Suresh Ramasubramanian (ops.li...@gmail.com) > Gives a new meaning to a sh*** connection. Or perhaps to flushing a mail queue... David Sent from a mobile device, please forgive autocorrection.
Re: Color vision for network techs
From: Betsy Schwartz > I ended up with green diamonds, red X's, purple squares, and yellow >exclamation points (and on this particular > application a mouse-over would also tell you the name of the color > gif) Looked better for *everyone*. Is that the "Lucky Charms" style of icon generation? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: job screening question
(please excuse the top post) If you want a great analysis of how this happened before, check out Clanchy's book _From memory to written record_ about the implications of the spread of literacy as a technology in England in the 1300s. David Barak
Re: HE.net BGP origin attribute rewriting
From: Nick Hilliard >If you don't rewrite your transit providers' origin, then you are telling >them that they can directly influence your exit discrimination policy on >the basis of a purely advisory flag which has no real meaning. On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a "purely advisory flag which has no real meaning"? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is "network abuse" - it's more accurately described as "network routing policy." As has been stated here before: your network, your rules. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: HE.net BGP origin attribute rewriting
On May 31, 2012, at 8:03 AM, sth...@nethelp.no wrote: >> I disagree. Origin is tremendously useful as a multi-AS weighting >> tool, and isn't the blunt hammer that AS_PATH is. > > If you think of AS_PATH as a blunt hammer, how would you describe > localpref? > > We use AS_PATH in many cases *precisely* because we don't consider it > to be a blunt hammer... > So you're connected to providers A and B, who in turn connect to C. Additionally, B has customer D. If you set origin E toward B (leaving origin I toward A) you influence C's decision without affecting either B or D, and you ensure that C still learns both routes to you. It's a more subtle nudge than as-path. In general, I prefer routinely using attributes that are further down the algorithm so at the big guns can be saved for when they're needed or for special policy issues. David Barak Sent from a mobile device, please forgive autocorrection.
Re: HE.net BGP origin attribute rewriting
On May 31, 2012, at 7:26 AM, Nick Hilliard wrote: > There are many useful ways to build a > multi-exit discrimination policy. Using origin is not one of them, in my > opinion. > > The problem is that origin is ranked one place higher than MED. So if you > don't rewrite it, you are automatically giving your upstreams an inherent > means of strongly influencing the tie-breaking policy. If this were an > attribute which actually meant something, then maybe there would be some > point in paying attention to it, but it conveys no useful information these > days. IOW, it is completely pointless these days and you almost certainly > want to work the possibility of any upstream tweaking it. > > Nick > I disagree. Origin is tremendously useful as a multi-AS weighting tool, and isn't the blunt hammer that AS_PATH is. The place where I've gotten the most benefit is large internal networks, where there may be multiple MPLS clouds along with sites cascaded off of them - it provides a way of sending "soft" preferences down the transitive chain. Also useful is "set origin egp XX" - on a route injector, that can post-pend an ASN and limit the spread of a route while still allowing the same transitive properties. David Barak Sent from a mobile device, please forgive autocorrection.
Re: Network diagram app that shows realtime link utilizatin
Netbrain OE does this. David Barak Sent from a mobile device, please forgive autocorrection. On May 1, 2012, at 12:47 PM, Andrey Khomyakov wrote: > cacti by use of weather maps? > Alternatively, Intermapper is pretty good, but commercial. It's more of an > NMS than a diagram tool though. Everywhere I used it, I was pretty happy > with it. > > --Andrey > > > On Tue, May 1, 2012 at 12:41 PM, Hank Disuko wrote: > >> >> >> Hi folks, >> >> I wonder if anyone can recommend a network diagram tool that can show >> realtime link utilization via snmp? >> >> Mikrotik's "The Dude" app actually does exactly what I'm looking for, but >> the snmp support for non-RouterOS devices seems to be lacking, as it simply >> won't enumerate my switch interfaces in order to capture utilization. >> >> I've downloaded several trial tools (WhatsUp, NetCure, Solarwinds >> LANsurveyor etc.) but they don't serve this very basic need of mine to see >> the realtime link util in the diagram. >> >> Thanks, >> Hank Disuko >> >>
Re: Switch designed for mirroring tap ports
Hi Ameen, Wouldn't it work to have a switch aggregating your monitor sessions just disable MAC learning? Traffic from a single input interface would be replicated to all other ports on the vlan where learning is disabled. I've used this with a 3750, and I haven't seen any trouble (other than that you don't want that switch in-line with anything else). David Barak
Re: Common operational misconceptions
>From: Owen DeLong o...@delong.com >Sigh... NAT is a horrible hack that served us all too well in address >conservation. Beyond that, it is merely a source of pain. I understand why you say that - NAT did yeoman's work in address conservation. However, it also enabled (yes, really) lots of topologies and approaches which are *not* designed upon the end-to-end model. Some of these approaches have found their way into business proceses. An argument you and others have made many times boils down to "but if we never had NAT, think how much better it would be!" To this, the response "so what?" is not unreasonable - organizations which have built up processes and products around the non-end-to-end model may or may not see a benefit in changing their ways. Asserting that there is something wrong with existing, succesful business practices is not, by itself, compelling. While you and I may find this type of packet header manipulation distasteful, there's lots of organizations for which it's normal operations. The more NAT for v6 gets fought, the more folks will fight to preserve it. Time could be better spent demonstrating why NAT isn't needed in X or Y use case, and providing configuration snippets / assistance for non-NAT-based solutions to those various groups. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: MD5 considered harmful
From: harbor235 > Also, It does not matter how many attempts compromising a BGP session > occurs, it only takes one, so why not nail it down. Because downtime is a security issue too, and MD5 is more likely to contribute to downtime (either via lost password, crypto load on CPU, or other) than the problem it purports to fix. The goal of a network engineer is to move packets from A -> B. The goal of a security engineer is to keep that from happening. A business needs to weigh the cost and benefit of any given approach, and MD5 BGP auth does not come out well in the of situations. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Does anybody out there use Authentication Header (AH)?
It can be used to prevent NAT on an intermediate path, which can be useful under certain circumstances. I have seen it in the wild, both in Internet and private networking contexts. David Barak
Re: next-best-transport! down with ethernet!
>From: Jared Mauch >(I'm hoping for some good snow storms in the midwest/north east/NoVA area to put some good stresses on the network for a week or so this winter that can be measured/observed). In DC and NoVA, the network which is most taxed by snow storms is the transportation network. That's probably the one time when you really *can* overestimate the bandwidth of a station wagon full of hard drives... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Writable SNMP
From: Jeff Wheeler >Juniper does not support writing via SNMP. I am glad. Hopefully that >is the first step toward not supporting SNMP at all. If I recall correctly, wasn't the old FORE CLI implemented via localhost SNMP? I liked using them, but that's a special case... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: IP addresses are now assets
Should the HAC be expected to manage the transition to HumorV6? David
Re: What vexes VoIP users?
>From: Joe Greco >I have no idea why anyone would be paying Ma Bell $69/month for a phone >line, unless you like giving them your money or something. In my neck of the woods (Washington DC), the POTS line is the one that works during a bad power outage, and has qualitatively different failure modes than my cable service. Whether that's something one wants to purchase is a different question. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Post-Exhaustion-phase "punishment" for early adopters
>From: R. Benjamin Kessler >>From: George Herbert [mailto:george.herb...@gmail.com] >>"Let's just grab 2/8, it's not routed on the Internet..." >+1 >I was consulting for a financial services firm in the late '90s that was >acquired by a large east-coast bank; the bank's brilliant scheme >was to >renumber all new acquisitions *out* of RFC1918 space and into (at the time) >bogon space. > >If I recall, some of the arguments were "they were too big to fit into RFC1918 >space" and by having all of their divisions in non->RFC1918 space it would >make >it easier for them to acquire new companies who used RFC1918 space internally. >I wonder what they're doing now... If we make the assumption that the hosts which were numbered in the space formerly known as bogon are typical enterprise hosts, it wouldn't be surprising if they were just fine: they probably don't *want* to have end-to-end connectivity, and are perfectly happy with the proxy-everything approach. If you're going to NAT everything anyway, then the damage done by having 2/8 on both sides of the NAT isn't any worse than having 10/8 on both sides of the NAT. If it turns out that they start running across the hosts in 2/8 as customers, those can get NATted into some third block, with probably a lot less effort and confusion than trying to sort out the chunks of overlapping 10/8s. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: quietly....
From: Iljitsch van Beijnum >I understand people use DHCP for lots of stuff today. But that's mainly >because >DHCP is there, not because it's the best possible way >to get that particular >job done. I don't particularly care whether DHCP is the *best* way to get some particular job done; I care that it is a well-known, well-understood way of *getting* the job done, and lots of operational work, development, and process has gone into making DHCP do this well, reliably, and scalably. The problem with DHCPv6 is that it doesn't do nearly enough when compared to DHCPv4, and there are not in fact any good alternatives. The insistence on RA, along with a handwaving dismissal of all of those folks who have a high reliance on DHCP has done a tremendous disservice to the uptake of IPv6. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: quietly....
From: Owen DeLong David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com >If you're determined to destroy IPv6 by bringing the problems of NAT forward >with you, then, I'm fine with you remaining in your >IPv4 island. I'm willing >to >bet that most organizations will embrace an internet unencumbered by the >brokenness that is NAT and >move forward. I do not think that lack of NAT has >been a significant barrier to IPv6 adoption, nor do I think it will be. Lack of NAT may or may not continue to be a barrier to IPv6 adoption. However, it certainly *has* been a barrier to IPv6 adoption - I have had customers tell me that explicitly, and I have no reason to doubt them.
Re: Is NAT can provide some kind of protection?
I hesitate to venture into this thread, but while Owen is correct in the
general
case ("NAT qua NAT provides no more security than a stateful firewall"), there
is a corner case in which security is improved via NAT. The case is that of an
enterprise network which uses 1918 addressing for all internal hosts, and uses
proxies or other bastions as middleboxes to relay outbound communication.
The security provided is that in the event of an accidental bridging of
"inside"
and "outside" networks (i.e. engineer plugged a cable between the wrong two
switches), the hosts will not be able to initiate communication with Internet
hosts. Additionally, this same resiliency to accidental bridging does mean
that
the enterprise has a smaller number of possible Internet-facing machines, and
thus can spend the time and effort to make them more robust.
That benefit is not huge (and not relevant to the typical home user, who is not
configuring a super-duper scanning proxy server), but it does exist, and it
certainly fuels some of the pro-NAT feeling I've encountered among customers.
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
Re: Vyatta as a BRAS
--- On Tue, 7/13/10, valdis.kletni...@vt.edu wrote: > I wasn't aware that the 7206 and M20 classified as > software-based. > No weasel words necessary. I won't speak for the M20, but I've always thought of the 7206 as a software-routing platform - it's a pretty good swiss-army-knife software router which supports limited hardware acceleration of specific functions. Is there anyone who considers the 7206 a "hardware" router? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
--- On Wed, 4/28/10, Mark Smith wrote: > > I'm not people are understanding or know the true reality. > NAT broke the > Internet's architecture, by turning IP from being a > peer-to-peer > protocol into a master/slave one (think mainframes and dumb > terminals). > Read RFC1958 if you don't understand what that means, > specifically the > 'end-to-end' principle part. IPv6's fundamental goal is to > restore > end-to-end. And this, in a few short sentences, is why IPv6 adoption has been so incredibly slow and frustrating. For some of us, IPv6's primary benefit is solving the "32 bits aren't enough" problem. For others, the commercial Internet architecture which evolved is aesthetically offensive, and they see IPv6 as the corrective mechanism. Only one of those two has any sort of time constraint (read: necessity), and it isn't the latter. The end-to-end principle is grand, I agree - but there are lots of commercial considerations which I find have a higher priority for my customers. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: legacy /8
--- On Sat, 4/3/10, Mark Smith
wrote:
> To: "George Bonser"
> > No. But that isn't the point. The point is
> that v6 was a bad solution
> > to the problem. Rather than simply address the
> address depletion
> > problem, it also "solves" a lot of problems that
> nobody has while
> > creating a whole bunch more that we will have.
>
> Ever used IPX or Appletalk? If you haven't, then you don't
> know how
> simple and capable networking can be. And those protocols
> were designed
> more than 20 years ago, yet they're still more capable than
> IPv4.
Spoken like someone who has forgotten how much {fun|trouble} cable range +
zones were...
IPX, AppleTalk, VINES, DECNet, SNA, and all of the other protocol suites which
were kicking around in the 80s and early 90s each had the "one thing they do
really really well," but none of them were sufficiently flexible, extensible,
easy, or cheap to capture the market.
Examples of some things which those protocols *didn't* do well include
(obviously the list is different for each individual protocol):
* interdomain routing - most were optimized for single-administrative control
networks
* multicast
* handle an encryption layer at layer 3
* cheap + easy to implement, no license required
* distributed centralized administration (i.e. DHCP servers)
* tolerate a wide variety of {link|connection} performance characteristics
> I think IPv6 has not just learnt from the history of IPv4,
> it has also learnt from the history of other protocols.
Sadly, though, it also picked up some of the mistaken optimizations from the
other protocols. The mess that has been made of RA+SLAAC+DHCPv6+DNS is
something which can't be described as "elegant," and I certainly don't find it
an improvement over IPv4 DHCP+DNS.
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
RE: NSP-SEC
--- On Fri, 3/19/10, Adam Stasiniewicz wrote: > IMHO, I think you have it > backwards. I see strategic discussions (like > new crypto algorithms, technologies, initiatives, etc) > should be open to > public debate, review, and scrutiny. But > operational/tactical discussions > (like new malware, software exploits, virus infected hosts, > botnets, etc) > don't need public review. Rather, those types of > communications should be > streamlined that would allow for quick resolution. > Fair point - I was using "strategic" in the law enforcement with things like "long-term undercover investigation" in mind, but your point is well taken. I think we agree that some things benefit from increased transparency and other things don't. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: NSP-SEC
Total transparency in security matters works about as well as it would for law enforcement: fine for tactical concerns, but not so great for long-term strategic concerns. -David Barak On Fri Mar 19th, 2010 9:44 AM EDT William Pitcock wrote: >On Fri, 2010-03-19 at 08:31 -0500, John Kristoff wrote: >> An ongoing area of work is to build better closed, >> trusted communities without leaks. > >Have you ever considered that public transparency might not be a bad >thing? This seems to be the plight of many security people, that they >have to be 100% secretive in everything they do, which is total >bullshit. > >Just saying. > >William > >
Re: Strange Cisco 6503 problem
- Original Message From: Peter Hicks To: Dean Belev >> I'm curious if some of you faced such a problem - reboot of the router >> caused by the console connection. >I once managed to send a BREAK signal to a 3640 by plugging in a console >cable. At the time, it was a pretty key router in the > network and sat at the rommon> prompt :) >I had that down to static somewhere, as it's the only explanation I could find. Certain serial speed mismatches get interpreted as BREAK - I routinely use "space bar at 1200" to password crack routers where they are expecting 9600. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Using /126 for IPv6 router links
- Original Message From: Dale W. Carder dwcar...@wisc.edu On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote: > you face 2 major issues with not using /127 for > PtP-type circuits: > >> 1) ping-ponging of packets on Sonet/SDH links > Following this, IPv4 /30 would have the same problem vs /31? No, because IPv4 has the concept of Broadcast, while IPv6 does not. Remotely sending packets to an IPv4 broadcast address is a "directed broadcast" and that is generally denied by default on modern kit. >> 2) ping sweep of death > >> Take the same assumption for addressing as above, and now ping > > sweep 2001:db8::/64... if the link is ethernet, well, hope you > > didn't have any important arp entries that the router actually > > needed to learn. >Wouldn't this affect *all* /64's configured on a router, not >just point to point links? Time for glean rate limiting. This is, of course, one of the reasons why some of us didn't like the ultra-mega-mega ranges used to address handfuls of hosts, but that ship sailed long ago. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Using /126 for IPv6 router links
From: Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
>Why can't IPv6 node addressing be as easy to understand and work with
>as Ethernet addresses? They were designed in the early 1980s*. 28 years
>or so years later, it's time for layer 3 addressing to catch up.
Becase Ethernet addresses are only locally significant, are not manually
assigned in the vast majority of cases, and changing a MAC by replacing a NIC
has no bearing on the configuration of a { server | router ACL | etc }.
Layer 3 addressing is globally significant, and the case we're discussing is
addresses which are human-assigned rather than automatically configured.
Link-local autoconfiguration in IPv6 works like a champ, and behaves pretty
much the way I would want it to. Global addressing approaches, on the other
hand, are highly optimized in directions which make them less flexible or have
surprising consequences (hence this thread).
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
Re: [NANOG] Roport on internet business
>- Original Message >From: Jared Mauch >I know, watching my local incumbent they are not replacing damaged copper with >fiber. I think they must have warehouses of it someplace. I can't imagine >that it is good to replace buried copper w/copper during the wintertime. If >you're out doing it, might as well *actually* install fiber in the conduit. >(Unless it's about unions/job protection for the copper guys). >- Jared (not saying unions are bad, but when you operate two assets and have a >different union for each, it can limit your potential significantly). One of the very hard things about running a large, geographically distributed layer 0/1 organization is managing the various and sundry physical cables from point to point. Replacing one bad span with a good span which is qualitatively different introduces a level of version control and management headache, and if done in a haphazard fashion can reduce the overall availability of the network. I don't know who your incumbent is, but it's reasonable to assume that they have some strategy for cable plant management which includes overall technology refresh at some point, with like-for-like replacement until then. Also, last I checked, the specs on "how to build a good layer 0/1 fiber infrastructure" were different than those for copper - because the capabilities are different, the network architecture has different optimizations available. This doesn't mean that the provider shouldn't be moving toward a large-scale fiber rollout - far from it! I just wanted to provide a reason why they might not want to do said rollout in a piecemeal fashion. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: IGMP and PIM protection
Multicast encryption using GDOI works well, although I haven't seen that implemented on a LAN. If you're trying to provide encryption for LAN listeners (more accurately to exclude some LAN listeners) you'll probably find more bang for the buck in implementing this on a per-application basis. That leaves the IGMP request subject to eavesdropping, but the data itself flows over a secure channel. If instead you want the IGMP itself to be encrypted, then you'll need all of the switches to participate in the security protocol, and I would imagine that there are far easier ways to provide secure connections. I believe GDOI is esp-only. Cisco's term for GDOI is GETVPN. -David Barak On Wed Dec 23rd, 2009 7:26 AM EST Peter Hicks wrote: >Glen Kent wrote: >> Any idea if folks use AH or ESP to protect IGMP/PIM packets? Wondering >> that if they do, then how would snooping switches work? >> >Would encrypting multicast not fundamentally break the concept of multicast >itself, unless you're encrypting multicast traffic over a backbone? > > >Peter > > >
Re: AH is pretty useless and perhaps should be deprecated
+1. I know of a network whose owners are far more worried about a replay attack than about data being revealed to the outside world. They need to verify the provenance of data (i. e. Make sure that it hasn't bee Natted), and AH is a simple way to do these precise things. -David Barak James Hess wrote: > On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn wrote: >> However, i still dont understand why AH would be preferred over >> ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying >> the OSPF packets. One could also do these things with AH. >> Am i missing something? > Neither protects against replay without additional measures. > However, AH is very close... consider using AH-authenticated > packets with the timestamp option and clock synchronization between > peers. > Discard packets arriving that are more than 5 minutes old. > In transport mode for security between LAN peers, ESP NULL verifies > the integrity of only the data payload in the packet. AH secures > the header, the IP header fields and options. > Therefore changing the timestamp to replay would be detected. > This evil act would not be detected if you are using ESP NULL, the > attacker can potentially replay this packet, while the SPI is still > good, and you'll never know. > One of AH's most visible disadvantages (cannot be used with NAT) is a > side-effect of the increased security coverage it provides. Many IPv4 > networks require NAT, making AH impractical. > However, matters could change for IPv6 networks with high > security requirements, that need to validate authenticity of more > than just packet contents... > -- > -J
Re: AH is pretty useless and perhaps should be deprecated
I've seen AH used as a "prove that this hasn't been through a NAT" mechanism. In this context, it's pretty much perfect. However, what I don't understand is where the dislike for it originates: if you don't like it, don't run it. It is useful in certain cases, and it's already in all of the production IPSec implementations. Why the hate? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Original Message From: Ray Soucy >Or is it that you want IPv6 to be a 128-bit version of IPv4? Yes, this is in fact exactly what the network operators keep saying. >RA is a >good idea and it works. You can add options to DHCPv6, but I don't >see many vendors implementing default gateway support unless you can >make a real case for it. >My fear is that your goal is to do away with RA completely and turn to >DHCPv6 for all configuration. RA is actually quite nice. You really >need to stop fighting it, because it's not going away. RA may be quite nice for some cases. However, several examples over this thread alone have been provided about some other cases where it is something other than nice. DHCPv4 is not a perfect protocol, but it's widely deployed and understood. It also is a one-stop-shop for centralized host configuration. IPv6 does not currently have a similar one-stop-shop protocol, and this is a major gap in functionality. There are a bunch of very large providers and enterprises which number their DHCP-managed end-sites in the hundreds of thousands or millions. The inability to provide the same centralized configuration management should not be considered a feature. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: IPv6 Deployment for the LAN
- Original Message >From: Iljitsch van Beijnum iljit...@muada.com >Then again, if we remove all the improvements from IPv6 what's the point of >adopting it? How about "IPv4 address depletion?" I'm perfectly happy with how my network works. I do, however, want it to keep growing, and this requires more addresses. The requirement for organizations with thousands (or in some cases millions) of deployed customers to dramatically change how they can associate an IP address with customer ports (or provide remote configuration of said customers' devices) is not an attractive feature. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: ISP customer assignments
The fallacy here is the idea that IPv6 has a 128-bit namespace. It does not. It has two 64 bit namespaces, where one is expected to be globally unique and flat, While the other is hierarchical. IPv6 has a lot more room than v4 does, but it is worth noting Than in v4, a customer would typically use a single /32. In v6-speak, a /48 is a smaller percentage of the overall space, but it would not be prudent to view the v6-space as infinite. Remember, the value of a network increases with the number of interconnections, and those interconnections are what get numbered. All of the comparisons to atoms in the galaxy or human population are ignoring the hierarchical element of the 64-bit space. The nature of hierarchical allocations requires a Significant "burn" in terms of wasted, unusable addresses. All that said, the /64-based v6 addressing approaches are going to be with us for quite a while, so they're worth getting used to. -David Barak David Andersen wrote: > On Oct 5, 2009, at 7:50 PM, Michael Thomas wrote: >> I'm perplexed. At what size address would people stop worrying about >> the "finite" address space? 256 bits? 1024 bits? >> >> I just don't get it. It's not like people get stressed out about running >> out of name space in English which is probably more "finite" than ipv6. > Unless you're trying to find a nice, catchy, short domain name. ;-) > But seriously: Many people don't seem to have good intuition about really > big numbers. Say, on the order of 2^128. The same thing comes up in > discussions about hash collisions in, e.g., content based naming with a > 160-bit namespace. I think it's because the numbers are so astronomically > big, that without some amount of math and having thought about it with paper > and pencil, people automatically scale the #s into terms they can think of as > "really big" (like, # of people on earth). So when they think about the > 128-bit namespace, they apply intuition that works for a 35-bit namespace... > -Dave
Re: FCCs RFC for the Definition of Broadband
- Original Message From: James Downs Except this is exactly what happened. The players with vested interests were allowed a sort of "first refusal" on projects. In areas where they had lots of customers, they passed on the projects. So, we find that in urban areas, you can't get fiber in the home, but there are countless rural farms and homes that have fiber just lying around. I have an acquaintance 60 miles from the closest commercial airport in TN, telling me about the fiber internet he has. As an example of the above, Verizon has until 2017 to get FIOS to all of the neighborhoods of Washington DC (http://www.bizjournals.com/washington/stories/2008/11/24/daily8.html). I am envious of many of my suburban-dwelling coworkers and friends who already have it. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
RE: Point to Point Ethernet
> > Do you think this is useful? Maybe vendors will > hear me/us. > > > > -- > > Andre We also need functional remote loop testing, of the "remote hands guy plugs in a loopback plug" or "I send remote-triggered loop" type. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Fiber cut - response in seconds?
--- On Tue, 6/2/09, Charles Wyble wrote: > David Barak wrote: > > Encryption is insufficient - if you let someone have > physical access for a long enough period, they'll eventually > crack anything. > > Really? I don't think so. I imagine it would be much more > dependent on the amount of computing power the attacker has > access to. More encrypted blobs won't help. If that was the > case then the various encryption schemes in wide use today > would be cracked already. Bad guys can setup networks and > blast data through it and have complete access. I don't see > them cracking encryption. Paranoia 101 teaches us that any given encryption approach will eventually fall before a brute-force onslaught of sufficient power and duration[1]. I'm not trying to argue that the attacker in this case could necessarily detect a flaw in the algorithm; rather, they'll get an effectively infinite number of chances to bang against it with no consequences. Once it's cracked, the attacker will *still* have the physical access which is thus compromised, and then has free access to all of the transmissions. Physical security is a prerequisite to all of the other approaches to communication security. Those cases where physical security is presumed to be non-existant have to rely on a lot of out-of-band knowledge for any given method to be resistant to attack, and it's very hard to make use of a connection of that type for regular operations. Pretty much all security eventually boils down to people with firearms saying "don't do that." David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Fiber cut - response in seconds?
Encryption is insufficient - if you let someone have physical access for a long enough period, they'll eventually crack anything. Encryption makes the period of time longer, but let them try? As regards "roving," we are talking about Tyson's Corner here: that's pretty close (< 5km) to major offices of lots of folks who would care deeply about such matters. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com --- On Tue, 6/2/09, Charles Wyble wrote: > From: Charles Wyble > Subject: Re: Fiber cut - response in seconds? > To: "nanog@nanog.org" > Date: Tuesday, June 2, 2009, 1:57 PM > Cheaper? > > To quote sneakers were the united states govt. we don't > do that sort > of thing. > > Martin Hannigan wrote: > > It would also be cheaper to add an additional layer of > security with > > encryption vs. roving teams of gun toting manhole > watchers. > > > > YMMV, > > > > Best! > > > > Marty > > > > > > > > On 6/2/09, Deepak Jain > wrote: > >>> No. And here's why: If you're a naughty > foreign intelligence team, and > >>> you know your stuff, you already know where > some of the cables you'd > >>> really like a tap on are buried. When you hear > of a construction > >>> project > >>> that might damage one, you set up your > innocuous white panel truck > >>> somewhere else, near a suitable manhole. When > the construction guy with > >>> a backhoe chops the cable (and you may well > slip him some money to do > >>> so), *then* you put your tap in, elsewhere, > with your actions covered > >>> by > >>> the downtime at the construction site. That's > why the guys in the SUVs > >>> are in such a hurry, because they want to > close the window of time in > >>> which someone can be tapping the cable > elsewhere. > >>> > >>> At least that's what I heard. I read it > somewhere on the internet. > >>> Definitely. Not at all a sneaky person. No > sir. > >> And if you were a naughty foreign intelligence > team installing a tap, or a > >> bend, or whatever in the fiber contemporaneously > with a known cut, you could > >> also reamplify and dispersion compensate for the > slight amount of affect > >> your work is having so that when its tested later, > the OTDR is blind to your > >> work. > >> > >> Ah, the fun of Paranoia, Inc. > >> > >> Deepak Jain > >> AiNET > >> > >> > > > > > >
RE: Fiber cut in SF area
--- On Mon, 4/13/09, chris.ra...@nokia.com wrote: >> From: Peter Beckman >> Subject: RE: Fiber cut in SF area > > Total cost...is about $3000 per mile for > equipment > I get the feeling you haven't deployed or operated large > networks. You never did say what the multiplier > was. How many miles or detection nodes there > were. Think millions. The number that popped > into my head when thinking of active detection measures for > the physical network is $billions. AT&T: 888,000 route miles(1). Verizon: 485,000 route miles(2). If we assume that 1/4 of AT&T and Verizon's route-miles are in the US(3), this would mean a capital expense of $666M and $364M respectively, not including any costs incurred for maintenance, monitoring, repair, false positive etc. In addition, as has been noted, this system wouldn't PREVENT a failure, it would just give you some warning that a failure may be coming, probably by a matter of minutes. In the words of Randy Bush, "I encourage my competitors to do this." David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com 1) http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=26554 2) http://mediumbusiness.verizon.com/about/network.aspx 3) I believe this to be an underestimate.
Re: switch speed question
Doesn't that assume that the communicarion is unidirectional? If two hosts are exchanging 1Gbps flows, the traffic across the bus will be 2Gbps, right? And of course, this doesn't include any bus-intensive operations like multicast or things which require cpu processing - those can consume a lot more resources than the input rate of the port. -David Barak Tom Storey wrote: >> Not every bit in results in just one bit out. Broadcast, multicast, >> flooding for unknown MACs (or switching failures), ... > They were talking about a simple scenario where a bit that enters a port > will leave a port. With 24 gigabit ports, for all intents and purposes, > you will only ever have 24 gigabits at the most traversing the backplane.
Re: IPv6 Confusion
If the IPv6 solutions are not going to be 'better' than v4, how about simply making sure that they are 'as good as' ipv4? Right now, I'd be hard pressed to think of a v6 function which is 'better' and I can think of a lot which are 'not as good as.' -David Barak Adrian Chadd wrote: > On Thu, Feb 19, 2009, Nathan Ward wrote: >> Yep. You asked your vendors to support equivalent IPv6 things at the >> time though, so when you roll out IPv6 the support is ready, right? >> >> The point is that these deficiencies exist in IPv4, and I'm not sure >> how you would solve them in IPv6 (assuming you can make all the >> changes you want, and get instant industry-wide support) any better >> than you solve them in IPv4. > Who says the IPv6 solutions need to be better than IPv4? > Adrian
Re: Private use of non-RFC1918 IP space
--- On Mon, 2/2/09, David Coulson wrote:
> I'm curious - Any particular
> technical reason not to assign out of 0.0.0.0/8? Can't say
> I've ever tried to use it, but I'd think it should work.
I have long wondered why two entire /8s are reserved for host self
identification (0 and 127, of course...) - it's too bad that we can't use
either those or class E space while folks {delay | prepare for} ipv6 adoption...
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
Re: Private use of non-RFC1918 IP space
--- On Mon, 2/2/09, Patrick W. Gilmore wrote: > > Most ISP's, if not all, null route 1.0.0.0/8 therefore > you shouldn't > > encounter any problems using it in a private network. > > Until IANA runs out and gives that space to Google or MS or > Comcast or $WHATEVER_THAT_NETWORK_TALKS_TO. It all comes down to "what do you mean by 'private network'" doesn't it? If you operate an IP network which is air-gapped from all other IP networks, which IP address you use is irrelevant. If that network interconnects with (only) a provider/customer using RFC 1918 space, you either have to coordinate with them, NAT, or use non-RFC 1918 space. If you run a network which should only communicate with others through a proxy/firewall/NAT device, how much does it matter what's on the inside? Of course, the risk of using IP addresses which are not uniquely assigned to you is that there will be an overlap somewhere. Whether the risk is greater inside or outside of RFC 1918, I leave for others to puzzle out (although it should be noted that organizational M&A activity makes hash of the best-laid IP address schema). David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Anyone notice strange announcements for 174.128.31.0/24
--- On Tue, 1/13/09, Patrick W. Gilmore wrote: > > AS_PATH != identity, and I would not recommend loading > the latter onto the former. > > We disagree. When I am researching something, I frequently > look at ASNs in the path to figure out not just where but > who controls the path. Oh, I certainly think that there is a loose coupling there, and the relationship is highly valuable from a troubleshooting point of view. However, I would counsel anyone investigating AS_Path relationships to remember that do not completely characterize the relationship between any two organizations, let alone the multipolar relationships between all organizations. It's a good first-cut, but it doesn't have the level of authority that you're implying. I'm not aware of any ASNs being trademarked... > >>Personally, I would be upset if someone injected > a route > >> with my ASN in the AS_PATH without my permission. > > > > Why? Is this a theoretical "because it's > ugly" complaint, or is there a reason why manipulating > this particular BGP attribute in this particular way is so > bad? Organizations do filtering and routing manipulation > all over the place. Is there something worse about doing it > this way than others? > > Filtering and other manipulation happened on your router, > prepending my ASN is putting that information into every > router. That seems to be a serious qualitative difference > to me. Do you disagree? This is qualitatively similar to an ASN announcing de-aggregated routes - it may be nice if they don't, and you don't have to accept them, but are they permitted? > > > This thread has been interesting & educational. So > many people seem to be happy to explain why they should be > allowed to use globally unique identifiers they do not own > in ways which were not intended, then explain to the people > who do own those identifiers how they should react, which > alarms should go off, and even which priority the alarms > should have. > > As I have repeated probably hundreds of times: Your > network, your decision. I have yet to hear a credible > argument against that stance. What you do _inside_ your > network is _your_ decision. When it leaves your network, > however, things change. Exactly! Provider RB announces $WEIRD. A bunch of providers receive alarms about the existence of $WEIRD, and they treated this as $IMPORTANT. The bunch of providers who treated this as $IMPORTANT are informing all of us about their monitoring thresholds and their responses to this threshold being met. Their networks, their decisions. It should be pointed out that pre-provisioned AS_Path filters and prefix-lists would actually be effective at defeating this and preventing someone who is actually malicious from using this technique. This is an excellent argument for implementing SIDR... > > Announcing an ASN which is not yours to eBGP peers means it > is leaving your network, which means it is not just your > business. Doing so and then telling the ASN owner that they > should not worry about it afterwards - and in fact arguing > when the owner repeatedly tells you this caused them > problems - does not seem to be the proper course of action. Understood, but if this is viewed as problematic, there is a very simple solution: don't allow a BGP customer (or peer!) to prepend someone else's ASN. > > > I mentioned earlier in the thread if Cogent prepending > Sprint's ASN to Verio, people would react differently. > Randy said tools can be used for good or bad, obviously > implying he's the good guy. He is not the good guy. He > used someone else's resources without their permission > and without even notifying them, costing them time & > effort. Randy doesn't get to decide if the ASN owner > should have alerted or investigated or whatever, and > neither do any of you unless it is your ASN. > > How can anyone seriously argue the ASN owner is somehow > wrong and keep a straight face? How can anyone else who > actually runs a network not see that as ridiculous? Are any providers going to implement ^ASN filtering as a result of this experiment? This could turn out to be a very inexpensive lesson, which is far preferable to more expensive lessons... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Anyone notice strange announcements for 174.128.31.0/24
--- On Tue, 1/13/09, Jared Mauch wrote: > > No, they are both victims. If I inject a path that > purports > there is an edge between two networks which are engaged in > a bitter > dispute, (i'll use cogent & sprint as an example) - > _1239_174_ that may > create a situation where someone asserts that their routes > are > being filtered when infact no connectivity exists. That's a theoretical possibility, but who would be the one doing the asserting? I would argue that it would either be the owner of the announced space or someone trying to reach it. In this case, nobody was trying to reach the /24 in question, and the owner was the one doing the experiment. Victimless crime, at most. > > Does that mean that I hijacked their identiy and forged > it? What level of trust do you place in the AS_PATH for your > routing, debugging and > decision making process? AS_PATH != identity, and I would not recommend loading the latter onto the former. > > Personally, I would be upset if someone injected a route > with my ASN in the AS_PATH without my permission. Why? Is this a theoretical "because it's ugly" complaint, or is there a reason why manipulating this particular BGP attribute in this particular way is so bad? Organizations do filtering and routing manipulation all over the place. Is there something worse about doing it this way than others? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Anyone notice strange announcements for 174.128.31.0/24
--- On Mon, 1/12/09, deles...@gmail.com wrote: > This was a test using unassigned IP block, unless I'm > reading it wrong. If a noc alerted on this it should have > still be a low priority issue. I don't see any issues > with the way this was carried out at all. > > -jim I completely agree with Jim: I have no idea why alert thresholds are set to a level of sensitivity which would cause this to become a "must be dealt with this minute" sort of issue. What exactly is the threat potential of someone else's IP space being announced with your ASN prepended? If the concern was a Pilosov/Kapela style hijack, wouldn't the first thing you'd check be what the address range was? That would lead you straight to Randy, and that should have cleared up the matter straightaway. Remember: the owner of the IP space is the victim, not the ASN which gets prepended into the path... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re:
Collaborate & Listen http://xkcd.com/210/ David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com --- On Mon, 1/12/09, Nathan Malynn wrote: > From: Nathan Malynn > Subject: Re: > To: "Aaron Imbrock" > Cc: NANOG@nanog.org > Date: Monday, January 12, 2009, 1:12 AM > Hammertime. > > On Mon, Jan 12, 2009 at 1:11 AM, Aaron Imbrock > wrote: > > Stop > > > > > > > >
Re: Ethical DDoS drone network
--- On Tue, 1/6/09, Justin Shore wrote: > David Barak wrote: > > Consider for a moment a large retail chain, with > several hundred or a couple thousand locations. How big a > lab should they have before deciding to roll out a new > network something-or-other? Should their lab be 1:10 scale? > A more realistic figure is that they'll consider > themselves lucky to be between 1:50 and 1:100, and that lab > is probably understaffed at best. Having a dedicated lab > manager is often seen as an expensive luxury, and many > businesses don't have the margin to support it. > > At the very least they should have a complete mock location > (for an IT perspective) in a lab. Identical copies of all > local servers and a carbon copy of their official template > network. This is how AOL does it. Every change is tested > in the mock remote site before the official template is > changed and the template is pushed out to all the production > sites. I don't disagree at all: that is a straightforward way to anticipate *most* problems. What is does not and cannot validate is whether there is a scaling issue, and this is what doing "live" testing does give you. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Ethical DDoS drone network
-- On Mon, 1/5/09, Roland Dobbins wrote: > From: Roland Dobbins > Subject: Re: Ethical DDoS drone network > To: "NANOG list" > Date: Monday, January 5, 2009, 6:39 PM > On Jan 6, 2009, at 7:23 AM, David Barak wrote: > > > In my opinion, the real thing you can puzzle out of > this kind of testing is the occasional hidden dependency. > > Yes - but if your lab accurately reflects production, you > can discover this kind of thing in the lab (and one ought to > already have a lab setup which reflects production for many > reasons having nothing to do with security). I agree - having a lab of that type is absolutely ideal. However, the ideal and the real diverge tremendously in large and mid-size enterprise networks, because most enterprises just don't have enough lab equipment to adequately model all of the possible scenarios, and including the cost of a lab in the rollout immediately doubles all capital expenditures. The types of problems that the ultra-large DoS can ferret out are the kind which *don't* show up in anything smaller than a 1:1 or 1:2 scale model. Consider for a moment a large retail chain, with several hundred or a couple thousand locations. How big a lab should they have before deciding to roll out a new network something-or-other? Should their lab be 1:10 scale? A more realistic figure is that they'll consider themselves lucky to be between 1:50 and 1:100, and that lab is probably understaffed at best. Having a dedicated lab manager is often seen as an expensive luxury, and many businesses don't have the margin to support it. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
RE: Ethical DDoS drone network
In my opinion, the real thing you can puzzle out of this kind of testing is the occasional hidden dependency. I've seen ultra-robust servers fail because a performance monitoring application living on them was timing out in a remote query, and I've also seen devices fail well below their expected load because they were using multiple layers of encapsulation (IP over MPLS over IP over Ethernet over MPLS over Frame-Relay ...) and one of the hidden middle-layers was badly optimized. The advantage of performing this DDoS-style load testing on yourself is that *you can turn it off once you experience the failure* and then go figure out why it broke when it did. This is a lot more pleasant than trying to figure it out at 2:30 in the morning with insufficient coffee. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com --- On Mon, 1/5/09, BATTLES, TIMOTHY A (TIM), ATTLABS wrote: > From: BATTLES, TIMOTHY A (TIM), ATTLABS > Subject: RE: Ethical DDoS drone network > To: "Edward B. DREGER" , na...@merit.edu > Date: Monday, January 5, 2009, 4:16 PM > True, real world events differ, but so do denial of service > attacks. > Distribution in the network, PPS, BPS, Packet Type, Packet > Size, etc.. > Etc.. Etc.. So really I don't get the point either in > staging a real > life do it yourself test. So, you put pieces of your > network in > jeopardy night after night during maintenance windows to > determine if > what?? Your vulnerable to DDOS? We all know we are, > it's just a question > of what type and how much right? So we identify our choke > points. We all > know them. We look at the vendor data on how much PPS it > can handle and > quickly dismiss that. So what's the next step? Put the > device that IS > the choke point and pump it full of all different flavors > until it > fails. No harm no foul an now we have data regarding how > much and what > takes the device out. If the network is scaled, well we now > know that we > have x amount of devices that can fail if the DDOS goes X > PPS with Y > packet types. What I don't get is what you would be > doing trying to > accomplish this on a production network. Worse case is you > break > something. Best case is you don't. So if best case > scenario is reach, > what have you learned? Nothing! So what do you do next ramp > it up? Seems > silly. > > > > -Original Message- > From: Edward B. DREGER > [mailto:eddy+public+s...@noc.everquick.net] > Sent: Monday, January 05, 2009 12:03 PM > To: na...@merit.edu > Subject: RE: Ethical DDoS drone network > > TAB> Date: Mon, 5 Jan 2009 11:54:06 -0500 > TAB> From: "BATTLES, TIMOTHY A (TIM), ATTLABS" > > TAB> assuming your somewhat scaled, I would think this > could all be done > TAB> in the lab. > > And end up with a network that works in the lab. :-) > > - bw * delay > - effects of flow caching, where applicable > - jitter (esp. under load) > - packet dups and loss (esp. under load) > - packet reordering and assiciated side-effects > - upstream/sidestream throughput (esp. under load) > > No, reality is far more complex. Some things do not lend > themselves to > _a priori_ models, nor even "TFAR" > generalizations. > > > Eddy > -- > Everquick Internet - http://www.everquick.net/ > A division of Brotsman & Dreger, Inc. - > http://www.brotsman.com/ > Bandwidth, consulting, e-commerce, hosting, and network > building > Phone: +1 785 865 5885 Lawrence and [inter]national > Phone: +1 316 794 8922 Wichita > > DO NOT send mail to the following addresses: > dav...@brics.com -*- jfconmaa...@intc.net -*- > s...@everquick.net > Sending mail to spambait addresses is a great way to get > blocked. > Ditto for broken OOO autoresponders and foolish AV software > backscatter.
Re: Public shaming list for ISPs announcing other ISPs IP space by mistake
--- On Sun, 8/17/08, Jared Mauch <[EMAIL PROTECTED]> wrote: > On Sun, Aug 17, 2008 at 03:44:40PM -0400, Jon Lewis wrote: > > On that topic, how do you delete IRR objects when the > person who created > > them used a unique maintainer object and is no longer > around to provide > > the password for the maintainer object? > > This is what the human at most db-admin aliases is for. > > I know that we staff humans behind our alias to respond to > such queries. Or this points to the utility of creating your own internal RRd server, and peering with the public IRRs. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: Cable Colors
- Original Message >From: Steve Bertrand [EMAIL PROTECTED] >Jay R. Ashworth wrote: >> Their datacenter is new, $3.6M in a new completely automated $200M >> building, and it's *gorgeous*. Thanks to APC for organizing a (sales) >> tour about 3 months ago; I love facility porn. >...facility porn... But is the facility porn available over IPv6? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: IPv6 & DNS
--- JORDI PALET MARTINEZ <[EMAIL PROTECTED]> wrote: > > But as said, IPv6 was designed having in mind a > smooth transition including > dual-stack. Nothing is wrong when IPv6 "alone" > doesn't work today. Is like > trying to use only gas in an engine that requires a > mix of gas and oil. It > is something wrong ? No, it is the way you try to > use the engine, because > was not designed that way ! The problem is that turning on v6, while requiring that v4 continue to work means accepting the limitations and security risks of both protocols. This is not a "transition" - this is another level of indirection (c.f. RFC 1925). A "transition" has an end-state which is clearly defined, and we are only just starting to ferret out the end-state with regard to v6. > In fact, I have not talked about public IPv4 > addresses at all ! As explained > in another message, we are doing large IPv6-only > deployments (5.000 sites). > The "only" applies to the core and access network, > but we keep > net10+NAT+IPv6 in the LANs. That's what you mean by "IPv6-only"? When I talk about IPv6-only, what I mean is "no other layer-3 protocols running: no IPv4, no Appletalk, no IPX, etc." I get that there is rough consensus. I'm waiting for the running code. -David Barak David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
