The Chatham House Rule

Recently, we at IIT were asked to facilitate a learning and development activity under the Chatham House rule. This is a frequently misunderstood rule regarding the sharing of information. According to the official website of Chatham House, www.chathamhouse.org, the rule is structured as follows: “When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed”. Chatham House is an institution dedicated to debate, analysis, and the sharing of influential ideas, with the goal of informing and building a prosperous and positive world. Chatham House is home of the Royal Institute of International Affairs. The organisation hosts world renowned speakers, events, and conferences, as well as houses several publications and supports a variety of research.

The Chatham House Rule developed first in 1927 and was revised in 1992 and 2002. The Rule originated during meetings and discussions at Chatham House, and has continued in practice as a means of facilitating open and free discussion. Invoking the Chatham House Rule allows a speaker or participant to express themselves in a way that provides anonymity. Although ideas presented in said meeting or event may be discussed following the event, the speaker and their affiliations cannot be revealed. Institutions and organisations worldwide have adopted this rule as it encourages free expression of ideas without fear of infringing upon an individual’s reputation.

If an event takes place under the Chatham House Rule, the identities of those who have participated may not be publicly revealed. The Chatham House has stated that the Rule applies to social media as well, including web sites such as Twitter. A meeting occurring under the Chatham House Rule allows participants to “tweet” during the meeting, but they are restricted from identifying the speaker or other participants. They are allowed to share ideas only. The Chatham House Rule is very effective in this way, as it isolates the information which is discussed and shared-- encouraging the healthy spread of ideas and knowledge--but protecting the privacy and identity of individual contributors.

Hardening Web Environment

A recent Distributed Denial of Service (DDoS) attack using Network Time Protocol (NTP) amplification has provided a reminder of the growing need for a hardened web environment. This attack highlights the necessity of secure NTP servers, as well as the enhanced security of the operating system and other integral elements. The NTP amplification type of attack functions by attacking servers on networks that do not follow Best Current Practice (BCP) 38. These networks allow the spoofing of source Internet Protocol (IP) addresses. User Datagram Packets (UDP) are made by the attacker using the spoofed IP address, and then sent to Network Time Protocol (NTP) servers which support the command MONLIST. These DDoS attacks are designed to disable a network by permeating it with pointless traffic.

It is very important, therefore to check if your NTP server is hardened and its' support of the unhelpful MONLIST command. Additionally, ascertain that your network is following BCP38. There are multiple internet sources that can provide information on checking these issues. A good starting point is guidance from BCP38 see http://tools.ietf.org/html/bcp38‎.

If you’d like some more direct, hands-on guidance on how to secure your web server, IIT will be offering a 3-day course devoted to the subject. We will spend the course focusing on protecting your server in a risk-laden web environment, and aid you in making these changes to harden your web security. This course will take place in Canberra, from the 6th to the 9th of May, 2014.

Significance of IPv6 Interface Identifiers

The last 64 bits of an IPv6 address are what is known as the interface identifier. IPv6 unicast addresses are made up of a prefix followed by an Interface Identifier (IID), the last 64 bits. According to a recent RFC on the subject, these identifiers are formed through varying methods. The RFC, which can be read in its entirety here, elaborates on the idea that the bits in the interface identifier should be “treated as an opaque value”, and have no stand-alone significance.

This finding comes to a conclusion that the value of the "u" bit in IIDs contains no significant meaning.  As stated in the document, “In the case of an IID created from a MAC address according to RFC 4291, its value is determined by the MAC address,  but that is all.” The U and G bits are found to have little significance in relation to their originally believed “purpose”, but may present other details of importance.

This RFC makes a change to RFC 4291, by indicating that the Universal and Group bits of an IEEE link-layer address are merely significant in the act of gleaning interface identifiers from that IEEE link-layer address.