Internet DRAFT - draft-dupont-ipv6-ingress-filtering
draft-dupont-ipv6-ingress-filtering
Internet Engineering Task Force Francis Dupont
INTERNET DRAFT ENST Bretagne
Expires in July 2002 Claude Castelluccia
INRIA
January 2002
IPv6 Network Ingress Filtering
<draft-dupont-ipv6-ingress-filtering-00.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
This document is an Internet-Draft. 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.
Distribution of this memo is unlimited.
Abstract
This document describes how network ingress filtering should be
done for the IPv6 protocol, including with mobile IPv6.
Ingress filtering is a standard reply to Distributed Denial of
Service (DDoS) using forged source addresses. A priori ingress
filtering can be done anywhere but is most efficient when it is
done by border routers of the source site. This can be considered
as a form of "responsible use of the network".
Mobile IPv6 amplifies the DDoS threat with the home address option:
this can be used in order to add an indirection level in DDoS attacks
and to foul simple ingress filtering. The proposed reply is a better
ingress filtering. This document explains how to improve basic
anti-spoofing filtering too.
draft-dupont-ipv6-ingress-filtering-00.txt [Page 1]
INTERNET-DRAFT IPv6 ingress filtering Jan 2002
1. Introduction
In a DDoS attack a large number of compromised nodes "As" send a lot
of packets to a target "T" using forged source addresses [1]. The
reply is to verify the validity of source addresses, i.e. to do
network ingress filtering and/or to try to find the real sources
like with itrace [2].
Ingress filtering can be done inside a backbone at aggregation
points, using unicast Reverse Path Forwarding (uRPF) check,
i.e. verifying that the incoming traffic interface and the route to
the source address match. This has some issue with multi-homing,
stressed by IPv6, even if contrary to a common myth uRPF can work
with asymmetrical routing [3].
Another (better) choice is to implement ingress filtering in
Internet connectivity border router, i.e. to put a fire-wall which
filters traffic from inside the site to the Internet. This is not so
uncommon: this kind of filters is heavily used (or should be heavily
used) when Internet access is provided to an unskilled or untrusted
community (cybercafes, student rooms, ...). One can consider this as
a form of "responsible use of the network" enforcement.
Mobile IPv6 [4] introduces a new issue: the home address option
which contains an alternate source address (a mobile node sends
packets with a care-of address as the source address in the IPv6
header and with the home address in the home address option). When the
home address option is processed by the node receiving a packet with
it, the alternate source address replaces the original source address,
i.e. the traffic seems to come from the alternate source address but
but the source address seen by simple ingress filtering devices is
topologically correct.
A node blindly processing home address options can be used as a
reflector, i.e. in a iDDoS attack some nodes "As" send a lot of
packets with their own source addresses and a home address option
with the address of the target "T" to reflectors "Rs". Reflectors
"Rs" send replies to "T". This is a flood of replies, less dangerous
by far enough if the purpose is to overload "T" or its
infrastructure. The advantage of bad guys is the traffic from "Rs"
to "T" does not mention "As": trace back is far more difficult.
draft-dupont-ipv6-ingress-filtering-00.txt [Page 2]
INTERNET-DRAFT IPv6 ingress filtering Jan 2002
The threat is against ingress filtering: simple ingress filtering
devices check only the source address in the IPv6 header, not the
alternate source address in the home address option. So the basic
solution is to verify both addresses are legitimate, i.e. to know
the "binding" between the two addresses.
The remainder of the document will essentially explain how to use
this knowledge. Note the home address option is a degenerate case
of tunneling where inner and outer destination addresses are the
same [5]. The same threat (and the same solution) exists with
tunneling but, by simplicity, this document deals only with in
the current mobile IPv6 context.
2. Correspondent Nodes
The first solution is to use the knowledge of bindings in
correspondent nodes: when a packet is received with a home address
option, it is checked against the binding cache. If it does not
match, it is declared invalid.
This solution is too drastic and leaves only two modes to mobile
IPv6: bidirectional tunnel between the mobile node and its home
agent, or routing optimization, i.e. two way direct communication
between the mobile node and its correspondent, using home address
options and routing headers. The asymmetrical medium possibility is
no more available.
Of course, this cannot work without bindings, i.e. this solution
is not applicable to other uses of home address options than
mobile IPv6.
Our opinion is that binding cache entry check should be used
only as a sanity check.
3. Smart Ingress Filtering
The second solution is to use better ingress filtering in the
access network: fire-walls between the access network know active
bindings and check outgoing traffic against them. If it does not
match the action is the same than with forged source addresses.
The main issue with this solution is how to get the knowledge of
bindings. The proposal is to improve the network access control:
as a node inside the site should not be allowed to use an
unauthorized source address, a mobile node inside the site has to
declare in addition via the network access control system its home
address(es), or filters will not be "opened" for its home address
options.
draft-dupont-ipv6-ingress-filtering-00.txt [Page 3]
INTERNET-DRAFT IPv6 ingress filtering Jan 2002
Mobile IPv6 and AAA drafts [6b, 7] have already this feature: the
local/visited AAA server has the knowledge of care-of and home
address(es), home agent address, ... More, home related informations
are certified by the home/remote AAA server: smart ingress
filtering doesn't rely on AAA infrastructure availability but
an AAA infrastructure shall provide many new/extra features.
This solution has two drawbacks: fire-walls enforcing it are more
complex, for instance they have to manage some state (even if the
state is the network access control system too). This solution
relies in an advanced network access control too, but one may say
that without a good network access control an Internet access
provider is only a danger for everybody, i.e. this is more a "how
to enforce a Best Current Practice" than a technical issue.
4. Other Threats
4.1 Smart Anti-Spoofing Filtering
A common and very useful filtering rule is to forbid traffic from
the outside using an inside address as source. Of course, this has
to be extended to home address options.
The only valid case of an inside address in a home address option
is for a mobile node which belongs to the site, i.e. its home site
is the site. So the knowledge of special binding cases, home
registrations, are enough. In general, one can assume the possible
home addresses and home agent addresses are known, this provides
a basic protection against random home address option or binding
updates.
The needed knowledge of home registrations can be gained from
binding update/binding acknowledge exchanges or better from home
agent collaboration, for instance through the remote network access
control system (the home/remote AAA server of mobile IPv6 and AAA
drafts [6b, 7]), or (second example from a Michael Thomas' proposal)
by reflecting the binding update/binding acknowledge exchange (i.e.
home agents send the contents of the two packets of home
registrations to the border routers of the home domain.
This has the same drawbacks than for the smart ingress filtering
but the home agent function is a more advanced feature than Internet
access, so the required extra control should be easier to enforce
(for instance the part of the site where there may not be a home
agent is easy to protect by simply applying the anti-spoofing rule
to home address options).
draft-dupont-ipv6-ingress-filtering-00.txt [Page 4]
INTERNET-DRAFT IPv6 ingress filtering Jan 2002
4.2 Rogue Routing Headers
Even if nodes should deal with rogue routing headers with a proper
policy, especially hosts (there is consensus about sound policies
but there are not *yet* documented in a (partial) requirements for
IPv6 hosts document), with binding knowledge a fire-wall can easily
detect rogue routing headers.
The filtering rule to apply is exactly the symmetrical rule than
for home address options. Of course, all other things are the same.
This is not crucial but to know when one is under attack is in
general useful so this should be done (belt and braces too).
4.3 Rogue Tunneling
The current mobile IPv6 uses only tunneling between the mobile node
and the home agent. If the inner IPv6 header is not hidden, filtering
rules similar to home address option and routing header rules should
be applied with the constraint that the peer of the mobile node is
the home agent.
If the inner IPv6 header is hidden (by ESP for instance), this
should be authorized according to security policy rules (this can be
an issue because a protected tunnel with the outside may infringe
the Bell-LaPadula write rule [8]). The fact that the tunnel is for
mobile IPv6 if and only if peers are the mobile node and its home
agent should be used, for instance one can deny the use of tunnels
by inside nodes which have not negotiated mobility stuff.
5. Security Considerations
Today the best rely to Distributed Denial of Service attacks is the
network ingress filtering. Ingress filtering can be a bit harder
for IPv6 but mobile IPv6 introduces a new threat because of one of
its basic feature, the home address option.
This document argues as the home address option defeats simple
ingress filtering, the solution is to use better ingress filtering
which can be applied if the network access control provides the
knowledge of bindings to fire-walls between the access network and
the Internet.
draft-dupont-ipv6-ingress-filtering-00.txt [Page 5]
INTERNET-DRAFT IPv6 ingress filtering Jan 2002
6. Acknowledgments
This problem was discussed inside the MobiSecV6 project many years
ago (the MobiSecV6 project joined mobility and security, especially
fire-wall, people). As ingress filtering is not really enforced the
threat was considered as minor (i.e. we knew a good reply) but the
security requirements of mobile IPv6 were recently revisited,
including this issue, and too drastic IMHO solutions proposed [9].
We apologized because our intention was to publish this document
near one year ago. Unfortunately we spent to much time on warm
mailing list discussion and we let fear, uncertainty and doubt
settle when we knew by our concrete experience that secure mobile
IPv6 is possible.
Thanks to (from North to South), Pekka Nikander, Pekka Savola,
Jari Arkko, Stanislav Shaluno, Michael Thomas, ...
7. Normative References
[1] P. Ferguson, D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", RFC 2827 and BCP 38, May 2000.
8. Informative References
[2] S. Bellovin, M. Leech, T. Taylor, "ICMP Traceback Messages",
draft-ietf-itrace-01.txt, October 2001.
[3] Cisco, "Unicast Reverse Path Forwarding (uRPF) Enhancements
for the ISP-ISP Edge", http://www.cisco.com/public/cons/
isp/documents/uRPF_Enhancement.pdf, February 2001.
[4] D. Johnson, C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-15.txt, July 2001.
[5] S. Deering, B. Zill, "Redundant Address Deletion when
Encapsulating IPv6 in IPv6",
draft-deering-ipv6-encap-addr-deletion-00.txt, November 2001.
draft-dupont-ipv6-ingress-filtering-00.txt [Page 6]
INTERNET-DRAFT IPv6 ingress filtering Jan 2002
[6] F. Dupont, M. Laurent-Maknavicius, J. Bournelle,
"AAA for mobile IPv6", draft-dupont-mipv6-aaa-01.txt,
November 2001.
[7] S. Faccin, F. Le, B. Patil, C. Perkins, "Diameter Mobile
IPv6 Application", draft-le-aaa-diameter-mobileipv6-01.txt,
November 2001.
[8] D. Bell, L. LaPadula, "Secure Computer System: Unified
Exposition and Multics Interpretation", MTR-2997 rev. 1,
March 1976.
[9] P. Savola, "Security of IPv6 Routing Header and Home Address
Options", draft-savola-ipv6-rh-ha-security-01.txt,
November 2001.
9. Authors' Addresses
Francis Dupont
ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
BP 78
35512 Cesson-Sevigne Cedex
FRANCE
Fax: +33 2 99 12 70 30
EMail: Francis.Dupont@enst-bretagne.fr
Claude Castelluccia
INRIA Rhone-Alpes
655, avenue de l'Europe
38330 Montbonnot Saint-Martin
FRANCE
Fax: +33 4 76 61 52 52
EMail: claude.castelluccia@inria.fr
draft-dupont-ipv6-ingress-filtering-00.txt [Page 7]
