Hello IPv6, Goodbye CGNs – Recent Discussions at a EU/Europol Meeting
Jan Zorz was recently invited to speak at a workshop held by the Estonian Presidency of the Council of the EU and Europol. Jan gave a well-received talk about how Slovenia widely deployed IPv6 and encouraged EU policymakers and law enforcement officials to do the same across Europe.
Per the press release, the workshop was “to address the increasing problem of non-crime attribution associated with the widespread use of Carrier Grade Network Address Translation (CGN) technologies by companies that provide access to the internet.”
With IPv4 address space depleting, CGNs have been widely implemented to conserve public IPv4 address space. In other words, many customers are sharing a single public IPv4 address that often also changes over time. Problems with sharing IP addresses (and therefore CGNs) are well outlined in RFC 6269: “Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on.”
CGNs also present a problem for law enforcement agencies looking to investigate and prosecute crimes online, as it’s much more difficult to narrow down the culprit. This workshop had several IPv6 experts speak of their experiences, partially on the assertion that IPv6 deployment would eliminate CGNs and once again Continue reading
CLI or API… Again (and Again and Again…)
Got this comment on one of my blog posts:
When looking at some of the CLIs just front-ending RESTAPIs, I wonder if "survival" of CLI isn't just in the eyes of the beholder.
It made me really sad because I wrote about this exact topic several times… obviously in vain. Or as one of my network automation friends said when I asked him to look at the draft of this blog post:
Read more ...Is my TPM affected by the Infineon disaster?
I made a tool to check if your TPM chip is bad. Well, it extracts the SRK public key and you can then use marcan’s tool to easily check if the key is good or bad.
Example use:
$ g++ -o check-srk -std=gnu++11 check-srk.cc -ltspi -lssl -lcrypto 2>&1 && ./check-srk
Size: 2048
Outputting modulus…
8490234823904890234823904823904890238490238490238490238490[…]893428490823904231
$ wget https://gist.githubusercontent.com/marcan/fc87aa78085c2b6f979aefc73fdc381f/raw/526bc2f2249a2e3f5d4450c7c412e0dbf57b2288/roca_test.py
[…]
$ python roca_test.py 8490234823904890234823904823904890238490238490238490238490[…]893428490823904231
Vuln!
(use -s if you have an SRK PIN)
If the SRK is weak then not only are very likely anything else you generated in the TPM weak, but also anything generated outside the TPM and imported is crackable, since your blobs are encrypted using this crackable SRK key.
How to Monkey-Patch the Linux Kernel
I have a weird setup. I type in Dvorak. But, when I hold ctrl or alt, my keyboard reverts to Qwerty.
You see, the classic text-editing hotkeys, ctrl+Z, ctrl+X, ctrl+C, and ctrl+V are all located optimally for a Qwerty layout: next to the control key, easy to reach with your left hand while mousing with your right. In Dvorak, unfortunately, these hotkeys are scattered around mostly on the right half of the keyboard, making them much less convenient. Using Dvorak for typing but Qwerty for hotkeys turns out to be a nice compromise.
But, the only way I could find to make this work on Linux / X was to write a program that uses X "grabs" to intercept key events and rewrite them. That was mostly fine, until recently, when my machine, unannounced, updated to Wayland. Remarkably, I didn't even notice at first! But at some point, I realized my hotkeys weren't working right. You see, Wayland, unlike X, actually has some sensible security rules, and as a result, random programs can't just man-in-the-middle all keyboard events anymore. Which broke my setup.
Yes, that's right, I'm that guy:
Source: xkcd 1172
So what was I to do? I began Continue reading
Think Of Your Audience
One of the challenges technical authors face is that of peer respect. That is, technical people who took a lot of time to learn what they know want to be respected by their peers when they write. They want to be recognized for their knowledge, wisdom, and insights.
In that context, there’s often fear before pressing “Publish.” Was every detail correct? Was every scenario considered? Was the very latest information about a topic included?
The fear of hitting publish is well-founded for technical authors, because technical folks have a way of being nit-picky, pedantic, and annoying. One small detail wrong, one badly stated premise, and the angry comment and critical tweet claws come out, slashing at your ego.
Will they like me? I just want everyone to like me.
One solution, of course, is to have a thick skin. If you view criticisms as a way to improve a piece, that’s the best route to go, especially when the commenter has a good point. Being able to ignore critics is another useful skill, because there are plenty of folks who say a lot while adding no value whatsoever.
However, I think the most important point to keep in mind Continue reading
Think Of Your Audience
One of the challenges technical authors face is that of peer respect. That is, technical people who took a lot of time to learn what they know want to be respected by their peers when they write. They want to be recognized for their knowledge, wisdom, and insights.
In that context, there’s often fear before pressing “Publish.” Was every detail correct? Was every scenario considered? Was the very latest information about a topic included?
The fear of hitting publish is well-founded for technical authors, because technical folks have a way of being nit-picky, pedantic, and annoying. One small detail wrong, one badly stated premise, and the angry comment and critical tweet claws come out, slashing at your ego.
Will they like me? I just want everyone to like me.
One solution, of course, is to have a thick skin. If you view criticisms as a way to improve a piece, that’s the best route to go, especially when the commenter has a good point. Being able to ignore critics is another useful skill, because there are plenty of folks who say a lot while adding no value whatsoever.
However, I think the most important point to keep in mind Continue reading
Cisco’s $1.9B BroadSoft Purchase Gives it a Telecom Cloud Services Edge
Cisco's latest acquisition follows its Perspica purchase announced last week.
Fujitsu Provides SD-WAN for Service Providers via Silver Peak’s Tech
It conforms with MEF’s SD-WAN terminology.
Alphabet’s Project Loon Delivers Internet in Puerto Rico
The balloon-based connectivity project is working with AT&T.
SK Telecom Pumps Up WiFi to Match 5G Speeds
The WiFi technology is expected to help support video consumption ... eventually.
BGPsec and Reality
From time to time, someone publishes a new blog post lauding the wonderfulness of BGPsec, such as this one over at the Internet Society. In return, I sometimes feel like I am a broken record discussing the problems with the basic idea of BGPsec—while it can solve some problems, it creates a lot of new ones. Overall, BGPsec, as defined by the IETF Secure Interdomain (SIDR) working group is a “bad idea,” a classic study in the power of unintended consequences, and the fond hope that more processing power can solve everything. To begin, a quick review of the operation of BGPsec might be in order. Essentially, each AS in the AS Path signs the “BGP update” as it passes through the internetwork, as shown below.
In this diagram, assume AS65000 is originating some route at A, and advertising it to AS65001 and AS65002 at B and C. At B, the route is advertised with a cryptographic signature “covering” the first two hops in the AS Path, AS65000 and AS65001. At C, the route is advertised with a cryptogrphic signature “covering” the first two hops in the AS Path, AS65000 and AS65002. When F advertises this route to H, at Continue reading