Internet DRAFT - draft-ietf-savi-threat-scope

draft-ietf-savi-threat-scope







SAVI                                                        D. McPherson
Internet-Draft                                            VeriSign, Inc.
Intended status: Informational                                F.J. Baker
Expires: October 12, 2013                                  Cisco Systems
                                                            J.M. Halpern
                                                                Ericsson
                                                          April 10, 2013


                           SAVI Threat Scope
                    draft-ietf-savi-threat-scope-08

Abstract

   Source Address Validation Improvement (SAVI) effort aims to
   complement ingress filtering with finer-grained, standardized IP
   source address validation.  This document describes threats enabled
   by IP source address spoofing both in the global and finer-grained
   context, describes currently available solutions and challenges, and
   provides a starting point analysis for finer-grained (host
   granularity) anti-spoofing work.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 12, 2013.

Copyright Notice

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

   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



McPherson, et al.       Expires October 12, 2013                [Page 1]

Internet-Draft                                                April 2013


   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.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Glossary of Terms . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Spoofed-based Attack Vectors  . . . . . . . . . . . . . . . .   5
     3.1.  Blind Attacks . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.1.  Single Packet Attacks . . . . . . . . . . . . . . . .   6
       3.1.2.  Flood-Based DoS . . . . . . . . . . . . . . . . . . .   6
       3.1.3.  Poisoning Attacks . . . . . . . . . . . . . . . . . .   8
       3.1.4.  Spoof-based Worm/Malware Propagation  . . . . . . . .   8
       3.1.5.  Reflective Attacks  . . . . . . . . . . . . . . . . .   8
       3.1.6.  Accounting Subversion . . . . . . . . . . . . . . . .   9
       3.1.7.  Other Blind Spoofing Attacks  . . . . . . . . . . . .   9
     3.2.  Non-Blind Attacks . . . . . . . . . . . . . . . . . . . .   9
       3.2.1.  Man in the Middle (MITM)  . . . . . . . . . . . . . .   9
       3.2.2.  Third Party Recon . . . . . . . . . . . . . . . . . .  10
       3.2.3.  Other Non-Blind Spoofing Attacks  . . . . . . . . . .  10
   4.  Current Anti-Spoofing Solutions . . . . . . . . . . . . . . .  10
     4.1.  Topological Locations for Enforcement . . . . . . . . . .  12
       4.1.1.  Host to link layer neighbor via switch  . . . . . . .  12
       4.1.2.  Upstream Switches . . . . . . . . . . . . . . . . . .  13
       4.1.3.  Upstream Routers  . . . . . . . . . . . . . . . . . .  13
       4.1.4.  ISP Edge PE Router  . . . . . . . . . . . . . . . . .  13
       4.1.5.  ISP NNI Router to ISP NNI Router  . . . . . . . . . .  14
       4.1.6.  Cable Modem Subscriber Access . . . . . . . . . . . .  14
       4.1.7.  DSL Subscriber Access . . . . . . . . . . . . . . . .  15
     4.2.  Currently Available Tools . . . . . . . . . . . . . . . .  15
       4.2.1.  BCP 38  . . . . . . . . . . . . . . . . . . . . . . .  15
       4.2.2.  Unicast RPF . . . . . . . . . . . . . . . . . . . . .  15
       4.2.3.  Port-based Address Binding  . . . . . . . . . . . . .  15
       4.2.4.  Cryptographic Techniques  . . . . . . . . . . . . . .  17
       4.2.5.  Residual Attacks  . . . . . . . . . . . . . . . . . .  17
   5.  Topological Challenges Facing SAVI  . . . . . . . . . . . . .  17
     5.1.  Address Provisioning Mechanisms . . . . . . . . . . . . .  17
     5.2.  LAN devices with Multiple Addresses . . . . . . . . . . .  18
       5.2.1.  Routers . . . . . . . . . . . . . . . . . . . . . . .  18
       5.2.2.  NATs  . . . . . . . . . . . . . . . . . . . . . . . .  18
       5.2.3.  Multi-Instance Hosts  . . . . . . . . . . . . . . . .  18
       5.2.4.  Multi-LAN Hosts . . . . . . . . . . . . . . . . . . .  19
       5.2.5.  Firewalls . . . . . . . . . . . . . . . . . . . . . .  20
       5.2.6.  Mobile IP . . . . . . . . . . . . . . . . . . . . . .  20
       5.2.7.  Other Topologies  . . . . . . . . . . . . . . . . . .  20



McPherson, et al.       Expires October 12, 2013                [Page 2]

Internet-Draft                                                April 2013


     5.3.  IPv6 Considerations . . . . . . . . . . . . . . . . . . .  20
   6.  Analysis of Host Granularity Anti-Spoofing  . . . . . . . . .  21
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
     8.1.  Privacy Considerations  . . . . . . . . . . . . . . . . .  23
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  24
     10.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Overview

   The Internet Protocol, specifically IPv4 [RFC0791] and IPv6
   [RFC2460], employ a connectionless hop-by-hop packet forwarding
   paradigm.  A host connected to an IP network that wishes to
   communicate with another host on the network generates an IP packet
   with source and destination IP addressing information, among other
   options.

   At the IP Network Layer, or Internet Layer, there is typically no
   required transactional state when communicating with other hosts on
   the network.  In particular, the network does not track any state
   about the hosts using the network.  This is normally a benefit.
   However, as a consequence of this, hosts generating packets for
   transmission have the opportunity to spoof (forge) the source address
   of packets which they transmit, as the network does not have any way
   to tell that some of the information is false.

   Source address validation is necessary in order to detect and reject
   IP spoofed packets in the network, and contributes to the overall
   security of IP networks.  This draft deals with the subset of such
   validation done by the network based on observed traffic and policy.
   Such source address validation techniques enable detection and
   rejection of many spoofed packets, and also implicitly provide some
   assurances that the source address in an IP packet is legitimately
   assigned to the system that generated the packet.

   Solutions such as BCP 38 [RFC2827] provide guidelines for one such
   technique for network ingress filtering.  However, if these
   techniques are not implemented at the ingress point of the IP
   network, then the validity of the source address cannot be positively
   ascertained.  Furthermore, BCP 38 only implies source address
   validation at the Internet Layer, and is most often implemented on IP
   subnetwork address boundaries.  One of the difficulties in
   encouraging the deployment of BCP 38 is that there is relatively
   little benefit until it is very widely deployed, which is not yet the
   case.



McPherson, et al.       Expires October 12, 2013                [Page 3]

Internet-Draft                                                April 2013


   Hence, in order to try to get better behavior, it is helpful to look
   for an application like BCP 38, but one which can be applied locally,
   and give locally beneficial results.  The local benefit would provide
   a reason for the site to deploy, while moving the Internet as a whole
   towards an environment where BCP 38 is widely effected.  SAVI is
   aimed at providing locally more specific protection, with the benefit
   of better local behavior and, in conjunction with appropriate
   logging, better local traceability, while also providing better
   compliance with the cases dealt with by BCP 38.

   It should be noted that while BCP 38 directs providers to provide
   protection from spoofed prefixes, it is clearly desirable for
   enterprise operators to provide that protection more locally, and
   with better traceability.  This allows the enterprise to be a better
   Internet participant, and to quickly detect and remedy problems when
   they occur.  For example, when an enterprise receives a report of an
   attack originating within that enterprise, the operational staff
   desires to be able to track from the IP address sourcing the attack
   to the particular machine within the enterprise that is the source.
   This is typically simpler and more reliable than other techniques,
   such as trying to find the attack in ongoing outbound traffic To do
   this, the enterprise needs both that the address assignment and usage
   information be usable (appropriate logging), and that the information
   be accurate (SAVI), i.e.  that no other machine could have been using
   that address.

   Also, there is a possibility that in a LAN environment where multiple
   hosts share a single LAN or IP port on a switch or router, one of
   those hosts may spoof the source addresses of other hosts within the
   local subnet.  Understanding these threats and the relevant
   topologies in which they're introduced is critical when assessing the
   threats that exist with source address spoofing.

   This document provides additional details regarding spoofed-based
   threat vectors, and discuss implications of various network
   topologies.

2.  Glossary of Terms

   The following acronyms and terms are used throughout this memo.

   binding anchor:  The relationship used by a device performing source
      address enforcement to perform the validation and enforcement.
      Examples in different situations include Layer 2 addresses or
      physical ports.

   BGP:  The Border Gateway Protocol, used to manage routing policy
      between large networks.



McPherson, et al.       Expires October 12, 2013                [Page 4]

Internet-Draft                                                April 2013


   CPE Router:  Customer Premises Equipment Router.  The router on the
      customer premises, whether owned by the customer or the provider.
      Also called the Customer Edge, or CE, Router.

   IP Address:  An Internet Protocol Address, whether IPv4 or IPv6.

   ISP:  Internet Service Provider.  Any person or company that delivers
      Internet service to another.

   MAC Address:  An Ethernet Address or comparable IEEE 802 series
      address.

   NNI Router:  Network to Network Interface Router.  This router
      interface faces a similar system operated by another ISP or other
      large network.

   PE Router:  Provider Edge Router.  This router faces a customer of an
      ISP.

   Spoofing:  The act of sending a datagram header whose contents at the
      Link or Network Layer do not match the network policies and
      activities on address assignment or claiming.  Generally, this
      corresponds to sending messages with source network or link layer
      information that is assigned to or curretly properly claimed by
      some other devices in the network

   TCP:  The Transmission Control Protocol, used on end systems to
      manage data exchange.

   uRPF:  Unicast Reverse Path Forwarding.  A procedure in which the
      route table, which is usually used to look up destination
      addresses and route towards them, is used to look up the source
      address and ensure that one is routing away from it.  When this
      test fails, the event may be logged, and the traffic is commonly
      dropped.

3.  Spoofed-based Attack Vectors

   Spoofing is employed on the Internet for a number of reasons, most of
   which are in some manner associated with malicious or otherwise
   nefarious activities.  In general, two classes of spoofed-based
   attack vectors exist: blind attacks and non-blind attacks.  The
   following sections provide some information of blind and non-blind
   attacks.  The section includes information on attacks where the
   spoofing is primarily intended to interfere with tracing the attacks,
   as well as attacks where spoofing the source address is a necessary
   component to the damage or interference.




McPherson, et al.       Expires October 12, 2013                [Page 5]

Internet-Draft                                                April 2013


3.1.  Blind Attacks

   Blind attacks typically occur when an attacker isn't on the same
   local area network as a source or target, or when an attacker has no
   access to the data path between the attack source(s) and the target
   systems.  In this situation, the attacker has no access to the source
   and target systems.

3.1.1.  Single Packet Attacks

   One type of blind attacks, which we'll refer to here as "single
   packet DoS (Denial of Service) attacks", involves an attacking system
   injecting spoofed information into the network which results in
   either a complete crash of the target system, or in some manner
   poisons some network configuration or other information on a target
   system so as to impact network or other services.

   An example of an attack that can cause a receiving system to crash is
   what is called a LAND (Local Area Network Denial) attack.  A LAND
   attack packet would consist of an attacking system sending a packet
   (e.g., TCP SYN) to a target system that contains both a source and
   destination address of that target system.  It would also contain a
   single value for port number, used as both the source and destination
   port number.  Certain target systems will then "lock up" when
   creating connection state associated with the packet, or would get
   stuck in a state where it continuously replies to itself.  As this is
   an attack that relies on bugs in the target, it is possible, but by
   no means certain, that this threat is no longer viable.

   Another form of blind attack is a RST probe [RFC4953] (section 2.3).
   The attacker sends a series of packets to a destination which is
   engaged in a long-lived TCP session.  The packets are RST packets,
   and the attacker uses the known source and destination addresses and
   port numbers, along with guesses at the sequence number.  If he can
   send a packet close enough to the right value, in theory he can
   terminate the TCP connection.  While there are various steps that
   have been developed to ameliorate this attack, preventing the
   spoofing of source addresses completely prevents the attack from
   occuring.

3.1.2.  Flood-Based DoS










McPherson, et al.       Expires October 12, 2013                [Page 6]

Internet-Draft                                                April 2013


   Flooding-based DoS attack vectors are particularly effective attacks
   on the Internet today.  They usually entail flooding a large number
   of packets towards a target system, with the hopes of either
   exhausting connection state on the target system, consuming all
   packet processing capabilities of the target or intermediate systems,
   or consuming a great deal of bandwidth available to the target system
   such that they are essentially inaccessible.

   Because these attacks require no reply from the target system and
   require no legitimate transaction state, attackers often attempt to
   obfuscate the identity of the systems that are generating the attack
   traffic by spoofing the source IP address of the attacking traffic
   flows.  Because ingress filtering isn't applied ubiquitously on the
   Internet today, spoof-based flooding attack vectors are typically
   very difficult to traceback.  In particular, there may be one or more
   attacking sources beyond your network border, and the attacking
   sources may or may not be legitimate sources, it's difficult to
   determine if the sources are not directly connected to the local
   routing system.  These attacks might be seen as primarily to be
   addressed by BCP 38 deployment, which would not be in scope for this
   document.  However, as noted earlier, deployment of SAVI can help
   remediate lack of BCP 38, and even when BCP 38 is deployed can help
   provide useful information for responding to such attacks.

   Common flood-based DoS attack vectors today include SYN floods, ICMP
   floods, and IP fragmentation attacks.  Attackers may use a single
   legitimate or spoofed fixed attacking source address, although
   frequently they cycle through large swaths of address space.  As a
   result, mitigating these attacks on the receiving end with source-
   based policies is extremely difficult.

   If an attacker can inject messages for a protocol which requires
   control plane activity, it may be possible to deny network control
   services at a much lower attack level.  While there are various forms
   of protection deployed against this, they are by no means complete.
   Attacks which are harder to trace (such as with spoofed addresses)
   are of course of more concern.

   Furthermore, the motivator for spoof-based DoS attacks may actually
   be to encourage the target to filter explicitly on a given set of
   source addresses, or order to disrupt the legitimate owner(s) access
   to the target system.









McPherson, et al.       Expires October 12, 2013                [Page 7]

Internet-Draft                                                April 2013


3.1.3.  Poisoning Attacks

   While poison attacks can often be done with single packets, it is
   also true that a stream of packets can be used to find a window where
   the target will accept the incorrect information.  In general, this
   can be used to perform broadly the same kinds of poisonings as above,
   with more versatility.

   One important class of poisoning attacks are attacks aimed at
   poisoning network or DNS cache information, perhaps to simply break a
   given host's connection, enable MITM (Man in the Middle) or other
   attacks.  Network level attacks that could involve single packet DoS
   include ARP cache poisoning and ICMP redirects.  The most obvious
   example which depends upon falsifying an IP source address is an on-
   link attacker poisoning a router's ARP or ND cache.  The ability to
   forge a source address can also be helpful in causing a DNS cache to
   accept and use incorrect information.

3.1.4.  Spoof-based Worm/Malware Propagation

   Self-propagating malware has been observed that spoofs its source
   address when attempting to propagate to other systems.  Presumably,
   this was done to obfuscate the actual source address of the infected
   system.  This attack is important both in terms of an attack vector
   that SAVI may help prevent, and also as a problem which SAVI can help
   track back to find infected systems.

3.1.5.  Reflective Attacks

   Reflective amplifications attacks, wherein a sender sends a single
   packet to an intermediary, resulting in the intermediary sending a
   large number of packets, or much larger packets, to the target, are a
   particularly potent DoS attack vector on the Internet today.  Many of
   these attacks rely on using a false source address, so that the
   amplifier attacks the target by responding to the messages.

   DNS is one of the common targets of such attacks.  The amplification
   factor observed for attacks targeting DNS root and other top level
   domain name infrastructure in early 2006 was on the order of 76:1.
   The result is that just 15 attacking sources with 512Kbps of upstream
   attack bandwidth could generate one Gbps of response attack traffic
   towards a target system.

   Smurf attacks employ a similar reflective amplification attack
   vector, exploiting traditional default IP subnet directed broadcast
   address behaviors that would result in all the active hosts on a
   given subnet responding to (spoofed) ICMP echo request from an
   attacker, and generating a large amount of ICMP echo response traffic



McPherson, et al.       Expires October 12, 2013                [Page 8]

Internet-Draft                                                April 2013


   directed towards a target system.  They were particularly effective
   in large campus LAN environments where 50k or more hosts might reside
   on a single subnet.

3.1.6.  Accounting Subversion

   If an attacker wishes to distribute content or other material in a
   manner that employs protocols that require only uni-directional
   flooding and generate no end-end transactional state, they may desire
   to spoof the source IP address of that content in order to avoid
   detection or accounting functions enabled at the IP layer.  While
   this particular attack has not been observed, it is included here to
   reflect the range of power that spoofed addresses may have even
   without the ability to receive responses.

3.1.7.  Other Blind Spoofing Attacks

   Other Blind spoofing attacks might include spoofing in order to
   exploit source routing or other policy based routing implemented in a
   network.  It may also be possible in some environments to use
   spoofing techniques to perform blind or non-blind attacks on the
   routers in a site or in the Internet.  There are many techniques to
   mitigate these attacks, but it is well known that there are
   vulnerabilities in this area.

3.2.  Non-Blind Attacks

   Non-blind attacks often involve mechanisms such as eavesdropping on
   connection, resetting state so that new connections may be hijacked,
   and an array of other attack vectors.  Perhaps the most common of
   these attack vectors is known as man in the middle attacks.  In this
   case, we are concerned not with an attacker who can modify a stream,
   but rather one who has access to information from the stream, and
   uses that to launch his own attacks.

3.2.1.  Man in the Middle (MITM)

   Connection Hijacking is one of the more common man in the middle
   attack vectors.  In order to hijack a connection an attacker usually
   needs to be in the forwarding path and often times employs TCP RST or
   other attacks in order to reset a transaction.  The attacker may have
   already compromised a system that's in the forwarding path, or they
   may wish to insert themselves in the forwarding path.

   For example, an attacker with access to a host on LAN segment may
   wish to redirect all the traffic on the local segment destined for a
   default gateway address (or all addresses) to itself in order to
   perform man-in-the-middle attacks.  In order to accomplish this, in



McPherson, et al.       Expires October 12, 2013                [Page 9]

Internet-Draft                                                April 2013


   IPv4 the attacker might transmit gratuitous ARP [RFC0826] messages or
   ARP replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff,
   notifying all the hosts on the segment that the IP address(es) of the
   target(s) now map to it's own Layer 2 address.  The source IP address
   in this case is spoofed.  Similar vulnerabilities exist in IPv6 NDP
   [RFC4861], although the multicast requirements of IPv6 NDP make this
   harder to perform with the same generality.

3.2.2.  Third Party Recon

   Another example of non-blind attack is third party reconnaissance.
   The use of spoofed addresses, while not necessary for this, can often
   provide additional information, and helps mask the traceability of
   the activity.  The attack involves sending packets towards a given
   target system and observing either target or intermediate system
   responses.  For example, if an attacker were to source spoof TCP SYN
   packets towards a target system from a large set of source addresses,
   and observe responses from that target system or some intermediate
   firewall or other middle box, they would be able to identify what IP
   layer filtering policies may be in place to protect that system.

3.2.3.  Other Non-Blind Spoofing Attacks

   There are presumably many other attacks that can be performed based
   on the ability t spoof source address while seeing the target.  Among
   other attacks, if there are multiple routers on-link with hosts, a
   host may be able to cause problems for the routing system by
   replaying modified or unmodified routing packets as if they came from
   another router.

4.  Current Anti-Spoofing Solutions

   The goal of this work is to reduce datagrams with spoofed IP
   addresses from the Internet.  This can be aided by Identifying and
   dropping datagrams whose source address binding is incompatible with
   the Internet topology and learned information.  This can be done at
   sites where the relationship between the source address and topology
   and binding information can be checked.  For example, With these
   bindings, in many networks Internet devices can confirm that:

   o  The IP source address is appropriate for the lower layer address
      (they both identify the same system)

   o  The IP source address is explicitly identified as appropriate for
      the physical topology; for example, the source address is
      appropriate for the layer 2 switch port through which the datagram
      was received.




McPherson, et al.       Expires October 12, 2013               [Page 10]

Internet-Draft                                                April 2013


   o  The prefix to which the IP source address belongs is appropriate
      for the part of the network topology from which the IP datagram
      was received (while the individual system may be unknown, it is
      reasonable to believe that the system is located in that part of
      the network).

   In general, this involves two kinds of inspection.  The primary
   action is checking the source IP address in the IP header of IP
   packets.  In order to support such checking, the claimed or assigned
   IP addresses in messages concerned with such claims or assignments
   (IP ARP Requests and Responses, DHCP Replies, IPv6 ND DAD messages,
   etc.)  must also be examined and where appropriate verified.  SAVI is
   not concerned with verifying IP addresses in the contents of
   arbitrary higher level protocol messages.

   Filtering points farther away from the source of the datagram can
   make decreasingly authoritative assertions about the validity of the
   source address in the datagram.  Nonetheless, there is value in
   dropping traffic that is clearly inappropriate, and in maintaining
   knowledge of the level of trust one can place in an address.

             Edge Network 1            CPE-ISP _.------------.
           _.----------------.         Ingress/   ISP A       `--.
      ,--''                   `---.      ,'                       `.
    ,'  +----+  +------+  +------+ `.   /  +------+       +------+  \\
   (    |Host+--+Switch+--+ CPE  +---)-(---+  PE  +- - - -+ NNI  |   )
    `.  +----+  +------+  |Router| ,'   \\  |Router|       |Router|  /
      `---. Host-neighbor +------+'      `.+------+       +--+---+,'
           `----------------''             '--.              |_.-'
                                               `------------'|
                                                             |
             Edge Network 2                  ISP-ISP Ingress |
           _.----------------.                  _.----------.|
      ,--''                   `---.         ,-''             |--.
    ,'  +----+  +------+  +------+ `.     ,+------+       +--+---+.
   (    |Host+--+Switch+--+ CPE  +---)---+-+  PE  +- - - -+ NNI  | \\
    `.  +----+  +------+  |Router| ,'   (  |Router|       |Router|  )
      `---.               +------+'      \\ +------+       +------+ /
           `----------------''            `.                     ,'
                                            '--.   ISP B     _.-'
                                                `----------''

            Figure 1: Points where an address can be validated

   Figure 1 illustrates five related paths where a source address can be
   validated:

   o  host to switch, including host to host via the switch



McPherson, et al.       Expires October 12, 2013               [Page 11]

Internet-Draft                                                April 2013


   o  Host to enterprise CPE Router

   o  Enterprise CPE Router to ISP edge PE Router, and the reverse

   o  ISP NNI Router to ISP NNI Router

   In general, datagrams with spoofed IP addresses can be detected and
   discarded by devices that have an authoritative mapping between IP
   addresses and the network topology.  For example, a device that has
   an authoritative table between Link Layer and IP addresses on a link
   can discard any datagrams in which the IP address is not associated
   with the Link Layer address in the datagram.  The degree of
   confidence in the source address depends on where the spoofing
   detection is performed and the prefix aggregation in place between
   the spoofing detection and the source of the datagram.

4.1.  Topological Locations for Enforcement

   There are a number of kinds of places, which one might call
   topological locations, where solutions may or should be deployed.  As
   can be seen in the details below, as the point of enforcement moves
   away from a single cable attached directly to the host being
   validated, additional complications arise.  It is likely that fully
   addressing many of these cases may require additional coordination
   mechanisms across the device which cover the disparate paths.

4.1.1.  Host to link layer neighbor via switch

   The first point at which a datagram with a spoofed address can be
   detected is on the link to which the source of the datagram is
   connected.  At this point in the network, the source Link Layer and
   IP addresses are both available, and can be validated against each
   other, and potentially against the physical port being used.  A
   datagram in which the IP source address does not match the
   corresponding Link Layer address can be discarded.  Of course, the
   trust in the filtering depends on the trust in the method through
   which the mappings are developed.  This mechanism can be applied by a
   first hop router, or switch on the link.  The first hop switch has
   the most precise information for this.

   On a truly shared medium link, such as classic Ethernet, the best
   that can be done is to validate the Link Layer and IP addresses
   against the mappings.  When the link is not shared, such as when the
   hosts are connected through a switch, the source host can be
   identified precisely based on the port through which the datagram is
   received or the Layer 2 address if it is known to the switch.  Port
   identification prevents transmission of malicious datagrams whose
   Link Layer and IP addresses are both spoofed to mimic another host.



McPherson, et al.       Expires October 12, 2013               [Page 12]

Internet-Draft                                                April 2013


   Other kinds of links may fall at different places in this spectrum,
   with some wireless links having easier ways of identifying individual
   devices than others, for example.

4.1.2.  Upstream Switches

   In many topologies, there can be additional switches between the host
   attached switch and the first router in the network.  In these cases,
   additional issues can arise which affect SAVI operations.  If the
   bridging topologies which connects the switches changes, or if LACP
   [IEEE802.3ad], VRRP, or link management operations, change which
   links are used to deliver traffic, the switch may need to move the
   SAVI state to a different port, or the state may need to be moved or
   reestablished on a different switch.

4.1.3.  Upstream Routers

   Beyond the first hop router, subsequent routers may additionally
   filter traffic from downstream networks.  Because these routers do
   not have access to the Link Layer address of the device from which
   the datagram was sent, they are limited to confirming that the source
   IP address is within a prefix that is appropriate for downstream
   router from which the datagram was received.

   Options include the use of simple access lists or the use of unicast
   reverse path filtering (uRPF).  Access lists are generally
   appropriate only for the simplest cases, as management can be
   difficult.  Strict Unicast RPF accepts the source address on a
   datagram if and only if it comes from a direction that would be
   rational to send a datagram directed to the address, which means that
   the filter is derived from routing information.  These filtering
   procedures are discussed in more detail in [RFC3704].

   In many cases, this router has access to information about what IP
   prefixes are to be used on a given subnet.  This might be because it
   delegated that prefix through DHCP or monitored such a delegation.
   It may have advertised that prefix in IPv6 Neighbor Discovery Router
   Advertisement messages, or monitored such an advertisement.  These
   can be seen as generalizations of the access lists above.  When the
   topology permits, the router can enforce that these prefixes are used
   by the hosts.

4.1.4.  ISP Edge PE Router

   An obvious special case of the discussion is with an ISP PE router,
   where it provides its customer with access.  BCP 38 specifically
   encourages ISPs to use ingress filtering to limit the incidence of
   spoofed addresses in the network.



McPherson, et al.       Expires October 12, 2013               [Page 13]

Internet-Draft                                                April 2013


   The question that the ISP must answer for itself is the degree to
   which it trusts its downstream network.  A contract might be written
   between an ISP and its customer requiring that the customer apply the
   procedures of network ingress filtering to the customer's own
   network, although there's no way upstream networks would be able to
   validate this.

   Conversely, if the provider has assigned a single IP address to the
   customer (for example, with IPv4 NAT in the CPE) PE enforcement of
   BCP 38 can be on the full address, simplifying many issues.

4.1.5.  ISP NNI Router to ISP NNI Router

   The considerations explicitly related to customer networks can also
   be applied to neighboring ISPs.  An interconnection agreement might
   be written between two companies requiring network ingress filtering
   policy be implemented on all customers connections.  ISPs might, for
   example, mark datagrams from neighboring ISPs that do not sign such a
   contract or demonstrably do not behave in accordance with it as
   'untrusted'.  Alternatively, the ISP might place untrusted prefixes
   into a separate BGP community [RFC4271] and use that to advertise the
   level of trust to its BGP peers.

   In this case, uRPF is less effective as a validation tool, due to
   asymmetric routing.  However, when it can be shown that spoofed
   addresses are present, the procedure can be applied.

   Part of the complication here is that in the abstract it is very
   difficult to know what addresses should appear in packets sent from
   one ISP to another.  Hence packet level filtering and enforcement is
   very difficult at this point in the network.  Whether one views this
   as specific to the NNI, or a general property of the Internet, it is
   still a major factor that needs to be taken into account.

4.1.6.  Cable Modem Subscriber Access

   Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access
   Control (MAC) domains.  These share some properties with general
   switched networks, as described above in Section 4.1.1, some
   properties with DSL access networks, as described below in
   Section 4.1.7.  They also often have their own provisioning and
   monitoring tools which may address some of the issues described here.









McPherson, et al.       Expires October 12, 2013               [Page 14]

Internet-Draft                                                April 2013


4.1.7.  DSL Subscriber Access

   While DSL subscriber access can be bridged or routed, as seen by the
   service provider's device, it is generally the case that the
   protocols carry enough information to validate which subscriber is
   sending packets.  Thus, for ensuring that one DSL subscriber does not
   spoof another, enforcement can generally be done at the aggregation
   router.  This is true even when there is a bridged infrastructure
   among the subscribers, as DSL access generally requires all
   subscriber traffic to go through the access aggregation router.

   If it is desirable to provide spoofing protection among the devices
   within a residence, that would need to be provided by the CPE device,
   as the ISPs router does not have enough visibility to do that.  It is
   not clear at this time that this problem is seen as a relevant
   threat.

4.2.  Currently Available Tools

   There are a number of tools which have been developed, and have seen
   some deployment, for addressing these attacks.

4.2.1.  BCP 38

   If BCP 38 [RFC2827] is implemented in LAN segments, it is typically
   done so on subnetwork boundaries and traditionally relates only to
   Network Layer ingress filtering policies.  The result is that hosts
   within the segment cannot spoof packets from address space outside of
   the local segment itself, however, they may still spoof packets using
   sources addresses that exist within the local network segment.

4.2.2.  Unicast RPF

   Unicast RPF is a crude mechanism to automate definition of BCP 38
   style filters based on routing table information.  Its applicability
   parallels that of BCP 38, although deployment caveats exist, as
   outlined in [RFC3704].

4.2.3.  Port-based Address Binding

   Much of the work of SAVI is initially targeting minimizing source
   address spoofing in the LAN.  In particular, if mechanisms can be
   defined to accommodate configuration of port binding information for
   IP, either to a port, to an an unchangeable or authenticated MAC
   address, or to other credentials in the packet such that an impostor
   can not create the needed values, a large portion of the spoofing
   threat space in the LAN can be marginalized.




McPherson, et al.       Expires October 12, 2013               [Page 15]

Internet-Draft                                                April 2013


   However, establishing this binding is not trivial, and varyies across
   both topology types and address allocation mechanisms.

4.2.3.1.  Manual Binding

   Binding of a single Link Layer and Network Layer address to a port
   may initially seem trivial.  However, two primary areas exist that
   can complicate such techniques.  In particular, these areas involve
   topologies where more than a single IP layer address may be
   associated with a MAC address on a given port, or where multiple
   hosts are connected via a single physical port.  Furthermore, if one
   or more dynamic address allocation mechanisms such as DHCP are
   employed, then some mechanism must exist to associate those IP layer
   addresses with the appropriate Link layer ports, as addresses are
   allocated or reclaimed.

4.2.3.2.  Automated Binding

   For IPv4 the primary and very widely used automated address
   assignment technique is DHCP based address assignment.  This can be
   coupled with filtering policies which control which hosts can
   originate DHCP replies.  Under such circumstances, SAVI switches can
   treat DHCP replies as authoritative sources of IP Address binding
   information.  By eavesdropping on the DHCP exchanges, the SAVI switch
   can create the bindings needed for address usage enforcement.

   For IPv6, there are two common automated address assignment
   techniques.  While there are many variations and details, for
   purposes of understanding the threats and basic responses, these are
   Stateless Address Autoconfiguration (SLAAC) and DHCPv6 based address
   assignment.  For DHCP based IPv6 address assignment, the techniques
   above are applicable and suitable.

   When SLAAC is used for IPv address assignment, the switches can
   observe the duplicate address detection messages and use those to
   create the enforcement bindings.  This enables the switches to ensure
   that only properly claimed IP addresses are used for data traffic.
   It does not enforce that these addresses are assigned to the hosts,
   since SLAAC does not have a notion of address assignment.

4.2.3.3.  IEEE 802.1x










McPherson, et al.       Expires October 12, 2013               [Page 16]

Internet-Draft                                                April 2013


   IEEE 802.1x is an authentication protocol that permits a network to
   determine the identity of a user seeking to join it and apply
   authorization rules to permit or deny the action.  In and of
   themselves, such tools confirm only that the user is authorized to
   use the network, but do not enforce what IP address the user is
   allowed to use.  It is worth noting that elements of 802.1x may well
   be useful as binding anchors for SAVI solutions.

4.2.4.  Cryptographic Techniques

   MITM and replay attacks can typically be mitigated with cryptographic
   techniques.  However, many of the applications today either don't or
   can't employ cryptographic authentication and protection mechanisms.
   ARP for IPv4 does not use such protection.  While SEND provides such
   protection for IPv6 NDP, SEND is not widely used to date.  Usage of
   such techniques is outside the scope of this document.

   While DNSSEC will significantly help protect DNS from the effects of
   spoof based poisoning attacks, such protection does not help protect
   the rest of the network from spoofed attacks.

4.2.5.  Residual Attacks

   It should be understood that not all combinations of network, service
   and enforcement choices will result in a protectable network.  For
   example, if one uses conventional SLAAC, in a switched network, but
   tries to only provide address enforcement on the routers on the
   network, then the ability to provide protection is severely limited.

5.  Topological Challenges Facing SAVI

   As noted previously, topological components and address allocation
   mechanisms have significant implications on what is feasible with
   regard to Link layer address and IP address port bindings.  The
   following sections discuss some of the various topologies and address
   allocation mechanisms that proposed SAVI solutions should attempt to
   address.

5.1.  Address Provisioning Mechanisms

   In a strictly static environment, configuration management for access
   filters that map Link Layer and Network Layer addresses on a specific
   switch port might be a viable option.  However, most networks,
   certainly those that accommodate actual human users, are much more
   dynamic in nature.  As such, mechanisms that provide port-MAC-IP
   bindings need to accommodate dynamic address allocation schemes
   enabled by protocols such as DHCP, DHCPv6 for address allocation, and
   IPv6 Stateless Address Autoconfiguration.



McPherson, et al.       Expires October 12, 2013               [Page 17]

Internet-Draft                                                April 2013


5.2.  LAN devices with Multiple Addresses

   From the perspective of network topology, consider hosts connected to
   switch ports that may have one or more IP addresses, and devices that
   forward packets from other network segments.  It is much harder to
   enforce port-MAC-IP bindings on traffic from such hosts and devices,
   than for traffic from more simply-conencted devices.

5.2.1.  Routers

   Routers are the most obvious examples of devices for which it is
   problematic to implement port-MAC-IP bindings.  Routers not only
   originate packets themselves and often have multiple interfaces, but
   also forward packets from other network segments.  As a result, it's
   difficult for port-MAC-IP binding rules to be established a priori,
   because it's likely that many addresses and IP subnets should be
   associated with the port-MAC in question.

5.2.2.  NATs

   Validating traffic from Prefix-based and multi-address NATs is also
   problematic, for the same reasons as for routers.  Because they may
   forward traffic from an array of addresses, validation requires
   advance knowledge of what IPs should be associated with a given port-
   MAC pair.

5.2.3.  Multi-Instance Hosts

   Another example that introduces complexities is that of multi-
   instance hosts attached to a switch port.  These are single physical
   devices, which internally run multiple physical or logical hosts.
   When the device is a blade server, e.g.  with internal blades each
   hosting a physical machine, there is essentially a physical switch
   inside the blade server.  While feasible, this creates some
   complexity for determining where enforcement logic can or should
   live.















McPherson, et al.       Expires October 12, 2013               [Page 18]

Internet-Draft                                                April 2013


   Logically distinct hosts, such as are provided by many varieties of
   virtualization logic, result in a single physical host, connect to a
   single port on the Ethernet switch in the topology, actually having
   multiple internal virtual machines.  Each virutal machine may have
   it's own IP and MAC addresses.  These ae conected by what is
   essentially (or sometimes literally) an internal LAN switch.  While
   this internal switch may be a SAVI enforcemet point to help control
   threats among the virtual hosts, or between virtual hosts and other
   parts of the network, such enforcement cannot be counted on i ll
   implementations.  If the virtual machines are interconnected by the
   interal switch, than that logical device is the first switch for the
   purposes of this analysis.

   A further complication with multi-instance hosts is that in many
   environments these hosts may move while retaining their IP addresses.
   This can be an actual relocation of the running software, or a backup
   instance taking over the functions of the software.  In both cases,
   the IP address will appear at a new topological location.  Depending
   upon the protocols used, it may have the same MAC address or
   different one, and the system may or may not issue a gratuitous ARP
   request after relocation.  When such a move is done without changing
   the MAC address, the SAVI switches will need to update their state.
   While the ARP may be helpful, traffic detection, switch based
   neighbor solicitation, interaction with orchestration system, or
   other means may be used.

5.2.4.  Multi-LAN Hosts

   Multi-interface hosts, in particular those that are multi-homed and
   may forward packets from any of a number of source addresses, can be
   problematic as well.  In particular, if a port-MAC-IP binding is made
   on each of the interfaces, and then either a loopback IP or the
   address of third interface is used as the source address of a packet
   forwarded through an interface for which the port-MAC-IP binding
   doesn't map, the traffic may be discarded.  Static configuration of
   port-MAC-IP bindings may accommodate this scenario, although some a
   priori knowledge on address assignment and topology is required.

   While the use of loopback addressing or sending packets out one
   interface with the source address from another are rare, they do
   legitimately occur.  Some servers, particularly ones that have
   underlying virtualization, use loopback techniques for management.









McPherson, et al.       Expires October 12, 2013               [Page 19]

Internet-Draft                                                April 2013


5.2.5.  Firewalls

   Firewalls that forward packets from other network segments, or serve
   as a source for locally originated packets, suffer from the same
   issues as routers.

5.2.6.  Mobile IP

   Mobile IP hosts in both IPv4 and IPv6 are proper members of the site
   where they are currently located.  Their care-of-address is a
   properly assigned address that is on the link they are using.  And
   their packets are sent and received using that address.  Thus, they
   do not introduce any additional complications.  (There was at one
   time consideration of allowing mobile hosts to use their home address
   when away from home.  This was not done, precisely to ensure that
   mobile hosts comply with source address validity requirements.)
   Mobile Hosts with multiple physical interfaces fall into the cases
   above.

   Mobile IP home agents are somewhat more interesting.  Although they
   are (typically) fixed devices, they are required to send and receive
   packets addressed from or to any currently properly registered mobile
   node.  From an analysis point of view, even though the packets that a
   Home Agent handles are actually addressed to or from the link the HA
   is on, it is probably best to think of them as routers, with a
   virtual interface to the actual hosts they are serving.  Thus, if the
   Mobile IP home agent is trusted, it can itself perform IP Source
   address checking on the packets it forwards on behalf of mobile
   nodes.  This would utilize bindings established by the Mobile IP
   registration mechanisms.

5.2.7.  Other Topologies

   Any topology that results in the possibility that a device connected
   to a switch port may forward packets with more than a single source
   address for packet which it originated may be problematic.
   Additionally, address allocation schemas introduce additional
   considerations when examining a given SAVI solutions space.

5.3.  IPv6 Considerations

   IPv6 introduces additional capabilities which indirectly complicate
   the spoofing analysis.  IPv6 introduces and recommends the use of
   SLAAC [RFC4862].  This allows hosts to determine their IP prefix,
   select an IID, and then start communicating.  While there are many
   advantages to this, the absence of control interactions complicates
   the process of behavioral enforcement.




McPherson, et al.       Expires October 12, 2013               [Page 20]

Internet-Draft                                                April 2013


   An additional complication is the very large IID space.  Again, this
   64 bit ID space provided by IPv6 has many advantages.  It provides
   the opportunity for many useful behaviors.  However, it also means
   that in the absence of controls, hosts can mint anonymous addresses
   as often as they like, modulo the idiosyncrasies of the duplicate
   address procedure.  Like many behaviors, this is a feature for some
   purposes, and a problem for others.  For example, without claiming
   the entire ID space, an on-link attacker may be able to generate
   enough IP addresses to fill the Neighbor Discovery table space of the
   other L3 devices on the link, including switches which are monitoring
   L3 behavior.  This could seriously interfere with the ability for
   other devices on the link to function.

6.  Analysis of Host Granularity Anti-Spoofing

   Applying anti-spoofing techniques at the host level enables a site to
   achieve several valuable objectives.  While it is likely the case
   that for many site topologies and policies, full source spoofing
   protection is not possible, it is also true that for many sites there
   are steps that can be taken that provide benefit.

   One important class of benefit is masquerade prevention.  Security
   threats involving one machine masquerading as another, for example in
   order to hijack an apparently secure session, can occur within a site
   with significant impact.  Having mechanisms such that host facing
   devices prevent this is a significant intra-site security
   improvement.  Given that security experts report that most security
   breaches are internal, this can be valuable.  One example of this is
   that such techniques should mitigate internal attacks on the site
   routing system.

   A second class of benefit is related to the traceability described
   above.  When a security incident is detected, either within a site,
   or externally (and traced to the site) it can be critical to
   determine what the actual source of the incident was.  If address
   usage can be tied to the kinds of anchors described earlier, this can
   help in responding to security incidents.

   In addition to these local observable benefits, there can be more
   global benefits.  For example, if address usage is tied to anchors,
   it may be possible to prevent or control the use of large numbers of
   anonymous IPv6 addresses for attacks, or at least to track even those
   attacks back to their source.

   As described below in the security considerations, these operational
   behaviors need to be evaluated in the context of the reduction in
   user privacy implied if one logs traffic bindings.  In particular, in
   addition to the architectural trade offs, the network administrator



McPherson, et al.       Expires October 12, 2013               [Page 21]

Internet-Draft                                                April 2013


   must plan for the proper handling of this privacy relevant
   information about his users.

7.  IANA Considerations

   This memo asks the IANA for no new parameters.

   Note to RFC Editor: This section will have served its purpose if it
   correctly tells IANA that no new assignments or registries are
   required, or if those assignments or registries are created during
   the RFC publication process.  From the authors' perspective, it may
   therefore be removed upon publication as an RFC at the RFC Editor's
   discretion.

8.  Security Considerations

   This document provides limited discussion of some security threats
   source address validation improvements will help to mitigate.  It is
   not meant to be all-inclusive, either from a threat analysis
   perspective, or from the source address validation application side.

   It is seductive to think of SAVI solutions as providing the ability
   to use this technology to trace a datagram to the person, or at least
   end system, that originated it.  For several reasons, the technology
   can be used to derive circumstantial evidence, but does not actually
   solve that problem.

   In the Internet Layer, the source address of a datagram should be the
   address of the system that originated it and to which any reply is
   expected to come.  But systems fall into several broad categories.
   Many are single user systems, such as laptops and PDAs.  Multi-user
   systems are commonly used in industry, and a wide variety of
   middleware systems and application servers have no user at all, but
   by design relay messages or perform services on behalf of users of
   other systems (e.g., SMTP and peer-to-peer file sharing).

   Even if every Internet-connected network implements source address
   validation at the ultimate network ingress, and assurances exist that
   intermediate devices are to never modify datagram source addresses,
   source addresses cannot be used as an authentication mechanism.  The
   only technique to unquestionably validate source addresses of a
   received datagram are cryptographic authentication mechanisms such as
   IPsec.

   It must be presume that there will be some failure modes in any SAVI
   deployment, given the history of technical security mechanisms.  A
   possible attack to be considered by network administrators is an
   inside attack probing the network for modes of spoofing that can be



McPherson, et al.       Expires October 12, 2013               [Page 22]

Internet-Draft                                                April 2013


   accomplished.  If the probes are conducted at a level below alarm
   thresholds, this might allow an internal attacker to safely determine
   what spoof modes he can use.  Thus, the use of these techniques must
   be managed in such a way as to avoid giving a false sense of security
   to the network administrator.

8.1.  Privacy Considerations

   It should be understood that enforcing and recording IP address
   bindings has privacy implications.  In some circumstances this
   binding data may be considerd to be personally identifying
   information.  In general, collecting private information about users
   brings ethical and legal responsibilities to the network
   administrator.

   For this reason, the collection and retention of logged binding
   information needs to be considered carefully.  Prevention of spoofing
   does not in itself require suhc retnetion.  Analysis of immediate
   events may rely on having logs of current bindings.  Thus, privacy
   issues can be ameliorated by removing binding logs after the binding
   lifetimes expire.  Logs of apparent spoof attempts are a separate
   matter, and may require longer retention to detect patterns of
   deliberate or accidental abuse.

   With operations of the type described here, the network administrator
   is collecting information about where on his network the user is
   active.  In addition, the recorded bindings supplement address usage
   information about users that is available from DHCP logs.  For
   example, if IPv6 SLAAC is being used, ad IP to Layer 2 address
   bindings are being logged, the administrator will have access to
   information associating users with their IP addresses even if IPv6
   privacy addresses are used.

   In addition to this, care must be taken in attributing actions to
   users on the basis of this sort of information.  Whatever the
   theoretical strength of the tools, administrators should always allow
   for such information being wrong, and should be careful about any
   actions taken on the basis of apparent attribution.  These techniques
   do nothing about address spoofing from other sites, so any evaluation
   of attribution also needs to allow for such cases.

9.  Acknowledgments

   A portion of the primer text in this document came directly from
   [I-D.baker-sava-operational], authored by Fred Baker and Ralph Droms.
   Many thanks to Christian Vogt, Suresh Bhogavilli, and Pekka Savola
   for contributing text and a careful review of this document.




McPherson, et al.       Expires October 12, 2013               [Page 23]

Internet-Draft                                                April 2013


10.  References

10.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

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

10.2.  Informative References

   [I-D.baker-sava-operational]
              Baker, F. and R. Droms, "IPv4/IPv6 Source Address
              Verification", draft-baker-sava-operational-00 (work in
              progress), June 2007.

   [IEEE802.3ad]
              Standards Association, IEEE., "IEEE 801.1AX-2008, IEEE
              Standard for Local and Metropolitan Area Networks - Link
              Aggregation", 2008.

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              converting network protocol addresses to 48.bit Ethernet
              address for transmission on Ethernet hardware", STD 37,
              RFC 826, November 1982.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [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.

   [RFC4953]  Touch, J., "Defending TCP Against Spoofing Attacks", RFC
              4953, July 2007.





McPherson, et al.       Expires October 12, 2013               [Page 24]

Internet-Draft                                                April 2013


Authors' Addresses

   Danny McPherson
   VeriSign, Inc.

   Email: dmcpherson@verisign.com


   Fred Baker
   Cisco Systems

   Email: fred@cisco.com


   Joel M. Halpern
   Ericsson

   Email: joel.halpern@ericsson.com
































McPherson, et al.       Expires October 12, 2013               [Page 25]