Host Scanning in IPv6 Networks
draft-gont-opsec-ipv6-host-scanning-00

Operational Security Capabilities for                            F. Gont
IP Network Infrastructure (opsec)                                UK CPNI
Internet-Draft                                            April 20, 2012
Intended status: Informational
Expires: October 22, 2012

                     Host Scanning in IPv6 Networks
                 draft-gont-opsec-ipv6-host-scanning-00

Abstract

   IPv6 offers a much larger address space than that of its IPv4
   counterpart.  The standard /64 IPv6 subnets can (in theory)
   accommodate approximately 1.844 * 10^19 hosts, thus resulting in a
   much lower host density (#hosts/#addresses) than their IPv4
   counterparts.  As a result, it is widely assumed that it would take a
   tremendous effort to perform host scanning attacks against IPv6
   networks, and therefore IPv6 host scanning attacks have long been
   considered unfeasible.  This document analyzes the IPv6 address
   configuration policies implemented in most popular IPv6 stacks, and
   identifies a number of patterns in the resulting addresses lead to a
   tremendous reduction in the host address search space, thus
   dismantling the myth that IPv6 host scanning attacks are unfeasible.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 22, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Gont                    Expires October 22, 2012                [Page 1]
Internet-Draft             IPv6 Host Scanning                 April 2012

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Address configuration in IPv6  . . . . . . . . . . . . . . . .  5
     3.1.  StateLess Address Auto-Configuration (SLAAC) . . . . . . .  5
       3.1.1.  Interface-Identifiers embedding IEEE Identifiers . . .  5
       3.1.2.  Privacy Addresses  . . . . . . . . . . . . . . . . . .  7
       3.1.3.  Stable and random Interface Identifiers  . . . . . . .  7
     3.2.  Dynamic Host Configuration Protocol version 6 (DHCPv6) . .  8
     3.3.  Manually-configured addresses  . . . . . . . . . . . . . .  8
   4.  IPv6 address assignment in real-world network scenarios  . . . 10
   5.  Previous work in the area of IPv6 host scanning  . . . . . . . 12
     5.1.  IPv6 host scanning of remote networks  . . . . . . . . . . 12
   6.  Mitigations  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18

Gont                    Expires October 22, 2012                [Page 2]
Internet-Draft             IPv6 Host Scanning                 April 2012

1.  Disclaimer

   This document is a "stripped down" version of a document we have
   authored on IPv6 host scanning.  This version is ssentially meant to
   provide some numbers as to how feasible IPv6 host scanning attacks
   are.  Future revisions will cover the topic more thoroughly.

Gont                    Expires October 22, 2012                [Page 3]
Internet-Draft             IPv6 Host Scanning                 April 2012

2.  Introduction

   The main driver for IPv6 deployment is its larger address space
   [CPNI-IPv6].  This larger address space not only allows for an
   increased number of connected devices, but also introduces a number
   of subtle changes in several aspects of the resulting networks.  One
   of such changes is the reduced host density (Nr. of addresses/Nr. of
   hosts) of a typical IPv6 subnet: with default IPv6 subnets of /64,
   each subnet comprises for more than 1.844 * 10^19 addresses; however,
   the actual number of nodes in each subnet is likely to remain similar
   to that of IPv4 subnetworks (at most a few hundred nodes per subnet).
   This lower host-density has lead to the widely-established myth that
   IPv6 host-scanning attacks are unfeasible, since they would require a
   ridiculously long time (along with a tremendous amount of traffic) to
   be successfully performed.

   This document performs a careful analysis of how IPv6 addresses are
   generated, and sheds some light on the real size of the search space
   when performing an IPv6 host scanning attack, dismantling the myth
   that such IPv6 ahost scanning attacks are unfeasible.  Section 3
   discusses how address configuration is performed in IPv6, describes
   the IPv6 address generation algorithms currently implemented in
   popular IPv6 stacks, and identifies patterns in IPv6 addresses that
   can be leveraged to reduce the IPv6 address search space when
   performing host scanning attacks.  Section 5 describes previous work
   in the area of IPv6 host scanning, and explains its limitations. .
   Section 6 provides advice on how to mitigate IPv6 host scanning
   attacks.

Gont                    Expires October 22, 2012                [Page 4]
Internet-Draft             IPv6 Host Scanning                 April 2012

3.  Address configuration in IPv6

   IPv6 incorporates two automatic address-configuration mechanisms:
   SLAAC (StateLess Address Auto-Configuration) [RFC4862] and DHCPv6
   (Dynamic Host Configuration Protocol version 6) [RFC3315].  SLAAC is
   the mandatory mechanism for automatic address configuration, while
   DHCPv6 is optional - however, most current versions of general-
   purpose operating systems support both.  In addition to automatic
   address configuration, hosts may employ manual configuration, in
   which all the necessary information is manually entered by the host
   or network administrator into configuration files at the host.

   The following subsections describe each of the possible configuration
   mechanisms/approaches in more detail.

3.1.  StateLess Address Auto-Configuration (SLAAC)

   The basic idea behind SLAAC is that every host joining a network will
   send a multicasted solicitation requesting network configuration
   information, and local routers will respond to the request providing
   the necessary information.  SLAAC employs two different ICMPv6
   message types: ICMPv6 Router Solicitation and ICMPv6 Router
   Advertisement messages.  Router Solicitation messages are employed by
   hosts to query local routers for configuration information, while
   Router Advertisement messages are employed by local routers to convey
   the requested information.

   Router Advertisement messages convey a plethora of network
   configuration information, including the IPv6 prefix that should be
   used for configuring IPv6 addresses on the local network.  For each
   local prefix learned from a Router Advertisement message, an IPv6
   address is configured by appending a locally-generated Interface
   Identifier (IID) to the corresponding IPv6 prefix.

   The following subsections describe currently-deployed policies for
   generating the IIDs used with SLAAC.

3.1.1.  Interface-Identifiers embedding IEEE Identifiers

   Many network technologies generate the 64-bit interface identifier
   based on the link-layer address of the corresponding network
   interface card.  For example, in the case of Ethernet addresses, the
   IIDs are constructed as follows:

   1.  The "Universal" bit (bit 6, from left to right) of the address is
       set to 1

Gont                    Expires October 22, 2012                [Page 5]
Internet-Draft             IPv6 Host Scanning                 April 2012

   2.  The word 0xfffe is inserted between the OUI (Organizationally
       Unique Identifier) and the rest of the Ethernet address

   For example, the MAC address 00:1b:38:83:88:3c would lead to the IID
   021b:38ff:fe83:883c.

   A number of considerations should be made about these identifiers.
   Firstly, as it should be obvious from the algorithm described above,
   two bytes (bytes 4-5) of the resulting address always have a fixed
   value (0xff, 0xfe), thus reducing the search space for the IID.
   Secondly, the first three bytes of these identifiers correspond to
   the OUI of the network interface card vendor.  Since not all possible
   OUIs have been assigned, this further reduces the IID search space.
   Furthermore, of the assigned OUIs, many could be regarded as
   corresponding to legacy devices, and thus unlikely to be used for
   Internet-connected IPv6-enabled systems, yet further reducing the IID
   search space.  Finally, in some scenarios it could be possible to
   infer the OUI in use by the target network devices, yet narrowing
   down the possible IIDs even more.

      For example, an organization known for being provisioned by vendor
      X is likely to have most of the nodes in its organizational
      network with OUIs corresponding to vendor X.

   These considerations mean that in some scenarios, the original IID
   search space of 64 bits may be effectively reduced to 2^24 , or n *
   2^24 (where "n" is the number of different OUIs assigned to the
   target vendor).

   Another interesting factor arises from the use of virtualization
   technologies, since they generally employ automatically-generated MAC
   addressses, with very specific patterns.  For example, all
   automatically-generated MAC addresses in VirtualBox virtual machines
   employ the OUI 08:00:27 [VBox2011].  This means that all SLAAC-
   produced addresses will have an IID of the form a00:27ff:feXX:XXXX,
   thus effectively reducing the IID search space from 64 bits to 24
   bits.

   VMWare ESX server provides yet a more interesting example.
   Automatically-generated MAC addresses have the following pattern
   [vmesx2011]:

   1.  The OUI is set to 00:05:59

   2.  The next 16-bits of the MAC address are set to the same value as
       the last 16 bits of the console operating system's primary IPv4
       address

Gont                    Expires October 22, 2012                [Page 6]
Internet-Draft             IPv6 Host Scanning                 April 2012

   3.  The final eight bits of the MAC address are set to a hash value
       based on the name of the virtual machine's configuration file.

   This means that, assuming the console operating system's primary IPv4
   address is known, the IID search space is reduced from 64 bits to 8
   bits.

   On the other hand, manually-configured MAC addresses in VMWare ESX
   server employ the OUI 00:50:56, with the low-order three bytes being
   in the range 0x000000-0x3fffff (to avoid conflicts with other VMware
   products).  Therefore, even in the case of manually-configured MAC
   addresses, the IID search space is reduced from 64-bits to 22 bits.

3.1.2.  Privacy Addresses

   Privacy concerns [CPNI-IPv6] [Gont-DEEPSEC2011] regarding interface
   identifiers embedding IEEE identifiers led to the introduction of
   "Privacy Extensions for Stateless Address Auto-configuration in IPv6"
   [RFC4941], also known as "privacy addresses" or "temporary
   addresses".  Essentially, "privacy addresses" produce random
   addresses by concatenating a random identifier to the auto-
   configuration IPv6 prefix advertised in a Router Advertisement.

      In addition to their unpredictability, these addresses are
      typically short-lived, such that even if an attacker were to learn
      one of these addresses, they would be of use for a reduced period
      of time.

   It is important to note that "privacy addresses" are generated in
   addition to traditional SLAAC addresses (i.e., based on IEEE
   identifiers): traditional SLAAC addresses are employed for incoming
   (i.e. server-like) communications, while "privacy addresses" are
   employed for outgoing (i.e., client-like) communications.  This means
   that implementation/use of "privacy addresses" does not prevent an
   attacker from leveraging the predictability of traditional SLAAC
   addresses, since "privacy addresses" are generated in addition to
   (rather than in replacement of) the traditional SLAAC addresses
   derived from e.g.  IEEE identifiers.

3.1.3.  Stable and random Interface Identifiers

   In order to mitigate the security implications arising from the
   predictable IPv6 addresses derived from IEEE identifiers, Microsoft
   Windows produced an alternative scheme for generating "stable
   addresses" (in repalcement of the ones embedding IEEE identifiers).
   The aforementioned scheme is allegedly an implementation of RFC 4941
   [RFC4941], but without regenerating the addresses over time.  The
   resulting interface IDs are constant across system bootstraps, and

Gont                    Expires October 22, 2012                [Page 7]
Internet-Draft             IPv6 Host Scanning                 April 2012

   also constant across networks.

   Assuming no flaws in the aforementioned algorithm, this scheme would
   remove any patterns from the SLAAC addresses.

      However, since the resulting interface IDs are constant across
      networks, these addresses may still be leveraged for host tracking
      purposes.  [I-D.gont-6man-stable-privacy-addresses]

3.2.  Dynamic Host Configuration Protocol version 6 (DHCPv6)

   DHCPv6 is a stateful address configuration mechanism, in which a
   server (the DHCPv6 server) leases IPv6 addresses to IPv6 hosts.  As
   with the IPv4 counterpart, addresses are assigned acording to a
   configuration-defined address range and policy, with some DHCPv6
   servers assigned addresses sequentially, from a specific range.  In
   such cases, addresses tend to be predictable.

      For example, if the prefix 2001:db8::/64 is used for assigning
      addresses on the local network, the DHCPv6 server might
      (sequentially) assign addresses from the range 2001:db8::1 - 2001:
      db8::100.

   In most common scenarios, this means that the IID search space will
   be reduced from the origina 64 bits, to 8 or 16 bits.

3.3.  Manually-configured addresses

   In some scenarios, node addresses may be manually configured.  This
   is typically the case for IPv6 addresses assigned to routers, since
   router do not employ automatic address configuration.

   While network administrators are mostly free to select the IID from
   any value in the range 1 - 264 range, for the sake of simplicity
   (i.e., ease of remembering) they tend to select addresses with one of
   the following patterns:

   o  "low-byte" addresses: in which all bytes of the IID (except the
      lowest one) are set to 0.

   o  IPv4-based addresses: in which the IID encodes the IPv4-address of
      the network interface (as in 2001:db8::192.168.1.1)

   o  wordy addresses: which encode words (as in 2001:db8::dead:beef)

   Clearly, the first two patterns reduce the search space from the
   original 64 bits to roughly 8 bits (assuming the IPv4 address range
   is known for the case of "IPv4-based" addresses).  On the other hand,

Gont                    Expires October 22, 2012                [Page 8]
Internet-Draft             IPv6 Host Scanning                 April 2012

   the search space for IPv6 wordy-addresses is probably larger and more
   complex, but still greatly reduced when compared to the original 64-
   bit search space.

Gont                    Expires October 22, 2012                [Page 9]
Internet-Draft             IPv6 Host Scanning                 April 2012

4.  IPv6 address assignment in real-world network scenarios

   Table 1 and Table 2 provide a rough summary of the results obtained
   by [Malone2008] for IPv6 clients and IPv6 routers, respectively.
   These results are provided manly for completeness-sake, since they
   are the most comprehensive address-measurement results that have so
   far been made publicly available.

      We note, however, that evolution of IPv6 implementations, changes
      in the IPv6 address selection policy, etc., might limit (or even
      obsolete) the validity of these results.

                       +--------------+------------+
                       | Address type | Percentage |
                       +--------------+------------+
                       |     SLAAC    |     50%    |
                       +--------------+------------+
                       |  IPv4-based  |     20%    |
                       +--------------+------------+
                       |    Teredo    |     10%    |
                       +--------------+------------+
                       |   Low-byte   |      8%    |
                       +--------------+------------+
                       |    Privacy   |      6%    |
                       +--------------+------------+
                       |     Wordy    |     <1%    |
                       +--------------+------------+
                       |     Other    |     <1%    |
                       +--------------+------------+

                    Table 1: Measured client addresses

Gont                    Expires October 22, 2012               [Page 10]
Internet-Draft             IPv6 Host Scanning                 April 2012

                       +--------------+------------+
                       | Address type | Percentage |
                       +--------------+------------+
                       |   Low-byte   |     70%    |
                       +--------------+------------+
                       |  IPv4-based  |      5%    |
                       +--------------+------------+
                       |     SLAAC    |      1%    |
                       +--------------+------------+
                       |     Wordy    |     <1%    |
                       +--------------+------------+
                       |    Privacy   |     <1%    |
                       +--------------+------------+
                       |    Teredo    |     <1%    |
                       +--------------+------------+
                       |     Other    |     <1%    |
                       +--------------+------------+

                    Table 2: Measured router addresses

   It should be clear from these measurements that a very high
   percentage of the follow very specific patterns.

Gont                    Expires October 22, 2012               [Page 11]
Internet-Draft             IPv6 Host Scanning                 April 2012

5.  Previous work in the area of IPv6 host scanning

5.1.  IPv6 host scanning of remote networks

   IPv4 host scanning tools have traditionally carried out their task
   for probing an entire address range (usually the entire range of a
   target subnetwork).  One might argue that the reason for which they
   we have been able to get off with such somewhat "rudimentary" tools
   is that the scale of the "problem" is so small in the IPv4 world,
   that even such a "poor" job is "good enough".  However, the scale of
   the "host scanning" problem is so large in IPv6, that we must be very
   creative to be "good enough".

   Simply sweeping an entire /64 IPv6 subnet would just not be feasible.
   For instance, that is probably one of the reasons for which host
   scanning tools such as nmap [nmap2012] do not even support sweeping
   an IPv6 address range.

      The nmap(1) manual page states "IPv6 addresses can only be
      specified by their fully qualified IPv6 address or hostname.  CIDR
      and octet ranges aren't supported for IPv6 because they are rarely
      useful.

   The most "advanced" IPv6 scanning technique that we are aware of is
   that reported in [Ybema2010], in which the attacker seemed to be
   scanning specific IPv6 addressesbased on specific patterns.  However,
   it probably still falls into the category of "rudimentary".

   Clearly, the limitation of currently-available tools is that they
   lack of an "heuristics engine" that can help reduce the search space,
   such that the problem of IPv6 host scanning becomes tractable.

Gont                    Expires October 22, 2012               [Page 12]
Internet-Draft             IPv6 Host Scanning                 April 2012

6.  Mitigations

   IPv6 host scanning attacks can be mitigated in a number of ways.  A
   non-exhaustive of the possible mitigations follows:

   o  Employ stable privacy-enhanced addresses
      [I-D.gont-6man-stable-privacy-addresses] in replacement of
      addresses based on IEEE identifiers, such that any address
      patterns are eliminated

   o  Employ Intrusion Prevention Systems (IPS) at the perimeter, such
      that host scanning attacks are mitigated

   o  If virtual machines are employed, and "resistance" to host
      scanning attacks is deemed as desirable, employ manually-
      configured MAC addresses

   It should be noted that some of the aforementioned mitigations are
   operational, while others depend on the availability of corresponding
   "patches".

   Additionally, while some resistance to host scanning attacks is
   generally desirable (particularly when lightweight mitigations are
   available), there are scenarios in which such mitigation is unlikely
   to be a high-priority (if at all possible).  Such scenarios include:

   o  Mitigation of IPv6 local host-scanning scans

   o  Mitigation of IPv6 host-scanning attacks in public-facing servers

   In general, it is only possible to mitigate some vectors for IPv6
   local host scanning attacks, but virtually impossible to completely
   mitigate them, particularly when a local attacker can rely on network
   snooping, and protocols employed for the so-called "opportunistic
   networking" (such as mDNS).  On the other hand, public-facing servers
   generally contain corresponding entries in the DNS, in which case an
   attacker can rely on the DNS for network reconnaissance.

   o  We note, however, that if any address patterns are eliminated from
      servers with entries in the DNS, an attacker may have to rely on
      using dictionaries with the DNS, which is generally less reliable
      and more time/traffic consuming than mapping nodes with
      predictable IPv6 addresses.

Gont                    Expires October 22, 2012               [Page 13]
Internet-Draft             IPv6 Host Scanning                 April 2012

7.  Security Considerations

   This document demonstrates that the widely-established myth of IPv6
   host-scanning attacks being unfeasible is more based on "hope" than
   on careful analysis or facts.  We expect host scanning attacks to
   become more and more elaborated (i.e., less "brute force") as general
   deployment of IPv6 increases, and more specifically, as more IPv6-
   only devices are deployed.

Gont                    Expires October 22, 2012               [Page 14]
Internet-Draft             IPv6 Host Scanning                 April 2012

8.  Acknowledgements

   This document resulted from the project "Security Assessment of the
   Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by
   Fernando Gont on behalf of the UK Centre for the Protection of
   National Infrastructure (CPNI).  Fernando Gont would like to thank
   the UK CPNI for their continued support.

Gont                    Expires October 22, 2012               [Page 15]
Internet-Draft             IPv6 Host Scanning                 April 2012

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

9.2.  Informative References

   [I-D.gont-6man-stable-privacy-addresses]
              Gont, F., "A method for Generating Stable Privacy-Enhanced
              Addresses with IPv6 Stateless Address Autoconfiguration
              (SLAAC)", draft-gont-6man-stable-privacy-addresses-01
              (work in progress), March 2012.

   [I-D.ietf-v6ops-v6nd-problems]
              Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
              Neighbor Discovery Problems",
              draft-ietf-v6ops-v6nd-problems-05 (work in progress),
              March 2012.

   [CPNI-IPv6]
              Gont, F., "Security Assessment of the Internet Protocol
              version 6 (IPv6)",  UK Centre for the Protection of
              National Infrastructure, (available on request).

   [Malone2008]

Gont                    Expires October 22, 2012               [Page 16]
Internet-Draft             IPv6 Host Scanning                 April 2012

              Malone, D., "Observations of IPv6 Addresses",  Passive and
              Active Measurement Conference (PAM 2008, LNCS 4979),
              April 2008,
              <http://www.maths.tcd.ie/~dwmalone/p/addr-pam08.pdf>.

   [nmap2012]
              Fyodor, F., "nmap - Network exploration tool and security
              / port scanner", 2011, <http://insecure.org>.

   [VBox2011]
              VirtualBox, V., "Oracle VM VirtualBox User Manual, version
              4.1.2", August 2011, <http://www.virtualbox.org>.

   [vmesx2011]
              vmware, vmware., "Setting a static MAC address for a
              virtual NIC",  vmware Knowledge Base, August 2011, <http:/
              /kb.vmware.com/selfservice/microsites/
              search.do?language=en_US&cmd=displayKC&externalId=219>.

   [Ybema2010]
              Ybema, I., "just seen my first IPv6 network abuse scan, is
              this the start for more?",  Post to the NANOG mailing-
              list, August 2011, <http://mailman.nanog.org/pipermail/
              nanog/2010-September/025049.html>.

   [Gont-DEEPSEC2011]
              Gont, "Results of a Security Assessment of the Internet
              Protocol version 6 (IPv6)",  DEEPSEC 2011 Conference,
              Vienna, Austria, November 2011, <http://
              www.si6networks.com/presentations/deepsec2011/
              fgont-deepsec2011-ipv6-security.pdf>.

   [THC-IPV6]
              "THC-IPV6", <http://www.thc.org/thc-ipv6/>.

Gont                    Expires October 22, 2012               [Page 17]
Internet-Draft             IPv6 Host Scanning                 April 2012

Author's Address

   Fernando Gont
   UK Centre for the Protection of National Infrastructure

   Email: fernando@gont.com.ar
   URI:   http://www.cpni.gov.uk

Gont                    Expires October 22, 2012               [Page 18]