Deliver liquidity, multiple ledgers at a time please

The low friction cost of Bitcoin is an appealing parts of its proposition. You can send bitcoins at a fraction of the cost of traditional payment platforms. Now that user interfaces are improving and supported by more secure technologies such as TEE the overall usability of Bitcoin as a payment platform begins to look more and more appealing.

But results are lagging. One of the main reasons that is grinding the Bitcoin dream to a halt is the volatility of the cryptocurrency. The lack of a fixed exchange rate with fiat currencies makes for an unattractive proposition where any user could suddenly pay x% more or less for a product or service. As a payment solution, Bitcoin is undoubtedly a great alternative. But since it’ll never be pegged to the Euro, Dollar or any other fiat currency it’s potential remains unfulfilled.

Distributed ledgers such as Ripple allow fiat currencies, backed by gateways, to exist on the ledger and be transacted as if it was a cryptocurrency. While this appears to be a great solutions the challenge now lies in how to transfer these fiat currencies from the Ripple ledger to another ledger, say the Ethereum blockchain. In short: You can’t. You’ll have to redeem the funds at the gateway where they were issued, wire them back to your bank account and deposit them with a different gateway.

For now the promise of frictionless payments via distributed ledgers can only be fulfilled when the funds reside on one distributed legder and remain there. This scenario is unlikely to sustain given the diversity of altcoins that already exist and the progress of many fintech companies to offer new services based on this frictionless promise. This is especially true for smart contract-based blockchains, whose utility accelerates as soon as both the funds and the contract can be stored and transacted.

If we want distributed ledgers to exchange value we’ll need to look beyond gateways that only transact value to and from a distributed ledger. Exchanges already fulfill a service where cryptocurrencies can be exchanged but when it comes to transacting with the real world, everything slows down to the same crawl we’re already used to. Ideally the right to redeem funds from a certain gateway can be transferred to another ledger (for example with a smart contract), otherwise gateways would have to act as a means of transfer and the cost of liquidity on a distributed ledger becomes as high as they are today.

Distributed ledgers hold a frictionless promise when it comes to volatile cryptocurrencies. Only once we’re able to transact fiat currency in between blockchains this promise can be fulfilled. If not we’ll just be stuck with a bunch of ledgers that can’t exchange real world value amongst each other, much like the system we use today.


The impact of Blockchain Technology on Financial Transaction Platforms

I recently finished my thesis with the above mentioned title. For those interested please have a look at it here:

Default IP address and enable password of a Cisco 887V-W ISR router

This will probably be the case for other Cisco routers as well but for reasons unknown Cisco has decided to set an enable password on this router. The usual guessing (cisco, Cisco etc) didn’t work out so I had to break out the console cable and recover it as it didn’t seem to be documented anywhere.

It it c. Yes that’s just that one letter. The ip address was

Tele2 Fiberspeed VDSL with a Cisco modem

I have ordered Fiberspeed from Tele2, an affordable 50/5 VDSL connection. The modem is in but I’d like to hook it up to a Cisco router. I’ve ordered a 887VW that should do the job and used this hint to gain access to the setup of the Comtrend modem that Tele2 ships. The setup backup file reveals your PPPoE username and password although I suspect that they’re the same for everyone (username Comtrend, password Q29xxxxxxxxx). If this is indeed the case I’ll post them here later.

Update: Those settings indeed apply to every new modem shipped to a customer. However once connected it will download a new connection profile with your own PPPoE username and password in it which you’ll need to setup your Cisco router (or any other router for that matter). As of today the Tele2 Comtrend modem is still vulnerable to the hack listed in the link above so you should have no problem extracting the username and password. The username ends in and the password is encoded with base64 that you can safely decode here. Once you have this information it’s time to setup your Cisco router, I posted the required config lines here.

Using the Radius server in Mac OS X Server 10.6 for Cisco IOS WebVPN user and group authentication

One of my customers was looking for a simple WebVPN Cisco solution to replace his older EasyVPN. Goals were to increase security (by defining user groups and IP access lists) and ease deployment for external parties that needed to log onto the VPN. This posed the following problems:

– The Cisco router that was used (a 1921) only supports local users, in order to apply different group policies there had to be group authentication as well.
– Mac OS X 10.6 uses a Radius server only to authenticate users on Airport basestations. Authorization for other devices is not enabled by default and groups are not pushed to other devices.

So… let’s get started! For this to work you’ll need to have your Cisco router connected to your Mac OS X server in some way. I won’t go into the basics of setting up your router, your WebVPN or your Mac OS X server here, there are plenty of tutorials on that on the web already.

First of all we’ll have have to alter the configuration of the excellent FreeRADIUS server that Apple ships with Mac OS X Server 10.6. This is easier than it seems. Stop the RADIUS server in the Server Admin utility and browse to the /etc/raddb/ directory. We’ll make changes to 2 files here.

In users.conf we’ll have to instruct the RADIUS server to accept incoming connections form the Cisco router. This is done by adding the following lines just above the “client localhost {” part:

client {
secret = somesecretyoucameupwith
shortname = vpn
nastype = cisco

The shortname is the hostname of the router, the IP address is the IP address of the router. Save the file (you’ll need administrator access to do this) but don’t start the RADIUS server just yet. We have to edit the users file (in the same directory) as well in order to push group information to the router.

In the users file you can specify the return values that should be pushed back to the router upon a successfull authentication. I looked into the possibility to make the RADIUS server push the default user group to the router but deemed that it was far too difficult to make it work. Instead I opted to make separate entries for all my users and specify their policy group explicitly. At the bottom of the users file you can add entries like this:

user1          Cleartext-Password := “password”
Service-Type = NAS-Prompt-User,
cisco-avpair = “webvpn:user-vpn-group=management”

When user1 tries to login to the WebVPN the RADIUS server will (upon a successfull authentication) push the webvpn:user-vpn-group attribute to the router. This attribute (in this case the group name management) will select the correct policy for the user. Now the RADIUS part is done, start the RADIUS server and see if it runs. If it doesn’t start you probably made a typo somewhere, see below on how to debug it.

Now it’s time to implement RADIUS authentication in the router. First we’ll add the radius server to the config:

radius-server host auth-port 1812 acct-port 1813 key 7 <somesecretyoucameupwith>

The secret needs to be the same as the secret you entered in the clients file.

These are the AAA settings that I used, I first want the router to check for a local account so I can always access it in case the RADIUS server stops working. After that the router will query the RADIUS server to look for valid accounts.

aaa authentication login default local group radius
aaa authorization exec default local
aaa authorization network default local group radius
aaa authorization auth-proxy default group radius cache radius local
aaa accounting auth-proxy default start-stop group radius

From here it’s easy, you can create different policy groups in your webvpn context. In this case I would create a policy group called management for user1 that will allow him to reach certain hosts and see a specific URL list.

policy group management
url-list “URLs”
functions svc-enabled
svc address-pool “sslvpn-pool”
svc keep-client-installed
svc split include
svc split include
svc dns-server primary
svc dns-server secondary

Also add the following line to your webvpn context to make sure the RADIUS server is queried for valid accounts:

aaa authentication auto

Now your Cisco will pass on logins to the RADIUS server and receive the correct attribute to select the right group policy for the WebVPN. Nice!


– In order for this to work the users specified have to both exist in the OpenDirectory and the users file.
– I have used port 1812 and 1813. In older RADIUS implementations port in the 1600 range were used. The Cisco configuration professional still suggests these ports but they don’t work with FreeRADIUS.
– I included the DNS servers as there is a bug with the current version of the AnyConnect client where DNS requests are not correctly forwarded in case of a split tunnel (CSCtf20226).
– If this doesn’t work first launch the RADIUS server in debug mode on Mac OS X server to see if the authentication runs well. This can be done by starting a terminal session and launching radiusd -X as root.
– Secondly use the radius debug feature of the Cisco router to see if the authentication packets that are returned contain the avpair attribute. If the attribute is not included the router will assign the default policy. In my case I removed the default policy as it poses a security risk.

A big thanks for the folks on the FreeRADIUS mailinglist for their assistance!