Network Working Group E. Nordmark
Internet-Draft Sun
Intended status: Standards Track M. Bagnulo
Expires: July 26, 2009 UC3M
January 22, 2009
First-Come First-Serve Source-Address Validation Implementation
draft-ietf-savi-fcfs-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 July 26, 2009.
Copyright Notice
Copyright (c) 2009 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
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
This memo describes FCFS SAVI a mechanism to provide source address
Nordmark & Bagnulo Expires July 26, 2009 [Page 1]
Internet-Draft FCFS SAVI January 2009
validation for IPv4 and IPv6 networks using the First-Come First-
Serve approach. The proposed mechanism is intended to complement
ingress filtering techniques to provide a higher granularity on the
control of the source addresses used.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Design considerations . . . . . . . . . . . . . . . . . . . . 3
2.1. Scope of FCFS SAVI . . . . . . . . . . . . . . . . . . . . 3
2.2. Constraints for FCFS SAVI . . . . . . . . . . . . . . . . 3
2.3. Address ownership proof . . . . . . . . . . . . . . . . . 4
2.4. Special cases . . . . . . . . . . . . . . . . . . . . . . 5
3. FCFS SAVI specification . . . . . . . . . . . . . . . . . . . 5
3.1. FCFS SAVI Data structures . . . . . . . . . . . . . . . . 5
3.2. FCFS SAVI algorithm . . . . . . . . . . . . . . . . . . . 6
3.3. IPv4 Neighbor Unreachability Detection Procedure . . . . . 7
3.3.1. ARP-based Neighbor Unreachability Detection
procedure . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. ICMP-based Neighbor Unreachability Detection
procedure . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
6. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Nordmark & Bagnulo Expires July 26, 2009 [Page 2]
Internet-Draft FCFS SAVI January 2009
1. Introduction
This memo describes FCFS SAVI, a mechanism to provide source address
validation for IPv4 and IPv6 networks using the First-Come First-
Serve approach. The proposed mechanism is intended to complement
ingress filtering techniques to provide a higher granularity on the
control of the source addresses used.
2. Design considerations
2.1. Scope of FCFS SAVI
The application scenario for FCFS SAVI is limited to the local-link.
This means that the goal of FCFS SAVI is verify that the source
address of the packets generated by the hosts attached to the local
link have not been spoofed. FCFS SAVI can be used in IPv4 and in
IPv6 networks.
In any link there usually are hosts and routers attached. Hosts
generate packets with their own address as the source address. This
is the so-called local traffic. while routers send packets containing
a source address other than their own, since they are forwarding
packets generated by other hosts (usually located in a different
link). This what the so-called transit traffic.
The applicability of FCFS SAVI is limited to the local traffic i.e.
to verify if the traffic generated by the hosts attached to the local
link contains a valid source address. The verification of the source
address of the transit traffic is out of the scope of FCFS SAVI.
Other techniques, like ingress filtering [RFC2827], are recommended
to validate transit traffic. In that sense, FCFS SAVI complements
ingress filtering, since it relies on ingress filtering to validate
transit traffic but is provides validation of local traffic, which is
not provided by ingress filtering. Hence, the security level is
increased by using these two techniques.
2.2. Constraints for FCFS SAVI
FCFS SAVI is designed to be susceptible of deployment in existing
networks requiring a minimum set of changes. For that reason, FCFS
SAVI does not require any changes in the hosts which source address
is to be verified. Any verification must solely rely in the usage of
already available protocols. This means that FCFS SAVI cannot define
a new protocol nor to define any new message on existing protocols
nor to require that a host uses an existent protocol message in a
different way. In other words, the requirement is no host changes.
Nordmark & Bagnulo Expires July 26, 2009 [Page 3]
Internet-Draft FCFS SAVI January 2009
FCFS SAVI validation is performed by the FSFC SAVI function. Such
function can be placed in different type of devices, including a
router or a layer-2 bridge. the basic idea is that the FCFS SAVI
function is located in the points of the topology that can enforce
the correct usage of source address by dropping the non-compliant
packets.
2.3. Address ownership proof
The main function performed by FCFS SAVI is to verify that the source
address used in data packets actually belongs to the originator of
the packet. Since FCFS SAVI scope is limited to the local-link, the
originator of the packet is attached to the local-link. In order to
to define any source address validation solution, we need to define
some address ownership proof concept i.e. what it means to be able to
proof that a given host owns a given address in the sense that the
host is entitled to send packet with that source address.
Since no hast changes are acceptable, we need to find the means to
proof address ownership without requiring a new protocol. In FCFS
SAVI the address ownership proof is based in the First-Come first
Serve approach. This means that the first host that sends a packet
with a given source address is the owner of the address until further
notice. More precisely, whenever a source address is used for the
first time, a state is created in the device that is performing the
FCFS SAVI function binding the source address to the layer-2
information that the FCFS SAVI box has available (e.g. the MAC
address in a LAN, or the port in a switched LAN). Following data
packets containing that IP source address must use the same layer-2
information in order to be compliant.
There are however additional consideration to be taken into account.
For instance, consider the case of a host that moves from one segment
of a LAN to another segment of the same subnetwork and it keeps the
same IP address. In this case, the host is still the owner of the IP
address, but the associated layer-2 information has changed. In
order to cope with this case, FCFS SAVI performs an active check to
verify if the host is still reachable using the previous layer-2
information. In order to do that FCFS SAVI uses ARP protocol in IPv4
and ND in IPv6. If the host is no longer reachable at the previously
recorded layer-2 information, FCFS SAVI assumes that the new location
is valid and creates a new binding using the new LAyer-2 information.
In case the host is still reachable using the previously recorded
information, the packets coming from the new layer-2 information are
dropped (see some caveats described in the following section).
Note that this only applies to local traffic. Transit traffic
generated by a router would be verified using alternative techniques,
Nordmark & Bagnulo Expires July 26, 2009 [Page 4]
Internet-Draft FCFS SAVI January 2009
such as ingress filtering. ARP or ND checks would not be fulfilled
by the transit traffic, since the router is not the owner of the
source address contained in the packets.
Layer-2 considerations:TBD
2.4. Special cases
The following special cases that need to be considered
o Hosts with multiple physical interfaces, potentially connected to
different networks.
o Anycast i.e. multiple hosts using the same source address to send
packets.
o Proxy ARP/ND i.e. host sending packets on behalf of other, in a
layer-3 transparent manner.
3. FCFS SAVI specification
3.1. FCFS SAVI Data structures
FCFS SAVI function relies on state information binding the source
address used in data packets to the layer-2 information that
contained the first packet that used that source IP address. Such
information is stored in FCFS SAVI Data Base (DB). The FCFS SAVI DB
will contain a set of entries about the currently used IP source
addresses. So each entry will contain the following information:
o IP source address
o Layer-2 information, such as Layer-2 address, port through which
the packet was received, etc
o Lifetime
In addition to this, FCFS SAVI need to know what are the prefixes
that are directly connected, so it maintains a data structure called
the the FCFS SAVI prefix list, which contains:
o Prefix
o Interface where prefix is directly connected
Finally, FCFS SAVI keep a list of the routers that are directly
connected, since the FCFS SAVI checks will not directly apply to
them. In the FCFS SAVI Router List, the following information is
stored:
o Router IP address (of the directly connected interface)
o Router Layer-2 information such as layer-2 address or port which
the router is connected to
Nordmark & Bagnulo Expires July 26, 2009 [Page 5]
Internet-Draft FCFS SAVI January 2009
3.2. FCFS SAVI algorithm
The FCFS SAVI function is located in a forwarding device, such as a
router or a layer-2 bridge. Upon the reception of a data packet, the
packet will be passed to the FCFS SAVI function which will perform
the processing detailed in this section. The outcome of such
processing can be that the packet is discarded or that is forwarded
as usual.
After a data packet is received, the FCFS SAVI function checks
whether the received data packet is local traffic or transit traffic.
It does so by verifying if the source address of the packet belongs
to one of the directly connected prefixes available in the receiving
interface. It does so by searching the FCFS SAVI Prefix List.
o If the IP source address belongs to one of the local prefixes of
the receiving interface, the data packet is local traffic and the
FCFS SAVI algorithm is executed as described next.
o If the IP source address does not belong to one of the local
prefixes of the receiving interface, this means that the dat
packet is transit traffic. The FCFS SAVI SHOULD verify if the
layer-2 information of the packet corresponds to one of the
routers available in the receiving interface, by using the
information available in the FCFS SAVI router list. If the packet
comes from one of the know routers for that interface, then the
packet is passed so additional checks such as ingress filtering
can be performed. If the packet does not comes from one of the
known routers, then the packet SHOULD be discarded. The FCFS SAVI
function MAY send an ICMP Destination Unreachable Error back to
the source address of the data packet. (In ICMPv4, code 0 (net
unreachable) should be used and in ICMPv6, code 5 (Source address
failed ingress/egress policy) should be used) (Note; we could skip
this verification altogether and simply pass it to the ingress
filters, but it think this could be useful, especially if used
along with SeND)
After checking that the data packet is local traffic, the FCFS SAVI
function will verify the source address used in the packet. In order
to do so, it searches the FCFS SAVI DB using the IP source address as
a key.
o If no entry is found, then a new entry is created, using the
information of the data packet, including all the related layer-2
information of where the packet was received from and the lifetime
of the entry is set to LIFETIME. The packet is forwarded as
usual.
o If an entry is found and the layer-2 information of the received
data packet matches to the information contained in the existing
entry, then the lifetime is set of LIFETIME and the packet is
forwarded as usual.
Nordmark & Bagnulo Expires July 26, 2009 [Page 6]
Internet-Draft FCFS SAVI January 2009
o If an entry is found and the layer-2 information of the received
data packet does not match the information contained in the
existing matching entry, then the FCFS SAVI performs a Neighbor
Unreachability Detection procedure as described in [RFC4861] for
IPv4 and in Section 3.3 for IPv4. It uses the IP source address
and Layer-2 information available in the FCFS SAVI DB entry.
* If the procedure determines that the neighbor is no longer
reachable using the information available in the FCFS SAVI DB
entry, then the entry information is modified to include the
new information about the data packet received (in particular
the new layer-2 information) and lifetime of the entry is
updated to LIFETIME. The packet is forwarded as usual.
* If the procedure determines that the neighbor is still
reachable using the information available in the FCFS SAVI DB,
then the data packet is discarded and the lifetime of the entry
is set to LIFETIME. The FCFS SAVI function MAY send an ICMP
Destination Unreachable Error back to the source address of the
data packet. (In ICMPv4, code 0 (net unreachable) should be
used and in ICMPv6, code 5 (Source address failed ingress/
egress policy) should be used)
3.3. IPv4 Neighbor Unreachability Detection Procedure
As opposed to IPv6, there is no general Neighbor Unreachability
Detection procedure defined for IPv4. Since this is needed in order
to verify if the original node is still using the IP address it once
used, in this section, we define the procedure to perform such
verification. However, unlike IPv6 Neighbor discovery, the IPv4 ARP
protocol [RFC0826] cannot be assumed to be available in all link
layers. So, we will define a ARP based procedure to be used in
layers 2 that the ARP protocol is available and an ICMP based
[RFC0792] procedure for the cases where the ARP protocols is not
available. The ARP based procedure is used whenever it is possible
and when ARP is not available, the ICMP based procedure is used.
3.3.1. ARP-based Neighbor Unreachability Detection procedure
Consider two nodes, S and T, directly connected through a layer 2
where the ARP protocol is available. Node S has with IP address IPS
and layer 2 address MACS and Node T has IP address IPT and layer 2
address MACT.
Node S wants to perform the ARP based Neighbor Unreachability
Detection Procedure for node T. Node S has both IPT and MACT
available. So, node S generates an ARP REQUEST packet, containing
the following information:
Nordmark & Bagnulo Expires July 26, 2009 [Page 7]
Internet-Draft FCFS SAVI January 2009
Ethernet transmission layer:
Ethernet address of destination: MACT
Ethernet address of sender: MACS
Protocol type = ether_type$ADDRESS_RESOLUTION
Ethernet packet data:
(ar$hrd) Hardware address space (e.g., Ethernet, Packet Radio
Net.)
(ar$pro) Protocol address space:0x0800 Internet Protocol
Version 4 (IPv4)
(ar$hln) byte length of each hardware address
(ar$pln) byte length of each protocol address: 4
(ar$op) opcode (ares_op$REQUEST)
(ar$sha) Hardware address of sender of this packet: MACS
(ar$spa) Protocol address of sender of this packet: IPS
(ar$tha) Hardware address of target of this packet: MACT
(ar$tpa) Protocol address of target: IPT
Upon the reception of the ARP REQUEST, if node T follows current ARP
specification [RFC0826], it will reply with an ARP REPLY packet with
the following information:
Ethernet transmission layer:
Ethernet address of destination: MACS
Ethernet address of sender: MACT
Protocol type = ether_type$ADDRESS_RESOLUTION
Ethernet packet data:
(ar$hrd) Hardware address space (e.g., Ethernet, Packet Radio
Net.)
(ar$pro) Protocol address space:0x0800 Internet Protocol
Version 4 (IPv4)
(ar$hln) byte length of each hardware address
(ar$pln) byte length of each protocol address: 4
(ar$op) opcode (ares_op$REPLY)
(ar$sha) Hardware address of sender of this packet: MACT
(ar$spa) Protocol address of sender of this packet: IPT
(ar$tha) Hardware address of target of this packet: MACS
(ar$tpa) Protocol address of target: IPS
If node S receives the ARP REPLY message, the Neighbor Unreachability
procedure was successful and the neighbor T is still reachable with
the available information. If node S does not receives the ARP REPLY
message after ARPTIMEOUT, then the Neighbor Unreachability procedure
has failed and the neighbor T is no longer reachable with the current
information.
3.3.2. ICMP-based Neighbor Unreachability Detection procedure
Consider two nodes, S and T, directly connected through a layer 2.
Node S has with IP address IPS and layer 2 address LLAS and Node T
Nordmark & Bagnulo Expires July 26, 2009 [Page 8]
Internet-Draft FCFS SAVI January 2009
has IP address IPT and layer 2 address LLAT.
Node S wants to perform the ICMP based Neighbor Unreachability
Detection Procedure for node T. Node S has both IPT and LLAT
available. So, node S generates an ICMP ECHO packet [RFC0792] ,
containing the following information:
Link Layer fields:
Source address: LLAS
Destination address: LLAT
IP header fields:
IP Source Address: IPS
IP Destination Address: IPT
ICMP fields
Type: 8
Identifier: set to random number by S
Upon the reception of the ICMP ECHO message, if node T follows
current ICMP specification [RFC0792], it will reply with an ECHO
REPLY packet with the following information:
Link Layer fields:
Source address: LLAT
Destination address: LLAS
IP header fields:
IP Source Address: IPT
IP Destination Address: IPS
ICMP fields
Type: 0
Identifier: copied from the ECHO message received
If node S receives a ECHO REPLY message, it will verify that the
source IP address and the source link layer address match to the
original ones used in the ECHO message. Besides, it will check that
the identifier matches to the one contained in the original ECHO
message. If these checks are successful the Neighbor Unreachability
procedure was successful and the neighbor T is still reachable with
the available information. If node S does not receives the ECHO
REPLY message after ICMPTIMEOUT, then the Neighbor Unreachability
procedure has failed and the neighbor T is no longer reachable with
the current information.
4. Security Considerations
Compare with Threat analysis and identify residual threats: TBD
Nordmark & Bagnulo Expires July 26, 2009 [Page 9]
Internet-Draft FCFS SAVI January 2009
5. Acknowledgments
Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework
Program.
6. Normative References
[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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[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.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
Authors' Addresses
Erik Nordmark
Sun Microsystems, Inc.
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1 650 786 2921
Email: Erik.Nordmark@Sun.COM
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6248814
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Nordmark & Bagnulo Expires July 26, 2009 [Page 10]
