Re: The Reg does 240/4
I've said it before, and I'll say it again: The only thing stopping global IPv6 deployment is Netflix continuing to offer services over IPv4. If Netflix dropped IPv4, you would see IPv6 available *everywhere* within a month. --lyndon
Re: The Reg does 240/4
> > How many legacy mail clients can handle IPv6? I would suspect all of them, since MUAs, by definition, are not involved in any mail transport operations. But if you're thinking of MUAs that use Submission, they are unlikely to care one whit what the underlying transport is. You configure a submission hostname, and the client just hands that off to the underlying OS to deal with. It doesn't care what parameters are passed to the connect() call under the hood. As for mail servers handling v6 out of the box, I am not familiar with *any* currently shipping MTA that does NOT do v6 with no configuration required. --lyndon
Re: The Reg does 240/4
And what are they going to do when 240/4 runs out?
Re: JunOS config yacc grammar?
OFFS people, spare me the bikeshed. It was a simple yes/no question. In case you missed it, here is the decision tree: /---\ | START | \---/ | | ^ / \ / \ / \ / \ / \ /Do You \ No/--\ < Have A> - | STOP | \ Yacc/\--/ \ Grammar? / \ / \ / \ / \ / \ / | Yes | ^ / \ / \ / \ / \ / \ No/--\ < Share? > - | STOP | \ /\--/ \ / \ / \ / \ / | Yes | |--| | Email | | Grammar | |--| | | /--\ | STOP | \--/ --lyndon
Re: JunOS config yacc grammar?
Diogo Montagner writes: > --728632060377d0b2 > Content-Type: text/plain; charset="UTF-8" > > I would first try to understand what you are trying to achieve. JUNOS is > very flexible on this front and I am wondering why you think yacc is the > right way to achieve what you are trying to do. Because I've been writing yacc grammars for decades. I just wanted to see if someone had already done it, as that would save me some time. But if there's nothing out there I'll just roll one myself. --lyndon
Re: JunOS config yacc grammar?
Nick Hilliard writes: > No need to reinvent that wheel: > > root@foo> show configuration | display xml > root@foo> show configuration | display json That doesn't quite work for this scenario. It would mean ssh-ing to the switch to grab it, and that's pretty locked down. We already have cron jobs running on the switches that tftp the config file to a server, and I'd prefer to leverage off that. Also, the yacc parser would let me do some validation checks before we push new configs. --lyndon
JunOS config yacc grammar?
Any chance somebody out there has a yacc grammar that will parse a Juniper config files? My immediate interest involves v19.X on our EX4300s, but anything in the ballpark would save me having to write one from scratch. --lyndon
Amateur radio @ nanog 88
For the hams attending 88, should we pick a simplex frequency or two to rendevouz on for beer consumption planning purposes? I'll be armed with a tribander for 146/222/440. --lyndon
Re: Aptum refuses to SWIP
Forrest Christian (List Account) writes: > I'm also wondering if this might be a "no one that has got the request > actually has a clue how to resolve your issues" issue. I've seen > situations where companies don't know how to respond to a request outside > the most common requests they get. Sometimes some enterprising employee > will also totally misunderstand your request and do stupid things like do > exactly opposite what you want them to do like remove correct information > in an effort to "fix the incorrect info". And sometimes employees convey > "we don't have a clue" as "we don't do that". I long ago resigned myself to the reality that the first response to any ticket will be a pointless, irrelevant, and mostly content free reply from somebody who didn't even make an effort to actually read the ticket. It generally takes three rounds before the ticket gets to somebody with a clue. This applies across the board to pretty much every vendor/supplier these days :-( > Have you tried any other backchannels other than NANOG? Like peeringdb > contacts (if you have access) or maybe through linkedin or something like > that? Someone from Aptum did get in touch and says they will apply the mallet 'o understanding to the appropriate people inside estruxture. I don't think estruxture were the actual problem, but if I get a fix to the problem, that's good enough. For now. > Or threaten to change providers at the earliest possible moment? Our current contract is up in about two years. Based on what we've seen out of estruxture/Aptum over the last couple of years, I'm certainly going to investigate alternatives. Bell has much more modern colo < two blocks from our office. Now would be prime time to start planning for a move. --lyndon
Re: Aptum refuses to SWIP
Forrest Christian (List Account) writes: > I can't speak for aptum, but I'm curious as to why this is important to > you? I'm not trying to discount this at all, just curious why this > matters in the internet of 2023. Two main reasons. 1) We are trying to set up internal peering with AWS, and they use the rwhois info to validate that the addresses we want to route to them are actually assigned to us. 2) We (Hushmail) often have to deal with overly zealous mail firewall administrators (typically, state gov't medically-focused departments) who have a bad habit of outright blocking any mail from a non-US source. But we also get this from general mail firewall appliance vendors who maintain their own blacklist. Being able to point them at valid rwhois data to verify this mail is coming from a legitimate email provider is (or has been) our first step in getting our mail relays removed from those lists. (1) is directly impacting our business right now. (2) will rear its head before long -- we usually run into those cases every three to four months. But the last time I looked, it's also ARIN's policy to require ISPs (which Aptum is) to SWIP addresses in order to justify future requests for address space. I'm curious what will happen the next time they ask for additional ip6 allocations. Or maybe they have no growth plans? --lyndon
Aptum refuses to SWIP
It seems Aptum has decided they will no longer SWIP any of their address space. I've been trying to get a SWIP for a /48 that we were allocated in 2017, but they refuse. And I also see they have pro-actively gone in and un-SWIPed both our /24s. Since you are ignoring my tickets about this, maybe somebody from Aptum would care to speak up in public and defend this "policy?" --lyndon
BGP Books
It has been a couple of decades since I've done any BGP in anger, but it looks like I will be jumping into the deep end again, soon, and I desperately need to get up to speed again. There seem to be a lot of good guides out there from Cisco, Juniper, and the like, but naturally they are very product oriented. What I'm looking for is more like the Stevens networking bibles (i.e. "BGP Illustrated Vol I and II"). Something that covers more than just the raw protocols, and includes things like RPKI. (The world sure has changed since the last time I was doing this!) Any/all suggestions welcome. Thanks! --lyndon
Re: Imperva / Apple Private Relay issues
Robert Schoneman writes: > I've tested accessing one of our sites that uses Imperva WAF w/ DDOS protec= > tion enabled from an iPhone w/ Apple Private Relay turned on. I experienced= > no issues but only have that single test to go on. =20 A couple of people from Cloudflare and Apple contacted me directly. They did some poking around internally but didn't really find anything. And the problem seemed to clear itself up over the weekend. At this point I'm chalking it up to some transient routing issues upstream of Imperva that sorted themselves out. Thanks to everyone who replied off-list and offered to help! --lyndon
Imperva / Apple Private Relay issues
We have been receiving a steady stream of calls from customers complaining they cannot reach our websites when they have Apple's Private Relay enabled. For those in the dark, Private Relay sends (only) Safari connections through an assortment of CDNs to anonymize the client's IP address. What we are seeing is that, more often than not, connections to our public servers that route through Imperva's DDoS service do not go through. When we look on the uplink interfaces on our firewalls, there is nothing from those addresses. But connections to other hosts in the same cage, but which bypass Imperva, connect fine. We've opened a ticket, but thus far Imperva's support team has been unhelpful. What I'm wondering is if anyone else is seeing similar behaviour with their Imperva-protected hosts. A quick way to test is to turn on Private Relay on an iPhone (System Preferences -> iCloud -> iCloud -> Private Relay) and then try connecting to a web service hosted behind Imperva's DDoS service. For our servers, not all the connections fail, but a large percentage do, and it's definitely tied to the proxy address you get assigned (verified using whatismyip.com). We are seeing failures on connections relayed through both Cloudflare and Akamai. Apple could be using other CDNs as well, but those are the two we have specifically identified as having unusable addresses. --lyndon
Re: FCC to Consider New Rules to Combat International Scam Robocalls
Jon Lewis writes: > > I've noticed a few (small number) of robocalls have started spoofing > > international phone numbers instead of local phone numbers. I don't know if > Are you sure this isn't just either a failure to spoof or incompetent > spoofing? Nope. I've been seeing an increasing number of bogus international numbers as well. And I'm all in favour of it because for those ones I *know* they are bogus and should be ignored. --lyndon
Re: junos config commit question
Owen DeLong writes: > top > rollback I am *sure* I tried exactly that but it wasn't working as I expected. But maybe I was just imagining things. And somehow I completely missed the 'rollback 0' variant while plowing through the documentation. Thanks everyone for assisting the blind ;-) --lyndon
Re: junos config commit question
Nick Suan via NANOG writes: > I was actually interested to see if the EX series would let me do this, and i > t turns out that if STP is enabled on any of the switch interfaces, it won't: > tevruden@core-02# commit check > [edit protocols rstp] > 'interface' > XSTP : Interface ge-0/0/0.0 is not enabled for Ethernet Switching > error: configuration check-out failed Do you have any rstp-specific overrides in your config? E.g. we have things like this in some of ours: rstp { interface ge-0/0/45 { cost 1000; mode point-to-point; } interface ge-1/0/45 { cost 1000; mode point-to-point; } interface ae4; bpdu-block-on-edge; } With the interfaces gone I would expect the commit check to fail. --lyndon
Re: junos config commit question
Marco Davids via NANOG writes: > rollback 0 OFFS 8-0 Thanks :-)
junos config commit question
On an EX4300 switch running JunOS 14.1 let's imagine I typed config delete interfaces before coming to my senses. How am I supposed to back out of that mess? For the life of me, after a week of reading the 3000 page reference manual, and endless DuckDuckGoing, I cannot see a simple way of just abandoning the commit. I've got to be missing something stunningly obvious here because it's unthinkable that this functionality doesn't exist. Help?!? The only way out I can see is to drop into the shell, make an uncompressed copy of juniper.conf.gz, then pop back into the config editor and load that over top of the editor's config view. Surely there's a saner way of dealing with this. --lyndon
Re: Is WHOIS going to go away?
> On Apr 21, 2018, at 3:48 PM, Mark Andrews wrote: > > You have a logic fail. This fails because it STILL depends on the DNS for > the zone working. If the DNS fails to that extent, everything fails. I was addressing the single application endpoint point-of-failure. But from a practical standpoint, you're probably right :-( --lyndon
Re: Is WHOIS going to go away?
> On Apr 21, 2018, at 2:47 PM, Keith Medcalf wrote: > > Actually, a I doubt that there are any "real" people with vanity domains > behind this move. I suspect that it is the scammers and spammers who want to > hide their information for very good reason. > > And of course, the "powers of the EU" seem to be in cahoots with those > scammers and spammers (if they are not the scammers and spammers who > themselves are wanting to hide). I also think more fine-grained control of the data would satisfy many needs. E.g., for my own domains, for the purposes of contacting me to deal with abuse (or insanely large but unlikely buyout offers), all you need is an email contact address. I can put my personal or company name out there, along with a working email address, and still not hand over my home address, phone numbers, etc. For domains backing consumer-facing companies, they would likely want to expose more information. There is no one-size-fits-all here. And that's where the EU is losing credibility. --lyndon
Re: Is WHOIS going to go away?
> On Apr 21, 2018, at 2:27 PM, Lyndon Nerenberg wrote: > >> But backup and failover are reasonably well understood technologies >> where one cares. Registrars could for example cache copies of those >> zone records and act as failover whois servers. Sorry! I left out the last line that was the point of my diatribe. Using SRV to point to multiple domain-specific whois servers eliminates the caching problem Barry raised.
Re: Is WHOIS going to go away?
> On Apr 21, 2018, at 1:58 PM, b...@theworld.com wrote: > > That's actually an excellent point and counterpoint to my suggestion > to move the WHOIS information into DNS RRs. > > But backup and failover are reasonably well understood technologies > where one cares. Registrars could for example cache copies of those > zone records and act as failover whois servers. Instead of putting the contact info directly into the DNS, put pointers to the locations of the data instead. I.e. whois moves off dedicated ports and hardwired servers and into zone-controlled SRV records: _whois._tcp.orthanc.ca SRV 0 0 43 orthanc.ca. SRV 5 0 43 backup.otherdomain.example.com. This gives each zone control of the information they want to export (by directing whois(1) to what they consider to be authoritative servers). The domain owners themselves could control the information they chose to expose to the public, through the SRV records, and the information they chose to publish in the whois servers those records point at. If the domain owner is happy with their (say) registrar providing that information, they would just point the appropriate SRV record at the registrar. This is no different from how people handle email outsourcing via MX records. The idea that whois is in any way authoritative is long gone. Those who want to hide have been able to do that for ages. (I think I pay $15/year to mask some of the domains I control.) But for law enforcement, a warrant will always turn up the payment information used to register a domain, should the constabulary want to find that information out. And for court proceedings, whois data is useless. (I speak from $WORK experience.) --lyndon
Re: Waste will kill ipv6 too
> On Dec 28, 2017, at 7:50 PM, valdis.kletni...@vt.edu wrote: > > Comcast is passing out CPE that provides a subnet for the actual subscriber, > and another one for *other* Comcast roaming customers. And somehow this > works for a company the size of Comcast without the customers needing to know > how to set them up. This sounds like the Shaw "Wifi to Go" routers they (Shaw) push out. Agree to make your Shaw internet connection "shared" and they drop in a hotspot that provides a 2nd wifi network that subscribers can connect to. In exchange for a discount on your local internet bill. (Separate subnet.) Of course, Shaw STILL doesn't do IPv6 ... ;-P
Re: Waste will kill ipv6 too
> On Dec 28, 2017, at 7:26 PM, Brock Tice wrote: > > Most of our customers only have 2-5 devices. I know this is not the case > in most of America but we are quite rural and for many people they've > never had better than 1.5Mbps DSL until we install service at their > location. Most of them have no idea what a subnet is. Let us say that > over the next ten years they get quite savvy and decide to isolate their > wireless clients, some public servers, their IoT devices, and their > security cameras. We have given them a /52 which contains 4096 /64s. So, > most likely, they will use one of those for their LAN and be done. In > case they decide to make several VLANs or whatever they have used 4 /64s > and they have 4092 left. And that's where you're missing the IPv6 addressing concept. You are thinking of "devices." That's not how the v6 address space was planned out. Future address (subnet, really) consumption will be decided by the devices behind the CPE, not the number of devices behind the CPE. That's why there is such a huge address space allocation to each end point. What people do in the privacy of their own routing domain is their own business. As I mentioned in an earlier post to the list, think of IPv6 as a /64 address space; ignore the noise to the right. ARIN allots you a /48 for each of your customer end points. That means, as an ISP, you get a /32 right away. That covers 64K customer end points out of the gate. If you need a larger allocation, you can get that immediately. So there is no need to carve up end point /48s. And you don't want to. It just makes more work configuring your routers. Your monitoring software will assume /48 per CPE, so you'll have to explicitly configure that, etc. All you are doing is making work for yourself. And messing things up for your customers. --lyndon
Re: Waste will kill ipv6 too
> On Dec 28, 2017, at 7:28 PM, Tony Wicks wrote: > > I think its time you all had a bit of a holiday break and stopped thinking > of IP networking for a little while, Just saying... Nah. This is a useful conversation (and argument) to have.
Re: Waste will kill ipv6 too
> On Dec 28, 2017, at 6:54 PM, Ricky Beam wrote: > > Home networks with multiple LANs??? Never going to happen; people don't know > how to set them up, and there's little technical need for it. Again, you are assuming you know how people will use networks forever. Stop overthinking things, and just concentrate on just routing the packets. Your ONLY concern as a network operator is the number of routing table entries you need to carry. The size of my netmask (giggity) is irrelevant. Ship me a 48, 52, 64, 120, doesn't matter. It's a single RTE as far as you are concerned. (Again, unless you can't $afford renting the extra address space from ARIN. In which case you don't have a network infrastructure problem ...)
Re: Waste will kill ipv6 too
Peripherally, it's worth noting that, in far less time then we have not migrated from IPv4 to IPv6, the UK moved from 7-digit to 11-digit telephone numbers. If that's not embarrassing ... --lyndon
Re: Waste will kill ipv6 too
> On Dec 28, 2017, at 6:11 PM, Scott Weeks wrote: > > All I was trying to say is there're going to be things > not thought of yet that will chew up address space > faster than ever before now that everyone believes it's > essentially inexhaustible. And, I expect, sooner than > imagined. If that's the case, it will be because there were few restrictions placed upon that address space. And if some genius comes up with something that burns through all the IPv6 address space, you can rest assured the market (and not the IETF) will come up with a replacement that extends things beyond 128 bits in a ripping big hurry.
Re: Waste will kill ipv6 too
> :: Isn't this the utopia we've been seeking out? > > I like that one! :-) Seriously. If we run out of networks while handing out /48s, by migrating everything to HTTPS we can claw back the 16 bit 'port' field in the IP header and reassign it as part of the 140-bit IPv6.1 address space. Mind you, the FCC will likely auction off those extra 16 bits to Amazon, so you'll need a Prime membership to use them. --lyndon
Re: Waste will kill ipv6 too
> On Dec 28, 2017, at 4:57 PM, Lyndon Nerenberg wrote: > > Instead, think about how we can carve up a 2^61 address space (based on the > current /3 active global allocation pool) between 2^32 people (Earth's > current population) Of course, I screwed up the numbers (thanks Javier for pointing this out). 2^32 is closer to 2^33 for population, so adjust the netmasks accordingly.
Re: Waste will kill ipv6 too
> On Dec 28, 2017, at 3:28 PM, Brock Tice wrote: > > We are currently handing out /52s to customers. Based on a reasonable > sparse allocation scheme that would account for future growth that > seemed like the best option. Could you detail the reasoning behind your allocation scheme? I.e., what are the assumptions you're making about customers deploying hardware? How will they need those devices isolated? What data fed the model you used to come up with those numbers? I ask because I have seen many ISPs advocate for smaller than /48 customer allocations, but I haven't seen anyone present the model they used to come up with those numbers. I really am curious to know the assumptions and rationale behind the various allocation schemes ISPs are coming up with. > I can't really see how /52 is too small for a residential customer. I > know originally it was supposed to be /48 but after doing a bit of > reading I think many people have admitted there is room for nuance. What reading? Can you provide pointers to the documents you were reading? Again, I'm curious to understand how and why ISPs are making these decisions. Also, the fact that you "can't see it" doesn't mean they (or someone else) can't or won't. An ISP's job is to shovel packets around. No more, no less. > Do you think I could go to ARIN and say, well, we haven't used hardly > any of this but based on such-and-such allocation scheme, it would be > much better if you gave us a /32 instead of a /36? Hardly used any of what? Are you talking about density of the customer hosts inside each of these /64 subnets? This is where I think the biggest misunderstandings of the IPv6 allocation strategy comes from. Ask yourself this: do you think the intention was to have 2^64 hosts on a single LAN segment? Can you imagine any practical switch fabric that could handle that? (I'd be curious to know the size of the largest - in the number of hosts sense - 10-Gig Ethernet LAN anyone has deployed.) The number of hosts per /64 will always be limited by the associated switch hardware. This will be true until the universe collapses, I suspect. > Also, does anyone know whether ARIN is using sparse allocation, such > that if we go back later and ask for more they will just increase the > size of our allocation starting from the same point? You could just ask them. But the policies for ISP allocations (last time I read them) makes it pretty straight forward for you to get a block that fits your growth needs for the foreseeable future.† But really, if you are worried about having to advertise, say, eight IPv6 prefixes to the DFZ for all your allocations, haven't you just argued against the fragmented /52 allocations to your downstream customers? You need to treat IPv6 addresses as being 64 bits long. Those extra 64 bits on the right are just noise – ignore them. Instead, think about how we can carve up a 2^61 address space (based on the current /3 active global allocation pool) between 2^32 people (Earth's current population), each having 2^16 devices, needing their own network. That makes for a densely allocated /48 for each person on the planet. (Coincidence?) But when we get to the point of filling up that /3, we still have five more /3s to work with. Now think about scaling. If the population doubles, we're now down to four spare /3s. If that doubled population doubles the number of devices, we're down to two spare /3s. If the population doubles again, there will be no civilization left, let alone an Internet. Etc. So realistically, the current address space allocation policies can handle a doubling of the planet's population, with each person having a quarter of a million addressable nodes. Each node having its own /64 to address individual endpoints within whatever that 'node' represents. Just think, 2^64 port-443 HTTPS servers per "thing." Isn't this the utopia we've been seeking out? I'm pretty confident IPv6 as a protocol (and, really, IP as a networking concept) will be dead *long* before we run out of address space. Not because we run out the numbers of bits allocated to hosts, or subnets, or ports; but because the current topology of routed networks won't fit with what we want or need to do in the future. (My prediction is that everything will move to adhoc meshes, with no control planes at all. But that's completely out of scope for this discussion.) --lyndon † https://www.arin.net/resources/ipv6_planning.html states that ISP allocations for > /32 block sizes is based on a /48 per customer site allocation policy.
Re: Waste will kill ipv6 too
> On Dec 28, 2017, at 2:31 PM, Thomas Bellman wrote: > > My problem with the IPv6 addressing scheme is not the waste of 64 bits > for the interface identifier, but the lack of bits for the subnet id. > 16 bits (as you normally get a /48) is not much for a semi-large organi- > zation, and will force many to have a dense address plan, handing out > just one or a few subnets at a time, resulting in a patch-work of > allocations. 24 bits for subnet id would be more usable. If you need (and can justify) more than a site /48, you can easily get that. > > Consider e.g. a university or company campus. There are probably at > least 16 departments, so I would like to use 8 bits as department id. > Several departments are likely to have offices on more than one floor, > or in more than one building, so I would like to let them have 4 bits > to specify location, and then 8 bits to specify office/workplace within > each location. And allow them to hand out 16 subnets per workplace. > That adds up to 24 bits. So a /40 would be nice, not a /48. IPv6 prefixes are not databases. Coding this sort of thing into your address space is silly. You can (and should) track this info externally. It's pretty simple to do this using easily parsable text files. If you encode policy into your address space like this, sooner or later you will find yourself painted into a corner you can't get out of. Instead, carve up the 16bits of subnet space by allocating network bits from left-to-right. This gives you the ability to slice your subnet space into variable-length allocations. When you allocate in the subnet space, do so by bisecting the current network prefix. That gives you room to grow your /64s into something larger, while keeping the routing simple. This is the same thing we've been doing to carve up IPv4 space for years: number hosts right to left, number networks left to right. For IPv6, just s;hosts;/64s;. --lyndon
Re: Suggestions for a more privacy conscious email provider
> On Dec 4, 2017, at 3:19 AM, Edwin Pers wrote: > > As an anecdotal aside, approx. 70% of incoming portscanners/rdp bots/ssh > bots/etc that hit the firewalls at my sites are coming from AWS. > I used to send abuse emails but eventually gave up after receiving nothing > beyond "well, aws ip's are dynamic/shared so we can't help you" Last week we found out that Helpscout sends email from AWS servers. Thank you, Helpscout, for forcing me to lift the AWS blocks on my incoming MTAs, that were cutting down my incoming spam scanning load by a factor of two. At least. Note that I work for an email hosting company, which makes this infinitely more annoying. A factor of two, in this case, is a non-trivial number. --lyndon
Re: RFC 1918 network range choices
> On Oct 5, 2017, at 4:52 PM, Steve Feldman wrote: > > I have a vague recollection of parts of 192.168.0.0/16 being used as default > addresses on early Sun systems. If that's actually true, it might explain > that choice. 192.9.200.X rings a bell; but those might have been the example addresses they used in the SunOS 3.X documentation.
Re: Hurricane Maria: Dominica partial communications restored
> On Sep 20, 2017, at 6:40 PM, Sean Donelan wrote: > > Some ham radio operators have been verified as operating from Dominica. Its > an unfortunate, but necessary thing that needs to be verified during disaster > communications. I'm not clear what you're getting at here. Are you saying people are faking operating from the islands? That seems unlikely. Basic RDF is going to tell you in short order where they are transmitting from. And for the smaller islands, the local operators are well known in the region, so it seems unlikely someone would be able to set up shop in, say, Tennessee and claim to be a new ham who just moved to Anguilla last week. --lyndon
mailops https breakage
> On Aug 27, 2016, at 6:46 PM, Matt Palmer wrote: > > On Sat, Aug 27, 2016 at 01:25:42AM -, John Levine wrote: >> In article >> you >> write: >>> I was working within the limits of what I had available. >> >> Here's the subscription page for mailop. It's got about as odd >> a mix of people as nanog, ranging from people with single user linux >> machines to people who run some of the largest mail systems in >> the world, including Gmail: >> >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > I know they're mailops, and not tlsops, but surely presenting a cert that > didn't expire six months ago isn't beyond the site admin's capabilities? I tried again, ten months later. Still broken :-( Is there a replacement site I'm missing out on?
Re: SHA1 collisions proven possisble
> On Feb 23, 2017, at 6:10 PM, Ricky Beam wrote: > > When you can do that in the timespan of weeks or days, get back to me. Stop thinking in the context of bits of fake news on your phone. Start thinking in the context of trans-national agreements that will soon be signed by such keys. --lyndon
Re: Canada joins the 21st century !
Canada should just have Comcast (or is it "Xfinity"?) provided nation-wide Internet service as a for-profit monopoly. Just as long as we have *someone* to Telus whom to chose.
Re: Legislative proposal sent to my Congressman
> On Oct 3, 2016, at 6:52 PM, Lyndon Nerenberg wrote: > > It's the closed software that is fscking everything up right now. A little > sunshine on the code base will go a long way towards those people not losing > their Ferrari's after all. Or coming from a more legalistic view, if they lock things down that hard, they cannot possibly blame anyone else for having "rooted" the gear, therefore no passing the buck. They would have to admit that it was their - and only their - code that was responsible for inflicting the damages. I've been in the tech biz for 30+ years, and have worked for a wide range of organizations over that time. The only common denominator across them all (small, large, and everything between - commercial and not) is that rapid response high level organizational change ONLY happen when the executives see the possibility of an imminent, significant, personal loss. That might be monetary loss, or loss of reputation. But it must be personally hurtful. When the reaper appears on the horizon, it's amazing how quickly they see the path to redemption. The sooner we all admit this is not a *technical* problem, the sooner we will eradicate it. --lyndon
Re: Legislative proposal sent to my Congressman
> On Oct 3, 2016, at 6:33 PM, Matthew Petach wrote: > > If you hold the executives of the hardware manufacturer > responsible for the software running on their devices, > then the next generation of hardware from every > manufacturer is going to be hardware locked to > ONLY run their software. No OpenWRT, no Tomato, > no third party software that could be compromised > and leave them holding the liability bag. It's the closed software that is fscking everything up right now. A little sunshine on the code base will go a long way towards those people not losing their Ferrari's after all.
Re: Legislative proposal sent to my Congressman
> On Oct 3, 2016, at 5:39 PM, Jay R. Ashworth wrote: > > You're not familiar with CPSC mandatory recalls, are you? I'm not sure how you could make the case that a compromised DVR, e.g., directly creates a risk of physical injury to a person. Without that, I don't see how the CPSA would apply. But even if a mandatory recall was made under some law, how many of those devices do you think would be returned/exchanged, realistically. And what percentage of those devices would fall under the jurisdiction of any one country's laws? The only way to stop this sort of thing once and for all is to make it punitively costly to the humans at the helm of the corporations selling this crap in the first place. Under corporate law, this almost always means the directors. Only when they start losing their homes/yachts/Jaguars, or start spending some quality time in jail, will this problem go away. Of course, this does require governments to grow some balls :-P --lyndon
Re: Legislative proposal sent to my Congressman
This is where device profiles could help. If enough devices register profiles with the local router, at some point the router's default could be closed, so devices with no profile can't talk to the outside. That would be nice, but a manufacturer who can't be bothered to take even the most basic security precautions certainly isn't going to implement this, either. The only cure to this will be changing the law so that the directors of the companies that ship massively insecure devices like these are personally liable for all the financial loss attributed to their products. Bankrupt a few companies' board of directors and you'll start seeing things change in a hurry. --lyndon
Re: Legislative proposal sent to my Congressman
But that does not remove those devices from the network. That ship has sailed.
Re: Legislative proposal sent to my Congressman
In thinking over the last DDos involving IoT devices, I think we don't have a good technical solution to the problem. Cutting off people with defective devices they they don't understand, and have little control over, is an action that makes sense, but hurts the innocent. "Hey, Grandma, did you know your TV set is hurting the Internet?" The way this will get solved is for a couple of large ISPs and DDoS targets to sue a few of these IoT device manufacturers into oblivion. --lyndon
Re: Kudos to Rogers Wireless on IPv6 deployment
> On Oct 1, 2016, at 8:37 PM, Hugo Slabbert wrote: > > So, kudos, Rogers Wireless! This has also been live on Roger's Fido sub-brand for a while now, too. 2605:8d80:484:: is live in Vancouver. --lyndon
Re: Chinese root CA issues rogue/fake certificates
> On Aug 31, 2016, at 6:36 PM, Matt Palmer wrote: > > Thanks, Netscape. Great ecosystem you built. Nobody at that time had a clue how this environment was going to scale, let alone what the wide-ranging security issues would be. And where were you back then, not saving us from our erroneous path ... signature.asc Description: Message signed with OpenPGP using GPGMail
yahoo mta admin help needed
Is there a Yahoo MTA admin listening who can help diagnose what might be a network ACL block to one of our SMTP server subnets? Thanks, --lyndon
Re: Netflix VPN detection - actual engineer needed
> In other words, it's not just Netflix that has this problem... No, it's Netflix that has the problem. Audible actually gives a fuck about their customers.
Re: Netflix VPN detection - actual engineer needed
> 1. C-band teleport in Singapore with SingTel IPs, remote terminals in > Afghanistan. > > 2. Ku-band teleport in Germany with IP space in an Intelsat /20, remote > terminal on the roof of a US government diplomatic facility in > $DEVELOPING_COUNTRY > > 3. Teleports in Miami with IP space that looks indistinguishable (in terms > of BGP-adjacency and traceroutes) from any other ISP in the metro Miami > area, providing services to small TDMA VSAT terminals in west Africa. > > 4. Things in Antarctica that are on the other end of a C-band SCPC pipe > from a large earth station in southern California. > > 5. Maritime Ku and C-band VSAT services with 2.5 meter size 3-axis tracking > antennas on top of cruise ships that could be literally anywhere in the > Mediterranean or Caribbean oceans, with the terrestrial end of the > connection in Switzerland, Italy, Maryland or Georgia. > > 6. Small pacific island nations that have no submarine fiber connectivity > and are now using o3b for IP backhaul, or C-band connectivity to teleports > in Australia. Yes. All big Netflix customers.
Re: Netflix VPN detection - actual engineer needed
> On Jun 3, 2016, at 4:59 PM, jim deleskie wrote: > > I don't suspect many folks that are outside of this list would likely have > any idea how to set up a v6 tunnel. Those of us on the list, likely have a > much greater ability to influence v6 adoption or not via day job > deployments then Netflix supporting v6 tunnels or not. In western Canada, Telus is on a big push to deploy IPv6. TekSavvy less so. But it's happening. I cancelled my Netflix subscription last summer. I needed native IPv6 more than I needed Grace and Frankie. Which isn't to say I didn't want to watch Grace and Frankie more than having IPv6 access to machines I need to have access to in order to earn the money I need to pay to (not) watch Grace and Frankie ... --lyndon
Re: NIST NTP servers
[...] but I would also have doubts over running anything business critical on a RP2. We use them as reverse terminal servers, for dhcp/tftp bootstrapping other machines, and soon, NTP. They are absolutely rock solid. There's something to be said for "no moving parts inside." --lyndon
Re: NIST NTP servers
> On May 11, 2016, at 5:42 PM, Scott Weeks wrote: > > Wouldn't the buffers empty in a FIFO manner? They will empty in whatever order the implementation decides to write them. But what's more important is the order in which the incoming packets are presented to the syslogd process. If you're listening on TCP connections, the receive order is very much determined by the strategy the syslogd implementation uses to read from FDs with available data. I.e. elevator scan, lowest/highest first, circular queue, ... In a threaded implementation, your reader workers, buffer writers, etc., are all at the mercy of the threading implementation; it's difficult to control thread dispatch ordering at that level of granularity. --lyndon
Re: remote serial console (IP to Serial)
I'd get something like a 1U ATOM server ($120 eBay) with small SSD ($18). Runup your favorite FOSS OS, and conserver. For more than the single real serialport, you can most likely fit a USB hub inside the case still, and hang a number of USB serial dongles off. We use Raspberry Pi 2s with single- and 8-port USB serial dongles. Works like a charm, especially with tmux installed. --lyndon
MACsec to edge hosts
Are any of you pushing MACsec (802.1AE) out from your switches to the edge hosts? Vs. just running it on the network cross-connect fabric? We have a scenario where, if we could MACsec encrypt those (switch <-> host) links, we could eliminate a lot of application level TLS. But searching for a list of PHYs that support this turned up a very thin set of chips, with most of them being several years old now. Are people even using MACsec in anything other than an "encrypt cross connects between the cages" context? I would be very interested in chatting with anyone who has tried pushing this out from their switches to the connected hosts. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Staring Down the Armada Collective
On Dec 3, 2015, at 9:14 PM, Lyndon Nerenberg wrote: > I should also mention that, despite their bluster, they can't keep it up for > more than half an hour. The mailing list has been quiet. All step forward who are scared to say "me too" on account of Armada. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Staring Down the Armada Collective
On Dec 3, 2015, at 6:28 PM, Lyndon Nerenberg wrote: > Are we perhaps, finally, reaching the cusp where everyone has realized that > if we all, collectively, tell the rodents to f*** off, they just might? I should also mention that, despite their bluster, they can't keep it up for more than half an hour. By then, the upstream networks have figured it out and have null routed anything of consequence - far upstream. Meanwhile, back haul your traffic in via a private network and they won't be able to do shit to you. (E.g. the standard Cloudflare model.) They are not as smart as they make themselves out to be. Don't let fear drive your decisions. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Staring Down the Armada Collective
Typically, businesses hide from admitting they've been hit by drive-by attacks like Armada is trying to pull off. It has been interesting to see the public reaction from the post-Protonmail targets, many of whom are being very visible about 1) admitting they have been hit by the attacks, and 2) making it very clear the Armada crew can f*** right off as far as collecting ransom is concerned. (Also, 3) the amazing support from customers who understand why we are working on putting up defences instead of just paying, and therefore put up with the inevitable downtime as we reconfigure sometimes large chunks of our networks.) The money asked for was a pittance (around USD$6K) for the attacks I'm personally aware of. The targeted were willing to spend far in excess of that to deploy the necessary wall of DDoS protection to keep their services running. If they didn't have it there, already. What does that say for the business model of the botnet handlers? They can't up their ransom demands, because nobody is paying at the current rates. And they can't lower them, for the same reason. And if they change their targets to sites than might potentially pay a few hundred dollars at best, those sites will just shut down anyway. Are we perhaps, finally, reaching the cusp where everyone has realized that if we all, collectively, tell the rodents to f*** off, they just might? Happy Holidays! --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Ransom DDoS attack - need help!
On Dec 3, 2015, at 5:00 PM, alvin nanog wrote: > run tcpdump and/or etherreal to capture the DDoS attacks Of course! If we had only thought of this sooner! :-) --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Ransom DDoS attack - need help!
Afaik, the DDoS is "only" a UDP based one (or much of the attack), you should be able to mitigate some to much of the damage caused by filled pipes by blocking incomming UDP trafic at your ISP level. This is the Armada Collective, based on the description. We just went through a round with them. The hardest they were able to hit us peaked at a little under 80 Gbits/second. Primarily DNS and NTP amplification attacks. They also hit our web servers with a little over 80 million requests over a one hour period, and played some games with TCP to try to mess with the protocol stacks on the servers and network gear. Cloudflare took care of the web attacks. For DDoS, something like Incapsula will take care of the layer 3 stuff. Not cheap, but very effective. --lyndon
Re: ARIN IPV4 Countdown
On Jul 14, 2015, at 7:26 PM, valdis.kletni...@vt.edu wrote: > But.. But... How does that work without using UPNP? :) SHOUT LOUDER! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Dual stack IPv6 for IPv4 depletion
On Jul 14, 2015, at 11:56 AM, Tony Hain wrote: > IPv6 is not the last protocol known to mankind. IF it burns out in 400-500 > years, something will have gone terribly wrong, because newer ideas about > networking will have been squashed along the way. 64 bits for both hosts and > routing was over 3 orders of magnitude more than sufficient to meet the > design goals for the IPv4 replacement, but in the context of the dot-com > bubble there was a vast outcry from the ops community that it would be > insufficient for the needs of routing. So the entire 64 bits of the original > proposal was given to routing, and the IETF spent another year arguing about > how many bits more to add for hosts. Now, post bubble burst, we are left > with 32,768x the already more than sufficient number of routing prefixes, > but "IPv4-think" conservation believes we still need to be extremely > conservative about allocations. If you look at how the IoT model is evolving, the entire host+service (i.e. IP address + port number) model is rapidly disintegrating. Services are the end-points now. They need to be individually addressable, since they really have no affinity to physical hardware in the sense we currently think of "hosts," with IP and MAC addresses. Host hardware is fungible; services are mobile. The IPv6 address space conservatives are missing the entire point that IPv6, as a global addressing scheme, will collapse in the next couple of decades. Host+port endpoint identifiers are already done. We just haven't noticed yet. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ARIN IPV4 Countdown
On Jul 14, 2015, at 6:33 PM, Curtis Maurand wrote: > Since IPV6 does not have NAT, it's going to be difficult for the layman to > understand their firewall. deployment of ipv4 is pretty simple. ipv6 on the > otherhand is pretty difficult at the network level. yes, all the clients get > everything automatically except for the router/firewall. Are we *still* doing this argument?!? block all pass out on $extif keep state Is it that fucking difficult for people to figure out? Really? signature.asc Description: Message signed with OpenPGP using GPGMail
Re: another tilt^2 [real numbers]
For a bit of fun, the results after 30 minutes of https://orthanc.ca/figure-1 being out on the nanog list: IPv4: 315 IPv6: 22 This is strictly GETs on the target page, not tainted by CSS or favicon nonsense. I don't know what this says about the proclivity of Nanog readers to blindly click on email URLs. (But the delineation between web and MUA email client user behaviours is ... interesting ...) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: another tilt at the Verizon FIOS IPv6 windmill
On Jul 13, 2015, at 1:57 PM, Mel Beckman wrote: > David, > Did you consider running an IPv6 tunnel through HE.net? Tunnels work, but they really are getting old. I have run 3ffe:: 6bone, HE tunnels, and (currently) aiccu. They all work very reliably, and I have immense gratitude towards the people who commit the time, the hardware, and the software, to making that go. But the bottom line is that 200+ms RTTs to my servers over v6 tunnels simply can't compete with 20ms RTTs on native v4. I know my code works over v6, but how can I ever know it works well when I'm behind a v6 dialup link? This past weekend I bit the projectile and decided to flip my service over to Teksavvy. The latter have native v6, claim to offer /48s, and have the audacity to charge me $10/month less than Telus. I'm game. More importantly, after eight years of Telus promising an IPv6 beta, I can tell them to see https://orthanc.ca/figure-1 :-P --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Thoughts On Cheap Chinese xDSL Testers
I've been poking around looking for an inexpensive xDSL circuit tester to do some measurements on my home DSL line, in opposition to the telco. $2K+ is not in the budget, so I'm curious about the accuracy of the $300 Chinese units kicking around eBay (e.g. the ST332B). Anyone out there have experience with them? Are they even remotely close to accurate? --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ARIN just subdivided their last /17, /18, /19, /20, /21 and /22. Down to only /23s and /24s now. : ipv6
On Jun 27, 2015, at 5:35 AM, Rafael Possamai wrote: > How long do you think it will take to completely get rid of IPv4? Or is it > even going to happen at all? IPX ruled the roost, very popularly, for a little while. How long did it take to die? Why did it die? What were the triggers that pushed it over the cliff? I think there's a lot to be learned from that piece of recent history. Specifically, as a demonstration of how a "most popular" protocol can find itself ejected from the arena in the blink of an eye. I knew several people who built their career path on the assumptions of IPX. Ouch. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Residential VSAT experiences?
On Jun 22, 2015, at 5:27 PM, Scott Weeks wrote: > I do SSH over geostationary satellite links (C-band) all > the time. I'd say it's slow, but not excruciating, unless > you type really fast on the network device's CLI. :-) SSH client/server authors would do well to learn the lessons of telnet line mode. As would authors of 'interactive' command line applications. The NVT concept is still useful in this day and age, far beyond the LA36. (I.e., if the termcap entry says 'dumb', honour it. There is a damn good reason we are saying 'turn off the bling'.) --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: DMARC in education
> What problem do you expect this to solve? This is a real question, > since you can be 100% sure that any DMARC policy will wreak havoc on > any of your users who use mailing lists like this one. *Any* mailing list. Please help stamp out this abomination by refusing to capitulate to its insane desire to pretend the last three+ decades of email functionality never existed. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Android (lack of) support for DHCPv6
On Jun 11, 2015, at 9:06 PM, Karl Auer wrote: >> You don't get to just say "I'm not going to implement this because I don't >> agree with it," which is what Google is doing in the case of Android. > > Actually, you DO get to just say that. Anyone can, but especially > something as big as Google. And if DHCPv6 turns out to be important > enough to enough people, Android will lose market share and either fork, > die or change its mind. It wouldn't be the first mobile platform to > disappear into the sludge of history. Sadly, there is another side to this. Witness how the DMARC crew are destroying the functionality of email as we have known it for decades. Sometimes the 800 pound gorillas DO have the ability to fsck things over for everyone. --lyndon P.S. But it is the mindless-sheep-like behaviour that lets them. So instead I should be complaining to the masses who are incapable of thinking for themselves? We know how well *that* works ... signature.asc Description: Message signed with OpenPGP using GPGMail
Nobody is looking for serious candidates
On Jun 10, 2015, at 8:39 PM, Stephen Satchell wrote: > After the phone screen, the company called me in for the face-to-face > "interview". I put the word "interview" in quotes because, for 25 minutes, > the chief programmer of the place played a video game he wrote. That was the > extent of the interview! Mmm hmm. E.g. I spent half+ an hour being grilled on the internals and efficiencies of various regular expression library implementations. '[a-z]' vs. '[:islower:]' or something equally irrelevant to the interview at hand, for a position creating/managing the kernel - not apps - for an email spam filtering appliance. The second half hour devolved into a rant by the interviewer about 'volatile' in whatever was the latest version of the ANSI C standard. You can have a lot of fun, though, by playing the interviewers. When you discover your interest in the company is a noop, steering things into the Brazil regime can generate endless entertainment ;-) In fact, fishing for silliness can produce plenty of results. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: eBay is looking for network heavies...
On Jun 10, 2015, at 11:18 AM, goe...@anime.net wrote: > Indeed, the interview process is a two way street. Lets you evaluate who you > would be working for -- or if you really would want to. I wrote most of a very long follow-up to this. But what it boils down to is: +10,000 For all of you sitting across the table, consider that you are being interviewed even more intensely than you think you are interviewing us. (By anyone who has been in the game for a while, at least. Which means the people you have short-listed, right?) Over the past 25 years or so, I can think of a half-dozen offers I've turned down because the employer failed the interview. (Which doesn't make me a geeenious ... just someone who values low blood pressure, and prefers an interesting work environment over $$$) --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Android (lack of) support for DHCPv6
Where is Mr. Protocol? When we need him most?! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: symmetric vs. asymmetric [was: Verizon Policy Statement on Net Neutrality]
On Feb 28, 2015, at 7:17 PM, Barry Shein wrote: > I remember when downloading still images (dial-up days) was considered > bandwidth hogging and only something very few people did. Of course no > one did it, it took minutes to download even a rather small image and > there was little market for image-oriented software (other than porn.) That was 1992-4ish? I helped spin up early ISPs back then. The traffic analysis we did at the time showed the porn crowd came out after dark and left at sunrise. And they were facing self-limiting servers that could not keep up with the demand anyway, so the 'average' customer base wasn't affected. This crossed a pair of ISPs each backed by a single T1 trunk to "the internet" and two T1 channel banks for the dialup pool. Not quite "The World" but it was big time stuff for where we were. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Verizon Policy Statement on Net Neutrality
> In my part of the world, a well-known service provider runs FTTC and > then runs VDSL into the home. Ummh... I live in a 3rd word country. Oh Canada! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Verizon Policy Statement on Net Neutrality
On Feb 28, 2015, at 5:24 PM, Stephen Satchell wrote: > (N.B.: "we forced long TTLs to reduce the traffic necessary across our > peering points." At one point, the cable people said they had one, > count 'em one, peering link at 44 megabits/s, to serve all cable > companies [with their own internal network]. I still don't know whether > to buy that or not, and now it's moot.) Who was the late-90s ISP that had their "geek" mouthing off on TV about them having "multiple T3's to the Internet" ??? It was a very well done commercial. I remember having a good laugh at how it parodied both ends of the "internet pipe" of the time. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Verizon Policy Statement on Net Neutrality
On Feb 28, 2015, at 4:37 PM, Jack Bates wrote: > The question is, if YOU paid for the fiber to be run to their ped, would they > hook you up? No. But that's because they are using the fibre pedestals to deliver a high bandwidth DSL service. The condo customers still get DSLon copper, but because the copper pipe is so short they can crank a hell of a lot of bps over it. Enough to deliver HDTV, at whatever compression rate they use to their set top boxes. It's way more then the 5 Mb/s up/down (S)DSL I would be quite happy with :-) --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Verizon Policy Statement on Net Neutrality
> It's not about "that's all they need", "that's all they want", etc. Whenever any vendor spouts "this is what our customers want" you know they are talking pure bullshit. The only customers who know what they "want" are the microscopic percentage who know what's actually possible, and we are dismissed as cranks. Even though they keep hiring us to run their networks. In the spirit of adding real data to the symmetry conversation, let me describe why I would prefer symmetric. Currently I have all-copper DSL running at 3 Mb/s down and about 640 Kb/s up. There are days I wish I had 1.5 Mb each way, as there are times when I need to push large files out (well in excess of 1 GB each). Doing that now is painfully slow, but I can live with the long transfer times because I'm not doing it every day. Where it is painful is how the clogged pipe breaks other things. The big one is my SIP phone service. Because the ACKs on the file upload come back faster than the data can leave, it's almost impossible to avoid queueing delays in my border router, despite it being a real UNIX box vs. a cheap appliance NAT router with buffer bloat. TCP doesn't deal well with the asymmetry, so the only way to address this is to drastically reduce the sendspace window on my uploading box in order to throttle it back to where TCP's flow control works as designed. So do I hack FTP and ssh on my machines to take a command line option to squash the sendspace? Or worse, do I use the existing knobs to turn sendspace down for the entire host? Neither one is pleasant, and I shouldn't have to implement either. Having a DSL link that allocated bandwidth based on real-time need would solve this for me. But since that's not an option, converting the link I have from ADSL to SDSL would solve my problem. I would gladly trade in a portion of my downstream *bandwidth* for a corresponding reduction in my upstream *latency*. And I suspect a lot of those bullshitting ISPs would find this is "what our customers want" if their customers ever learned that it is this asymmetry that underlies many of their perceived performance issues. Mind you, the truly annoying part of this story (for me) is knowing Telus has fibre pedestals not a block away, with enough bandwidth to serve up IPTV to all the condos in the neighbourhood. But I'm in the marina across the street. Since there are only a handful of us here with service of any sort, they aren't about to come out and reroute us to the fibre pedestal. So I get to stay on the very long and corroded copper circuit back to one of the original downtown Vancouver exchanges. As one of the Telus techs said when he came out to help troubleshoot a failing DSL modem: I am amazed it works at all :-) And he's right -- the dB line losses are horrific. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
protection.outlook.com SMTP support contact needed
I'm running into TLS interoperability problems with some of the SMTP servers under the inbound.protection.outlook.com domain. Are there any Outlook postmasters lurking here that could contact me off list to help debug this? Thanks, --lyndon
Re: Craigslist hacked?
On Nov 23, 2014, at 8:51 PM, Randy Bush wrote: > and what tasty things did the hijacker's web site serve? Firefox on my Mac started acting very strangely after encountering one of the 'unresponsive' versions of craigslist.ca. Apparent browser hangs, javascript script timeouts, and odd things related to the browser history. I restored ~/Library/Application\ Support/Firefox from a Time Machine snapshot taken just before the Craigslist hack, and all appears fine now. I have to diff between the two versions of that directory before I claim the website hack had anything to do with it, but for now Mac Firefox users might want to be wary ... (Note: Mac OS 10.9.5 and Firefox 33.1 are what I was running.) --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Craigslist hacked?
On Nov 23, 2014, at 7:41 PM, Brian Henson wrote: > Is anyone else seeing their local craigslist redirected to another site > other than craigslist? I see it loading http://digitalgangster.com/5um. *.craigslist.ca and *.craigslist.org have been offline since about 16:40 Pacific Standard Time from at least three different networks I have access to. From the limited poking around I've done it looks like it could be a DNS hijacking. I haven't seen anything about it on the outages list yet ... --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: cheap laptop with 32G or 64G recommendations
On Nov 10, 2014, at 4:24 PM, Izaac wrote: > If you're stuck working in a completely isolated environment, then work it > into the contract. That's the cost of being on an island. This is the argument being made against all the citizens who have the temerity to live in British Columbia, yet not within the borders of a sanctioned municipality. Izaac, spend a year getting shot at in Surrey, then get back to us. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Urgent
On Aug 18, 2014, at 3:05 PM, Randy Bush wrote: > the request message was a forge, see below. damned shame i did not > think of it, though. otoh, i consider the contact requests useful. You just blew an opportunity to get on every north american late night talk show. Oh ... (sorry) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Verizon Public Policy on Netflix
On Jul 14, 2014, at 5:39 PM, Matt Palmer wrote: > I assume that there's a leopard involved there somewhere? It's noodling around in the disused lavatory with Moaning Myrtle. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Canada and IPv6 (& DNSSEC)
On Jun 20, 2014, at 6:24 AM, Jacques Latour wrote: > Just as an indicator, we have 316 .ca domains with IPv6 glue records :-( Part of the problem might be that two of the bigger registrars (Webnames and easyDNS) *still* can't handle input of IPv6 addresses in their management panels - you have to initiate a support request and have them enter the records manually. And neither ca do a zone transfer from an IPv6-only master. I tried a little experiment a couple of months back. I set up a new domain, IPv6 only - not an A record in sight, including for the name servers. I then tried getting the name servers and glue records registered, first through Webnames, then through easyDNS. Both required manual intervention to set this up. I then tried using their secondary DNS services to add them as additional slave servers. Neither of them is capable of providing secondary DNS to an IPv6-only domain. In both cases, they can only initiate an xfer against an IPv4 master. Given the current state of affairs with the registrar infrastructure, it doesn't surprise me one bit those numbers are so low. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: OpenNTPProject.org
On Feb 16, 2014, at 8:30 PM, Christopher Morrow wrote: > and good luck with figuring out: > 1) when you need to re-do that magic move > 2) making sure that the move is automatable over time I was suggesting it as an alternative to just chopping off NTP at your border. Presumably it would be a one-off thing until Juniper issues a patch. As for automating it, 'expect' can be a very useful tool in situations like this. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: OpenNTPProject.org
On Feb 16, 2014, at 7:59 PM, Mark Tinka wrote: > Juniper's Junos implementation (which is based on FreeBSD) > hasn't been patched > > Using firewall filters is the only way to mitigate the > vulnerability. But doesn't the JunOS ntpd read/parse ntpd.conf? It's worth getting to the admin mode shell prompt and taking a poke around /etc. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic
On Nov 1, 2013, at 7:18 PM, Mike Lyon wrote: > So even if Goog or Yahoo encrypt their data between DCs, what stops > the NSA from decrypting that data? Or would it be done simply to make > their lives a bit more of a PiTA to get the data they want? Markhov chain text generators are cheap. Rather than amping up the crypto, why not bury them under heaping piles of steaming bullshit? After all, it would be the patriotic thing to do. Not only would you be helping employ your fellow network engineers (someone has to increase the size of the effluent pipes), you would be boosting manufacturing (disks for storage, high-end network gear for capture, mainframes and asics for filtering and analysis) and helping the much-maligned coal industry ensure its future prospects (that gear isn't built from electron sipping Atom CPUs, you know!). --lyndon
Re: Assistance for Eavesdropping Legally on Avian Carriers (AELAC)
On 2013-06-25, at 8:54 PM, Jason Hellenthal wrote: > Anyone got a pentagram packet and a weje board ? Be careful, when you pull out the chalk to draw a pentaGRAM around your data centre, that you don't – accidentally – draw a pentaGONE.
Re: Assistance for Eavesdropping Legally on Avian Carriers (AELAC)
On 2013-06-25, at 8:24 PM, "Caruso, Anthony" wrote: > Yes, if you can identify the source of the grains, you know origin and flight > path prior to your lawn. NSA approach's is getting the pigeon shit off of > everyone's lawn... Then I am in favour of PRISM. NSA: come vacuum all the pigeon shit off my boat! Please!!!
Re: Assistance for Eavesdropping Legally on Avian Carriers (AELAC)
On 2013-06-25, at 7:58 PM, Sean Donelan wrote: > The memo provides an overview and principles regarding Lawful Intercept(LI) > of networks using RFC 1149, "A Standard for the Transmission of IP Datagrams > on Avian Carriers." National requirements are not addressed. Is scooping pigeon shit off my front lawn considered meta-data collection? --lyndon
Re: why haven't ethernet connectors changed?
On 2012-12-20, at 12:13 PM, Michael Thomas wrote: > Do these > things need to have gig-e speeds? Probably not... for a lot even Bluetooth > speeds > are probably fine. But they do want to be really small and really inexpensive. Then run RS-422 or RS-485 over a single twisted pair. You don't even need a connector – you can solder directly to the PCB. --lyndon
Re: Detection of Rogue Access Points
On 2012-10-14, at 14:56 PM, Matthias Waehlisch wrote: > do you mean http://conferences.sigcomm.org/imc/2007/papers/imc122.pdf > ? That's the one!
Re: Detection of Rogue Access Points
> I'm looking for innovative ideas on how to find such a rogue device, > ideally as soon as it is plugged in to the network. There was a SIGCOMM paper a few years back that described a scheme based on measuring the the ACK delays of TCP sessions. In a nutshell, you can detect nodes on the wireless network by looking for the extra delay added by the radio link. It had very good accuracy, and caught new nodes quickly. It didn't require any prior knowledge of the network. I don't have a copy of the paper at hand, and I don't remember the title/author or the publication date (2007ish?), but maybe this will ring a bell for someone else on the list who does. --lyndon
Re: Asia's Fastest Communications Cable Comes Online
On 2012-08-24, at 10:33 AM, valdis.kletni...@vt.edu wrote: > If you can use 3ms to extract enough money out of the market to pay for a > cable, that market is *way* too volatile in the first place. Heh. Think things are volatile now? Wait 'til they get it down to pico-payment based trading of quantum virtual particles. Oh, I have to nip down to the patent office ... --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Dear Linkedin,
It is far preferable for the merchant to request ID and verify that the signature matches the ID _AND_ the picture in the ID matches the customer. In the late 1990s I had a Visa card from (I think) Citibank that had my picture embossed on the front of the card. I'm surprised this didn't catch on with more card issuers. I see that Bank of America offers this free of charge to their Visa clients, as do some US based credit unions. That card was never lost or stolen, so I don't know if the photo verification would fail as spectacularly as signatures do. --lyndon
Re: Password safes &c. (was: Dear Linkedin,)
On 2012-06-08, at 2:07 PM, Andrew Sullivan wrote: > I'm not trying to be dismissive. Those are excellent stopgap > measures. They're not a solution. There is no "solution." Security is about risk management, nothing more. The only way to ensure your personal passwords are never compromised is to kill yourself after destroying all physical copies of those passwords. While ultimately secure, you won't be able to do your daily online banking. --lyndon
Password Safes
On 2012-06-08, at 1:41 PM, Michael Thomas wrote: > I run a website. If it can change it on mine, I'd like to understand > how it manages to do that. I log in to your website, change my password, and the software picks up that I've changed the password and updates the safe accordingly. The software doesn't initiate the password change, it just notices it and updates its database accordingly. Sorry, I should have explained that more clearly. If you have a Mac or a Windows box, download the 1Password 30 day trail and take it for a run. It really is a useful bit of software. No, it doesn't work on my *BSD, Solaris, or Plan 9 machines. But it does sync across all my Mac, Windows, and Android gear, and the Android client lets me pull up passwords on my phone when I'm on one of the systems that doesn't have a native 1Password client, or when I am on the road. --lyndon
Re: Dear Linkedin,
On 2012-06-08, at 1:22 PM, Michael Thomas wrote: > Does your password safe know how to change the password on each > website every several months? Yes.
Re: Dear Linkedin,
On 2012-06-08, at 1:02 PM, Scott Weeks wrote: > Only if you have an OS you have to pay for: apple or ms. I don't pay for them. $WORK pays for them. If you're complaint is about 1Password not running on your particular operating systems, then pick a solution that *does* run on your OS. There are several open source alternatives you can use.