Why register?

The question to this answer seems simple. To know who has registered with an organisation. This makes it possible to contact the registered person or organisation, to send bills and to discuss policy with the members.

The rationale of unreachable registrations

This one completely goes by me. ICANN distributes IP resources at the highest level that are on principle scarce: domain names and IP addresses and sets policy around the distribution of domain names. So it seems to be in the utmost interest of ICANN to have an accurate database. Over the past years it has been shown over and over again, that accuracy was not a priority of ICANN, even against her existing policies.

There does not seem to be a rationale for this lapses in registration measures. ICANN in the end loses money as she provides a service, but is most likely not paid for this service after registered parties have become unreachable. Next to that it is not good for ICANN's image, as government and LEA reactions have shown over the past years. It could even become a threat to ICANN's very existence.

Cyber crime and enforcement

With the coming of cyber crime, spam and botnets, law enforcement agencies of different back ground became interested in Whois data and were very much frustrated when they found data not to be accurate. (And vetting and revocation mechanisms not being in place.) Whois data is a primary source at the start of investigations. So if these are false this makes investigations harder, not impossible.

Inaccurate data

What can be reasons that data is inaccurate? There can be several reasons. To give a few examples. Someone forgot to change the data after a move of the office, contact person, a merger, bank account, a company stopped its activities, etc. In the meantime the domain names are still used as they were meant to, but from an unknown address.

A second reason could be that free speech advocates want to have a chance to hide their identity behind a so called proxy registration. This way they are safe from prosecution in their home country. Usually this is supported by western governments.

A third reason can be criminal intent. A person or group of persons use domain names for personal gain through illegal activities. They never intended to provide accurate data. From a society point of view this is an activity that preferably is stopped as fast as possible.

What to do about it?

We are discussing unreachable registered companies. It looks quite simple to me. ICANN has many ways to reach out to these companies and does so. Everyone concerned gets one year to alter the data. As soon as someone complies, the data is submitted to the Whois database, after being vetted by ICANN.

All that have not updated their registration on time -and one year is a very lenient time frame- are de-registered by ICANN .

Legit after claims

If ICANN makes sure there's a good procedure to follow for legit claims after the de-registration that come in anyway, I'm sure this procedure will work. Criminals usually do not show up and try to find new ways to proceed their business.

Vetting of all new registrations

When ICANN makes sure new applicants are vetted before being admitted and an ongoing checking procedure of existing members is put in place, I'm convinced that the Internet will become a safer place for all concerned. Also, she becomes an example for policy at lower level, whether domain name or IP address organisations, by setting a standard. It makes one avenue on the Internet harder to reach for criminals.

Update - Feb 7, 2012: Some amendments were made to the post as per comment #4

Written by Wout de Natris, Consultant international cooperation cyber crime + trainer spam enforcement

The service is not automated and if you want to access it you will need to submit a request via email with information about not only what you want to know, but why you are interested in accessing the information.

The service could be useful for understanding an IP block's reputation, assuming it has changed hands.

More information about the service on the ARIN site and the announcement here.

Thanks to Scott Pinzon (@spinzon) for bringing it to my attention.

Written by Michele Neylon, MD of Blacknight Solutions

If you've ever looked up information about a domain name you've used a Whois service. It's the public information system about contact information for a domain name or IP addresses, though in this article, we will just talk about domain name Whois.

In some generic and sponsored Top Level Domains (gTLDs), Whois is run authoritatively by the gTLD. In older gTLDs such as .com and .net, the authoritative Whois service is run by the registrar responsible for the domain name. While some TLD operators run their own infrastructure, when a TLD operator uses a back-end service provider, that provider also provides the TLD Whois service. This public information system is of interest to law enforcement agencies and bodies, attorneys and courts, those studying the commerce of domain names, and those trying to address technical administration issues. It is typically operated as an open system that anyone can query. However, that very well could change over time and in certain circumstances, as I explain later in this article.

How you access Whois

Most people query Whois information through a web-based query page, usually through a registrar's Whois website, as well as those of gTLDs. The information returned is typically only relevant to the registrar's offered gTLDs, but there are also more generic Whois query tools. (Whois also has a machine level interface offered for querying on Port 43, which is what those nice web-based Whois query pages are actually talking to behind the scenes.)

What does Whois provide?

The content returned in different registry and registrar implementations of Whois can vary in how the output is displayed, but they are all more or less providing the same area of information. Whois services return contact information by area of responsibility for the domain: technical, administrative, billing or finance, along with the registrant of the domain, the registrar, and registration date. The contact information itself typically contains items such as name, address, email and phone numbers.

Would you like your Whois, thick or thin please?

Thick Whois: Gathered by the registrar during the registration process, this information is stored in the registry of the gTLD operator, which is responsible ensuring the data is valid. Most gTLDs conduct periodic Whois compliance audits rather than a complete real-time validation of submitted Whois data. Even if a gTLD offers thick Whois, registrars are required to maintain their own Whois service for their domain names. Since the registrar has the ability to update the related Whois information in the actual registry in near real-time, it is expected that the registrar maintain synchronized Whois data output between what their Whois service offers and what the gTLD Whois service offers.

Thin Whois: This really only applies to .com, .net and certain ccTLDs where the gTLD's Whois offers much less information about the domain. Its primary value is to point to the registrar's Whois service, where one should expect to find the detail Whois we see in a thick Whois. In this model, the registrar's Whois service is authoritative and must remain in compliance with ICANN's Whois data output requirements.

Why is this model not as desirable? It comes down to compliance monitoring. It's easier to hold a number of gTLD's accountable for Whois compliance under the thick model than to run periodic audits on many registrars for the many gTLDs they may service.

Privacy

Local privacy laws and practices in a global operating environment remain a challenge. Requiring full public Whois output can violate privacy rights of the region/jurisdiction where a registrant operates.

ICANN allows for exceptions to their requirements for thick Whois contact data where local laws contravene those requirements. This means that, theoretically, a gTLD might have to treat the Whois output of a registrant differently based on their residence or in relationship to the corporate home or operating region of the gTLD itself. It's clear there will be some variation in the way gTLDs approach Whois output as a result of these issues.

Whois proxy services have been offered by registrars for some time now. These are services that provide indirect contact information for those Whois contact areas previously mentioned. For example, instead of putting the real registrant's email address, the email address in the Whois output simply may be a forwarded email address. It still allows you to reach the registrant, but likely it's first filtered by the registrar to see if it's a valid request related to the domain. This product was born out of domain commerce parties mining Whois output for email contacts and incorporating those emails in various email marketing campaigns — some for legitimate products and some not.

Operating a robust Whois service in the new gTLD environment

Operating a solid thick Whois has a number of upcoming challenges. Whois is frequently a target of companies looking to mine the data. This is done by first downloading daily zone files for a given gTLD, which is free to the requestor and an ICANN required provision by gTLDs. These companies then use automated tools to systematically query the list of active domains and collect contact information for commercial purposes. Unfortunately, Whois queries can be quite small in comparison to the large amount of output the reply generates. This means someone mining Whois can readily apply load on the gTLD Whois servers. In short, an unprotected Whois server is easily knocked over with excessive load.

A good back-end registry service provider will have a plan to address this. Most apply a combination of Anycast network based Whois services with significant infrastructure capability and, mostly important, a source-based rate-limiting system to control how quickly a data miner can submit automated queries. Ask your back-end registry service provider what they can do for you and make sure those capabilities are reflected in your Abuse and Access policies in your Whois Service.

A Future for Whois

The changing environment of our Internet is bringing great new opportunities but also new challenges for Whois. For example, one problem is that new Internationalized Domain Name (IDN) TLD registries can't offer contact information in the native characters those IDN registries support in their domains. Another problem is that traditional source based rate-limiting, currently effective against data-miners, is not effective in the burgeoning new IPv6 number space.

Whois capabilities being considered are tiered permissioned access to Whois services with related variable output to reflect the different needs of Whois consumers and localized privacy issues. Both consumers and providers alike have expressed an interest in an industry-wide, standardized Whois output structure for some time.

Work is underway in several areas to address a number of these shortcomings in Whois optional functionality. Some recent examples of these efforts include ICANN's Internationalized Registration Data Working Group (IRD-WG), various ICANN project groups working on specific IDN TLD implementation script issues, the WHOIS-based Extensible Internet Registration Data Service (WEIRDS) discussion list in the Internet Engineering Task Force (IETF), and ICANN's Whois Survey Working Group (concerned with Whois functional requirements).

The most important message a potential gTLD applicant can take away on Whois is this: Expect that the once "simple" service will become a much more complicated. Anticipated new functionality in Whois and integration of that functionality into your related Abuse and Access policies should be addressed by the back-end service provider you are considering.

Written by Michael Young, Chief Technology Officer at Architelos

Signing email transitioned from a proposed standard to a draft standard (RFC6376 — one of the new RFCs) over at the IETF a few days ago. The other is RFC6377.

Let's go through a brief history of DKIM RFCs to refresh our memories –

RFC4871: May 2007 → the original DKIM RFC

RFC5672: August 2009 → an update to RFC4871, which clarifies the nature, roles, and relationship of the 2 DKIM identifier tag values that are candidates for payload delivery to a receiving processing module.

RFC6376: September 2011 → This cleans up the original version(s) of DKIM, thereby knocking off RFC's 4871 & RFC5672.

RFC6377: Recommended practices for using DKIM, mostly focused at mailing list managers — with some useful guidance.

Throwing a little light on DKIM (DomainKeys Identified Mail), it's a method of associating a domain name to an email, allowing a firm/organization to assume responsibility of messages that is validated by recipients. Validation is based on public-key cryptography. This allows mail transfer agents (MTAs) to sign email messages that pass through them — and to also verify a signature attached to an incoming email. These "signatures" — which use public key cryptography - are linked to domain names (as mentioned above), and then the public keys are published via DNS.

Reference: The IETF RFC Index at http://tools.ietf.org/rfc/index

Changes to WHOIS Query Behaviour

ARIN announces a pending change to Whois query behavior on port 43

Prior to 25 June 2011, a query for an IP address in the ARIN region would return with that assignment/allocation within the ARIN region, and a query in the ARIN region for an IP address with no assignment/allocation would result in a "no match" response. On 25 June 2011, a change was misapplied. The intent of this change was to return ARIN's /8 for IP queries within ARIN's region for which there is no assignment/allocation, a behavior meant to align ARIN's Whois output with that of the other RIRs. However, this change introduced an unintended behavior of returning ARIN's /8 (in addition to the desired results) in responses where IP addresses had been assigned or allocated. This change in behavior has created some confusion. On 2 October, ARIN will reinstate the previous behavior for Whois IP queries so that results are returned the way they were before 25 June. ARIN has provided two examples of a Whois query for reference: one with ARIN's /8 returned in the result set hierarchy, and one without ARIN's /8 returned in the result set.

Whois-RWS behavior will not change as it was not affected by the configuration change made on 25 June.

Reference: ARIN's Announcement Archive

Updates at Hotmail's Postmaster Pages:

I can't accurately confirm exactly when they updated their postmaster pages, but I can say its recent. This was split into 2 areas — one for Sender Solutions, and the other for ISP Solutions.

• Sender Solutions is an overview of useful services beneficial to senders. These cover stuff services like a postmaster page, SenderID, Return Path Sender Score Certified Email, Junk Email Reporting Program (JMRP), Smart Network Data Services (SNDS), and deliverability issues support.

• ISP Solutions is an overview of useful services beneficial to Internet Service Providers (ISPs) and mailbox providers (MSPs). These also cover similar services like the Sender Solutions (with the exception of Return Path Sender Score Certified Email).

Hotmail's Postmaster home page is at http://mail.live.com/mail/postmaster.aspx.

Written by Udeme Ukutt, Postmaster

First contact

Over four years ago the first contact between OPTA (the Dutch telecoms and post regulator) and the RIPE NCC was laid. It was an awkward meeting of two groups of people who were talking to each other, but didn't connect at any level. Around the same time RIPE NCC got into contact with LEAs that had an urgent need for accurate information in cybercrime investigations and was confronted with a growing number of requests for information. All this culminated in invitations participate in the Government Roundtable meetings for LEAs, including a special meeting aside.

From misconceptions to dialogue

At the first meeting in 2008 it was clear that there were several misconceptions on both sides as to content and purpose. There was a distinct tension between both parties and an expressed urgency on the side of the LEAs, which made dialogue hard to establish. What happened however, was that the friction built up during the first meeting was taken away by discussing possible future approaches. An agenda of topics was identified and an invitation formulated to continue the discussion. This led over the course of 2009 to the invitation to participate in respective relevant events. OPTA and representatives of cybercrime units presented at RIPE meetings, while RIPE NCC presented at the London Action Plan, the e-crime event in London and in the EU Cyber Crime Task Force. Relevant knowledge and information was shared between both sides.

Understanding each other's positions

This made a few things clear to participants. Law Enforcement officers learned to understand about policy processes within the RIPE community and that the only way to influence these processes is to participate and address the right people. Also they learned what sort of organisation RIPE NCC is and the sort of information she has on its members and the Internet in general. What of this information is public and what is private sensitive data. RIPE and RIPE NCC learned that (governments and) LEAs have legitimate concerns about the safety and security of the Internet and need accurate information on LIRs for investigating criminality or spam violations. But most probably also that they have no use for members that do not pay their bills and are untraceable as well as that it is not good for reputation when RIPE NCC is, no matter how unwillingly, associated with (organised) crime, which unfortunately, in very small numbers, was the case. This awareness caused RIPE NCC to look at her standards and procedures and alter them when deemed necessary, which is a great claim for self-governance.

Cooperation is successful

The reaching out led to the installation of the Cyber Crime Working Party in May 2010. In the CCWP LEAs, the Anti-Abuse Working Group of RIPE and LEAs share data and work together. The biggest challenge for law enforcement agencies is to dedicate resources to cooperation and participation, that do not immediately show a result in facts and figures presentable to the outside world. The figures presented by RIPE NCC on 12 September, as well as recent presentations by ARIN and AfriNIC, show that cooperation does pay off, but needs time to develop. On both sides! So use the figures within your respective organisations and make sure that this raises the awareness of the right people there.

As CCWP chair I complemented RIPE NCC with these results and noted that we have come a long way over the past few years. There is more to be done, but this moment of reflection is as good as any.

Written by Wout de Natris, Consultant international cooperation cyber crime + trainer spam enforcement

IP address space is a finite public resource. Traditionally, folk who need IP addresses fill in a simple form documenting how current addresses are used and explaining how the requested IPs will be used. It's a simple process that takes a few minutes to complete, and even less time to process. Having been a Hostmaster at one of the RIRs, I have some experience in this area. Back in the very early days of the IANA, requirements were even more simple and many organisations got lots more IPs than they could actually use due to the classfull nature of addressing at the time. These early Allocations are often called "legacy space", as they were made prior to the formation of the RIR system as we know it.

There seems to be a vocal minority clamoring for the removal of this needs requirement in some of the RIR regions, some of whom are undoubtedly hoping to profit from the sale of IP addresses, while others seem to be guided by free-market philosophies. Unfortunately, neither motivation seems to advance the public interest in IP address distribution, despite their rhetoric to the contrary.

If organisations were allowed to obtain IP blocks from the RIRs (or from other companies) without first demonstrating that they needed them, the Internet would have run out of IPv4 long ago. This would obviously not have been in the public interest, as Internet growth would have stagnated.

Recently, we have seen the Internetgovernanceproject blogging about this issue and they talk about the needs requirement as a "barrier to trade". While this may be the case, a much bigger and more damaging barrier to would be erected if folk were allowed to flog their IP resources (legacy or not) to the highest bidder without any regard for Internet resource stewardship. In the theoretical case that IGP raises, where Asian companies looking for more addresses than they think they can get from their RIR are eyeing legacy IP blocks. IGP seems to think that such organisation should be able to buy legacy blocks without demonstrating that they actually need these resources. In other words, the companies who have the most cash "wins", which is not a philosophy normally associated with public interest outcomes. Many in the RIR policy communities are concerned that this will lead to hoarding and speculation, driving up the cost of doing business for all while enriching the few.

The current RIR system works incredibly well. It is the most respected part of the ICANN system in terms of openness, transparency and true bottom uppity-ness. Normally, IGP decries the heavy influence in ICANN processes by monied interests, but in this case, they seem to be cheerleading for the monied interests due to some deep seated Ayn Rand-ian laissez faire-ness. Inexplicable really, but I digress.

Now that we are faced with the impending run out of IPv4, several RIR policy communities are placing greater restrictions on allocation and assignments as a natural reaction the coming shortage. For example, in the AfriNIC region, consensus was reached at the last AfriNIC meeting on a "Soft Landing" policy, which is now in Last Call. Amongst other things, this policy specifically states that resources allocated to the AfriNIC region are meant to be used in the region, thus precluding inter-region transfers.

Currently the APNIC community is in the process of restoring the justification of need for transfers, which was relaxed just last year.

Asking folk why they need a certain number of addresses has worked to prevent hoarding and speculation of Internet resources for many years. It is even more important now that we are running low on the supply side of IPv4. RIR policies are set by groups of people working together to reach consensus positions. Asking that we allow the "Invisible Hand" to determine policies going forward is not responsible stewardship, it's just crass commercialism.

Written by McTim, Co-Chair of the African Network Information Center Policy Development WG

The concept behind WHOIS was simple. For each and every registered domain name, provide the facility for querying details about who owns it, who administers it, when was it created and when it will expire. Unfortunately the service lost its way practically from day one after failing to agree upon or adhere to any formal structure of the content it provides.

Despite the absence of any formal structure to the content, regular [removed]Regex) string handling has managed to overcome many of these formatting hurdles (from a programmatic perspective). In general though, having overcome the registrars ad hoc formatting, the content of the WHOIS data is unreliable. It's certainly unreliable from a security practitioner and abuse handling perspective!

If I had to summarize the "value" of the data actually contained in the returned WHOIS query results, it would probably break down in to the following:

1. Relatively complete records for everyday regular Internet users who happened to register a domain at some stage and never realized that their personal address information would be visible to everyone on the Internet.
2. Relatively complete records for privacy holding companies that manage WHOIS privacy for folks that registered domains and knew that their personal information would otherwise be broadcast over the Internet.
3. Sparse and incomplete records for everyday regular Internet users who knew that these registration details would be leaked to all Internet users and didn't want to pony up the fees for some additional "value add" privacy service offered by their registrar.
4. Fraudulent and faked information supplied by cybercriminals as they registered the domains they wanted to use for an upcoming fraud campaign — where the details need to look real enough (probably linked to the stolen credit card they used to pay for the registration in the first place).
5. Sparse fraudulent and faked information grudgingly supplied (in its minimal state) by the cybercriminals as they automatically bulk register new domains.
6. Made-up nonsense registration data. There was a field that had to be filled in, so it was — with anything — and could have been supplied by legitimate registrants or cybercriminals. The expectation being that the domain is completely disposable and will only exist for a few hours.

I'm sure the list could go on, but effectively the odds that the data contained within a particular WHOIS record is actually accurate are stacked against an inquisitive security practitioner. That said, most threat researchers would give up an appendage (or a smaller more sensitive part of their anatomy) if they could reliably obtain the WHOIS data for all the domain registrations (and renewals) carried out every day. If they could get the same WHOIS data for some of the more frequently abused country code Top-Level Domains (ccTLDs) in remote lands, they'd probably be prepared to offer up their first born.

If the data can't be trusted, why is it so useful to a threat researcher? The answer is "correlation". There are enough bad guys out there that are stupid, make mistakes or simply "don't care" that they end up recycling some or all of their registration data.

For example, the cybercrooks want to launch a phishing campaign. They'll be sending out a few million phishing emails — which they'll have prepared the templates for in advance. On the day of the attack, they'll do a bulk registration of multiple domain names and use the same contact/administration email address so they can efficiently log in to the domain control accounts and configure the correct DNS settings. Even though they are using multiple domain names (often from multiple registrars and spread over multiple TLDs), if a security analyst intercepts even a single phishing email they are able to extract the domain name listed in the email and being used to drive victims to the phishing Web site.

Armed with that domain name, the analyst can check the WHOIS data, identify registration attributes (e.g. the contact/administration email address), and then search/cross-reference/correlate with all other domain name registrations sharing the same details. In many cases, they'll uncover dozens of additional domains that happened to have been registered within hours of each other using the same email address — and able to conclude that the additional domains are part of the same phishing campaign.

The usefulness of WHOIS data from a security practitioner perspective is dependent upon the cybercriminal to provide "interesting" registration details — and those details have been getting increasingly sparse over recent years. The growth of privacy screening WHOIS services and the explosion of new gTLDs, ccTLDs and novelty TLDs is making things worse.

Perhaps it is time to retire WHOIS if the registrars can't enforce registrants to use correct (and verifiable) registration information. In the meantime security practitioners will be milking the system for all it's worth.

That "milking" process raises its own problems of course. Registrars are very protective of their WHOIS data. They've been forced to implement security features and rate limit the volume of requests for data. For example, consider the value of having the correct registration details of every domain name owner — and the value of that information to marketers, spammers, etc. Despite these protective measures, the bad guys have been automatically leaching this information for years. Unfortunately the good guys are forced to replicate the bad guys techniques for extracting WHOIS data — and end up becoming abusers of the system themselves.

The entire WHOIS system is broken.

Written by Gunter Ollmann, VP of Research at Damballa

The court's order (found here) was signed without objection at a hearing attended by representatives from Nortel, Microsoft (GFS), ARIN, Addrex, various creditors and observers. It specifically authorizes the sale of various IPv4 address blocks, totaling 666,624 individual IPv4 Internet Numbers, for USD $7.5M (or $11.25 each). The sale agreement, filed with the court and approved by this order, identifies the seller's "exclusive rights to use and transfer" the Internet Numbers. The sale agreement also states that Microsoft, as the buyer, has agreed to enter into a Legacy Registry Services Agreement (LRSA) with ARIN. As a result we now have an example of Specified Transfer based, more or less, upon ARIN's Number Resource Policy Manual (NRPM) section 8.3. This is the beginning of a legal structure for recognizing IP addresses as a form of property and a template for future transactions in the ARIN region.

Of course, there are still open questions. For instance, the actual LRSA side-agreement entered into by Microsoft was not disclosed to the court. At this time we don't know what ARIN and Microsoft agreed or how it compares to the standard LRSA that others have signed. Also, there is no indication that a RSA is required for a legal transfer, only that ARIN requires a RSA as a condition of updating their Whois database. The court did not require the RSA, or any arbitrary terms of the sale agreement - it merely accepted the agreement negotiated between Nortel and Microsoft. Effectively, any question about whether a RSA is required has been postponed until a later date because Microsoft has agreed to sign a LRSA with ARIN. And there are questions about Microsoft's "justification of need", with regards to the ARIN transfer policy requirement. ARIN has stated that Microsoft did justify need and qualify for the transfer, but this raises a question about why Microsoft chose to buy these addresses rather than receive them as a direct allocation from ARIN.

Because of open questions such as these, we don't know what complexities might exist for future sales. One challenging area will be inter-regional sales of legacy blocks. These may be more politically sensitive, for instance, depending on who the buyer is. And there will almost certainly be open issues with inter-RIR cooperation. For example, these transfers may be economically complex, now that the APNIC region is under the "final /8" policies (announcement) and transfers no longer require justification of need.

As more IPv4 addresses enter the market (including Nortel's legacy /8 block) the community should pay close attention, and work to answer these questions proactively. A robust address market will benefit continued Internet growth and a smooth IPv6 transition, and we must be open-minded about these changes - exhaustion is here, whether or not we're prepared.

Written by Benson Schliesser, Principal Engineer, Cisco Systems

RIPE NCC staged several very interesting presentations that showed the LEAs the importance of the work done within RIPE and ARIN, the information RIPE NCC has and the relevance of all this to LEAs. Also issues were addressed that can potentially be harmful to future investigations.

An invitation to cooperate

If the law enforcement agencies got one message in London to take home, it was as SOCA's senior manager e-crime Lee Miles formulated it: "the door is open at RIPE NCC to cooperate". (In an off-conference remark a police officer said: "We are not used to the fact that a door is open. It is the opposite, we always have to break in the door. This is a new situation".)

There are many issues at present or in the near future that are of interest to or will effect law enforcement (investigations). RIPE NCC presented freely on this, thus showing her willingness to build a serious and in depth relationship with law enforcement. All presentations were of excellent quality and made it quite clear to LEAs what the state of play concerning RIPE policy making is, which information RIPE NCC has available and where in the case of technical problems around IPv4 depletion and (the lack of) transition to IPv6 a role for governments is necessary. This was a very stark message the police officers present got to take home: only governments can regulate or promote IPv6 transition!

Influence only through participation

LEAs were clearly made to understand that RIPE policy is formed in a bottom up process and that to have influence on this participation is necessary. If LEAs can address common concerns about the distribution and where necessary reclamation of IP addresses in the RIPE policy groups, they may be able to achieve changes that were not foreseen until recently. Their concerns are already more widely and receptively heard than expected even less than a year back. If the regular interaction of the past year has shown something, it is that several topics concerning the prevention of criminal use of IP resources are firm on the agenda.

If IP resources become more difficult to acquire for cyber criminals and RIPE NCC has a more stringent policy for reclaiming addresses, the Internet becomes safer at one of its front doors. Hence the importance for LEAs to work with the RIPE community in shaping policy together, policy RIPE NCC will execute.

Cyber Crime Working Party

LEA cooperation with RIPE NCC and the RIPE community is foreseen to go through the CCWP. From this body RIPE policy can be monitored and influenced, trainings coordinated, war games staged for all parties, knowledge exchanged and trust build. SOCA showed quite keenly showed her colleagues what she stands to gain through cooperation. All LEAs were invited to either join or support the initiative.

The fact that ARIN has now joined the CCWP is a strong sign that both RIRs think this initiative is of significant importance. The work ARIN does in the field of LEA cooperation and self-regulation in the U.S. and Canada is seen as an example by RIPE NCC.

Standardised information exchange

One of the goals of the CCWP is providing LEAs with a template that standardises information requests to RIPE NCC. This would make the work of the RIPE NCC substantially easier. On the spot it was decided to start work on the template. A breakthrough and success to be for the CCWP.

21st Century cooperation

Should this cooperation take off further in the near future, it will give a good example how public — private cooperation takes shape. Two entities not used to work together are forced to take each other's stock and commit resources to mend an acute problem. The moment they pull this off, the world is changed. Can LEAs afford not to be present as this unfolds? I don't think so.

Written by Wout de Natris, Consultant international cooperation cyber crime + trainer spam enforcement

One of the controversial sub-issues is privacy-proxy domain registrations which allow a registrant to replace their WHOIS details with the contact information a of privacy shield company. The privacy-proxy business is a nebulous world with no standards and little accountability. Supporters claim it protects victims and political activists from attacks and private citizens from getting spammed or scammed. Critics, like me, contend it is a loose system run on behalf of criminals and spammers. Additionally, the illicit use of privacy-proxy erodes the legitimate use. This is compounded by the fact that many privacy-proxy services are phantom companies themselves.

In September of last year ICANN released the results of a study estimating 18% usage of privacy-proxy services in the gTLD (full report). However, Knujon research has revealed that privacy-proxy usage is significantly higher among illicit domain registrations. We looked at two specific categories: spammed domains and illicit pharmacy domains. The conventional logic has always been that spammers and criminals would not waste money on privacy services, that they would simply falsify registration data or use "throw-away" free email addresses. We know this is not the case. One section of a report KnujOn will issue on Tuesday March 15th will show 33% usage of privacy-proxy registrations for domains advertised in spam and 39 to 51% usage among illicit pharmacy domains.

KnujOn studied 13,277 repeatedly spammed domains over six months and found that among the general population, most registrants used unmonitored or false yahoo.com, gmail.com, hotmail.com, and other free-email accounts in the registration. However, six out of the top ten spam registrations were through Registrar-sponsored privacy services. Also, 31 of the all the 152 registrant emails domains collected were privacy services.

For illicit pharmacy domains, the numbers are even more interesting. Once again gmail, yahoo, hotmail and aol "throw-aways" were most popular but 15 out of the top 20 contact emails used were at privacy services, most were the services offered by the sponsoring Registrar. Among the general population of 27,414 illicit pharmacy domains studied 39% used privacy-proxy. Within the 50th percentile there is 45% privacy usage, in the 25th percentile it is 48%. Among the top 50 contact email domains 51% were privacy services. The most used privacy services had 8,380 illicit pharmacies as customers.

For some, the question still remains, why pay for a privacy service when bogus WHOIS information is easy to use? There are a variety of reasons. First, it adds another layer of obfuscation to confound investigators. A separate KnujOn study found over 100 illicit pharmacy domains, that had the privacy service removed after complaints, had false WHOIS underneath. A second reason is that it provides additional cover for illicit registrants by creating an unaccountable phantom third party that is neither completely registrant nor Registrar. This is evidenced in multiple UDPRs where a brand owner eventually wins an infringing domain name through default but the true identity of the original owner is never revealed.

There are many more issues including which privacy services are compliant with the ICANN RAA and who owns the privacy services heavily used by illicit domainers. This will be detailed in our full report.

Written by Garth Bruen, Internet Fraud Analyst and Policy Developer

Consider the Regional Internet Registry (RIR) system which is the registry responsible for Internet Protocol numbering resources such as IP version 4 and IP version 6 address blocks and autonomous system numbers. Those number resources that were assigned by the US government before the RIR system existed are called "legacy" resources, and these legacy resources are part of the current Whois registry. Sometimes an argument is heard that since some of these "legacy" resource holders are not members of any RIR and pay no fees, they do not deserve the privilege of being listed in Whois. Some opponents of this argument say that being listed in Whois is a right not a privilege. Both arguments miss the point, which is that correct registration information in Whois is an obligation by every registrant to the community, not a privilege and not a right.

The entire Internet community has a right to know who holds what address block and has a right to know how to contact that holder if there is an operational problem involving an address in that block. The Internet is a public system, nongovernmental but still governed, and the stewards of Internet resources must always look first to the public good even though their own internal elections and fees are limited to a membership. You can see this principle reinforced by the fact that policy development for Internet governance is done in public forums with full public participation not limited to regional residents or to a membership. The Internet public has a right to be heard on matters of policy, not just at ARIN (where I am serving my 7th year on the Board of Trustees, though I am writing here as an Internet citizen only — not speaking for ARIN or for my day job) but in all the RIRs (AfriNIC, APNIC, LACNIC, and RIPE).

During last week's meeting of APNIC (Asia Pacific Network Information Center) I was moved to comment at the microphone during the public Policy SIG meeting on a proposal (#96) to reestablish the principle of demonstrated need for allocations out of the "last /8". The "last /8" is the address block APNIC received from ICANN in Miami last month when the final five /8's in ICANN's inventory were allocated to the five regional Internet registries (RIRs). APNIC has special allocation rules for this /8, it won't be handed out as "business as usual", and one of the special rules is presently that the recipient does not have to show demonstrated need per the rules of RFC 2050. An RIR departing from RFC 2050 is a radical change since this RFC is the founding document of the RIR system as well as a restatement of the policies which governed the pre-RIR "legacy allocations" made up to that point by US government contractors IANA and InterNIC.

Proponents of policy proposal #96 said that the lack of a demonstrated need rule will make APNIC members ineligible for inter-RIR transfers if the source region is still requiring demonstrated need. During the transition from IP version 4 to IP version 6 it's expected that some networks will convert before others and that the early ones will agree (possibly in exchange for payment) to transfer their network numbering resources to the later ones. In this way the debate about proposal #96 quickly turned into a proxy debate about transfers in general, and whether transfer recipients ought to have to show demonstrated need or not. Call me old fashioned (as many do) but to me a recipient of an address block who has no demonstrated need for it is simply a speculator and while the Internet community ought to be helping people build networks it has no reason to help speculators acquire rights for later sale (or rental) to people who build networks.

Several opponents to policy proposal #96 got up to the microphone and one of the oppositional themes that emerged was that APNIC was a registry and that a registry's value to the Internet community is that it provides uniqueness and that if APNIC were to enforce "demonstrated need" on recipients then it would merely push such recipients off the books at great cost in the uniqueness and therefore the relevance of the APNIC registry. This got me out of my chair and over to the microphone.

"Don't run scared," I said. The network operators who search APNIC's Whois registry may be doing so for reasons beyond the value of uniqueness. They may be counting on this registry to tell them not only who holds an address block but also what policies governed the receipt of that address block. If they know that the presence of an entry in APNIC's Whois registry means that the address holder had to demonstrate need then they may trust the registry far more than if they know that anyone who does a private off books transfer and pays a filing fee can get themselves recorded as the holder of an address block. If network operators think that speculators who are not building networks can hold or control address allocation then they might stop trusting the registry altogether no matter how much uniqueness it still has.

In the end, policy proposal #96 was "sent back to the mailing list", there to gather some kind of consensus whether in favour or in opposition. Perhaps that debate will stick to the merits of the proposal, but in the Policy SIG session during the Hong Kong APNIC meeting the real debate was about the value (and the valuers) of Whois and how policy ought to be shaped in order to make an effective transfer system for IP version 4 resources during the transition to IP version 6.

In the region where I make my home, the RIR (which is ARIN) has a transfer policy allowing private transfers of network resources to be recorded in the Whois registry, as long as the recipient is a signatory to a Registration Services Agreement (RSA) and can demonstrate an operational need for the address space within the next 12 months. This policy represents the ARIN community's acknowledgement that IP version 4 (IPv4) addresses will soon be a scarce resource and there will naturally be a market of people willing to give up their rights to address blocks ("sellers") and people willing to pay money to get address space ("buyers"). ARIN's policies are determined by the community through an open and transparent public participation and consensus process, and the community's expressed wishes in this case are that transfers should be recordable in order that the ARIN Whois registry can be correct and therefore useful. Note, though, ARIN is a creature of RFC 2050 and all address recipients whether by allocation or by transfer must demonstrate an operational need for the address block they are receiving. In other words speculators would not meet the terms of ARIN's community driven consensus based policies.

Does this "demonstrated need" policy somehow outlaw private transfers? Not in law, no it does not. But ARIN would treat the use of an address block by someone who is not the registered holder of that address block as potentially fraudulent which could in some cases lead to address block reclamation and reassignment after a six month hold-down period. In effect, off books transfers are less attractive since the recipient would not be the registrant. In that sense the ARIN Whois registry offers confidence in both uniqueness and demonstrated need. The intent is to maximize both the utility and utilization of Internet address space, where utilization means building and growing and operating networks not hedging or leveraging or renting address resources.

In the ARIN region, the community's expressed policy assumes that the Whois registry is valuable because of the policies that control it not just because it assures uniqueness. Which is why I said, in support of APNIC policy proposal #96, when I heard someone say that a registry should just record whatever people want it to record and should not dictate any policy at all, "don't run scared." These registries are valuable for reasons beyond simple uniqueness, and as long as these registries continue to support the community's need to build networks, nobody needs to worry much about address block recipients who cannot demonstrate need, which is to say, about speculators.

Written by Paul Vixie, Chairman and Chief Scientist, Internet Systems Consortium

The idea behind the RAA recommendations

Registries and registrars together with other entities lower in the Internet ecosystem, the Local Internet Registries, respectively resellers, have a role in making access to the Internet possible for end users. They dispense IP addresses or domain names around the globe. Domain names are either generic names like .com, .biz and .org or country code domain names like .be and .nl. The domain name registrars' impression of the meeting is found in the Register. Nigel Roberts, CTO of the .gg registry, wrote on the topic from a privacy point of view on this site. (I could not find a link to the recommendations. So google: RAA + recommendations + ICANN + May 2009 for a downloadable Word document.)

From a law enforcement projective, in short, it is important that the registration of the IP resources are as correct as possible and easily, but lawfully accessible. The more correct data is, the easier it is for law enforcement to investigate abuse or crime. More correct data will most probably lead to less abuse of IP resources. The recommendations look for ways to raise accuracy of registrations as well as to enforce the accreditation agreement between registered parties and ICANN, when a registry or registrar is not in compliance with the agreement. Where access is concerned, I'm fairly convinced that LEAs would not mind having slightly easier than full open access to the data, if the data found is accurate.

The EU-US cyber crime meeting

The meeting started off with the understanding that the document was endorsed by e.g. the Government Advisory Committee of ICANN, the Message Anti-Abuse Working Group, the London Action Plan, in other words almost clad in iron. This made what happened in Brussels all the more surprising. In the afternoon of the first day the meeting's agenda was set aside for an in-depth discussion of the recommendation text. This led to a fruitful discussion and to more insight into each other's motivation, background and intent. Let me name a few.

The registrars and registries felt themselves heard by governments and LEAs as they could freely speak on content and process. This led to text amendments in the recommendation on the spot and a first step to an inventory on solutions, but also made understanding between both parties to grow. The presentations of VeriSign, ARIN and the Cyber Crime Working Party at RIPE NCC showed forms of cooperation and different approaches to information sharing. What also became evident is that there is a difference between the recommendations itself and the enforcement of it. That this is not dealt with in the recommendations, but that this is a task for ICANN herself. It became clear that parties agreed on the intent, as industry clearly stated that they do not (want to) profit from criminals. For LEAs it was made evident which parts of the recommendations were a real no-go zone for industry and why.

In one way the meeting took everyone two steps back as the endorsed text is of the table, but momentum wise the people in the room took giant steps. This makes it possible to take a look forward.

Cooperation in the near and medium future. Is it possible?

When I think back to the meeting, I can see several ways forward that could be discussed over the coming period, that may take the registrar community as well as their interaction with law enforcement to another level.

– Information and communication. It may be worthwhile looking into communication both ways. The discussed template for information requests to registrars from law enforcement will make procedures more efficient and less costly. Next to that, in what way could the community communicate towards law enforcement, e.g. through their respective websites? This would make communication more efficient as well. Can this be seen as a two way street?

– Competition vs. mutually perceived concerns. Despite the fact that the registrar community is highly competitive, are there, analogous to the banking industry, segments of interaction between them that could be declared as non-competitive, that once identified may actually lead to a mutual benefit? This could lead to a different approach and commonly agreed upon solutions for these concerns.

– Enforcement. As soon as the leading registrars act on common concerns, many smaller will follow. This sets the good guys apart from the bad guys, who can be easily identified. This makes enforcement, ICANN and LEA wise, of the real black hats a distinct possibility. What does it take for ICANN to act and what role could the registrars play in this?

– Information sharing. Are there ways in which the registry and registrar communities can work with LEAs on exchanging information that will take intelligence gathering to a higher level?

Answers to these questions may just make life a lot easier and safer for the community herself and for everyone concerned.

Results to strive for

Quite rightly it was commented that the registries and registrars are not the source of all evil. There are other and even much bigger issues concerning the Internet that also need to be tackled. However, fact is that in order to push back abuse and crime on the Internet, the registration of IP resources is one of the factors that have to be taken into account. If by a common effort we do manage to make registration for criminals harder and deregistration more efficient, it becomes harder for them to access the Internet and inflict harm on end users.

It is a fact that at this moment there are a lot of people involved in Internet fraud and crime, because it is easy money with an almost zero percent chance at getting caught. They will go away if access becomes less easy and arrests go up. Figures in the Netherlands prove this, even for international criminal gangs. They move elsewhere when opposition is put up effectively.

Industry also stands to win. Requests from LEAs will first become more efficient, then will drop, black hats are identified and dealt with and reputation of the group as a whole goes up. There will always be crime, but the momentum in the room at the Albert Borschette in Brussels may just make it possible to push Internet crime rates back to more normal proportions

I hope to be able to say in a while that I was present at a meeting that proved to be a breakthrough. Let's work at making this work.

Written by Wout de Natris, Consultant international cooperation cyber crime + trainer spam enforcement

Enhancement #1: Search by CIDR matching

CIDR matching capability is enhanced on the search box for the web page, allowing you to search for a network address using prefix/length notation. Note that it will default to the less specific search result set that is described in the port 43 enhancements below.

Enhancement #2: Search by IP addresses, organizations, ASNs

The next enhancement is a change to the default output on a query initiated by the search box on the web page for IP addresses, organizations, and ASNs. The query for an IP address or network will return the network as well as the full output of related Organization and Point of Contact (POC) data for the network. Likewise, the query result for an AS number will output the associated organization and related POCs along with the AS number. The query result for an organization, will list all related networks and ASNs, and give full output of associated POCs. This will allow you to view all information on a single web page. This "pft" option is an enhancement to the RESTful web interface, and it is not available on port 43. To use it, append "/pft" to the URL, for example:

- http://whois.arin.net/rest/org/ARIN/pft
- http://whois.arin.net/rest/net/ NET-192-136-136-0-1/pft

Note also that web search forms will default to using the "pft" option.

In addition, the NICNAME/WHOIS port 43 service now supports more than exact match CIDR.

Feel free to read more — including full details on the Whois-RWS service at https://www.arin.net/resources/whoisrws/index.html.

Culled from ARIN's Announcement Archives.

Written by Udeme Ukutt, Postmaster

Read full story: PC World