JANET Development Eye

For the last few IETF meetings, the Internet Society (ISOC) have arranged panel discussions on challenges facing the Internet engineering community.  At IETF 78, here in Maastricht this week, the lunchtime discussion was on DNS.

With the root zone now signed with DNSSEC, the discussion was around were to go next with the DNS.  Moderated by Leslie Daigle (ISOC), she started out by noting that “the DNS” can mean one of at least three things — the protocol, as documented in RFCs; the infrastructure of servers and resolvers; or the contents of the tree.  Danny McPherson (Verisign) went on to frame the discussion by putting the DNS in the context of “confidentiality, integrity and availability” before talking about the DNS Quandry, a scale that went from truth at one end, the examples being DNSSEC, carriage of certificates, DKIM, service locators, through NAT and NAT-PT, topologically localised responses, and flux, either malicious or benign, through to lies at the other end of the scale, the examples of which were national policies, AAAA whitelisting, bot containment, response synthesis, reputation services, cache poisoning, rogue resolvers and ending up at static host records.

As more information is placed in the DNS, Patrik Faltstrom (Cisco) asked should that data be put in the DNS, or should all that appears in the DNS be a pointer to the data?  A nod to the computer science maxim that anything can be solved by the addition of a layer of indirection!

This spurred a discussion about some of the things that have been put in the DNS that shouldn’t have been, and what constraints are placed by the hierarchical nature of the system and the exact match on name, class and type without any “fuzzy” matching.

From there the discussion moved to when do we start thinking about DNSng?  What features should it have?  Fuzzy matching?  The ability for several names to point to the same object?  There were a couple of ideas about this, Lars-Johan Liman (Autonomica) described a possible system with a much reduced, simpler DNS that might provide pointers to other resolution services.  Patrik suggested it may not be so easy, which Lars-Johan readily agreed with.  There have also been several proposals over the years about “peer to peer DNS.”

Some of the lessons that have been learned from previous attempts to modify the DNS brought up the topic of A6 records, which was once an alternative to the AAAA records now in widespread use.  The A6 record, defined in RFC2874, was a flexible solution to having long IPv6 addresses in the DNS by using binary labels and having the ability to specify the prefix and the host address separately, but was a step too far in complexity for people getting to grips with IPv6.  Another “learning opportunity” was the move from “ip6.int” to “ip6.arpa” for IPv6 reverse lookups.  This is also a more generic topic about how to get new protocols into operation, not just with the DNS.  It often requires a few iterations of protocol design, testing, initial deployment, and learning the lessons from that deployment.

To wrap up, the panel came back to the topic of DNSSEC.  Whilst the root is now signed, top-level domains are starting to register their DS records in the root, and an increasing number of second level domains are signed, this is not useful until resolvers start to verify DNSSEC keys and report errors.  It has taken 13 years since the publication of the first DNSSEC RFC to get this far, how long will it take to complete the picture?

Several JANET sites that have a /16 of “legacy” address space, i.e. obtained directly from the InterNIC before the days of Regional Internet Registries (RIRs) such as the RIPE NCC, report that today they have received a request to buy a /24 out of that space for US$5k.

The request has come from a company called Ideco, and in the pattern I’ve seen so far, the second and third octets of the address space being requested are identical.  I.e. from A.B.0.0/16, the company is asking for A.B.B.0/24.

My initial reaction was that this was likely to be a spammer looking for “clean” address space that would be used as to send out spam, then discarded when it had appeared in too many blacklists, potentially also harming connectivity to the larger /16 if some of the more zealous blacklist operators failed to spot the sub-allocation.

However, earlier this year the same company approached RIPE and asked if they could request a specific address range to have a “memorable” DNS resolver address:

http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2010/msg00038.html

It would have been difficult to gain consensus to change RIPE policy to achieve this, and it was suggested they might have more luck by trying to obtain address space elsewhere.

http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2010/msg00061.html

This is what they now appear to be doing.

I have heard reports that some customers of SWITCH, the Swiss Research and Education network, have received the same request, so it is likely that it has been distributed quite widely.

Transfer of ownership of legacy address space is a gray area in current policies, but it is one we need to come to grips with soon as IPv4 exhaustion raises the prospect of address space becoming an asset with value.  I’d like to see the development of a community within JANET that allowed address space to be traded for minimal value in the cause of education and research, but that will be increasingly difficult to justify as the value increases.

Assuming that value increases at all, of course.  Widespread deployment of IPv6, with many addresses available at low (no) cost may decrease the value that IPv4 address space will hold, but uptake of IPv6 is still slow, even among the R&E community.

That is a digression.  If you’ve received such a request, I suggest careful consideration of what is involved in registering the transferred address space and fragmenting your own routing advertisements to cope with the loss of that one single /24 from some arbitrary part of the larger assignment.  I strongly suggest that not only is US$5k insufficient compensation for that, but there could be reputational harm in doing so.

A fascinating talk at the Gikii law conference by film-maker Hugh Hancock of Strange Company on story-telling and why the arguments in favour of the Digital Economy Act were more persuasive than those against. Hugh suggested that any good film script needs a Protagonist (a character who the audience can imagine, and with whom they empathise, though “you” is too vague), Stakes (the higher the better, but they must be explained before the audience gets bored) and an Emotional Payoff, so the audience experiences, perhaps vicariously, some feelings by the end of the story.  Virtuously defending someone who has been wronged is a good emotional payoff, as is envy of someone who has benefited unjustly; fear is good but overused; anger only works for geeks!

Given this analysis it’s pretty clear why restoring the income of struggling artists/photographers wins over a vague fear that “you will have your network connection cut off” (the audience for this particular story probably doesn’t see that as particularly high stakes). I’m not yet sure how we can better present the problems that might be caused by careless implementation of the Act, but Hugh’s framework has certainly given me a lot to think about.

Cloud computing was the theme of the day at the FIRST conference, with talks on security and incident response both concluding that we may need to re-learn old techniques. The adoption of at least some form of “cloud” seems to be inevitable, so we need to understand how to do this with an acceptable level of risk. Unfortunately assessing the risk requires both an understanding of the criticality of data and processes and knowledge of the security measures implemented by the cloud provider; one or both of these may be missing. Clouds are not inherently more or less secure than in-house physical machines: indeed the list of problems looks depressingly familiar – security by obscurity, lack of standards, lock-in, downtime, information leakage, application and platform vulnerabilities, power failures and burglary. These may be either increased or decreased by sharing infrastructure with a large number of other, unknown, parties.

Incident detection and response on traditional computers has increasingly focused on monitoring network traffic, but “network traffic” between cloud virtual machines may never leave memory and even if it does, the physical networks are monitored by a cloud provider with no way to distinguish a denial of service attack from a successful product launch! For the same reason logs from the cloud platform, even if they are available from the hosting provider, are likely to be very hard to interpret. Applications written for clouds therefore need to do their own logging, where possible to external storage since an attack may well result in the virtual machine and its data disappearing without trace. Incident response teams should work with application developers to ensure that relevant information is logged and preserved; ideally each application should have its own Security Response Plan covering logging, incident response tools, access management, fix deployment and escalation. In some cases traditional incident response tools may work on cloud platforms, but teams need to know which will give reliable results and practice using them before they are needed in an emergency.

Several years ago Microsoft published an analysis of different types of intruder, from script kiddy to spy, based on the motivation and skill level of each type. At the FIRST conference this week, Tim Casey and Steve Mancini of Intel presented a different, much more detailed Threat Agent Library which considers many more factors including existing level of access and willingness to break legal and ethical rules. This allows the model to include both internal and external parties as well as those such as vendors and suppliers who might be considered “competitive” rather than “hostile”. The model has many uses: for example information security measures can be much more accurately designed to meet the particular types of threat; newspaper headlines and movie plot threats can be analysed much more quickly to determine whether they are a real concern; reporting of both the current threat level and anticipated change can be much more precise and adapt better to threats related to events such as cyber-activism and employee dissatisfaction.

One of the major social networks on the Internet has started an IPv6 trial!

Facebook has enabled IPv6 access through the URL http://www.v6.facebook.com/ (clicking on this may not work if you do not have IPv6 access!) and the vanity address 2620:0:1cfe:face:b00c::3.

Much of the Facebook content is still served through Akamai (a content delivery network), which doesn’t yet do IPv6, but it is a start.

IPv6 deployment is slowly creeping through the Internet.  Google have a much publicised IPv6 programme which sites on JANET can register for.  However, the free pool of IPv4 addresses continues to dwindle with little over a year estimated to remain in the IANA pool, and under two years until the RIRs run dry.

Sites on JANET that do not have IPv6 yet can obtain their own IPv6 assignments here.

JANET(UK) has just launched a call for organisations within the education or research community to take part in a trial focusing on RadSec and IF-MAP technologies.

The trial will investigate the secure use of RADIUS protocol to send authentication requests across insecure networks.

Furthermore, the project aims to demonstrate how IF-MAP can be extended to provide a measurement & monitoring tool for a potential replacement service.

Full details of the project, and how to participate, are available on the JANET website (http://www.ja.net/development/middleware/radsec/index.html) or through the links below:

Further details of the project
Call document

Final date for receiving responses is 12:00 pm on 2nd July 2010.

I’ve been invited to act as one of TERENA’s “official bloggers” at their annual Networking Conference in Vilnius this week, so my postings on development issues have been temporarily re-located.

An interesting presentation by Giles Hogben of ENISA at TERENA’s CSIRT Task Force meeting in Heraklion last week, looking at security issues when moving to the public cloud computing model.There have been several papers on technical issues such as possible leakage of information between different virtual machines running on the same physical hardware (for example by Ristenpart et al), but the talk suggested that the major impacts actually come from the organisational change.

Here there are both risks and benefits: both arising from the fact that using a cloud (as with any type of outsourcing) means that you are depending on someone else to provide security. That could be seen as a risk, since the outsourcing organisation no longer has direct control of security measures and clouds are a “big juicy target” for attackers. However it may well be that the cloud operator is actually better  at doing security than the outsourcer: many security measures such as patch management and filtering scale very well to large systems and a cloud provider is more likely than a small or medium enterprise to be able to recruit and retain a team of security experts.

So cloud security may not be either “better” or “worse” but it’s definitely different. ENISA’s full report is definitely worth reading.

Welcome to the new JANET Development Eye Blog.

JANET Development team have launched this blog to share with the community some of the information and knowledge they have gathered during the course of their work. This may be an event review, a technology update or maybe their opinion on current market developments.

We hope you find this a useful tool and we welcome any feedback.

Older posts can be found on the JANET website at: http://www.ja.net/development/development-eye.html