Category Archives: Networking

Talk: “Ubiquitous Access to Public Services Online with PAWS”

Leave a reply

We have been hard at work over the last few months, designing and securing the PAWS network. This is the outline of talk that I gave a few weeks back. The full powerpoint is available on Slideshare

Intro

Hi Everyone, My name’s Heidi and today I’m going to walk you through some of ideas behind Project PAWS, the Public Access Wifi Service. It should take about 15 mins to run you through our aims, the obstacles and we are trying to address them.

Internet Access – A Human Right ?

In July 2012, the United Nations unanimously backed a notion stating that “All people should be allowed to connect to and express themselves freely on the Internet”. Our aim is to address this and extent internet access to all, particular regarding access to essential public services.

Lowest Cost Denominator Networking

Mostly internet access today is done using “best effect” access, given the infrastructure available and the current state of the network, provide the best access possible, which of course comes at a cost. This creates only 2 possible levels of access: those who have internet access and those who don’t.

We aim to extend this, introducing a new level of basic access called less-than-best effort access, its has lower user requirements, thus reducing costs, helping to make internet access more widely available. According to the Internet World Stats survey of October 2012, more than 10% of the UK population don’t have internet access in their homes. This is what we hope to address.

Trial Deployment: Aspley Nottingham

Before tackling the issue nationally, we want to tackle it in one small area of the UK. For this, we have chosen Ashley in Nottingham. We chose this because according to the Nottingham Citizens survey, around 1/3 of citizens don’t have internet access. This is 3 times the national average, so if we can tackle the problem here, then hopefully we can tackle the problem anywhere.

The aim is to provide internet access to 50 citizens of Aspley who don’t currently have access. Our approach, is to enable citizens of Aspley with internet access to share their broadband with the wider Aspley community. For this we will be aiming to find 50 broadband sharers who are willing to help get 50 other Aspley citizens online. Once we have found our 50 sharers and our 50 new internet citizens, we hope to run a system to provide them with access for 3 months. We will then analyse the results, with the view to running similar project elsewhere (we have begin work with the University of Aberdeen towards a rural PAWS trial)

So far, this has already raised a range of interesting research questions such as:

  • Is broadband sharing is most cost effective method for local councils to get citizens online ?
  • What level of internet access is most useful (but still feasible) to new internet citizens ? i.e. what bandwidth do citizens expect and what internet services will they use PAWS for?
  • How many sharers are required to get new citizens online ? for this trial we have assumed one sharer per citizen, but were we right to assume this?
  • Are people willing to share their bandwidth and what (if any) legal issues does this introduce ?

The question that I am personally most interested in and will talk about today is: How can we build a system which allows individuals to share their broadband in a secure but easy to use manner that ensures that the shares internet experience is not notably affected ?

Broadband Sharing is nothing new …

Broadband sharing is nothing new, there are quite a few examples of similar projects, they are commonly known as “Wireless Community Networks”. Wireless Community Networks are were communities of individuals group together to form a co-op where individuals opt to share their broadband over WiFi and in turn they can use the WiFI of the other members of the community.

FON is the worlds most popular Wireless Community Network, with over 8 million members of the community. This demonstrates that individuals are willing to share their broadband, provided its sufficiently incentivised. FON demonstrates that its possible to build a system which allows individuals to share their broadband in a secure but easy to use manner that ensures that the shares internet experience is not notably affected. Job done :)

Well not quite… FON allows individuals with internet access to extend their access. PAWS aims to get individuals without internet access online, but these individuals (who make up 1/3 of the people in Aspley) cannot be part of a community like FON. FON does offer some limited access to individuals who don’t have a broadband connection but at a high cost (£6 for 90 mins at the BT FON Spot). PAWS aims to build on the ideas behind Wireless Community Networks like FON, but with the aim of providing internet access to essential public services to all.

The PAWS Model

PAWS aims to work with local partners such as local councils, community groups and charities to make access online available to all. Now for technical stuff. To meets our aims, we need to build a system with following properties:

  • Ease of Use: Sharers need to have a simple set-up so that setup does not dis-incentive individuals from becoming sharers and the network need to be easy-to-use for citizens too, as this may be there first ever time online
  • Priority: Sharers internet traffic must always be given priority over that of a PAWS citizen, to ensure that a sharers internet access is not notably affected by the sharing their broadband with the PAWS citizens
  • Confidentiality, Integrity & Availability: Providing confidentiality means ensuring that PAWS citizens and sharer cannot see each other traffic. Providing integrity means ensuring there nobody can intercept a citizens traffic (i.e. by using a rogue WiFi hotspot). Providing availability means giving citizens reliable internet access in the face of hardware failures
  • Authentication, Authorization & Accounting: Like an Internet Service Provider (ISP), we will be responsible for ensuring that PAWS citizens use the network responsibility so we need to have a record of who is using the network
  • Scalability: Though this initial trial involves 50 sharers and 50 citizens in Aspley, we want to consider how this can scale up nationally with many linked PAWS communities up and down the country.

Ease of Use

Firstly let’s consider the setup and install process for PAWS sharers. Most of the home routers that households in the UK use are provided by their ISPs. Often these are simply plugged in to the internet and left on the default settings. It wouldn’t be feasible for us to replace households home routers nor is it scalable for us to re-configure everyone’s home router. We could try to share WiFi in software, using a program such as Connectify to turn a sharers PC or laptop into a WiFi hotspot. This would require the sharer to leave their computer on, require the supported WiFi card and require us to support a range of PC platforms.

Therefore we will introduce new hardware, that will connect to the sharer network and enable broadband sharing in a secure and fair manner. Connecting using an ethernet cable, provides the best bandwidth and most reliable connection between the new hardware for sharing with PAWS and the sharer home network. For the hardware, we have chosen to use a router, called NETGEAR N600, WNDR3800 for its compatibility with software that we would like to run.

Routers, like this one, run special software called firmware. This is similar to how computer run an operating system like Windows 7 or MacOS. The firmware that will be running on the PAWS router is called OpenWRT.

This PAWS router will advertise the name “PAWS”, citizens can then use the internet by connecting to the WiFI network called “PAWS” in some areas of Aspley in Nottingham.

Priority

In order for us to make a PAWS sharers spare bandwidth available to the PAWS citizens, we need to measure the bandwidth available and use this information to decide how much bandwidth to make available to PAWS citizens. To measure the bandwidth, we run regular tests from the PAWS router. You can run a test right now to see how much bandwidth you get using a website such as www.speedtest.net orwww.broadbandspeedchecker.co.uk. For PAWS, we will be measuring the bandwidth using a tools called “BISMark”, made by a team at Georgia Institute of Technology.

In the 3 month Aspley deployment we will spend the first month, measuring the bandwidth available and the next two month making this spare bandwidth available to the citizens of Aspley. We will ensure that PAWS citizens only use this spare bandwidth by throttling the bandwidth at the PAWS router in the sharers homes.

Authentication

We need to have a record of who has connected to the PAWS network and what they have used the network for. Therefore, we need all PAWS citizens to login when they connect to the PAWS network. In the same way that you need to login to WiFi at a cafe, train station or airport. For this we will use a software called RADIUS, which is also commonly used for managing the log in’s at public WiFi hotspots. RADIUS is used to for logging into many services online and therefore we could link PAWS to local services to allow PAWS citizen to be automatically registered and use the same password as they would for the local service. This will not be implemented in the trial deployment in Aspley

Accountability & Authorization

When you connect to the internet, you are known by number referred to as an “IP address”. You can find out the IP address that you are using to visit the internet now by visiting whatismyipaddress.com. IP addresses are allocated to households by their ISP and they can be used by the ISP to identify the source of any malicious activity online. PAWS citizens need to have a different IP address when they access the internet via a PAWS router than the sharers normal internet traffic. For this we use a Virtual Private Network (VPN), which sends all of the PAWS citizens internet traffic to another computer on the internet before sending it to the internet. This means that a all PAWS citizen will have a IP address that is different to that of the PAWS sharers. We can combine the VPN with RADIUS authentication so that all PAWS citizen log into the VPN with there own username and password.

Connecting to the PAWS network will therefore involve two steps: connecting to the WiFi network called “PAWS” and then login into the PAWS VPN.

A firewall, is a set of rules that govern what traffic can pass through a device, and we will run a firewall on the PAWS router to ensure that the only way to access the internet via the PAWS network is using the PAWS VPN

Confidentiality & Integrity

We need to ensure that PAWS sharers and citizens cannot see or change each others traffic. Wireless traffic is often poorly secured, this is why you shouldn’t check your bank account when using WiFi in a cafe. The use of VPN (as just described) means that we can easily encrypt PAWS citizens traffic from the citizen device like a laptop or mobile phone to a secure computer on the internet. This secure computer that all the PAWS internet traffic goes via is known as VPN server and hosted by local company ENMET.

Scalability

Though Aspley is the first ever trial of PAWS, we hope that there will be many more to follow. We plan to enable PAWS citizens to login to PAWS within any of these deployments without needing to register

Limitations

Our system isn’t perfect and there are some open issues to address. Firstly, not all devices are VPN compatible and on some devices which are, set up can be difficult. Fortunately in the Aspley trial we will have the PAWS team on hand to help PAWS citizens, though this isn’t scalable across the country. There are different type of VPN, offering different trade offs, unfortunately there is one type of VPN that is the all round best solution. In our own initial tests, we have found that some home routers, that have provided by UK ISPs, block VPN traffic by default. This is easy to fix by logging into the home router and changing a few setting but it does require the sharer to know there router’s username and password. The PAW’s routers currently cost about £110 each, which is fairly expensive. All PAWS traffic in the Aspley deployment is routed via a single VPN server, meaning that there is a single point of failure. In the Aspley deployment, we will welcome all PAWS sharers to becomes PAWS citizens but it would be nice if we could have greater incentives to share.

Ideas for Future Work

It would be nice to extend the incentives for members of the community to become PAWS citizens, potentially by introducing a two tier system where PAWS citizens who are also PAWS sharer are able to get more bandwidth on the PAWS network. Another potential improvement is to allow PAWS citizens who are also PAWS sharer, to use the PAWS router as a VPN server for there traffic. In the future, I would like explore the potential for replacing VPN with other security connectivity method such as WPA Enterprise. The PAWS citizens user experience could be streamlined by creating a mobile application to automatically connect to VPN when the user connects to a PAWS router, this application could then be extend to allow users to view a coverage map and add feedback about quality of access available at different points.

Thanks for Listening

Comparing Wireless Community Networks

Leave a reply

As work on the Public Access WiFi Service (PAWS) continues, people regularly point us in the direction of other wide area WiFi networks. Potential we can learn a lot from these projects, from both the social and technical sides. Here I am going to try to focus on the technical details and the payment models:

For each project, I hope to us the following framework to access it:

Project Location:
Coverage provided:
Project Organisers and Partners:
Funders:
Reason for funder to invest in project:
Time network was available ?
Cost to the user:
Service provided to users in terms of bandwidth, time browsering, websites available etc ?
Are the services provides allocated per user or per device ?
What form of user sign-up required ?
Can the user by-pass these restrictions ?
How is the WiFi network secured ?
Is the WiFi network open or encrypted ? If encrypted, how easily is the password available ?
Is the network vulnerable to rough access points ?
Is the network vulnerable to packet sniffing ?
Is the network/APs vulnerable to DoS attacks ?
Are the user informed of the importance of us a VPN or HTTPS

Quick Guide : Amazon Cloud EC2

Leave a reply

The following is a quick guide to setting up an virtual server on Amazon Cloud EC2:

SETUP

1) Login to AWS Management Console using your Amazon account and navigate to EC2

2) In the top right hand corner, check that the location of the servers is the one that you would like to use, I will be using Ireland

3) In the “Getting Started” section of the EC2 dashboard, select Launch instance to create a new virtual server

4) I will be demonstrating the “Classic Wizard”

5) Select the Amazon Machine Image (AMI) that you would like to use, I will be using the Amazon Linux AMI 2012.09, 64bit edition

6) Enter the instance details, I am going to be creating 1 micro instance on EC2 so I’ve not changed any of the options on this page or the following Advanced Instance Options page or Storage Device Configuration page

7) Now you can create tags, using tags for your instances is really useful so I highly recommend it. I’ve set the key and value to “PAWS-router-management-server”

8) Creating a public/private key is vital for using SSH to access your virtual server. Give the private key a sensible name and download it

9) Creating a new security group is highly recommended, otherwise you can use make use the default group. I will be accessing the server using SSH so I’ve opened up port 22 to SHH

10) Review the opinions you have chosen and save

ACCESS

1) If you navigate to the “instances” page, you will now be able to see your newly created instance. Selecting your instance will give you access to more detailed information

2) To access your new instance, open the terminal and locate the private key you downloaded during set up

3) Change the permissions on the key using: $ chmod 400

4) Connect via SSH using: $ ssh -i

More details on the Amazon Linus AMI are available at  http://aws.amazon.com/amazon-linux-ami/ . Its useful to note that there is no root password, you can’t SSH in as root or use su but if you use sudo, no password is required and that the package manager used is yum

Hierarchical MAC Addresses

Leave a reply

I recall a supervision question last year along the lines of:

“Are the following addresses hierarchical or flat ?
a) Posrcodes
b) IP addresses
c) MAC addresses ”

Its well know that MAC addresses are flat but what if they where instead hierarchical ? This is the idea behind the MOOSE project by Malcolm Scott.  Multi-level Origin-Organised Scalable Ethernet (MOOSE) is an Ethernet switch architecture that rewrites MAC addresses to impose a hierarchy upon the address space so switches no longer need to maintain a large forwarding database.

The context MOOSE is designed for is Ethernet within datacenters

Public Access WiFi Service

Leave a reply

Whilst at the All Hands Digital Economy Conference, I met Arjuna Sathiaseelan who told me about a new project called “PAWS: Public Access WiFi Service“. It sounds quite interesting and I might be joining the team in the next few months. The project poster is here : de2012

The main motivation behind the Public Access WiFi Service (PAWS) is to enable digital inclusion, which is important in the interest of social equality to ensure access to everyday services and benefits that are enjoyed by the majority, and ensure that all members of society are able to participate fully in the Digital Economy. Not only do the digitally excluded in societies currently not have access to these benefits, alternative provision of public services is a costly endeavour. While amongst the elderly the primary factor in digital exclusion is cultural (commonly that they do not perceive value in it), amongst younger demographics who want to be online, affordability is cited as the primary barrier, named by over 40% of digitally excluded 16-44 year olds. Most digital inclusion initiatives assume affordable broadband access, indeed the commercial imperative at the moment is to convert existing users to higher speeds, rather than deploy more widely; however we believe the notion of connectivity for all being governed by the simple market economics is a major impediment to achieving the benefits of a Digital Economy, and that basic Internet should be made available to all for societal benefit; a sentiment recently expressed by Berners-Lee. Although there is no single ‘magic bullet’ to remove socio-economic barriers, there are infrastructural solutions that could drastically reduce them. Our proposal is a first step in this direction: a feasibility study to establish technical requirements and identify the current practices and needs of the digitally excluded. Following successful demonstration, we hope that government policy can be nudged to support industry uptake leading to national deployment.

Our proposed programme of research seeks to inform and develop technology enabling free Internet connectivity for all, paving the way to new access models. We propose PAWS (Public Access WiFi Service), a new Internet access paradigm based on Lowest Cost Denominator Networking (LCD-Net) – a set of techniques making use of the available unused capacity in home broadband networks and allowing Less-than-Best-Effort access to these resources (lower quality service compared to the standard Internet service offered to paid users). Case study deployment of this technology will be underpinned by a programme of social research which will establish a socio-economic profile of the area, recruit potential participants and, most importantly, conduct a longitudinal multi-method assessment of participants’ current practices and subsequent experiences of this technology.

PAWS takes the approach of community-wide participation, where broadband customers can volunteer to share their high-speed broadband Internet connection for free with fellow citizens. Initiatives in the past have looked at sharing a user’s broadband Internet connection via their wireless connection (for e.g. BT FON). Although these methods are gaining worldwide acceptance, they are usually viewed as an extension of a user’s paid service – PAWS will extend this to support free access by users. As it is essential to ensure that the free user traffic does not impact perceived performance of the bandwidth donor, we will explore the impact of free services available through LBE access (also known as the Scavenger Class) to the network. These methods allow a person to use a shared link without competing for the resources of those who have shared their Internet connection. We will also explore the benefits offered by our proposed method to users and network operators. It is necessary for this work to be conducted ‘in the wild’ as it requires the deployment of technology to end-users, and subsequent assessment of its impact. The project will increase access opportunities, enabling digital inclusion and in turn supporting the UK Government’s ‘digital by default’ programme with its associated cost savings and service improvements”

Source: http://gow.epsrc.ac.uk/NGBOViewGrant.aspx?GrantRef=EP/K012703/1

Fault Tolerance comes to Twitter in the form of Twimight

Leave a reply

Making twitter fault tolerance may not seem like a priority at first thought, I mean surely in the unlikely event of the network failure, those 17 year of girls can will just have to learn to wait before they can tweet about there new jimmy shoes.

But if you consider further the situations in which network failure is likely to occur such as natural disaster, this is when twitter is needed the most. Here is an xkcd to illustrate the point

Seismic WavesIts difficult, particularly if you didn’t grow up with twitter to understand why keeping social network alive in the event of a disaster is so important. But like it or not, twitter is just as essential in some peoples live than other (more traditional) communications form such as text messaging or TV broadcasts. In fact, it could be argued that since scarcity of information is often a problem for individuals in a disaster, the broadcast properties of twitter, make it potential more useful than  uni cast text messaging or voice calls.

TWIMIGHT

The application to which has introduced this ‘disaster mode’ to twitter is called Twimight, its a open source twitter application with a couple of very interesting features. I’ve going to test out the application on my nexus 7.

The basic interface of the application is very similar to that of the standard twitter application but an exploration of the overflow icon highlights a range of features, that could be particularly useful in a disaster.

The basic idea of how this application aims to enable connectivity in a disaster situation is as follows:

  • Android device users install the application and get there friends to do the same
  • Bluetooth is used to pair your android device with your friends android devices
  • Disaster occurs so network connection is lost and the user enables the ‘Disaster Mode’ within the application which turns on bluetooth in an always discoverable mode
  • The user tweets despite the lack of a network connection
  • The tweet is send (via bluetooth) to friends within range
  • The disaster is over and the network connection is restored
  • Tweets are automatically posted to the web

ANDROID SENSOR TWITTETH

Twimight also support a plug-in called android-sensor-twitteth

TDS COMMUNICATIONS

The twitter disaster server is used to collect user activity and environment data

THE PLATFORM

In case of a disaster, individuals do not want let any other peice of hardware to carry around but given that 3/4 of the world’s population now have access to a mobile phone and that twitter now has 500 million users, mobile twitter access has the potential to be a powerful force for good.

The UX is designed such that its simple to use in a stressful situation, with the user enabling the ‘disaster mode’ in the application with a simple check box (though this box is a little harder to find than I would ideally like)

USE OF BLUETOOTH

Before Bluetooth can be used for the automatic spreading of tweeter messages, the devices must be paired, those potential irritating to the user, this is essential to allow the application to make up of the bluetooth protocol.

Once the user has enabled ‘Disaster Mode’ the application enables bluetooth, scanning takes place every  2 mins +- 20 sec

IMPACT ON BATTERY LIFE

Power consumption is important considation for all mobile applications, in this case it is particularly important as its more unlikely that users will have access to pwer supplies and suitable chargers. In ‘disaster mode’ the use of bluetooth much therefore be considered carefully. Bluetooth scanning time need be as high as possible to increase the speed of the transition of tweet, whilst using minimal battery life. The power saving heretics for Twimight are set so that the scanning interval is  reduced when battery is less than 50 % and scanning is stopped when battery is less than 30 %.

CRITICAL MASS

This application like many others, we be almost unless to individuals unless the number of devices that the application is install on reaches a critical number such that in the case of a disaster, there is at least one individuals within bluetooth transmitting distance with the application installed

This application will not be able to reach this critical mass, because individuals will not have the foresight to install such an application, “just in case” they were to need the disaster mode it provides.

Consider instead, the hypothetical case that twitter was to adopt such a “disaster mode” into its own supported mobile application.

The official twitter application has 578,194 downloads from the play store and 500 million activated android devices. So twitter and android are powerful platforms but with a typical bluetooth range of 10 m and the requirement for pair devices, is bluetooth really the best wireless protocol for this use

CASE STUDY : TWITTER & GREAT EAST JAPAN EARTHQUAKE

Tsukuba is a city of 200,000 located in Ibaraki Prefecture, Japan. Tsukuda lost electricity, communication networks and water immediately after the Great East Japan Earthquake of March 2011. The lack of power meant that smart phones became key devices for communication. Muneo Kaigo has written an excellent Keio Communication Review, examining the use of twitter in Tsukuda in the 7 days following the earthquake and I thoroughly recommend it

SOURCES

twimight hosting on google code –  code.google.com/p/twimight/
twimight unofficial application location –  twimight.googlecode.com/files/twimight_0.9.2.apk
android-sernsor-twitteth hosting on google code – code.google.com/p/android-sensor-twitteth/
the paper – people.ee.ethz.ch/~hossmath/papers/extremecom11_twimight.pdf
presentation from Extremecom 2011 – www.slideshare.net/thossmann/twitter-in-disaster-mode-extremecom-2011 
Keio Communication Review No. 34, 2012 – Social Media Usage During Disasters
and Social Capital: Twitter and the Great East Japan Earthquake –

DNSSEC – A basic Intro

1 Reply

This article aims to not just explain how DNSSEC work but why the protocols are designed the way that they are. I will begin with a simple mental model of public-key cryptography, then I highlight issues with scheme described so far and add complexity to fix issues as I highlight them. I finish the article with a simplified model of DNSSEC and a range of problems/question that I hope to explore in the next article.

DNSSEC is a collection of IETF specifications for securing DNS data. It is a set of extensions to DNS which provide to DNS resolvers with:

  • origin authentication of DNS data
  • authenticated denial of existence
  • data integrity

It does not provide the DNS resolvers with:

  • availability
  • confidentiality, DNSSEC results are not encrypted
  • protection from user mistakes/assumptions

DNSSEC aims to adds security to DNS, while maintaining backwards compatibility.

RFC 3833

DNSSEC protects DNS resolvers from forged DNS data, by digitally signing all DNSSEC replies. The DNS resolver is then able to check if the information it receives is identical to that information on the authoritative DNS server.

DNSSEC can also protect information such as cryptographic certificates stored in CERT records in DNS.

RFC 4398

RFC 4367

Negative article on DNSSEC

DNSSEC-bis is the name of the DNSSEC specification and the related RFCs are
4033 introduction & requirements, 4034 resource records for DNSSEC and 4035 on protocol modifications.

Public-key cryptography is the use of two keys, one public and one private to encrypt and decrypt a message. A message before encryption is referred to as plain text and a message after encryption is referred to as cipher text.

Public-key cryptography can be used to provide confidentiality or authentication.

To provide confidentiality, the public key is used for encryption so anyone can write a message but only the intended recipient has the private key which is used for decryption, so the only person who can decrypt the message is intended recipient.

To provide origin authentication, the private key is used for encryption so the only person who can send an encrypted message is the intended source. Then the public key is used for decryption so anyone can read the message, provided it was written by the intended source.

Figure 1 – How public key cryptography can be used to provide authentication or confidentiality

DNSSEC works by digitally signing the results of DNS look-ups using public-key cryptography. It uses public-key cryptography to provide authentication not confidentiality. This means that private key is used for encryption and the public key is used for decryption. So when a DNS resolver makes a DNSSEC query, then the response will be signed by the correct information source and then the DNS resolver will use the public key to decrypt the response, knowing the response is reliable as it was definitely send by the intended source.

So that’s the problem solved, the DNS responses will be encrypted by correct source and then all the DNS resolvers will decryption the responses using the public key. This ensures that the response was sent by the correct source so it provides source authentication as well an data integrity as it was signed using a private key.

Except that this model completely ignores the details of how DNS actually generates the replies to DNS query and what exactly is the “intended source” in this context.

So now I want to explain why the basic public-key cryptography scheme that I outline is not sufficient to provide authentication.

The cryptography scheme aimed to provide authentication between the DNS resolver and the source of the DNS response, but it didn’t consider the details of how this DNS response was generated.

The actually answer is that the “intended source” in DNS is an Authoritative Name Server, There are many authoritative name server forming a distributed database, each authoritative name server responses to a specific subset of the DNS queries.

The DNS resolver needs to locate the relevant authoritative name server, this is achieved through a chain of domain name servers, either recursively, iteratively or a hybrid of them both.

To generate the response to a DNS query for the DNS resolver, there are a series of request-replies. So for DNSSEC to meet its primary goal of providing authenticated responses, there needs to be authentication throughout the chain between the DNS resolver and the intended source, which is the authoritative name server.  When a DNSSEC enabled DNS resolver gets a response then it can use the public key to check that it was encrypted by the authoritative name server.

So now we have fixed the problem … Actually not

This solution would require that all DNS resolvers change because all DNS resolvers need to decrypt the DNSSEC response using the public key to get the the normal DNS response. Given that DNSSEC nees to be backwards compatible with DNS, this means we need to alter the above scheme.

So instead of encrypting and decrypting the whole DNS response, why don’t we add some text to the DNS response as another resource record and then encrypt and decrypt that text instead. This means that DNS resolvers that are not DNSSEC compatible can simply ignore the extra resource records. This extra bit of information therefore acts as a digital signature. This is actually used in DNSSEC and the new resource record is called RRSIG.

Now we have DNS record with an extra resource record called RRSIG, the authoritative name server has the private key and the DNS resolver use the public key to check that the DNS information received was from an authoritative name server. But where do the DNS resolvers get the public key from ?

A simple idea would be to have a single server with all public keys on, then all DNSSEC enabled resolvers could just request the public key from the central server. This is fundamentally flawed as its a centralized system which would completely defeat the purpose of DNS, which is to act as a distributed system.

Therefore we need a distributed system of our own to get the public keys to the DNSSEC enabled resolvers, why not use a system like DNS or even DNSSEC ?

DNSSEC gets the public key, from the authoritative name server to the DNSSEC enabled resolver by introducing another new resource record called DNSKEY. This has the public key in it so that the DNS resolver can use it to verify the RRSIG.

Done ? Nope of course not …

So its easy to assume that we finished here but as we developed the scheme we have actually introduced new issues, for example we have lost any data integrity. Its easy for a 3rd party to intersect a DNS query, change the data in the resources and set it forward to its destination. The DNSSEC enabled resolver would be nun the wiser, as the response to the DNSSEC query is still correctly signed and will have the correct RRSIG.

We can fix they by making the plain text in the RRSIG, a hash of the original message. This means that if the messaged is changed in transit then the DNS resolver will detect it because after decrypting the RRSIG text and hashing the other resource records, the results will no longer be the same because the hash generated from the DNSSEC response will be different to the RRSIG one as the text has been changed.

Lets review where we have got to so far…

DNSSEC uses public-key cryptography to provide authentication and data integrity between authoritative name servers and DNS resolvers. It does this using two new resource records, RRSIG and DNSKEY.

The authoritative name server hashes the RRs and then uses a private key to encode this hash, the result is placed in the RRSIG record and the public key is placed in the DNSKEY record. Then the DNS response moves though a chain of domain name servers to the DNS resolver. If the DNS resolver supports DNSSEC then it will use the public key in the DNSKEY record to decrypt the RRSIG, this will give a hash of the other RRs, the resolver can then hash the other RRs and compare the results.

So what is this public-key cryptography algorithm that DNSSEC uses and whats going to happen if its broken in the future ?

DNSSEC doesn’t use a specific algorithm. Both DNSKEY and RRSIG have a 8 bit number, which corresponds to the algorithm used, details of with values correspond to which algorithms is available here

This scheme has a big problem though…

Consider the following situation, I am an evil 3rd party would wants to return the incorrect DNS respond to a (DNSSEC enable) DNS resolver :

  1. The (DNSSEC enable) DNS resolver places a DNS request for www.google.com
  2. I spot this and I want to send a reply to this DNS request that will not be from the authoritative name server, managed by Google
  3. So I’m going to make my own response and make it appear as its has comes from the authoritative name server
  4. I create RR with the incorrect information and I then come up with my own public and private key pair, using the private key to encrypt the hash in the RRSIG and then place the public key in the DNSKEY record
  5. The DNS resolver then decrypts the RRSIG record using the key in the DNSKEY and checks that its a hash of the other RR records
  6. The DNS resolver believes that the response is from the authoritative name server at google

The problem is the above situation is that although the RRSIG and DNSKEY resource records aim to authenticate the other resource records, there is nothing to prevent a 3rd party changing the RRSIG and the DNSKEY. What we need is a method of authenticating the DNSKEY.

If we assume for a moment that the DNSKEY is authenticated, then a (DNSSEC enable) DNS resolver will be able to detect if the other resource records have been changed. As the decrypted RRSIG will not be a hash of the other resource records. If a evil 3rd party also when tries to also change the RRSIG value, so that the decrypted RRSIG is a hash of the changes made, then they can do this only if they know the private key. But they do not know the private key used and they cannot replace the public/private key pair as we have assumed that the DNSKEY is authenticated

So how can we ensure that the DNSKEY is from the authoritative name server ?

DNSSEC works around this is by signing the DNS replies at each step in the chain of response and reply. So when a domain name server queries another domain name server, not only is the expected result returned but also a flag indicating if that zone used DNSSEC and if it does it includes a hash of the DNSKEY record stored in a record called DS.

So far we have introduced 3 new resource records to DNS:

  • RRSIG – a hash of the other RRs that is encrypt using the private key by the authoritative name server
  • DNSKEY – the public key associated with the private key used to encrypt the RRSIG, a DNS resolver then using this public key to decypt the RRSIG and check that the plaintext is a hash of the other RRs
  • DS – a hash of the DNSKEY used in the zone that the DNS resolver is about to query so that the resolver can check that the response from the next name server query has not had the DNSKEY altered because it can check the DNSKEY received with DS received from the last name server.

This hash is then used when the name server queries the zone, as the DNSKEY returned hashed should match the DS RR from the previous query. If the response doesn’t include a DNSSEC RR or the DNSSEC hashed is not the same as the previously returned DS RR, then the integrity of the data has been comprised.
Example
This diagram attempt to demonstrate how the chain of DS and DNSKEY allows use to assume that the DNSKEY has not been tampered with. In this example, a DNS resolver queries the root DNS name server and its returned with the normal DNS response as well as a DS resource record. This DS RR is a hash of the DNSKEY that will be returned then the next DNS request is made. The DNS resolver then queries a TLD name server, this returns the normal DNS response as well as a DNSKEY and another DS. Now the DNS resolver can check that the response was from the TLD name server by checking that the DS that is recieved prevously from the root DNS name server is a hash of the DNSKEY. The DNS resolver can now contiune as it has the DS, which is a hash of the DNSKEY that should be returned by the next name server

Figure 2 – DNSSEC chain of trust created using corresponding DS and DNSKEY RRs, this assumes that the response from the root DNS can be trusted

 

How does the DNS resolver know that it can trust the result from the root DNS server ?

In the above example we cant guarantee that response from the root DNS server is actually from the root DNS server, this is why we introduce a trust anchor

Figure 3 – chain of trust between a trush anchor and the authoriatative name server using a series of DS and RRSIG resource records

But this appears just to move the problem, how can we trust the trust anchor ?
We get the DS resource record using a different method where we don’t need to authenticate the origin as we know that the message can’t have been intercepted (i.e. via the operating system)

As you can see we have created a chain of trust using a series of corresponding DS records and DNSKEYs, this means that when we reach the authoriative DNS name server, we know that we can trust the DNSKEY and that is will not have been tampered with.

There is a fun website here, which provides information on the chain of trust.

Thing to consider in the next article:

  • What’s the difference between a validating and non-validating stud resolver, which is better ?
  • DNSSEC also introduces NSEC and NSEC3 resource records, what are these used for ?
  • DNSSEC requires use of the “DO” flag in  EDNS, why don’t the DNS resolvers just ignore the RRSIG. DNSKEY and DS resource records ?
  • What happens if the authoriative name server do not support DNSSEC, how does the resolver know the difference between DNS response from an authoriative name server that don’t use DNSSEC and a attach where the evil 3rd party tries to pretent the the authoriative name server dose not use DNSSEC
  • How exactly goes the trust anchor get the DS for DNS root, what happens if the root DNS needs to update the DNSKEY and therefore the DS record in the trust anchor, if for example the cyptographic algorithm is broken
  • How does a authoriative name server prove that an DNS entery don’t exist ?
  • In July 2010, the DNSSEC was added to the root DNS, could you use DNSSEC before the root DNS support DNSEC if all other name server and the resolver supported DNSSEC ? DNS Lookaside validation ?
  • What happens when a name server between the root and authoriate name server doesnt support DNSSEC but the other name server involved do ?
  • Why are there additional timestamps in the RRSIG to limit the time that the signiture is valid ?
  • Why are these timestamps absolute not relative like TTLs ?
  • How are new keys implemented and what about the caching?
  • Whats zome emuation and how can it be dealt with ?

Notes on "A Close Examination of Performance and Power Characteristics of 4G LTE Networks"! – Pt1

Leave a reply

These are my notes on “A Close Examination of Performance and Power
Characteristics of 4G LTE Networks” which can be found here

4G is as the name suggests, the forth generation of mobile communication standards. There are currently two competing technologies, Mobile WiMAX and LTE. Long term evolution (LTE) is the technology that this paper considers.

4G Test Android Application

The team designed an android application called 4GTest. It is available in the Play store here. The application measures the network performance including latency, download speed and upload speed.

The application description claim that the results produced by this application are more accurate that any other test using single-threaded TCP tests.

I tested the application on an old HTC Magic but I couldn’t get the application to recognize my internet connection. The application is not compatible with the Nexus 7.

Overall Results/ Conclusions

The abstract states that “LTE generally has significantly higher downlink and uplink throughput than 3G and even WiFi, with a median value of 13Mbps and 6Mbps, respectively”. I am not sure why the median value has been quoted here instead of the mean value (if you know why, please comment below).

The data set for the study was 20 smart phone users over 5 months, this seems like a fairly limited sample size.

The power model of the LTE network, had a less than 6% error rate. It was found that LTE was less power efficient than WiFi and 3G. Testing of android applications highlighted that the device power is now becoming a bottleneck, instead of network performance, compared to 3G.

Long term evolution
LTE aims to enhance the Universal Terrestrial Radio Access Network, more commonly known as 3G. LTE is commercially avaliable but is not yet wide spread. The targeted user throughput is 100Mbps for downlink and 50Mbps for uplink. These targets are distinctly different to median values of 13Mbps and 6Mbps, respectively previously quoted.

User-plane latency is defined as the one-way transit time between the availability of a packet at the IP layer (the network layer) at the source and the availability of this packet at the IP layer (the network layer) at the destination. This definition means that user-plane latency includes the delay introduced by associated protocols. Since the delay is measured from network layer to network layer, we do not need to consider the delay introduced by the application layer or transport layer.

LTE can be compared to other networks such as Wi-FI and 3G by comparing network statistic such as bit rate, latency, user equipment (UE) power saving etc..

LTE uses Orthogonal Frequency Division Multiplex (OFDM) technology.
OFDM is based on FDM, but FDM wastes bandwidth as you need to leave bandwidth free between different carriers to stop the signals from interfering with each other. OFDM allows the carriers to be more closely spaced together so less bandwidth is wasted.

But OFDM is less power efficient as its more complex and requires linear amplification. To save power, LTE up ink uses a special implementation of OFDM called SC-FDMC.

Discontinuous reception (DRX) is also employed to reduce UE power consumption by some existing mobile technologies. LTE supports DRX. DRX is configured on a per UE basis and allows tradeoff to be made between power saving, delay and signalling overhead.

This study differs from previous ones since it doesn’t use either total on time or simplified LTE. Furthermore it uses real user traces instead of synthetic packets. UMICH refers to the real user data set of 20 smartphone users over 5 months, this data consists of user traces from Wi-Fi and 3G networks but not from LTE networks. So instead Wi-Fi traces are feed into the LTE model simulation framework, Wi-Fi traces were chosen over 3G as the RRT of Wi-Fi is more similar to that of LTE than 3G.

The study shows that LTE is less power efficient than WiFi and 3G for small data transfers but for bulk data transfers LTE is more power efficient than 3G but not Wi-Fi. Because LTE is more efficient than 3G for bulk data transfer then its important to make us of application tools such as Application Resource Optimizer (ARO) (MobiSys11 demo here) in LTE.

LTE is less power efficient than WiFi and 3G, even when DRX was used.

In LTE, the tail timer is the key parameter in determining the trade off between UE energy usage, performance and signalling overhead.

The study identified performance bottlenecks for android applications caused by device processing power, this is detected by monitoring CPU usage of application on the android devices.

Background on Radio Resource Control (RRC) and Discontinuous Reception (DRX) in LTE

Radio Resource Control (RRC) is a signalling protocol between user equipment (UE) and the 3G network (or 4G in this case). Long term evolution (LTE) has two RRC states: connected and idle. The transition from RRC-connected to RRC-idle is made when no data have been received/sent in a time peroid. The transition from RRC-idle to RRC-connection is made when some data is received/sent

Discontinuous Reception (DRX) is a used in mobile communication to conserve power. The UE and the network (in this case LTE) decide on phases when data transfer occurs, outside of these phases the network reciever on the mobile device is turned off thus consuming less energy.

For example. in 802.11 wireless networks, polling is used to control DRX. The mobile device is placed into standby for a set time interval and then a message is sent by the access point to indicate if there is any waiting data, if not then it is placed in standby again.

When LTE is RRC-connected state, then the UE can be in continuous reception, short DRX or long DRX. When LTE is RRC-idle, then the UE is only in DRX mode. Long DRX and short DRX are cycles of the receiver being on and off. The receiver is off for longer in long DRX, which increases delay but reduces emergy consuption. The receiver is on for longer in short DRX, which increases energy consuption but reduces deley. The parameters which dictate the length of time before various transitions, controls the trade-off between battery saving and latency.

Network Measurement
The android application designed to collect test data was called 4GTest and allows the user to switch between 3G, WiFI and LTE. The application made use of M-lab support. Measurement Lab (M-lab) is an distributed server platform for the deployment of internet measurement tools. The server-side tools are open source and the API’s allow researchers to develop client tools such as 4GTest.

When considering RRT for LTE, its important to consider the latency of the wired parts of the path from client to server because the latency of LTE is lower than that of 3G so errors (caused by wired parts) become more notable. To minimize the path from client to server, which is not LTE, the nearest server to the client is always used.

If GPS was not available then IP address was used to locate the client. This translation from IP address to GPS is a rough estimate. The service used for this translation was MaxMind.

To measure RRT and latency variation (difference in latency between connections not packets so its not called Jitter), the application repeatedly established a new TCP connection with the server and measures the delay between SYN and SYN-ACK packet. The median RTT measurements and the variation are reported to central server

To measure peek channel capacity, 4GTest sets up multi-threaded TCP measurements using the 3 nearest servers in M-lab. The throughput test lasts for 20 seconds, the first 5 seconds were ignored due to TCP slow start then the other 15 sec are split into 15 1 sec bins. The average throughput for each bin is calculated and the median of all bins is the measured throughput.

Interestingly, the median is used here instead of average as median reduces the impact of abnormal bins.

To collect packet traces on the android phone, tcpdump was cross-compiled.

To capture CPU usage history, a C program was written to read /proc/stat in the android system.

To understand the impact of packet size on one-way delay, delay was measured for a range of packet sizes and for each packet size, 100 samples were measured.

Power measurements were made using a Monsoon power monitor as power input for the android phone. Phone screen was turned off where possible.

The data set used for analysis is called UMICH and includes full packet traces in TCPdump format including both headers and payloads

The network model simulator takes the binary packet trace files in libpcap format and percessioning is required to collect accurate data.

Application performance 

The sample applications tested where some of the most popular apps. For the browser a simple website and a content-rich website were both tested. The approach taken involved launch the applications and then monitoring upstream, downstream data and CPU usage.

LTE Network characterization

These results are from the public deployment of 4GTest. In the US, the coverage of LTE, WiMAX and WiFi were found by 4GTest to be similar.

The public deployment of 4GTest found that the downlink and uplink throughput were both much higher for LTE than for Wi-FI, WiMAX and 3G technology. High variation in LTE throughput was observed.

For RRT and Jitter, LTE was found to have similar values to WiFi and better values than 3G and WiMAX

One-way delay and impact of packet size
On Wifi, packet size didn’t seem to influence one way delay, in either direction. On LTE, the uplink delay increases as packet size increases.

Modility
The requirements for LTE highlight that the network should be optimized for UE at low mobile speed (0 to 15 km/h) whilst still supporting high mobile speed (15 to 120 km/h).It was observed that in the face of speed changes, RTT remains stable and no significant change in throughput was observed.

Time of Day
Time of day was not found to have significant impact on the observed results .
 

TCPdump – An introduction

Leave a reply
As per usual, if you find any mistakes, concepts that could be explained better or have something to add, then please comment below and I’ll correct it.

What is TCPdump ?

TCPdump is a command line tool that is used to look at packets on the network. TCPdump does not generate the packets itself but instead it analyzes the packets generated by other applications and from this, it can determine network behaviour and performance.
Despite being called TCPdump, you can choose from a range of protocols including IP,ARP, TCP and UDP.

How do I get TCPdump ?

From Ubuntu, I simply got it via ‘sudo apt-get install tcpdump’. Otherwise the public repo is located here, along side some useful information and the manual pages.
You can also check the dependencies of TCPdump using ‘apt-cache depends tcpdump’. The output that this returns for me is:
  Depends: libc6
  Depends: libpcap0.8
  Depends: libssl1.0.0
  Suggests: apparmor
  Conflicts: tcpdump:i386
If you get the package for the public repo, then you need will extract the content of the .tar.gz file using ‘tar -zxf tcpdump-4.3.0.tar.gz’ after using cd to move to the directory that you downloaded the file to, then install the program.

So I’ve got it.. but how do I use it ?

To start with use ‘sudo tcpdump’ to output to the terminal, this gives the standard output of TCPdump, using the default arguments since you have not passed TCPdump any arguments yet. To the output will be printed to the terminal, until you stop the program using Ctrl-C.Don’t be scared … we will now begin the break this output down into understandable section (if you not scared then try ‘sudo tcpdump -v’ or ‘sudo tcpdump -vv‘  for a verbose output).

Changing network interface
When I’m using tcpdump, it listened on eth0 by default, but you can change this. Entering ‘sudo tcpdump -D’ will return a list of network interfaces that you can choose between. For me this returns:
        1.eth0
        2.wlan0
        3.usbmon1 (USB bus number 1)
        4.usbmon2 (USB bus number 2)
        5.any (Pseudo-device that captures on all interfaces)
        6.lo
The first item in the list is the Ethernet port, the 2nd is the Wireless card and the 3,4,5th is self explanatory. The 6th is the loopback virtual interface (more information here on wikipedia)You can then change the interface, by calling TCPdump using ‘sudo tcpdump -i ‘. For most of my work, I use the local Wi-Fi so can change the interface from Ethernet to wireless using ‘sudo tcpdump -i wlan0’.

Creating a file to store the tcpdump arguments
So far, we have only added one argument when we call TCPdump, but there will be a lot more to come. We can save these arguments, which filter the output of TCPdump to a file and then use the file when we call TCPdump.Create the file using your favourite text editors (mine in gedit at the moment) and then pass the file to TCP dump using ‘sudo tcpdump -F ‘. The file dose not need any special file extension or layout.

You may need to change the file permissions so that TCPdump can extract the file. You can view the file premissions using ‘ls -l ‘. The ‘ls’ part is command line tool to list the files in a directory and the argument -l means use long format so the file permissions will be included. The file 10 characters are the file permissions, they are decoded as follows:
  1. ‘d’ means this is a directory and ‘-‘ means this is a file
  2. ‘r’ means that the file owner can read the file, ‘-‘ means they can’t
  3. ‘w’ means that the file owner can write to the file,  ‘-‘ means they can’t
  4. ‘x’  means that the file owner can execute the file,  ‘-‘ means they can’t. If this is a directory then ‘x’ means that the owner can list the files in directory, ‘-‘ means they can’t.
  5. ‘r’ means that the file group can read the file, ‘-‘ means they can’t
  6. ‘w’ means that the file group can write to the file,  ‘-‘ means they can’t
  7. ‘x’  means that the file group can execute the file,  ‘-‘ means they can’t. If this is a directory then ‘x’ means that the owner can list the files in directory, ‘-‘ means they can’t.
  8. ‘r’ means that everyone else can read the file, ‘-‘ means they can’t
  9. ‘w’ means that everyone else can write to the file,  ‘-‘ means they can’t
  10. ‘x’  means that everyone else can execute the file,  ‘-‘ means they can’t. If this is a directory then ‘x’ means that the owner can list the files in directory, ‘-‘ means they can’t.
For me, the default file permissions are ‘-rw-rw-r–‘. This therefore means that the file owner doesn’t have permission to execute the file. This can be changed using ‘chmod u+x ‘. The command line tool is chmod, this is used for changing file permissions, ‘u’ means we are considering the users permissions, ‘+’ means we are granting a permission and ‘x’ means we can considering the execute permission. Now, if I redo ‘ls -l ‘ the new result is -rwxrw-r–.
  
Sending the output to file
You can send the output of tcpdump to a file instead of printing it to the terminal using ‘sudo tcpdump -w ‘. This output is not saved as a plain text so you can’t just read it in a text editor instead you need to use a special program to read the file and extract information from it. You can do this using tcpdump by ‘tcpdump -r ‘. Alternatively you can open it using wireshark, launch wireshark and using File>Open.
 
Filtering information by protocol
To filter packets by protocol, add the name of protocol to the arguments of tcpdump so use something like ‘sudo tcpdump ‘. The main protocols that I’m likely are use are IP, ARP, TCP and UDP but others are available, see the man pages for a full list
Filtering information by direction to different hosts
To filter packets by a direction and host, add the direction and then the host name. Possible direction options are src, dst, src or dst, src and dst. You specify the host using its IP address. You can use the logical operators not, or and and. For example, you can look up the local IP address of your machine using ‘ifconfig ‘. If you don’t specify the name of the interface, then all interfaces will be listed. Now if you only want to view incoming traffic you can use ‘sudo udpdump dst ‘.
Change the level of detail 
Compared to the level of detail provided by the standard query, The detail can be reduced using ‘-q’ for quiet output or increased using ‘-v’ for verbose, ‘-vv’ for more verbose and ‘-vvv’ for even more verbose.
The opinion ‘-t’ means do not print timestamp on each line and the option ‘-a’ allows you to display each packet in ASCII or ‘-x’ to display in hex or ‘-X’ to display in hex and ASCII
View IP address instead of domain names
You can stop the translation of IP address to domain names using the ‘-n’ opinion and you can stop the translation of port number too using the ‘-nn’ opinion
Sources of Info
Wikipedia article, which contains very little information
Official public repo, including the man pages and FAQ
Useful online tutorial at openmaniak, this site also has good tutorials on networking tools that I’ve previously covered including wireshark, OpenVPN, Iperf and ping.