// archives

The ‘net

This category contains 37 posts

Openness and telecoms

This is a response to Lee Dryburgh’s article on Skype.  We had a debate on Twitter, but I have not yet mastered the art of debate in 140 characters!

Lee’s premise is that “Certainly Skype is not a walled garden. All things being relative, it’s certainly not overly closed either.”  Lee claims that the accusations of closeness are unfair, because they are levied by commentators who advocate SIP based addressing and dialing rather than any other system.

This is not my premise.  I claim that Skype is closed because calls are signalled and completed using protocols that are entirely secret as a matter of policy.  Skype’s founder presented at Spring VON 2007 and stated that if Skype did not keep their protocols entirely secret, then Skype would be full of spam and attack like email is.  I think this is a poisonous claim, telephone networks have been interconnecting around the world since telephony was conceived.  By not allowing telecoms firms to interconnect between the skype namespace and other networks, Skype have prevented openness to develop and maintain a monopoly position. That’s perfectly acceptable business, but it is not in the slightest bit open.

walled.jpgRandy Bush googled Walled Garden for a recent presentation and found this cartoon.  I like this definition because it’s correct.  Is Skype a Walled Garden ?  Lee says a Walled Garden is a commercial restriction, for example, “sharing of ringtones via Bluetooth, using WiFi from a PDA, having access to all Web sites“.  I think that only allowing interconnection with the purchase of an upgrade like SkypeOut is a restrictive or practice that suggests Skype is a Walled Garden.  Worst of all a call between two VoIP networks using this method requires default PSTN routing, which harms signal quality, and prevents the expansion of next-generation services such as Wideband/High Definition audio.

The meshing of networks, whether they are traditional voice or IP networks, leads to higher audio quality and increased reliability.  Keeping telephony systems and protocols secret in order to prevent meshing may well be a viable business model, but it is not an open business model.

Internet broken for ASN32 speakers today.

Not trying to point fingers or name-and-shame, just to raise the profile of a nasty little bug handling breaches of RFC4893.  This post is basically shaped from a message I posted to nanog earlier.

AS196629 (3.21 in asdot) announce 91.207.218.0/23.  Experienced eyes will notice that this is quite a large as number.  It’s a ‘new’ 4-byte ASN.  When an OpenBGPd speaker with 4-Byte ASN support receives the update for this message, the session is torn down with the daemon logging a ‘fatal error’. Why?
OpenBGPd is checking AS4_PATH to ensure that it contains only AS_SET and AS_SEQUENCE types, as per RFC4893.  When processing the UPDATE for 91.207.218.0/23 it sees :

91.207.218.0/23
Path Attributes – Origin: Incomplete
Flags: 0×40 (Well-known, Transitive, Complete)
Origin: Incomplete (2)
AS_PATH: xx xx 35320 23456 (13 bytes)
AS4_PATH: (65044 65057) 196629 (7 bytes)

See the confederation ASNs in the AS4_PATH ?  Thats forbidden :

To prevent the possible propagation of confederation path segments outside of a confederation, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH attribute. RFC 4893.

The RFC does not suggest how to handle AS4_PATH violations, but if the bad path is learned on every upstream, this will cause a network with obgpd edges to disconnect from the internet…. Modifying the OpenBGPd software to permit AS_CONFED_SEQUENCE, AS_CONFED_SET in an as4_path causes the path to be accepted and the session is not torn down.  This isn’t a great fix.
The impact today is fairly limited as there are relatively few bgp speakers honouring the 4-byte ASN protocol extension rules, but as code that support these features creeps around the internet, the next time this happens the impact could be much greater, so we need to understand which implementation of which BGP software caused this illegal origination.

From a software point of view, I want to see a configurable option to reject the route but keep the session, reject the route and drop the session, accept the route but log/send trap, etc.

In any case we need to publish the arrangement that has led to this mistake so that other networks using the same toolset to originate prefixes can avoid the same situation happening.  I have made contact with an engineer at the NOC who are investigating.

2011 – An addressing odyssey. Preparing enterprise for IPv6.

Yesterday I gave a talk to Sheffield GeekUp on preparing enterprises for IPv6 [download].  The premise of the talk was :

  • IPv4 addresses are scarse, and at current consumption rates, the IANA pool of free v4 addresses will be gone at the start of 2011.
  • This starts a “Post IPv4 world” where the IPv4 internet continues to function as before (certainly initially), but obtaining new addresses becomes harder and expensive.  This inhibits expansion of existing firms, and new entrants to the market.
  • Address trading is likely to lead to a larger routing table, meaning that failure-recovery times increase, and the risk of blackholes on the internet increases.
  • Large broadband providers may not have enough v4 addresses to give one address per customer.  This means protocol translation techniques need to be used, which break the end to end model.  We rely on the end to end model when innovating new services on the internet.
  • If services and consumers gradually roll v4 and v6 (dual stack), the negative impact of markets for addresses, routing problems, and translation can be mitigated.
  • Service providers are enabling v6 in the core.  Enterprises need to move next in order to get the world v6 ready.

The advice I gave was :

  • Today’s market leaders are already learning v6 lessons in their labs, (e.g. ipv6.google.com).  They are doing this to help them retain market leadership.  If you want to retain your market position, start labbing your applications and service provision with v6.
  • Write a policy stating all new purchases of infrastructure and services need to be from providers with v6 support, or a well defined v6 road map.  In other words, make v6 a “life cycle upgrade”.
  • Share information, and learn information from your industry peers.
  • I also listed some advice to developers with regard to v4 and v6 differences.
  • I then delivered a very quick primer to those who have not seen v6 deployed before.

My hope is that this talk is improved upon and delivered internationally to enterprises.

VoIP For Network Operators Tutorial

These are the slides that I presented at NANOG44 in Los Angeles on Sunday, “VoIP For Network Operators“.

This talk was for network operators looking to build voice segments of their network, and the slides cover

  • Voice Basics for SPs
  • Why Operators should care
  • Voice Peering
  • Metrics
  • VoIP Security

Youtube pushed off the air

In between browsing Facebook and Youtube, the UK economy generates $1,930,000,000 of output a year. Thats $550,000 every two and a half hours. Well if today had been a work day, there’d have been one two and a half hour period where that was much higher. That’s because in a pique of routing excitement, Pakistan Telecom managed to hide Youtube from most of the internet for that length of time.

Pakistan Telecom and Youtube are likely to have no commercial relationship in place to carry Youtube traffic – particularly as around two hours ago, according to Yahoo News, the story broke that the Pakistan Government required ISPs operating in the country to block Youtube. Despite this, Pakistan Telecom were able to cause ISPs all over the world to send traffic that should be destined for Youtube to Pakistan instead.

This is because the protocol that determines how to find my network on the internet, is shaped by how “specific” the announcement of my network is. If I make an announcement of a network of 1,024 addresses, and someone else makes a second announcement of 256 addresses within a subset of my 1,024, then the network which announces the smaller subset win the traffic destined to those hosts. This is a feature – fully by design – of the BGP routing protocol. Almost every time a more specific block of addresses is announced, this is because the administrators of those networks intend for the routing to be different for a subset of a large number of addresses.

Sadly, there are accidents from time to time – another network can announce a subset of my addresses without my knowledge or permission, and they win the traffic that should have gone to me. This happened today – it seems that Pakistan Telecom decided to inject a fake route to their network containing Youtube’s webservers, and accidently then leaked that route to the networks they connect to.

Small networks and end sites can limit the chances that they will leak bad routes by explicitly listing the network addresses that they intend to send to their upstream or peered networks. Larger networks may find it harder to stop themselves propagating someone else’s mistake, because they may have a contract to carry forward any announcement that their customers make. Furthermore, the complexities of their own networks mean that an engineer working under pressure after announcements made by government ministers are more likely to make a typo error and do the wrong thing.

Richard Clayton presented a very interesting set of commentaries at the last LINX meeting. He commented that right now its very obvious indeed when someone hijacks some of my network space in this way, because all of my traffic disappears. Youtube were probably aware that something was very wrong within moments of the announcement. What if someone builds an infrastructure to steal my traffic – or at least some of my traffic – but after doing something with it, they send it back to me, it is much harder for me to spot that anything is wrong.

This is a significant risk to ecommerce infrastructures that competitors or e-pirates could seize upon opportunities to steal customer behaviour data. What if a wizard stole the network containing your web server, proxied your shop, but set up a fake checkout? How quickly would you spot?

Because this problem is inherent to the routing protocol, this is the obvious place to fix it. There are attempts to blend PKI with routing information, so that peers can verify the validity of your announcements. S/BGP (secure BGP) requires me to sign my announcements, and gives my peers a method to check in an impartial internet community database that my announcement is valid. It is the sort of technology that would have prevented Youtube from disappearing off the air today.

Life after email

The death of email has already been predicted on approximately 1,258,926 blogs, so I barely need to recount the chant that IM is already replacing regular conversation, social networking manages infrequent messaging between your peers and introduces you to new business partners, and that web forums are how the population now find out information.  Email is struggling to be the ubiquitous gold-standard for internet communication because of the amount of spam and malware that is distributed through the medium.
This doesn’t explain how email marketing will be replaced.  Email is an inexpensive and relatively simple and successful way of driving repeat business.  Once your customers have found your company useful once, you take future opportunities to remind them to spend some money with you again.  If legitimate email marketing dies, this could cause a dent in online trading.  That’s bad for folks like me and the folks who read these articles.

GMTV are finding they’re already a victim of spam filtering, or customer reluctance to read marketing email.  They’re originating messages that either get binned by the audience, or their audience’s automatic spam filters.  Customers who traditionally would have received emails informing them of new online content are now being encouraged to install a desktop client that alerts them in real time about new content.

I’m pretty worried that in order to stay in touch with suppliers in the future, I’ll be expected to use one particular desktop client.  This means in some cases, I may have to use one particular desktop environment for a start.  Secondly, this makes it more likely that I’ll receive malware – how can I trust the originators of the client?  And as it’s a network service, any desktop alerting system is also potentially at risk of abuse or spam.  So I get realtime spam as well as spam waiting for me when I check my mail.

Instead, I hope that more email clients incorporate RSS systems in the future, as Apple Mail has done in the latest release.  Using Apple Mail, I can subscribe to marketing announcements from the companies that I want to hear from, and have those arrive in a specified area of my mail client, and they’re not inflicted by spam.  As I try to make clear everywhere possible – use open standards and open protocols, if you want to keep your doors open to new business.

Internationalisation of DNS continues

Like most original internet standards, the DNS was designed to initially suit the needs of any section of the world that could communicate using 7-bit ASCII and Latin character sets. Then the internet became really popular. Everywhere. The DNS had to evolve to cope with naming schemes that came from alphabets all over the world.

All successful internet protocols are elegant and simple by design. This makes it possible to retro-fit great ideas someone has one. Internationalisation was proposed in 1992, and it eventually became possible to register Internationalised Domain Names (IDNs) in the .com space in 2003. Standards move slowly on the internet!

IDN is up for discussion again at the 31st ICANN meeting on Monday. This time, the world’s registry community are meeting in New Delhi, one of the most significant IT regions of the non-Latin world, to discuss the remaining “glitch” in the IDN system. An IDN might look like this: image.com. Therefore any user still needs to be able to type .com in order to reach the resource they request. There is a proposal at the ICANN meeting to add Internationalised top-level domains, actual complimentary TLDs to .com, that will mean that resources can be reached in any supported alphabet.

This is interesting stuff. One school of thought is that this could significantly assist the development of electronic enterprise in many more pockets of the world. The supremacy of Silicon Valley as the web’s main economy would then be broken. I think differently – I think that .com is now too established as the main ecommerce ‘brand’ TLD, and attempts to localise the meaning of .com will be fruitless. .com means “I trade online”. Despite .biz and similar TLDs being equal in technical terms, they are not equal in the eyes of shoppers or traders. .com now has specific global meaning, and can’t be diluted.

European Internet exchange update slides

I presented a talk on recent European Internet exchange news [download] with Mike Hughes from the LINX last week at UKNOF. Many of the attendees run networks that do not peer publicly, so it was a pleasure to explain the impact that European IXPs have on member traffic. We also then gave a perspective on peering in London.

Many of the statistics came from Serge at Euro-IX who did the leg work for the raw figures.

The highlight points of the talk were

  • Euro-IX identify 103 exchanges in Europe, in 31 countries. (3 in 1993)
  • 8 Exchanges in the UK (was 9 until BT’s UK6x closed)
  • At the end of 2007 networks publicly peered 1.215Tbit/sec at peak.
  • More public peering in EU than US (but it’s cheaper to peer in EU thanks to lower x-connect fees, and cheap ubiquitous mutual exchanges)
  • London is #1 for network reach – 601 networks peer publicly, 415 peer exclusively in the UK.
  • 22% of LINX members peer exclusively at LINX, 31% of LONAP members peer exclusively at LONAP.
  • 577 networks peer at more than one IXP, and one network (Colt) is present at 19 exchanges!
  • Last year the good weather in April caused an additional summer-time traffic dips in Europe, in addition to the regular dip in July/August

There’s other stuff in the slides too, such as the usual traffic updates for various major exchanges in Europe.