[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Source Address Validation                                       F. Baker
Architecture                                                    R. Droms
Internet-Draft                                             Cisco Systems
Intended status: Best Current                              June 18, 2007
Practice
Expires: December 20, 2007


                 IPv4/IPv6 Source Address Verification
                    draft-baker-sava-operational-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 20, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This note proposes a practical solution to Internet Layer Source
   Address Verification.  The purpose of such verification is to prevent
   attacks from using spoofed addresses and to facilitate the tracking
   of attack datagrams to the computers that send them.





Baker & Droms           Expires December 20, 2007               [Page 1]


Internet-Draft         Source Address Verification             June 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  On attacks and attack management . . . . . . . . . . . . .  3
     1.2.  On Trust . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Eliminating spoofed addresses in the Internet  . . . . . . . .  5
     2.1.  Host to link layer neighbor or switch  . . . . . . . . . .  7
     2.2.  Upstream routers . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  ISP edge PE Router . . . . . . . . . . . . . . . . . . . .  8
     2.4.  ISP NNI Router to ISP NNI Router . . . . . . . . . . . . .  8
   3.  Verification and Accountability  . . . . . . . . . . . . . . .  8
   4.  Encouraging customer use of antispoofing procedures  . . . . .  9
   5.  Accommodating incremental deployment . . . . . . . . . . . . .  9
     5.1.  ISP PE Router to CPE delivery point  . . . . . . . . . . . 10
     5.2.  ISP filtering under attack . . . . . . . . . . . . . . . . 10
   6.  Identified Addresses in the Internet . . . . . . . . . . . . . 10
     6.1.  Identified addresses in edge networks  . . . . . . . . . . 11
       6.1.1.  IEEE802.1X . . . . . . . . . . . . . . . . . . . . . . 11
       6.1.2.  IPv4 Address Resolution Protocol . . . . . . . . . . . 12
       6.1.3.  IPv6 Neighbor Discovery  . . . . . . . . . . . . . . . 12
       6.1.4.  IPv4 and IPv6 Dynamic Host Configuration Protocol  . . 13
       6.1.5.  Protocol for Carrying Authentication for Network
               Access . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  Identified addresses in a global domain  . . . . . . . . . 13
     6.3.  On source addresses  . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

















Baker & Droms           Expires December 20, 2007               [Page 2]


Internet-Draft         Source Address Verification             June 2007


1.  Introduction

   This note proposes a practical solution to Internet Layer (which is
   to say IPv4 [RFC0791] and IPv6 [RFC2460]) source address
   verification.  The purpose of such verification is to prevent attacks
   from using spoofed addresses and to facilitate the tracking of attack
   datagrams to the computers that send them.  The source address
   verification problem is proposed and motivated in other papers on
   this topic [I-D.sava-problem-statement].

   There are three contributions in this document.  The first is a
   compilation of mechanisms available for source address verification
   at various points in the Internet, and an informal analysis of the
   confidence in the verification for each of those mechanisms.  The
   second is the notion that source address verification can be
   negotiated between Internet entities based on this confidence in the
   source address verification mechanisms, and how source address
   verification can be used to accomplish goals such as attack avoidance
   and accountability for attacks.  The third contribution is a way to
   incorporate source address verification into the Internet without
   requiring ubiquitous adoption of source address verification
   mechanisms.

1.1.  On attacks and attack management

   The fundamental purpose of source address verification is the
   management of attacks.  Attacks come in many forms, from malicious
   activities such as denial of service or service disruption, to more
   subtle forms of theft, to limiting the provision of service to one's
   customers or clients.  Source address verification can be used in two
   ways to manage attacks: to detect and reject IP datagrams with
   incorrect ('spoofed') source addresses, which cannot guide a response
   to a datagram to the system that sent it; and, to establish
   accountability for attacks using IP datagrams with valid source
   addresses.

   The principal mode of attack in which a datagram with a spoofed
   source address is used is a single datagram attack; it is possible to
   spoof an address for the first exchange or a random exchange in a TCP
   session (as is done in TCP SYN and RST attacks), but given that
   nothing is known of how a peer replies to a datagram that was sent
   from a spoofed address, the further into such a session one goes the
   more difficult it is to maintain the illusion of coherence.
   Therefore, the first requirement is that the first datagram in a
   session have its address validated, and datagrams that fail this
   verification are ignored or dropped.

   IT administrations want to be able to track a datagram to its source.



Baker & Droms           Expires December 20, 2007               [Page 3]


Internet-Draft         Source Address Verification             June 2007


   Reasons include isolating the zombie sources of an attack, or
   tracking malicious behavior to the user of a system.  Removing IP
   datagrams with spoofed source addresses ensures that the remaining
   datagrams can be reliably traced back to their source.

   This note will not go on to generalized attack management.  Other
   papers, notably [I-D.ietf-idr-bgp-prefix-orf], and [RFC4778] address
   this; the matter will be left with them.

1.2.  On Trust

   Trust, in the Internet, is very much about relationships.  Two
   companies or two parties that do not know each other may provide
   minimal services, such as access to a web page, but do not rely on
   each other.  However, if a satisfactory relationship can be
   established, limited levels of trust are extended.  For example, an
   ISP that contracts with its customer or another ISP to exchange BGP
   routing will open the session and advertise and accept routes.  The
   ISP will also limit the routes it accepts (and therefore the trust it
   extends) to those specified in the agreement.  Similarly, the group
   that administers an enterprise network is often different from the
   group that manages the company's end systems.  The level of trust
   between an enterprise network and the end systems it services is
   often similarly limited; the end systems are viewed as liabilities as
   much as they are clients.

   This document is about the management of trust, and the level of
   trust that can be extended to a system that originates IP datagrams
   at the network layer.  This trust differs from session trust, in
   which a user logs in to a remote system or service, but the two can
   be used together to accomplish useful things.  Section 2.4 describes
   a method through which parties in the Internet such as service
   providers can negotiate the level of trust they are willing to assume
   in their exchange of Internet traffic.  This method provides a
   practical way in which source address verification can be deployed
   and used in the Internet.

1.3.  Glossary

   The following acronyms are used in this document:

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

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




Baker & Droms           Expires December 20, 2007               [Page 4]


Internet-Draft         Source Address Verification             June 2007


   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.

   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 Endpoint Router.  This router faces a customer
      of an ISP.

   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.


2.  Eliminating spoofed addresses in the Internet

   The first requirement is to eliminate datagrams with spoofed
   addresses from the Internet.  Identifying and dropping datagrams
   whose source address is incompatible with the Internet topology at
   sites where the relationship between the source address and topology
   can be checked can eliminate such datagrams.  For example, 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 appropriate for the device at the layer 2
      switch port (the address was assigned to a, and perhaps the,
      system that uses that port)

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

   Filtering points farther away from the source of the datagram can



Baker & Droms           Expires December 20, 2007               [Page 5]


Internet-Draft         Source Address Verification             June 2007


   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: Figure 1: Points where an address can be validated

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

   o  Host to host or host to switch,

   o  Host to enterprise CPE Router,

   o  Enterprise CPE Router to ISP edge PE Router,

   o  ISP NNI Router to ISP NNI Router, and the

   o  ISP edge PE Router facing the destination CPE Router.

   In general, datagrams with spoofed 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 layer 2 and IP addresses on a link can
   discard any datagrams in which the IP address is not associated with
   (and is therefore assumed to be spoofed) the layer 2 address in the
   datagram.  The degree of confidence in the source address depends on



Baker & Droms           Expires December 20, 2007               [Page 6]


Internet-Draft         Source Address Verification             June 2007


   where the spoofing detection is performed and the prefix aggregation
   in place between the spoofing detection and the source of the
   datagram.  The means of building such an authoritative mapping is
   discussed further in Section 6.1.

2.1.  Host to link layer neighbor or 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 layer 2 and IP
   addresses are both available, and can be verified against each other.
   A datagram in which the IP source address does not match the
   corresponding lower 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
   neighboring hosts, or by the first hop router.

   On a shared medium link, the best that can be done is to verify the
   layer 2 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 MAC address if it is known to
   the switch.  Port identification precludes transmission of malicious
   datagrams whose layer 2 and IP addresses are both spoofed to mimic
   another host.

2.2.  Upstream routers

   After the first hop router, which can use the mechanism described in
   Section 2.1 to filter datagrams, subsequent routers may additionally
   filter traffic from downstream networks.  Because these routers do
   not have access to the layer 2 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.  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.  These filtering procedures are discussed in
   more detail in [RFC3704].







Baker & Droms           Expires December 20, 2007               [Page 7]


Internet-Draft         Source Address Verification             June 2007


2.3.  ISP edge PE Router

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

   The question that the ISP must answer for itself is the degree to
   which it trusts its downstream network.  Appropriate answers include
   'not at all' and 'enough to only need to verify compliance'.  A
   contract might be written between an ISP and its customer requiring
   that the customer apply the procedures of Section 2.1 the customer's
   own network.  ISPs might, for example, mark datagrams from customers
   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 and use that
   to advertise the level of trust to its BGP peers.

2.4.  ISP NNI Router to ISP NNI Router

   The considerations of Section 2.3, which are explicitly related to
   customer networks, can also be applied to neighboring ISPs.  A
   contract might be written between the companies that the companies
   will require the procedures of Section 2.1 of their customers and
   apply them within their own network.  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 and use that to advertise the level of trust to its BGP
   peers.

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


3.  Verification and Accountability

   Assuming filtering as above has been implemented, the origin of
   malicious IP datagrams can be determined.  Within an organization or
   administrative domain, the details of where and how filtering is
   applied provide accountability and can be used to trace the origin of
   malicious datagrams back to the ultimate source or some region of the
   network.  Between organizations or administrative domains, the
   agreement in place between organizations allows an entity that
   detects malicious traffic to assign responsibility for the origin of
   that traffic.




Baker & Droms           Expires December 20, 2007               [Page 8]


Internet-Draft         Source Address Verification             June 2007


   The use of formal agreements between organizations is discussed in
   more detail in Section 4


4.  Encouraging customer use of antispoofing procedures

   As discussed in Section 1.2, the only operational circumstance in
   which an ISP can be said to trust its downstream is if it has an
   understanding (usually formalized in a contract) with the downstream
   regarding a matter.  For example, an ISP that opens a BGP session
   with a downstream trusts the routes that the downstream presents it.
   The ISP may limit this trust, however, by verifying that the prefixes
   advertised by the downstream are appropriate for it to advertise.
   One might characterize this kind of relationship as 'trust but
   verify'.

   In the case of anti-spoofing procedures, an ISP might include in its
   service contract a provision that the customer agrees to use the
   procedures in Section 2.1, and where appropriate Section 2.2, to
   eliminate address spoofing.  In this example of a contractual
   arrangement, the type of source address verification is specified in
   the service contract, and the customer implements those source
   address verification mechanisms.  The ISP then verifies compliance
   using uRPF or other audits, and applies a penalty when the procedure
   results in the ISP dropping traffic.  The penalty could be monetary,
   operational, or both.

   Peer ISPs can develop a somewhat different form of service contract,
   in which each ISP guarantees that it will identify traffic or the
   source prefixes of customers have not implemented source address
   verification, and that the ISPs have implemented the appropriate
   checks to confirm that verification.


5.  Accommodating incremental deployment

   In the Internet, new technologies are inevitably deployed
   incrementally.  Source address verification is no exception.  This
   incremental deployment is problematic in the case of source address
   verification, in that aggregated traffic flows include both verified
   and unverified traffic.  But simply dropping unverified traffic is
   unacceptable, as it prevents any form of incremental deployment.
   What is needed is a way to aggregate and deliver verified and
   unverified traffic, while retaining the ability to differentiate
   between those two types of traffic.






Baker & Droms           Expires December 20, 2007               [Page 9]


Internet-Draft         Source Address Verification             June 2007


5.1.  ISP PE Router to CPE delivery point

   A simple operational differentiation that can be applied to traffic
   from untrusted downstream networks (those who have not signed a
   contract such as described in Section 4, or who are demonstrably not
   in compliance with it) is to mark traffic from them as 'untrusted'.
   A simple approach would use a DSCP value [RFC2474] indicating that
   the datagram is from an untrusted source and therefore potentially
   contains a spoofed source address.

   The ultimate use of the 'Untrusted' DSCP value is at choke points in
   the infrastructure, usually at network egress.  Denial of Service
   attacks using spoofed addresses often target choke points.  By
   classifying untrusted traffic and running it through a queue of lower
   priority or rate, one can preserve the services of trusted senders,
   and squeeze out potentially-spoofed traffic.

   Thus, the use of the 'Untrusted' DSCP value both denies the untrusted
   user the enjoyment of network services end to end and permits
   prejudicial classification to give them distinctly poor service when
   they are potentially part of an attack.  This, along with monetary
   incentives, incents them both to become trusted and trustworthy
   communication partners.

5.2.  ISP filtering under attack

   Another approach, if the prefixes of untrusted sources are advertised
   between ISPs using an appropriate BGP community, would be for a
   network under attack (or whose customers are under attack) to
   temporarily block untrusted prefixes and then add them back
   piecemeal.  If the attack is sourced from an untrusted prefix,
   dropping the traffic will protect against the attack, and upon
   restoration of the prefix the attack should again be observable.
   This obviously only works as described with continuous attacks, but
   it can be helpful in isolating punctuated attacks as well.


6.  Identified Addresses in the Internet

   The document Internet Architectural Guidelines [RFC3439] focuses on a
   number of principles that have been used to beneficial effect in the
   design of the Internet.  An important one is the Simplicity
   Principle, which asserts that complexity is the primary factor that
   limits the ability of a system to scale to large populations.
   Another is the Coupling Principle, which is borrowed from Information
   Theory and asserts that as systems get larger, they often exhibit
   increased interdependence (coupling) between components.




Baker & Droms           Expires December 20, 2007              [Page 10]


Internet-Draft         Source Address Verification             June 2007


   The design principle that has fostered the economic vitality of the
   Internet is the localization of information on a 'need to know'
   basis, with a view to limiting unnecessary complexity and
   interaction.  In this context, making the Internet scale to large
   numbers of users calls on us to limit knowledge of individual users
   to the organizations they are part of, and to limit knowledge of
   individual systems to the networks in which they reside.  In other
   networks within the Internet system, we scale the Internet by
   carrying knowledge of the networks, or of important characteristics
   of relationships such as whether a user or system is trusted or not.

   As such, we divide the problem of address identification into two
   parts: identification of a user within the network that provides him
   service, whether that is an enterprise network, residential ISP, or
   other network, and the identification of other networks.

6.1.  Identified addresses in edge networks

   A common IT requirement is for an enterprise or residential ISP to
   restrict service to its authorized users or customers.  Numerous
   procedures have been used for this, such as DHCP Authentication and
   the definition of names in carried in DHCP requests.  While any
   adequate user management system could be used by the enterprise, at
   this point the state of the art appears to be the use of IEEE 802.1X
   access control, which associates a user with a MAC address and can be
   used with IPv4 or IPv6.

6.1.1.  IEEE802.1X

   IEEE 802.1X [IEEE802.1X] is an IEEE standard for port-based Network
   Access Control; it is part of the IEEE 802 (802.1) group of
   protocols.  It provides authentication to devices attached to a LAN
   port or wireless access point, establishing a point-to-point
   connection or preventing access from that port if authentication
   fails.

   802.1X is available on network switches, and can be configured to
   authenticate hosts that are equipped with supplicant software,
   denying unauthorized access to the network at the data link layer.

   On wireless access points, 802.1X can be used in certain situations
   where an access point needs to be operated as a closed access point.
   The authentication is usually done by a third-party entity, such as a
   RADIUS server.  This provides for client-only authentication, or more
   appropriately, strong mutual authentication using protocols such as
   EAP-TLS [RFC3748].

   Upon detection of the new client (supplicant), the port on the switch



Baker & Droms           Expires December 20, 2007              [Page 11]


Internet-Draft         Source Address Verification             June 2007


   (authenticator) will be enabled and set to the 'unauthorized' state.
   In this state, only 802.1X traffic will be allowed; other traffic,
   such as DHCP and HTTP, will be blocked at the data link layer.  The
   authenticator sends the EAP-Request identity to the supplicant, to
   which the supplicant replies using the EAP-Response datagram that the
   authenticator will forward to the authenticating server.  The
   authenticating server can accept or reject the EAP-Request; if it
   accepts the request, the authenticator will set the port to the
   'authorized' state and normal traffic will be allowed.  The
   supplicant logs off by sending an EAP-Logoff message to the
   authenticator.  The authenticator will then set the port to the
   'unauthorized' state, once again blocking all non-EAP traffic.

   The effect of such mutual authentication is two-fold.  First, the
   network (wired or wireless) can determine whether a person that is
   seeking attachment of his system is authorized to do so.  Also, the
   person's computer can determine whether the point of attachment is a
   rogue access point or is in fact the network it intends to enter.  As
   a side-effect of such authentication and authorization, server logs
   can be scanned at any time to determine what user was associated with
   any given system or MAC address and what IP (version 4 or 6)
   addresses are in use by those same MAC addresses, or such information
   can be logged in a search database for forensic purposes.

6.1.2.  IPv4 Address Resolution Protocol

   ARP [RFC0826] carries mappings between layer 2 and IP addresses,
   which can be used by nodes to construct a table of associations
   between layer 2 and IP addresses for other nodes on the same link.  A
   switch can intercept and examine ARP traffic as well to determine the
   layer 2 and IP addresses of nodes attached to its ports.

   However, as ARP is not secured in any way, the associations learned
   through ARP are not highly trustable.  It is easy to construct ARP
   messages that can alter the ARP tables in nodes so the source
   addresses in a datagram appear to be valid.

6.1.3.  IPv6 Neighbor Discovery

   The Neighbor Discovery protocol [RFC2461] (ND), which is part of the
   IPv6 protocol suite, provides address resolution functions and
   supports address assignment.  In much the same way as ARP can be used
   to learn associations between layer 2 and IPv4 addresses, the
   contents of ND messages can be used to learn associations between
   layer 2 and IPv6 addresses.

   SEcure Neighbor Discovery [RFC3971] (SEND) can be used to
   authenticate the associations between layer 2 and IPv6 addresses.



Baker & Droms           Expires December 20, 2007              [Page 12]


Internet-Draft         Source Address Verification             June 2007


6.1.4.  IPv4 and IPv6 Dynamic Host Configuration Protocol

   DHCP [RFC2131][RFC3315] can also be used to learn associations
   between layer 2 and IPv4 or IPv6 addresses.  In this method, network
   elements that actively transmit DHCP messages ('DHCP relay agents';
   typically a router) or forward DHCP messages (switches) between a
   DHCP server and hosts examine the contents of the DHCP messages and
   extract the associations between the layer 2 and IPv4 or IPv6 for
   hosts.  The layer 2 and IP addresses are contained in or can be
   deduced from the forwarded DHCP messages.  In many situations, the
   network path between the router/switch and the DHCP server is secure,
   so the information extracted from the DHCP messages is considered
   more reliable than information taken from ARP or ND.

6.1.5.  Protocol for Carrying Authentication for Network Access

   PANA [I-D.ietf-pana-pana] is related to IEEE802.1X, in that it
   authenticates the identity of a user and uses that authenticated
   identity to authenticate the association between a layer 2 address
   and an IP address.  PANA differs from IEEE802.1X in that it is
   carried as a layer 4 protocol, and can be used across intermediate
   network elements to an authenticating device.  As a side effect of
   PANA authentication, the authenticating device can derive a layer 2
   to IP address association for later use in detecting spoofed traffic.

6.2.  Identified addresses in a global domain

   In accordance with the design principles of the Internet, users in
   one network are generally not visible to other network
   administrations.  Rather, the administration of one network will
   refer questions of identity to the administration serving a user or
   system.

   That said, once source address spoofing has been eliminated, the
   source address of a datagram can be used to identify the domain from
   which it originated, and as a result what network administration must
   be contacted if it appears to be misbehaving.  This is the proper use
   of WHOIS service; IANA and the relevant RIR, or in some cases the NIR
   or LIR or local ISP, can identify the administration a prefix has
   been assigned to and provide contact information.

6.3.  On source addresses

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




Baker & Droms           Expires December 20, 2007              [Page 13]


Internet-Draft         Source Address Verification             June 2007


   In the network layer, the source address of a datagram is 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.

   Two simple examples middleware relays are SMTP (Electronic Mail) and
   peer-to-peer file sharing.  In SMTP, an email sent by a user is
   generally presented to a succession of intermediaries, which are
   called Mail Transfer Agents or MTAs.  While the email was originated
   by a person, the network address used on each successive MTA-MTA
   transfer is that of the MTA.  BitTorrent File Sharing may determine
   that a number of requests for a given file are coming from a given
   topological region in the network and push the file to a system it
   happens to know is located near there - without the knowledge of the
   originator of the file, the user whose system it was pushed from, the
   user whose system it was pushed to, or any potential future requester
   of the file.  In both cases, the network layer address has no
   relationship to the application layer user, and in the latter case
   the presence of the file on a given system does not imply that the
   user of the system knows it is there or has any intent to use it.

   Any association of an Internet address with a user is at best
   circumstantial; it may identify a set of obvious suspects, but it
   does not identify the user, and in many applications does not limit
   the set of suspects to the obvious ones.  Examples of personal
   identifications in Internet messages may be found in DKIM
   [I-D.ietf-dkim-base], SMIME [RFC1847], and Open PGP [RFC2440], among
   others.


7.  IANA Considerations

   This memo adds no new IANA considerations.  That said, one could
   imagine a future specification requesting a common DSCP identifying
   datagrams from untrusted sources based on an appropriate description
   of the relevant PHB.

   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 author's perspective, it may
   therefore be removed upon publication as an RFC at the RFC Editor's
   discretion.




Baker & Droms           Expires December 20, 2007              [Page 14]


Internet-Draft         Source Address Verification             June 2007


8.  Security Considerations

   The security issues this document imposes are not worse than existing
   security behavior.  The use of ARP, and DHCP are not currently
   secured, which may be an open attack vector.  Neighbor Discovery is
   similarly unsecured, but Secure Neighbor Discovery is usable in the
   context.  The mechanics of securing address assignment and
   announcement is considered a separate issue from the subject matter
   of this paper, but is material to its usefulness.

   The security considerations of RFCs 2474 and 2475 apply, as this uses
   the Differentiated Services Architecture.

   In any discussion of identity, an important issue is the chain of
   trust and the anchor of that chain.  In this context, the chain of
   trust is Internet routing, and the anchor of that chain is the system
   that verifies the source address used by its downstream peer.  As
   such, the first step - the verification of the source address by the
   immediate neighbor of an end system - is of paramount importance, and
   any check after that point is of lower efficacy.  That said, the
   first system that can be said to be trusted by any administrative
   entity is the ingress system under its control.  As such, each
   enterprise and ISP en route is responsible for its own security and
   must implement a verification procedure to ensure its own compliance.


9.  Acknowledgements

   The discussion of contracts and DSCP markings was first proposed by
   Steve Crocker in [Crocker].

   The discussion of BGP Communities derives from discussions with Barry
   Greene.

   The description of IEEE 802.1X was adapted from the Wikipedia article
   on the topic.  Paul Gleichauf added comments on trust and trust
   management.  Pekka Savola performed a detailed review.


10.  References

10.1.  Normative References

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:



Baker & Droms           Expires December 20, 2007              [Page 15]


Internet-Draft         Source Address Verification             June 2007


              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

10.2.  Informative References

   [Crocker]  Crocker, S., "Protecting the Internet from distributed
              denial-of-service attacks: a proposal", Proceedings of the
              IEEE Volume 92, Pages 1375-1381, September 2004.

   [I-D.ietf-dkim-base]
              Allman, E., "DomainKeys Identified Mail (DKIM)
              Signatures", draft-ietf-dkim-base-10 (work in progress),
              February 2007.

   [I-D.ietf-idr-bgp-prefix-orf]
              Chen, E. and S. Sangli, "Address Prefix Based Outbound
              Route Filter for BGP-4", draft-ietf-idr-bgp-prefix-orf-04
              (work in progress), July 2006.

   [I-D.ietf-pana-pana]
              Forsberg, D., "Protocol for Carrying Authentication for
              Network Access (PANA)", draft-ietf-pana-pana-15 (work in
              progress), May 2007.

   [I-D.sava-problem-statement]
              Wu, J., "Source Address Verification Architecture Problem
              Statement", draft-sava-problem-statement-00 (work in
              progress), February 2007.

   [IEEE802.1X]
              Institute of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Port-Based Network Access
              Control", IEEE Standard 802.1X, September 2004.

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

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

   [RFC1847]  Galvin, J., Murphy, S., Crocker, S., and N. Freed,
              "Security Multiparts for MIME: Multipart/Signed and
              Multipart/Encrypted", RFC 1847, October 1995.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.



Baker & Droms           Expires December 20, 2007              [Page 16]


Internet-Draft         Source Address Verification             June 2007


   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
              "OpenPGP Message Format", RFC 2440, November 1998.

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

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              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.

   [RFC3439]  Bush, R. and D. Meyer, "Some Internet Architectural
              Guidelines and Philosophy", RFC 3439, December 2002.

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

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4778]  Kaeo, M., "Operational Security Current Practices in
              Internet Service Provider Environments", RFC 4778,
              January 2007.


Authors' Addresses

   Fred Baker
   Cisco Systems

   Email: fred@cisco.com


   Ralph Droms
   Cisco Systems

   Email: rdroms@cisco.com






Baker & Droms           Expires December 20, 2007              [Page 17]


Internet-Draft         Source Address Verification             June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Baker & Droms           Expires December 20, 2007              [Page 18]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/