International Internet Governance in the Area of Infrastructure and Security

Contents: I. Introduction; II. Analysis of initiatives; III. Initiatives’ Procedural Histories; IV. Commentaries; References.

I. Introduction:

Two fundamental functions of government are (1) to provide a certain level of infrastructure to enable people to conduct daily affairs efficiently, and (2) to ensure the security of the land.  Historically, these two functions have always borne a close relationship to each other, as strengthening the one helps to reinforce the other.

The Internet originally grew out of a quest for security (that is, the aim of the U.S. Department of Defense for technological supremacy over the Soviet Union).  In its short life to date, this technology has become widely adopted and is now critical for the general infrastructure of countries throughout the world.  With this growing preeminence of the Internet for infrastructure, this technology is no longer simply a means to a security end, but rather is also a vital part of society needing protection.  Hence, as in the traditional real world, infrastructure and security are intertwined for cyberspace.

In infrastructure terms, the Internet includes all the networks, computers, lines and cables of communication, satellites, servers, backbones and computer languages (protocols such as http, pop, smtp, ftp, tcp, ip, etc.) – all of which must be addressed for the network of networks to function smoothly.

These same layers pose challenges for cybersecurity.  As processes of identification, authentication, validation, authorization and confirmation at this stage are rather limited, enforcement agencies currently do not see the face of the criminal, may not know what time or from what location an attack is originating, and may not know what technologies are involved in the crime. 

While the Internet’s advancement is presenting ever more complexities for infrastructure and security, governments are increasingly institutionalizing international approaches to legal and technological coordination to achieve a seamless, secure network.  The international organizations they are working through include: (i) Internet Society (“ISOC”); (ii) Internet Architecture Board (“IAB”); (iii) Internet Engineering Task Force (“IETF”); (iv) Internet Research Task Force (“IRTF”); (v) Internet Corporation for Assigned Names and Numbers (“ICANN”); (vi) International Telecommunication Union (ITU); and (vii) World Wide Web Consortium (“W3C”)[1].

II. Analysis of initiatives:

Orientation of International Collaborators:  Work is Technical, Not Political

Who controls the Internet? The answer is simple: generally speaking, nobody does.  However, the Internet is not totally “self regulated”.

Background research for this paper included a survey in which representatives of international organizations working on infrastructure and security were all asked the same question:  Are you or your international organization concerned about the legal aspects of such an initiative?  In all cases the answers were the same:  No.  As explained by them, the first stage is to define an adequate standard for the technology to be deployed. The legal analysis of such a standard is not carried out by the same groups that create the standards.

The individuals involved in creating a standard almost never require the assistance of a legal advisor. The reason, to them, is simple: They are technicians and not lawyers. Their job is to design tools that are useful.  Lawyers, on the other hand, are seen as obstructive:  If a scientist brings to a lawyer a sample of a new technology, it is almost certain that the lawyer will identify so many problems that the technology will never be launched.

So, too, this is the prevailing attitude in the area of security:  The vantage point for international organizations’ analysis of the security field is not legal; rather, it is purely technical.

In other words, for the governance areas of infrastructure and security, the people designing international solutions are technical and task oriented.  Though the political consequences of their decisions are great, these actors do not consider it their responsibility to consider these wider implications of their work.  Meanwhile, people who would take these governance questions seriously tend to lack the technological expertise to understand how choices affect the political power arrangement.

Structure of International Cooperation:  Hierarchy of Technical Bodies

The chart below offers an indication of the Internet’s infrastructure and security management at the international level.  It contains the main organizations that are in charge of the maintenance and standardization of technical parameters.[2]

While these organizations have been actively promoting numerous initiatives, the ones described below have been identified as priorities, based on: a) analysis of the content of the relevant organizations’ Web sites; b) analysis of articles published on Internet infrastructure; and (c) (the most important source) feedback from the personnel from those international organizations by email or telephone.

2.1 Internet Protocol Version 6 (IPv6)

The Internet Protocol version 4 (IPv4), in use for the past 20 years, has the capacity to allocate Internet address space for roughly 4 billion devices.  Because this address space is expected to be exhausted by 2008, governments have endorsed initiatives to upgrade the system.

The Internet Engineering Steering Group (IESG) chartered a working group for standardizing Internet Protocol version 6 (IPv6) to accommodate the exponential growth of the Internet.[3]  Approximately 15 per cent of address space under IPv6 will initially be allocated to already reserved addresses, while the remaining 85 per cent will be reserved for future use.[4]

IPv6 Operations (v6ops) is a related working group under the Internet Engineering Task Force (IETF).  This working group deals with the deployment of the IPv6, since the IPv4 still running and a dual world is being formed consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. According to the specialists, the IPv6 “deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring global addressing and connectivity for all IPv4 and IPv6 nodes.”[5] 

The IETF’s IPv6 Mobility (MIPv6) Working Group intends to determine the routing support in order to permit an IPv6 host to continue using its “permanent” home address as it moves around the Internet.[6]

2.2 Mobility

Every day more and more networks connect to the Internet, and more people are becoming familiar with using different electronic devices and tools.  With this growth in mind, the IETF is working to create appropriate mechanisms to stabilize and optimize the use of mobile networks.

“Access networks deployed in public transportation (buses, trains, taxis, aircrafts): they provide Internet access to IP devices carried by passengers

One group that is tangentially working on the mobility issue is the Network Mobility Working Group (“NEMO”).[8] NEMO is concerned with managing the mobility of an entire network, which includes one or more mobile routers which connect such network to the Internet; it also cooperates with the MIPv6 Working Group.
NEMO Working Group studies are very important due to the fact that each mobile router must have a “home agent”. As indicted in the description of the Working Group’s webpage, the current technology uses “bidirectional tunneling between the [mobile router] and [home agent] to preserve session continuity while the [mobile router] moves”[9].

The role of the Working Group is to create standards for some basic support mechanisms based on the bidirectional tunneling approach. In addition to that, NEMO Working Group is to “study the possible approaches and issues with providing more optimal routing than can be had with (potentially nested) tunneling. However, the [Working Group] is not chartered to actually standardize a solution to such route optimization for mobile networks at this point in time”.

2.3 Public Key X.509

Public Key Infrastructure (PKI) is a set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke public key certificates (PKCs) based on public-key cryptography.

In this regard, the PKI consists of five components: “(i) the Certification Authorities that issue and revoke PKCs; (ii) Organizational Registration Authorities that vouch for the binding between public keys and certificate holder identities and other attributes; (iii) Public Key Certificates holders are issued certificates and can sign digital documents and decrypt documents using private keys; (iv) Clients that validate digital signatures and their certification paths from a known public key of a trusted Certification Authorities and that encrypt document using public key from certificates of PKC holders; and (v) Repositories that store and make available PKCs and Certificate Revocation Lists.”[10]

The initial version of X.509 was published in 1988, version 2 was published in 1993, and version 3 was proposed in 1994 and considered for approval in 1995. Version 3 addresses some of the security concerns and limited flexibility that were issues in versions 1 and 2.

As explained by International Telecommunications Union (ITU)[11], an X.509 certificate consists of the following fields:  version, serial number, signature algorithm ID, issuer name, validity period, subject (user) name, subject public key information, issuer unique identifier (version 2 and 3 only), subject unique identifier (version 2 and 3 only), extensions (version 3 only), and signature on the above fields.

According to the information provided on the ITU webpage[14], the “directory authentication in X.509 can be carried out using either secret-key techniques or public-key techniques; the latter is based on public-key certificates. The standard does not specify a particular cryptographic algorithm, although an informative annex of the standard describes the RSA algorithm.”

2.4 Global Routing Operations (GROW)

The Global Routing Operations Working Group was created to understand and develop new standards to the Border Gateway Protocol (BGP), which is fundamental to the operation of the Internet.

With the increase of the operational issues related to BGP, other concerns such as the routing table growth rates, interaction of interior and exterior routing
protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table, have arisen. All of these issues have been discussed and analyzed by GROW.

GROW also advises various working groups, including the IDR and RPSEC Working Groups, with respect to relevant operational needs.

According the GROW’s Web site[15], its goals comprise the following tasks:

1.      To provide a clear definition of the problems facing Internet Routing Scaling today. This includes routing table size and route processing load (former PTOMAINE goal).

2.      To collate measurements of routing table scaling data and publish a reference list (former PTOMAINE goal).

3.      To discuss and document methods of filtering/aggregating prefix information and to discuss and document what support from protocols or vendor knobs that might be helpful in doing this. In addition, to suggest policy guidelines to RIRs, LIRs and/or ISPs for allocations and aggregations,etc. that may be useful (former PTOMAINE goal).

4.      To determine the long and short term effects of filtering/aggregating prefixes to reduce router resource consumption.

5.      To develop methods of controlling policy information propagation in order to limit the need for propagation of prefix sub-aggregates.

6.      To determine the effects of using BGP as a signaling mechanism on the scalability of BGP (e.g.,. draft-ietf-ppvpn-rfc2547bis-03.txt)

7.      To determine the effects of interaction of new IGP techniques (e.g., ISIS-TE) on the stability of BGP and in particular, what techniques are required to isolate the global infrastructure from the any of the dynamic properties of such TE systems.

8.      To document operational aspects of routing security and provide recommendations for protocol specific work to RPSEC, IDR, and other Working Groups in the routing area.

2.5 Routing Research Group

Routing on the Internet is one of the most important issues for infrastructure and security. If we do not have well-defined and organized routing, the entire system collapses. The Routing Research Group was created to “explore routing problems that are important to the development of the Internet but are not yet mature enough for engineering work within the IETF”.[16]

For this reason, the RRG is to work with the IESG Routing Area Director to ensure the free flow of information in both directions and avoid duplication of work with the other IETF working groups which are dealing with such issues.

The RRG Working Group is mandated to “survey the state of the art in routing research and the needs of the user community (ISPs, router vendors, etc.); based on these results and the interests of the members, the group will choose a number of topics on which to focus.”[17]

The survey also includes the: (i) quality of service routing; (ii) scalable multicast routing, including aggregation techniques; (iii) routing protocol stability; and (iv) extremely dynamic routing.

There is no limited membership and the RRG Working Group may hold open meetings from time to time to solicit input from its members. As mentioned in its webpage, “once per year there will be a review of the group’s activities held at an IETF meeting.”[18]

According to the IETF, this approach is not a problem within the RRG since it is not producing “standards”. Thus, there is no need to come to a single “answer” that satisfies everyone. Groups, starting with different, possibly incompatible, premises may reach different, incompatible conclusions. This is perfectly acceptable. 

If a standard is to be developed, if a “single answer” is required, then the IETF would be expected to create an appropriate working group to develop that answer.

2.6 Network Management[19]

The Network Management Research Group (NMRG) is a working group created to provide a forum for researchers to develop and discuss new technologies and procedures for the Internet management. In addition to that, another important duty of the NMRG is develop solutions for problems not yet understood by the engineering work within the IETF.

As opposed to most of the other working groups, the size of the NMRG is kept small (maximum of approximately 12 members). In order to avoid duplication of work among the various IETF’s groups dealing with such issues, the IETF Operations and Management Area Directors are included in the NMRG. The NMRG is not free for membership as many of the working groups, such that any member is  chosen based on his or her expertise in the network management field and only by means of indication by another member or invitation.[20]

2.7 E.164 – The ENUM[21]

The Internet is going to be everywhere. Computers, palm tops, refrigerators, mobile phones, fixed phones etc. have already some relation to the Internet. However, there are several numbers used to access the Internet, to receive a phone call or to receive an e-mail.

An ambitious program has been launched and it may cause a great revolution in the next years. This project is called E-Numbering, or ENUM or E.164 and is held by the ITU[22] and IAB.

The technical definition for E.164 is “ITU-T recommendation for international telecommunication numbering, especially in ISDN, BISDN, and SMDS. 1) An evolution of standard telephone numbers. 2.) Name of the field in an ATM address that contains numbers in E.164 format.”[23]

This is not simple to understand. A simple explanation can be that “E.164 addresses can be used in DNS by using ENUM. ENUM allocates a specific zone, namely e164.arpa for use with E.164 numbers. Any phone number, such as +1 555 42 42 can be transformed into a hostname by reversing the numbers, separating them with dots and adding the e164.arpa suffix, like so: 2.4.2.4.5.5.5.1.e164.arpa DNS can then be used to look up internet addresses for services such as SIP VoIP[24] telephony”.

The Internet Architecture Board (IAB) and ITU-T Study Group 2 are discussing collaboration on the operational, administration and delegation issues related to deployment of ENUM protocol-based services. This requires extensive consultation with administrators of resources derived from the international E.164 numbering plan including national and integrated numbering plan administrators.

The ITU-T Study Group 2[25]studies the operational aspects of service provision, networks and performance Lead Study Group on Service definition, Numbering, Routing and Global Mobility.

The main document that spells out the ENUM and its relation to the DNS is the request for Comments 2916, denominated “E.164 number and DNS”[26], elaborated by the IETF Network Working Group.

Each country will be assigned an E.164 country codes which will be associated to the Identification Code (IC) assignments. The criteria and procedures to assign E.164 country codes are in accordance with the principles contained in E.190 and the numbering plan formats detailed in E.164.

According to Ms. Dana M. Hirsh[27], the benefits of the E.164 are to “allow Internet-based users to make selections from a variety of services available for communicating with other persons when callers know only a telephone number or have access only to a telephone keypad. In addition, ENUM would enable users to access Internet-based services and resources from Internet-aware telephones, regular telephones connected to Internet gateways or proxy services, and other Internet-connected devices where input is limited to numeric digits.”

“Users of ENUM would be able to specify their preferences for receiving incoming communications, and they would have greater user control over communications. For instance, a user would be able to indicate a preference for voicemail messages over live calls during certain times of the day, or may indicate a destination for call forwarding”[28].

2.8 Routing Protocol Securaty

The main purpose of the RPSEC is the develop standards to ensure and adequate coverage of security for routing protocol designers due to the lack of a common set of security requirements and methods for routing protocols, which has resulted in a variety of security mechanisms for individual routing protocols.

According to the information provided[29], the “RPSEC working group is charged with the following tasks:

(1)  Document threat models for routing systems;

(2)  Document security requirements for routing systems; and

(3)  Provide a common area for discussion between security and routing experts on the topic of securing the routing system.

2.9 IP Security Protocol

Another IETF working group incorporated to deal with security is the IP Security Protocol Working Group (IPSEC)[30]. The IPSEC is in charge of the development of mechanisms to protect client protocols of IP, by creating a security protocol in the network layer to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality.

The working group will also update the existing key management protocol to clarify the specification and to reflect implementation experience, new requirements, and protocol analysis of the existing protocol.  

2.10 ICANN Security Committee

The Committee on Security and Stability will advise the ICANN community and Board on matters relating to the security and integrity of the Internet’s naming and address allocation systems. Reporting directly to the Board, the Committee is chartered to undertake the following tasks[31]:

· To develop a security framework for Internet naming and address allocation services that defines the key focus areas, and identifies where the responsibilities for each area lie. The committee will focus on the operational considerations of critical naming infrastructure;

· To communicate on security matters with the Internet technical community and the operators and managers of critical DNS infrastructure services, to include the root name server operator community, the top-level domain registries and registrars, the operators of the reverse delegation trees such as in-addr.arpa and ip6.arpa, and others as events and developments dictate. The Committee will gather and articulate requirements to offer to those engaged in technical revision of the protocols related to DNS and address allocation and those engaged in operations planning;

· To engage in ongoing threat assessment and risk analysis of the Internet naming and address allocation services to assess where the principal threats to stability and security lie, and to advise the ICANN community accordingly. The Committee will recommend any necessary audit activity to assess the current status of DNS and address allocation security in relation to identified risks and threats;

· To communicate with those who have direct responsibility for Internet naming and address allocation security matters (IETF, RSSAC, RIRs, name registries, etc.), to ensure that its advice on security risks, issues, and priorities is properly synchronized with existing standardization, deployment, operational, and coordination activities. The Committee will monitor these activities and inform the ICANN community and Board on their progress, as appropriate;

· To report periodically to the Board on its activity; and

· To make policy recommendations to the ICANN community and Board”.

2.11 W3C Security

The W3C works on various subjects related to security. They encompass computer system security, network security, authentication services, message validation, personal privacy issues, and cryptography.

Among all of the projects and activities related to security, the W3C is, according to its website[32], involved in the:

(1) “development of several protocols that relate to Web security”, such as the signed-XML proposed activity and the HTTP/1.1 protocol (which includes a much improved scheme for authenticating the identity of users known as Digest Authentication) and eCommerce (on the field of secure payments, studied by the Electronic Commerce Interest Group). In addition, the W3C also “produces software reference implementations that demonstrate the use of security measures;

(2) joint IETF working group to address XML Signatures (digital signatures); and

(3) release of a Digital Signature Initiative – the PICS Signed Labels 1.0 Recommendation, which permits that the digital signatures be associated with PICS labels (a Web annotation system).”

The W3C maintains a webpage called “World Wide Web Security FAQ” and provides an overview of Web security matters. Also, the W3C regularly issues security alerts regarding the topic, which include practical advice for avoiding unpleasant surprises.

III. Initiatives’ Procedural Histories

3.1 Internet Potocol Version 6

IPv6 Working Group

The IPv6 Working Group was created in 1994. In December 1995, the IPv6 Working Group issued the Request for Comments (“RFC”) No. 1884, entitled “IP Version 6 Addressing Architecture”[33]. This paper was to specify the addressing architecture of the IP Version 6 protocol [IPV6]. It contained the “IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 nodes required addresses”.

In the same month and year, the IPv6 WG published another relevant document. The RCP No. 1887, named “An Architecture for IPv6 Unicast Address Allocation”. This paper provided “an architecture for allocating IPv6 unicast addresses in the Internet”. The overall IPv6 addressing architecture was also defined therein.[34]

The same topic was proposed in July 1998 and April 2003 and other two papers called “IP Version 6 Addressing Architecture” were released.

The next steps to be taken by the IPv6 Working Group will be:

· December 2003: (i) Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) to be republished at Draft Standard; (ii) Submit Proxy RA to IESG for Proposed Standard; and (iii) Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard.

· January 2004: Re-charter or close the Working Group.

There are many more documents released by the IPv6 Working Group. The entire historical procedure of the IPv6 Working Group can be found on http://www.ietf.org/html.charters/ipv6-charter.html.

The “v6ops” Group

The v6ops goup was created in 2003 by the IETF. The only RFC issued was that No. 3574, named “Transition Scenarios for 3GPP Networks”, wich “describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS element in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study.”[35]

Next steps are:

·          February 2004: (i) Submit Cellular Deployment Solutions to IESG for BCP; and (ii) Submit Transition Mechanisms to IESG for DS.

·          March 2004: (i) Publish Enterprise Deployment Solutions as a WG I-D; and (ii) Submit IPv6 Neighbor Discovery On-Link Assumption to IESG for BCP.

·          April 2004: (i) Submit Unmanaged Network Deployment Solutions to IESG for BCP; (ii) Submit Dual Stack IPv6 on by Default to IESG for Informational; (iii) Submit ISP Deployment Scenarios & Solutions to IESG for BCP; and (iv) Submit Application Aspects of IPv6 Transition to IESG for Informational.

·          May 2004: Submit 6to4 Security Analysis to IESG for Informational.

·          August 2004: Submit Enterprise Deployment Solutions to IESG for BCP.

For further information regarding the historical procedures of this Working Group, please visit http://www.ietf.org/html.charters/v6ops-charter.html.

Mobile IPv6 (MIPv6)

Also created in 2003 by the IETF, the MIPv6 Working Group has not issues any RFC. Its next goals are:

·           January 2004: Bootstrapping problem statement to IESG.

·           February 2004: Submit MIPv6 MIB to IESG.

·           March 2004: (i) Alternate Route Optimization scheme to IESG; and (ii) Home agent reliability to IESG.

·           August 2004: Bootstrapping solution to IESG.

·           November 2004: Separate specs for Home Agent (HA) Discovery, Route Optimization, Renumbering to IESG.

For further information regarding the historical procedures of this Working Group, please visit http://www.ietf.org/html.charters/mip6-charter.html.

3.2 Mobility

Created in 2003 by the IETF, this Working Group has not issues any RFC. The next steps are:

·          March 2004: Submit the analysis of the solution space for route optimization.

·          June 2004: Shut down or recharter the WG to solve the route optimization.

For further information regarding the historical procedures of this Working Group, please visit  http://www.ietf.org/html.charters/nemo-charter.html.

3.3 Public Key X.509

Created in 1995 by the IETF, the PKI X.509 WG released several documents.

The PKI X.509 issued a paper on March 1999, the Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.

This paper spells out “A public-key certificate (hereinafter ‘certificate’) binds a public-key value to a set of information that identifies the entity (such as person, organization, account, or site) associated with use of the corresponding private key (this entity is known as the ‘subject’ of the certificate). A certificate is used by a ‘certificate user’ or ‘relying party’ that needs to use, and rely upon the accuracy of, the public key distributed via that certificate (a certificate user is typically an entity that is verifying a digital signature from the certificate’s subject or an entity sending encrypted data to the subject). The degree to which a certificate user can trust the binding embodied in a certificate depends on several factors. These factors include the practices followed by the certification authority in authenticating the subject; the [certification authority’s] operating policy, procedures, and security controls; the subject’s obligations (for example, in protecting the private key); and the stated undertakings.”[36]

Recently, in November 2003, essentially the same document was published, however it now had this focus: “This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates.  In particular, the framework provides a comprehensive list of topics that potentially (at the writer’s discretion) need to be covered in a certificate policy or a certification practice statement.”[37]

Next steps are:

· February 2004: Proxy Certificate RFC.

· March 2004: (i) SCVP proposed Standard RFC; (ii) Progression of Qualified Certificates Profile RFC to DRAFT Standard; (iii) Progression of Certificate & CRL Profile RFC to DRAFT Standard; (iv) Progression of Time Stamp Protocols RFC to DRAFT Standard; and (v) Progression of Logotype RFC to DRAFT Standard.

· April 2004: Progression of CRMF, CMP, and CMP Transport to DRAFT Standard.

· June 2004: (i) Progression of Proxy Certificate RFC to DRAFT Standard; (ii) Progression of SCVP to Draft Standard; and (iii) Progression of Attribute Certificate Profile RFC to DRAFT standard.

The entire historical procedure can be found on http://www.ietf.org/html.charters/pkix-charter.html.

3.4 Global Routing Operations (GROW)

Created in 2003, this Working Group issued a recent document in January 2004 called “BGP Communities for Data Collection,” by which it explained that “BGP communities (RFC 1997) are used by service providers for many purposes, including tagging of customer, peer, and geographically originated routes.  Such tagging is typically used to control the scope of redistribution of routes within a provider’s network, and to its peers and customers. With the advent of large scale BGP data collection (and associated research), it has become clear that the information carried in such communities is essential for a deeper understanding of the global routing system. This document defines standard (outbound) communities and their encodings for export to BGP route collectors”.

There is no further information regarding next steps on its website.[38]

3.5 Routing Research Group

     There is no information available regarding the historical procedure for this group.

3.6 Network Management

     There is no information available regarding the historical procedure for this group.

3.7 E.164 – The ENUM

      The only information available is that the ITU-T Study Group 2 has a period of four years from 2001 to 2004.[39]

3.8 Routing Protocol Security

     Created in 2003 by the IETF, the RPS Working Group has only one paper published.

The Generic Threats to Routing Protocols of December 17, 2003, which states: “Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked.”[40]

The next goal is in March 2004, when IETF will evaluate progress, re-charter with new goals (see possible future work above), or shut down.[41] 

3.9 IP Security Protocol

The next goal of the IP Security Protocol Group is the Submit, in January 2004, a revised draft on IPsec Architecture for consideration as Draft Standard.

For further information regarding its historical procedure, please access http://www.ietf.org/html.charters/ipsec-charter.html.

3.10 ICANN Security Committee

Recently launched by the Security Committee the DNS Infrastructure Recommendation of the Security and Stability Advisory Committee – SAC 005
Document 005 Version 1, on  November 1, 2003.

There is no further information available on the next projects or steps.

3.11 W3C Security

There is no further information regarding the next steps of this Working Group.

IV. Commentaries

As noted above, the agendas and activities of international organizations dealing with infrastructure and security are almost entirely technical.

For these reasons, it is not easy to find legal commentary focusing on governance questions for the specific initiatives presented in this paper. Commentaries found in this research are therefore limited to the following topics: (i) IPv6; (ii) X.509; and (iii) E.164.

4.1 IPv6 Commentaries

The big concern related to the IPv6 is privacy and anonymity. In his paper “Translating Privacy Values with Technology,” Mr. Shawn C. Helms[42] points out his concerns about the IPv6 authentication capabilities, which is the most important change from IPv4 to IPv6. 

According to Helms, “Currently, the structure of IPv4 allows users to create false return addresses on data packets, thus making some communications virtually impossible to trace.  IPv6, by contrast, marks each packet with an encryption ‘key’ that cannot be altered or forged, thus securely identifying the packet’s origin. This authentication function can identify every sender and receiver of information over the Internet, thus making it nearly impossible for people to remain anonymous on the Internet.

“The current plans for IPv6 also allocate a permanent address to every device on the Internet.  Currently, most IP addresses are only temporarily allocated to Internet users. The new addresses of IPv6 ‘will be embedded in hardware, and include information that can be traced back to individual network interface cards.’ This will be like a permanent cookie that can never be disabled.  The U.S. government is supporting the adoption of IPv6 technology in order to protect public safety; IPv6 could, for example, help it catch Internet hackers. Such a system, however, could certainly erode, if not eliminate, Internet anonymity.”

To Helms, “Americans are unknowingly giving up anonymity in exchange for convenience, higher productivity, faster communication, better crime prevention, and personalized information.  Such advancements are facilitated by the rapid development of identification technologies.  The proliferation of the Internet and these technologies is leading us toward a world in which our every action is monitored and stored, thus creating the Cyber-Panopticon.  This technological trend toward persistent identification threatens a number of core values that society has traditionally protected, including freedom of expression.”[43]

As noted earlier, the majority of the concerns related to the IPv6 are privacy and anonymity issues. The following articles deal with the same topic in almost the same manner:

(1) 52 Stan. L. Rev. 1315  Stanford Law Review  May, 2000, Symposium on Cyberspace and Privacy: “A New Legal Paradigm?   Resolving Conflicting International Data Privacy Rules in Cyberspace,” Joel R. Reidenberg.

(2) 52 Stan. L. Rev. 1461  Stanford Law Review  May, 2000    Symposium  Cyberspace and Privacy: A New Legal Paradigm?   The Death of Privacy?    A. Michael Froomkin;

(3) 52 Stan. L. Rev. 1251  Stanford Law Review  May, 2000    Symposium  Cyberspace and Privacy: A New Legal Paradigm?   Hardware-Based Id, Rights Management, and Trusted Systems, Jonathan Weinberg;

 (4) 9 Mich. Telecomm. & Tech. L. Rev. 395  Michigan Telecommunications and Technology Law Review  Spring 2003    Comment   Regulating Speech Across Borders: Technology vs. Values,    Matthew Fagin; 

(5) 3 Va. J.L. & Tech. 5  Virginia Journal of Law & Technology  Spring 1998    An Analysis of Internet Standardization,   Marcus Maher; and

(6) 79 Wash. U. L.B. 89  Washington University Law Buarterly  Spring 2001    Articles   Fool US once Shame on You–fool US Twice Shame on US: What We Can Learn From the Privatizations of the Internet Backbone Network and the Domain Name System    Jay P. Kesan [FNa1]  Rajiv C. Shah.  

4.2 PKI X.509 Commentaries

Trust in computer systems has always been a problem. The PKI X.509 is a Public Key paradigm to prevent fraud and to the data of someone (a person) or something (a specific computer). In the paper called “Public Key Infrastructure and ‘Digital Signature’

Legislation: Ten Public Policy Questions”, Mr. Brad Biddle[44] asks:  “Should Legislation Endorse the X.509 Paradigm?”

Biddle identifies strong policy questions not yet addressed:  If we trust in the X.509 infrastructure model, how can we trust in the authority certificate?  What liability is there for wrongdoing or misuse of a public key?

As he notes: “When the Utah Act was enacted, it explicitly endorsed the X.509 infrastructure model. Subsequent laws have dropped the explicit endorsement of X.509, but nonetheless remain true to the X.509 paradigm. Under most digital signature legislation, certificates serve to bind an individual’s identity to a particular public key. This binding is accomplished in the context of a rigid, hierarchical [certification authority] infrastructure.

“This model has been criticized for two main reasons: global [certification authority] hierarchies are almost certainly unworkable, and identity certificates often provide too much information when frequently an ‘attribute’ or ‘authority’ certificate will do. Alternative certificate formats, such as SDSI and SPKI, have emerged in response to these and other perceived flaws with the X.509 model. However, it is not clear that these alternative certificate formats can be accommodated under current digital signature legislation.”

Further documentation may be found in the resources listed below:

(1) 2 No. 9 Elec. Banking L. & Com. Rep. 9  Electronic Banking Law and Commerce Report  March, 1998, Certification Infrastructure Needs for Electronic Commerce and Personal Use, Carl M. Ellison; 

(2) 38 Jurimetrics J. 359  Jurimetrics Journal  Spring, 1998    Public Key Infrastructure Symposium   Public Key Infrastructure Interoperation,  Michael S. Baum, Warwick Ford ;

(3) 38 Jurimetrics J. 497  Jurimetrics Journal  Spring, 1998    Public Key Infrastructure Symposium   EDI and Digital Signatures for Business to Business Electronic Commerce, Juan Carlos Cruellas, Hoyt L. Kesterson II, Manuel Medina, Montse Rubia;

(4) 38 Jurimetrics J. 243  Jurimetrics Journal  Spring, 1998    Public Key Infrastructure Symposium   TUTORIAL.   Information Security Committee Section of Science and Technology American Bar Association;

(5) 75 Or. L. Rev. 49  Oregon Law Review  Spring 1996    Symposium: Innovation and the Information Environment   The Essential Role of Trusted Third Parties in Electronic Commerce,  A. Michael Froomkin

(6) 2 No. 2 Cyberspace Law. 7  Cyberspace Lawyer  April, 1997    Public Key Infrastructure and “Digital Signature” Legislation: Ten Public Policy Buestions,  Brad Biddle.

4.3 E.164/ENUM Commentaries

An ITU official explained in a telephone conversation that the E.164 has problems with respect to regulatory issues, since each country has sovereignty to decide the deployment of telecommunication technologies within its territory. Similarly, Ms. Dana M. Hirsh has noted[45]:

 “The challenge being faced by many countries as a result of the convergence of the worlds of voice and data, is the decision over which government agency should oversee ENUM. For instance, in the United States, the Federal Communications Commission has regulatory authority over telephone numbers while the Commerce Department, through the Internet Corporation for Assigned Names and Numbers (ICANN) manages the Internet DNS.

“Another core issue in the debate regarding ENUM is whether more than one company can operate and store the registry database to which all ENUM queries are made.

“NeuStar Inc., the company that currently operates the North American Numbering Plan (NANP), the master list of telephone area codes and other telephone numbering resources in the United States and the rest of North America, supports a system that would be operated by a single, government- regulated authority. NeuStar currently is operating the ENUM Public Trial on its ENUM.org web site. The ENUM Public Trial is a DNS directory offered to providers of equipment and applications who wish to test the ENUM technology.

 “VeriSign Global Registry Services, the registry operator for the .com Internet domain, advocates the establishment of a competitive marketplace for the provision of ENUM registration services, with participation by a variety of public companies.”

The real question right now is who will hold the E.164 number list?

Informações Sobre o Autor

Carlos Motta

Fundador e Presidente do CBEJI; Advogado associado ao Souza, Cescon Avedissian, Barrieu e Flesch Advogados, formado pela Universidade Mackenzie, foi aluno convidado do curso de pós-graduação em E-Commerce da Faculdade do Largo de São Francisco. Primeiro brasileiro a cursar o LL.M. (Master of Laws) em Law, Science & Technology na Stanford University (2003-2004).