Random ramblings

Monday August 25, 2008

BGP Path Hunting

Path-hunting is the tendency of BGP, when a path is withdrawn by a remote AS, to "hunt" from one path to another, before finally converging. The problem has been described elsewhere, particularly by Geoff Huston (e.g. in this ISOC column on BGP dampening). Manav Bhatia also has a nice, graphic explanation of BGP path hunting. Tony Li and Geoff Huston additionally have authored a very interesting draft on the problem, draft-li-bgp-stability - which analogises BGP convergence with wave-front propogation, where the "front" of convergence bends with differences in path-propogation times, and expands out where ASes connect with multiple others.

This problem is very similar to[5], if not a special-case of, the well-known "count to infinity" problem inherent to the Bellman-Ford, distance-vector protocols. With infinity being constrained, by BGPs built-in split-horizon behaviour, to the number of simple paths in the topology.

Path Hunting overview

In short: given some converged subset of the BGP topology, with A and B connected by a set of one or more distinct paths {1, ..., n}, with the time taken for a message to propogate down path x of t[x] so that the set of paths has a directly corresponding set of propogation times T = {t[0], ..., t[n]}. Then for any announcement which passes through A to B, BGP will reach a "useful convergence"[1] by or within a time of:

• For an UPDATE announcing a new/updated path: minimum(T)
• For a withdrawal: maximum(T)

The latter convergence time being due to the 'hunting' behaviour of BGP, and indeed consistent with the well-known "Good news travels quickly, bad news travels slowly"[3] behaviour of distance-vector protocols.

E.g. imagine A announces some prefix to C, and imagine (for simplicity) that B does not re-announce paths to E or H, with simple paths between A and B of {ABC,ACDEB,ACDFGHB,ACDFGEB,ACDEGHB}. I.e.:

-A--C----------B
     \        / \
      D------E   H
       \      \ /
        F------G

So after a time of minimum(T), B will have received at least one UPDATE corresponding to a valid path and would be able to forward packets toward A for the prefix. Though the system is not converged, any further UPDATEs B receives can only cause it to select a better path, so the system is at least "usefully-converged" - it can route packets.

After a time of maximum(T), the state at each speakers will be fully converged, and B may then have the following paths in its RIB (arbitrarily making assumptions about preferences speakers may have), for whatever prefix it is, from among which B may pick its preferred path:

• From C, Path: CA
• From E, Path: EDCA
• From H, Path: HGFDCA

Note that B does not know about the ACDFGEB or ACDEGHB paths, however if the DE edge were withdrawn, E potentially could switch to G (and issue an update to B when it does so) and similarly with the FG edge and latter path. B can pick anyone of the above as its preferred path. I.e. though these paths are hidden from B, they can still come into play.

Imagine A now withdraws the prefix from C - so the connectivity to the prefix is now lost as far as the rest of the graph goes. After a time of minimum(T) B will receive at least one message (that might be a withdrawal from C, but it could just as well be an UPDATE from E as E hunts its preferred path over to G). Imagine it happens to come from the peer which it had selected as best, and results in B picking sa new best path via another peer (e.g. because its a withdrawal, or an UPDATE with less favourable path-attributes). Then the next update arrives from the peer newly preferred, and so B picks again, and so on. So B's best-path may well change between the following best-paths:

1. From E, Path EDCA
2. From C, Path CA
3. From H, Path HGFDCA
4. From H, Path HGFDCA
5. From E, Path EGFDCA

I.e. before B can converge on "there is no path", it potentially will first "hunt" through various paths that are already dead[2]. Yet, B *did* receive a message which was triggered by As withdrawal - several in fact! If only B could use the first message to see that, as it was A which withdrew the prefix, that therefore all paths via A must be dead, then it could short-circuit the whole hunting process!

Possible Solutions

Huston and Li propose various possible changes to BGP to mitigate hunting, such as removing the MRAI timer, band-stop filtering of updates, path-exploration damping, etc, all of which are implementable without change to the BGP protocol itself. Other proposals include Brian Dickson's second-best-backup proposal which seeks to speed up convergence by providing visibility of additional paths besides the best-path (such as the ACDFGEB path which is initially hidden to B in the example above), and also to provide a fast-path for withdrawals (this proposal requires changes to BGP). None of these proposals actually solve path-hunting, they instead try to either filter it out and/or speed it up.

Hunting can eliminated in BGP if it could be extended with mechanisms to allow BGP to recognise nodal changes in state, across paths. Other DV protocols (DSDV, AODV) solve similar problems by numbering messages/routes with a sequence-number. This sequenced-DV approach is problematic with BGP as it tends to require either that routers in an AS somehow maintain a shared counter, or that BGP must describe a more detailed router-router topology (rather than todays abstract AS-AS topology).

Some possible mechanisms that eliminate hunting:

• BGP-RCN

  A possible means to allow for convergence in O(minimum(T)) for all kinds of state-changes is described by Pei, Azuma, Massey and Zhang in "BGP-RCN: improving BGP convergence through root cause notification". Speakers include an additional attribute of information with updates/withdrawals, called the "Root Cause Notification" consisting of a list of (ASN,sequence number) tuples. This allows a receiving speaker to compare announcements received via different paths and determine relative recency, so allowing it to always act on the most recent information.

  The sequence number dependency is a significant barrier to deployment.

• AS Poisoning[4]

  This is essentially a simplified version of BGP-RCN, that does away with the problematic sequence number. When withdrawing a prefix, a speaker can include information that "poisons" nodes (or even edges). E.g. if A sends some kind of "Poison: A" attribute with its withdrawal, and if that attribute will propogate along with the withdrawal, then B can conclude from the first withdrawal it receives that all paths that go via A are defunct. BGP can now converge on a prefix-withdrawn state in minimum(T). The downside being that convergence to the prefix-announced state instead occurs in maximum(T) - though it is possible that BGP can be "usefully converged" prior to that, which would be a more useful state than path-hunting.

  So we can "fix" path-hunting, and maximise withdrawal convergence without introducing any co-dependent state with only mild changes to BGP, though at some expense to announcement convergence.

A further observation to be made is that IGP routing has switched from distance-vector to link-state (or "map-distribution") because of the same convergence limitations. Further, there are proposals for BGP security extensions which overlay a link-stateish topology onto BGP, and the BGP-RCN approach is not far from a link-state protocol either. So it is perhaps not completely unreasonable to imagine whether some kind of topological-state mechanism could be bolted onto BGP, that could be used to augment the path-selection process.

So...

Solutions to the hunting problem either are imperfect local-hueristics (which may even make convergence worse in cases where they fail), or protocol extensions with fairly significant trade-offs (either in complexity or adverse side-effects). It seems unlikely there's any magic bullet, given the length of experience we have with Bellman-Ford/DV protocols.

--

Corrections and comments would be appreciated.

Update: Added footnote 5.

1. "Useful convergence" being where speakers all have converged on some particular state, OR are in a certain semi-converged state such that any further messages still propogating can only cause speakers to transition their routes from an existing, valid path to another valid path (this can not be the case if there are any withdrawal messages still to propogate). I.e. forwarding remains loop and blackhole free.

2. This is a problem as it means that if, outside of the subset we're consider, B has other, less-preferred connections, then B will have to wait max(T) before it can decide there are no valid paths in this subset and start to consider paths outside of this subset.

3. Does anyone know the original source of this? (Douglas Comer, "Internetworking with TCP/IP", Prentice-Hall, 1991, seems to quote it).

4. Described only in private correspondence, to date.

5. In the sense that the cause of the count-to-infinity problem was due to the source event of a routing update being indeterminable. Split-horizon cut-out the count-infinity problem for direct loops between neighbours, by preventing updates from propogating endlessly. The addition of a record-of-path (e.g. AS_PATH in BGP) solved count-infinity for multi-hop loops, by preventing updates from propogating along any but simple paths. The remaining problem is of updates travelling along multiple, parallel paths with different propogation times, preventing us from recognising which message received is the most recent - fixed with sequence numbers in some DV protocols. Each modification has pared down DV protocols slightly, restricting where valid information can flow and how it is recognised.

Wednesday August 13, 2008

More olympic fakery news

Tomorrow's big story: The piano player and the kid mimed their performance too!

From the coming weekend's Sunday broadsheets: In-depth expose interviews historian who claims to have evidence that the archer-lights-cauldron scene at the Los Angeles olympics was faked too!!!!!

News just in from 2012: All theatrics deemed fake by IOC. Opening ceremony in London to consist of a reading of selected DNA sequences by Richard Dawkins, and the sotto voce proving of theorems from "Principia Mathematica" by the Froncysyllte Male Voice Choir, followed by some sport.

Sunday August 10, 2008

Wholesale DSL reform: Possibilities...

Following on from my, somewhat rambling, post on wholesale DSL, here I'll speculate on possible reforms that could be made.

• Micro-peering.

  Alluded to as one of the "difficult to do" solutions. It's not at all viable today, but its interesting to consider what improvements would need to be made to internet protocols for this option to at least be possible. E.g. BGP is extremely management intensive. Even simple, non-protocol changes like better defaults could make a difference here. In terms of protocol, things like in-band transfer of policy information and auto-configuration of neighbours could simplify management greatly.

• Allow the telco's own ISP to switch IP locally, where it wishes.

  In other words, allow the telco-ISP run a single IP data-plane at the head-end for its own DSL customers, so allowing local switching of traffic within an exchange, if the telco-ISP so desires. At the moment, regulations would tend to prevent the telco discriminating between its wholesale-ISP customers and its own ISP in such a way. If it's the case that there are enough trunk-link bandwidth savings to be made to outweigh the initial costs of re-engineering and further additional managements costs, then it'll happen (at which point there'll be the tricky problem of what to do about the wholesale-ISPs not enjoying this advantage). If not, we'll know it doesn't matter - no harm done. I.e. loosen the regulations so that we can at least allow one player to obtain data on whether we need to re-think whole-sale DSL..

  This probably wouldn't work in the UK, where BT appears pretty well divided up. Might still work in Ireland, where Eircom appears still to be a single entity.

• Consolidate network layer responsibility in one company

  The benefits of the wholesale-DSL model in terms of the economic-efficiency of the network are actually negative[2]; both in terms of the congruence of IP/geography and in terms of the significant additional complexity and points-of-failure[1], which incur direct costs (engineering and sustaining) and indirect costs (more downtime for customers). Further, managing an IP network is well-understood, and the reliability of the whole-sale ISPs is reliant on the operational competence of the telco.

  The benefits of the competition introduced by the wholesale-DSL model therefore must lie primarily in customer-facing services. Therefore we could reform things by allowing the telco to manage the entire network stack (terminating PPP where it wished, assigning IPs, etc..), while leaving customer-services and further value-added services (domains, email accounts, etc..) to the "ISPs".

1. E.g. in Ireland, the few (4 odd?) "BRAS" routers operated by Eircom, which exist to dispatch PPPoE sessions to the various ISPs, via L2TP/IP. The wholesale-ISP must operate their own access-routers in addition to the "BRAS" - with obvious implications for failure rates. In a simpler model, such dispatching wouldn't be needed and PPP sessions could be terminated on cheaper (and so more numerous and perhaps more widely distributed) access-routers.

2. As per previous post: determined by comparison with single-operator networks.

Saturday August 09, 2008

Wholesale DSL: Economics of Scenic Routing

In Ireland and the UK, due to the bulk of the POTS plant being owned and managed by the incumbent, former state telco, DSL tends to be provisioned on a wholesale model, where the incumbent telco is obliged through regulation to resell access to DSL customers to independent ISPs. The resale price is usually carefully regulated to be fair to both the incumbent and the market. The customer deals with only the independent ISP, who deals with the incumbent telco to arrange provisioning, etc. So the link layer (at least, immediate to the customer, independent ISP and incumbent) is something like:

customer1----telco exchange------<telco network>------ISP1
customer2----/ |                                ------ISP2
...            |
customern-----/                                 ------ISPn

The incumbent ISP tunnels the data traffic between the independent ISP and the customer (this is known as "backhaul"). So at the IP level, it looks like a single link (over which PPP is run), and the topology looks like (the customer numbers do not correspond with above):

customer1---<PPP>----ISP access----<ISP network>----<internet>
customer2---<PPP>---- router
..                    |
customern--<PPP>------/

This scheme must have management and implementation benefits, as it is a popular model. There is a reasonably clear layering, of IP and layer-2 and corresponding separation of responsibility. Maintenance and management of each layer is reasonably well decoupled, e.g. the telco can upgrade DSL head-end equipment at the exchange without having to technically interact with ISPs and the ISPs can carry out IP layer maintenance (addressing, whether to allow a PPP session, etc) without involving the telco. The only changes which routinely need interaction are the provisioning of a link between any specific customer and ISP (i.e. setting up a new customer, or changing the level of paid-for service) - to this end the telco can provide interfaces suitable for bulk updates as well as back-end<->back-end support[1].

So far... so what?

The downside to this model is that the IP topology is quite divorced from the geographic topology.[2] E.g. Imagine two DSL customers, each attached to the same telephone exchange (so they live reasonably close to each other). The IP topology between them, to which their packets are constrained if they want to communicate in some way via the internet, likely will be (at least, if we assume the ideal of competition that drove the creation of a regulated, wholesale DSL has paid off):

customer1-------ISP1------ISP2-----customer2

Because of how ISPs tend to interconnect, the chances are they'll do so at only a few locations, such as London, Amsterdam or Frankfurt (some Irish traffic might exchange at Dublin, not all though). So packets between customer1 and customer2 will wander off to some major, European metropolitan hub, before coming back to the exact same data-plane in the exact same networking device (no doubt saying a cordial hello as they pass their fellow packets still awaiting their long excursion). E.g.:

             +------------+
customer1----|  Exchange  |
customer2----| in Glasgow |
             +------------+
                   |
             <telco network>
               |       |
              ISP1    ISP2
               |       |
              LINX (London)

Such less-than-optimal routing is not uncommon in the networking world. Packets often pass close by packets of the same flow, before going off on a long detour, maybe because there is no direct route between two physically proximate devices, or even sometimes in the same device when the relationship of the flows is obscured by abstractions in the data-layers (IP over ATM, or MPLS, etc). This is because creating links and exchanging routes has a cost, particularly so in the ongoing management of a network. Physical links require technicians to setup and maintain. Logical links require network-administrators to configure. Exchanging routing information with other organisations requires further manual configuration (filters, policies) and monitoring, adding costs that further complicate the business-case evaluation and approval processes for new inter-ISP links. Further, for intra-AS forwarding, IP is perceived as hard to manage, and organisations often prefer to tunnel IP over an abstracted and flat topology, doing their network-engineering with protocol stacks like ATM or MPLS instead.

These costs mean a less-than-optimal route in a geographical sense will actually tend to be a uneconomic route, at least in private enterprise. Economics are the overriding metric, and so we should expect that routing tends to being economically optimal.

Yawn.. obvious.. So?

So one company owns and operates the DSL networking equipment, and potentially even the inter-exchange network. Typically this would result in a single IP topology, abstracted to some degree but still vaguely congruent with the physical topology, at least in the free market. In the wholesale-DSL model, the IP layer instead is provisioned primarily according to regulatory concerns. The telco is usually constrained from discriminating between ISPs, or giving itself preferential treatment where it also operates a consumer ISP. In the UK, the regulated, local-loop telco portion of BT is effectively a seperate company called BT Openreach; in Ireland, Eircom is supposed to maintain an internal chinese-wall between its wholesale and end-user operations. This distorts the economics somewhat.

E.g. often the telco itself operates an end-user ISP division. If it operated DSL head-ends as IP access routers[3], which is not too unreasonable to imagine given the example of some cable-ISPs, then at least the traffic of its own customers would stay local to the exchange. However, in the regulated, wholesale DSL model, this traffic MUST be "backhauled" to a few central locations, like the traffic of all other ISPs.

The only way the traffic could be kept local is if the telco/ISP could offer *all* ISPs the opportunity to exchange traffic locally, by the same method the telco's ISP uses. This would be difficult to do, as things stand, without unacceptable consequences.

Point please.. Or I must kill you

Ok, ok. The point, essentially, is that the benefits of competition for ISP customer-service comes at the cost of distorted economics, and IP topologies that are far less geographically optimal than those observed in single-organisation, end-user IP access networks (assuming economic efficiency isn't substantially different for both, so that the regulatory framework for DSL is the key variable). I.e.:

• The wholesale model results in a network that must cost more (and/or delivers less) than it would have otherwise, by simple comparison of IP topology alone.
• As the DSL model still results in a single, (effective) monopoly operator of the majority of the network[5] (at various levels[6]), any economic benefits likely lie primarily in competition in customer-service amongst ISPs.
• The attractiveness of multicast is reduced by the encapsulation of IP inherent to the wholesale-DSL model. If people from m different ISPs at an exchange subscribe to a multicast stream, the load on the trunk into the exchange is m, rather than 1. (Not that inter-domain, end-user multicast deployment has seen much use).
• Locality aware caching in P2P software (e.g. Joost) can not minimise load across paths that are hidden from IP (such as exchange trunks).
• It'd be interesting to read of studies on user-behaviour (traffic patterns) for MANs or NANs ("neighbour area networks", e.g. shared cable IP networks) to see if the locality makes any difference at all (with existing protocols), as well as studies analysing P2P traffic for temporal-locality to see what, if any, potential there is for significant trunk-link bandwidth savings, such as those for IPTV[4].

In short, my argument is that we're possibly in a bad place - regulating ourselves into a more costly system of delivering broadband, particularly for popular content, which becomes ever more difficult to substantively change the more the regulation encourages investment in it, which the private market likely will not be able to crack.

An Eircom executive recently, in a speech at the IETF plenary, gently argued that Ireland's DSL regulation was a disincentive to investment by Eircom (not reported on anywhere, it seems). So I'm somewhat hopeful that there's a still a chance for Ireland[7] to improve things, and reform broadband-access regulation. That's not to say we should give Eircom exactly what they want, only that they could be a driver to initiate reform, and of that itself we should not be sceptical..

With thanks to Thomas Bridge for insights and discussion on this subject (he very likely disagrees with my conclusions though).

See follow-up post on reform possibilities.

1. I can't think of a better term for "non-consumer support".

2. Obviously, this isn't new with customer/ISP internet access (e.g. dial-up, ISDN), however what is new with the arrangements for DSL is that the telco layer is increasingly (if not overwhelmingly these days) an IP-capable network, likely managed via IP (from the ADLS head-end equipment on), with parts of (if not all) of the DSL-data-delivery occuring over an IP-forwarding network (e.g. Eircom hand-off wholesale DSL as PPPoE/L2TP over IP). Ignoring the regulatory aspects..

3. Where IP capable - often the case with more modern equipment.

4. E.g. On Next-Generation Telco-Managed P2P TV Architectures, which found locality-aware caching could contain 80% of trafffic to within a DSLAM.

5. I'd be glad to hear of examples of where telco deregulation has lead to any significant access-link, "we own the wires" competition outside of juicy, major metropolitan areas..

6. The wholesale DSL model can result in mini-ISPs that run no more than DCANs (data-centre area networks), with the state telco connecting them to their customers AND their IP transit providers (perhaps unknowingly, for the latter, via more abstraction).

7. The UK, OTOH, seems to have a lot of ISPs who rely on BT wholesale DSL, so presumably that boat would be a lot harder to turn.

Thursday August 07, 2008

PGP: Signing policy update / Please sign my photo UID

Couple of PGP things:

• I've updated my signing policy.

  It's not terribly consistent though, and I'm still not quite sure where I stand on signing keys on nothing more than a cursory examination of governmental ID (i.e. people at key-signing events whom I don't know personally), so I'm not very happy with it. I'm much more comfortable signing keys of people I've known and interacted with over a period of time, and even more so when I know others who've done same - even if I've not seen an ID.

  Some may wonder why I would sign keys on the basis of my level-1/Low policy, but the concept of "web of trust" implies additive trust (potential for at least), so even a "not much confidence" signature ought to be of value to the WoT.

• I've added a photographic UID to my public key (yeah, horrible photo ).

  If you can attest to that being a good likeness of me and have good reason to believe it's my key, please do sign that new UID. (Also, what's with people who sign only one UID on a key? I've no control over the order of UIDs, I think, so its always a less favoured UID that gets signed in such cases - arg! ).

Weird BIND9 AXFR error? Remove stray A6 records..

Some release after BIND 9.2.1, its parser for A6 records appears to have broken. If you've ever experimented with A6, you might to go check you've expunged all occurrences from your zone files. Resultant symptoms include:

• Slave BIND servers fail to AXFR zone updates, reporting "transfer of ..... from .... : failed while receiving responses: unexpected end of input" in their log files.
• Manual AXFRs with dig gives the errors of ";; Warning: Message parser reports malformed message packet." and ";; communications error to ....: end of file".

Background: For many years, as I saw it only between a master behind a sub-1500 MTU (PPPoE, sigh) and certain servers, I assumed it was an MTU-blackhole problem with some upstream sneakily doing firewalling. However, recently the problem started to afflict another server, after an upgrade of their BIND software, and affected AXFRs even over paths that were perfectly fine. Some brute-force testing ruled out obvious problems like size issues (not like my zones are big) or relatively new records like SSHFP, leading to some head-scratching, but eventually pinned it down to a couple of stray A6 records.

Wednesday July 23, 2008

APNICs AS-dot policy proposal

In a similar vein to my attempt to dissuade RIPE from continuing with AS-dot format, James Spenceley has submitted APNIC policy proposal 65 to try get APNIC to change their ways.

Pretty Good BGP (PGBGP)

A new, interesting, soft/side-band approach to BGP security: Pretty Good BGP.

No crypto involved, no need for extensive deployment. Just monitoring the BGP routing table and reporting anomolous updates to the operator for further investigation. What's especially interesting is that they claim this system has discovered otherwise unknown hijacks of important prefixes.

Wednesday July 02, 2008

last.fm double plus good

Recipe for discovering new music:

• Go to last.fm and sign-up for an account
• Configure your MP3 player's last.fm plugin with your account details (you may need to download and install a plugin if your player does not already provide one - I use rhythmbox's).
• Listen to your own, favourite music for a while (e.g. a few weeks), to "scrobble" tracks to last.fm and seed your profile.
• Use your last.fm plugin's playlist features, such as "My Neighbourhood", "Artist Similar to" and/or "Tagged with" to discover new music.

When is a Sunni fundamentalist terrorist not a terrorist?

.... Why, when they're Baluchistani 'dissidents' agitating against the Iranian regime, of course! One could perhaps predict that in 20 odd years time Baluchistanis will be identified as being behind some terrible terrorist attrocity committed in the west, but then one would need a basic sense of history!

In other news, Nelson Mandela and other ANC members have been taken off the US terrorist watch lists. ANC terrorism of course was not terrorism, but instead the noble, indiscriminate maiming and killing of people who would have gladly volunteered to have died for freedom had they been offered a chance (and those who wouldn't have must have been apartheid lovers). Anyway, it seems the only way off the terrorist watch-list (besides being a US Senator or buddies with the head of the US DHS) is to be a successful terrorist..

In other news, scientists have discovered a new shade. Said to be neither white, nor black, it has tentatively been named 'grey' and even may possibly form a continuum. It is speculated the world may in fact be full of it...

Saturday May 31, 2008

Howto share your web-browsing experience...

• Get an account at a bookmark-aggregation site, e.g. ma.gnolia (del.icio.us if you prefer, but their HTTP RPC API seems to be unreliable).
• Add their "bookmark a site" smart-booklet to your browser's toolbar, and/or install their browser extension (GNOME's epiphany browser already supports ma.gnolia and del.iciou.us - install the epiphany-extensions stuff). Ma.gnolia have a nifty, web-2.0, AJAX bookmarklet thing that's quite cool.
• Link to your bookmark-aggregation account's feed from your site, so that those who are interested may subscribe to it.
• Consult the documentation of your bookmark-aggregation site to see if they have some handy javascript you can stick in the template of your blog that auto-includes your latest bookmarks in a side-bar (e.g. ma.gnolia do - see my blogs web site).
• If you have a social-network profile, check if a plugin is available to connect your bookmark-aggregation account together with it.
• Don't enable your bookmark-aggregation site's "post linkroll to blog" feature, especially not if you already know your blog is syndicated by blog aggregators (if you don't know, it probably is).

Really, despite what your ego says, your web-browsing habits are unlikely to be more interesting than the various mechanisms that your bookmark/tag aggregator already supplies for finding interesting links, which other people already use, cause link-rolls are tedious..

This was originally a comment on another blog, but either I forgot to hit "submit" or it got deleted.

Thursday May 22, 2008

The Security-Industrial Complex

This piece in the Rolling Stone magazine on China's surveillance state is well-worth a read.

This piece finally gives me a sense that perhaps I can understand the economic (i.e. corporate) motivations behind the ever-increasing dominance of security in civil life, something that has puzzled me for a while. For example, the military-industrial complex clearly is a factor* in the USA's use** of military-intervention as a foreign policy tool. However, I could never understand the bias that many western-governments have shown against freedom, in favour of encumbering us with, sometimes absurd, security measures. In my naivety, I thought it had something to do with some kind of "psychology of fear"-as-political-tool - not thinking of the security industry itself as being a significant driver.

This piece though puts it into perspective. Just as there are large industrial interests driving military spending, via a revolving door between the military, the government and the industry, so that piece makes it clear there are similarly large industrial interests, and a similar revolving door (except perhaps substitute police for military+) around security. This security-industrial complex is helping to drive the security policies of our western governments, and so cause growing amounts of public (or governmentally-mandated) spending to be sent their way. Given this encompasses spending on data-retention (private spending, by EU directive), national identity databases (UK), and so on, the amounts are not quite insignificant.

It's important to realise that security-service++ spending is at best of indeterminable utility+++. At worst, it may largely be wasted, other than to a small number of people who manage to make a lot of money for little work. Further, even if there is some utility to this security spending, that money may have achieved more had it been spent elsewhere, e.g. education, research, health-care, etc. Given the dubious utility of such security spending, the opportunity costs may well be far more significant than the amount of that spending itself.

Sadly I've little confidence anything is going to change in the near future. I'm vaguely hopeful though that eventually some nations will gain a competitive, economic advantage from foregoing massive-spending on security-theatrics and so influence other states. At least now, I think, I have slightly less naive understanding of it..

* In the sense that there is clearly a strong feedback loop in the USA of high military-spending sustaining significant military-industrial interests in the USA, which lobby to have the USA sustain its high level of military spending. The end-result is a state heavily invested in military power.

** Not that I claim that other nations are more enlightened. Just that most don't have anywhere near the same military dominance***.

*** I.e. I'm uncomfortable with militarism, not nations.

+ There's also a revolving door between the military and the police forces. Many coppers seem to be ex-armed-forces in the UK at least, though I don't have hard data.

++ Note that I say "service". Money spent on research, e.g. face-recognition, low-energy, x-ray tomography of passengers, might find other applications. An X-ray scanner operator though is not contributing as much to society, in that capacity, as they might otherwise. Also, I'm thinking mostly of the kind of additional spending on indiscriminate surveillance, data-mining and check-points prevalent since 9/11, rather than spending on more traditional security, policing and civilian intelligence.

+++ Exactly how dubious, no-one knows. There is this, though it talks of the opportunity costs of terrorism rather than just of security spending - related, but not quite the same (i.e. implicit in my opinion above is that the current security theatrics are essentially useless in terms of preventing any future terrorism). I don't know of the studies into this, would be interested to hear of more.

Monday May 19, 2008

How not to improve the security of your online banking website

• Implement a browser white-list

  While it may be a good idea to disallow customers with ancient, bug-riddled, phish-magnet browsers from accessing their online banking, doing so via a white-list of approved browsers is certain to annoy some of your more technically savvy users. Either implement a blacklist, so that the browsers you don't know about can still get in, or give the user the option to continue with an unapproved browser after warning them of the risks (it's their money..).

• Redirect HTTPS requests to your login page back to HTTP

  There's a good reason why your customers might use a local bookmark to a HTTPS URL to access their online banking. Don't defeat it by redirecting them back to HTTP! The fact that your customers only can usefully bookmark your frontpage, thanks to your use of weird URLs that redirect to stranger URLs for site navigation, is part of the problem - presuming you want to minimise HTTPS load.

This blog entry was inspired by the RBS web site

Monday May 12, 2008

The single-loop exception

Found myself having to act on a set of things, in some specific order. Certain items are exceptional and if present then processing stops there. The common idioms for this, that I've seen in C, are:

1. Tangled spaghetti-jungle of if/else with long conditionals
2. Goto break out

The former is common enough (though, not in your code nor mine, of course ) to make this blog posting worthwhile.

The latter is the neater approach, and possibly the only remaining legitimate use of goto today. However, it requires placing labels - which isn't error-proof - and maintaining discipline to not abuse (those labels are so tempting!). Some languages have dedicated syntax exception handling (try/throw/catch/finally), but these can feel a tad over-wrought for simple, localised exception handling.

There's another possibility though, generic to all C-like-syntax languages even, using a single-loop:

do {
  if (foo)
     do_stuff (foo);
  if (bar)
     break;
  if (acme)
     do_stuff (acme);
} while (0);

do_final_stuff();

The do {} while (0); pattern is of course already widely used in C, to encapsulate function-like macros. However, I've not personally seen it used in code bodies for such light-weight exception handling.

Another variant, that allows for some basic exception processing:

do {
  if (foo)
     do_stuff (foo);
  if (bar)
     break;
  if (acme)
     do_stuff (acme);
  return;
} while (0);

do_exceptional_stuff();

Wednesday February 06, 2008

USA taken offline by a cable cut!

Some other bad news that wasn't reported today: "I can't ping some-random-router.some-institute.edu - it used to work but it doesn't now. OMGZ DA USA IZ OFFLINE!!!".

That's bad news in the "Regurgitate ill-informed rumours" sense, simply cause a simplistic web-page says some host is down, which at least a few high-profile bloggers who should know better have fallen victim to (never mind news-aggregation sites who don't care what rubbish stories drive their impression count). Better and more fact-based commentary on how the cable-cuts have affected internet connectivity is out there..