One document matched: draft-oneill-mipv6-cao-00.txt
Personal A. O'Neill
Internet Draft Flarion Technologies
Document: draft-oneill-mipv6-cao-00.txt 19 Sept 2002
Expires: Mar 2003
MIPv6 Care of Address Option
<draft-oneill-mipv6-cao-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
IPv6 and MIPv6 has constrained the HoA to being used within forward
and reverse tunnels via the HA. In the unicast case, the MN can then activate
Route Optimisation to bypass the HA in both directions by securely installing
a Binding Cache Entry into the CN. The MN then sends from the CCoA source
address to the CN directly into the foreign multicast system, and includes
the Home Address Option (HAO) so that the changing CCoA is masked from the
transport layer.
This draft defines the Care of Address Option, which carries the current CCoA
of the MN. The CAO can be included in a Hop By Hop Header or Destination
header and used instead of the packet source address for unicast ingress
filtering and multicast RPF purposes. This enables a MN to potentially use
the HoA as a source address on the foreign network, and to inform the CNs of
the evolving MN location.
A.W. O'Neill Expires Mar 2003 [Page 1]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
INDEX
Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . . . . 3
3. Terminology used in this document . . . . . . . . . . . . . . . . . 3
4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. The Ingress Filtering problem . . . . . . . . . . . . . . . . 4
4.2. The Mobile Source Tracking problem . . . . . . . . . . . . . . 5
5. High-Level processing Rules for the CAO . . . . . . . . . . . . . . 5
5.1. Option Enforcement Points and Ingress Filtering. . . . . . . . 5
5.2. Existing MIPv6 Processing Rules for the HoA Source Address . . 7
5.3. Modified Processing Rules for the Foreign Network. . . . . . . 9
5.4. MN Location Exchange . . . . . . . . . . . . . . . . . . . . . 9
5.5. CAO Specific Processing Rules at the CN. . . . . . . . . . . . 11
6. Format and Usage Rules for the Care of Address Option . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 15
8. Notice Regarding Intellectual Property Rights . . . . . . . . . . . 16
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Mobile IP for IPv4 enables the MN to use its HoA as a source address on the
foreign subnet when forwarding to the CN either directly or via the HA using
reverse tunnelling. The native forwarding follows the optimal route to the CN
but incurs the risk of being discarded by ingress filtering routers due to
the topologically incorrect source address. IPv6 and MIPv6 have therefore
constrained the HoA to being used as a source address when either at home or
within a reverse tunnel from a foreign subnet via the HA of the MN. The CN
then returns packets to the MN HoA, via the HA, and the forward HA to MN
tunnel based on the CCoA in the HA binding for the MN. In the unicast case,
the MN can then activate Route Optimisation to bypass the HA in both
directions by securely installing a Binding Cache Entry into the CN. The MN
then sends from the CCoA source address to the CN directly via the foreign
unicast or multicast system, and includes the Home Address Option (HAO) in
the unicast packets so that the changing CCoA is masked from the transport
layer. The CN sends directly to the MN using a routing header. In the
multicast case, the persistent HoA cannot be used as a multicast source
address because such packets will fail the multicast reverse path forwarding
check. The MN must instead use its CCoA on the foreign network as its source
address, and a new multicast tree must be built for each new CCoA on each MN
hand-off to ensure that the multicast source address is topologically
correct. These multicast issues are discussed in detail in [MIP-Multicast].
A.W. O'Neill Expires Mar 2003 [Page 2]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
This draft defines the Care of Address Option, which carries the current
location of the MN in the form of the CCoA or the HoA, within either a Hop By
Hop or a Destination Header. The Hop By Hop or Destination header based CAO
can be used to both redirect ingress filtering / multicast RPF checks so that
the MN can use its HoA as a source address from the foreign network directly
with the CN. The Destination Header based CAO can in addition be used to
inform the CN of the location of the MN when either reverse tunnelling to the
HA or on the home network, and hence when ingress filtering checks would
already succeed. They also inform the CN of the current location of the MN.
This information is stored by the CN in an Inverse Binding Cache Entry, which
may be used by high-layer mobility aware processes, and may also be used to
improve Route Optimisation procedures.
The CN can reflect a CAO back to the MN in a Destination header either
directly or via the HA using a routing header, to close the verification loop
so that the MN can be reasonably confident that the CN knows the desired
binding between the MN HoA and the MN CCoA.
The CAO, whilst primarily designed for unicast communications, may also be
used to enable the HoA to be used as a multicast source address on a foreign
subnet to pass multicast RPF checks, and address the efficiency limitations
of MIPv6 multicast. The multicast details of this are not covered in this
draft but are described at a high-level in [MIP-multicast].
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in RFC-2119 [RFC2119].
3. Terminology used in this document
Much of the terminology used in this document borrows from Mobile IPv4
[MIPv4] and [MIPv6] specifications and drafts. This draft introduces and uses
the following additional terminology.
Care of Address Option (CAO) - an option included in an IPv6 Hop by Hop or
Destination Header that is used to redirect source address checks to the CCoA
rather than the source address (HoA) of the packet and to indicate to the CN
the present location of the MN. The CAO may also be reflected back to the MN
in a Destination Header to verify the contents of the triggering CAO that was
received at the CN.
Inverse Binding Cache Entry - an optional entry in a table at the CN that has
the mapping between the MN HoA and its evolving location as well as details
of how and when the CAO was received, and if, how and when the CAO was
verified. As a result, any IBCE explicitly includes a measure of confidence
in the entry for each MN and implied or explicitly stated constraints on its
use by the CN.
A.W. O'Neill Expires Mar 2003 [Page 3]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
Option Enforcement Point (OEP) - a node that inspects options within
extension headers when the header type would not otherwise have caused
this node to process the options, such as with a firewall. A node that is
defined by the header type as able to process the option is a Defined node.
4. Motivation
4.1. The Ingress Filtering Problem
MIPv4 MNs can use the HoA as a source address for unicast packets from the
foreign subnet without using a reverse tunnel to the HA. In the case of a FA,
the MIP binding information between the HoA and the CoA is known and trusted,
and therefore the Access Router containing the FA can enable the
topologically incorrect source address to be forwarded safely. However, this
still risks the packet being discarded by ingress filtering in internal nodes
that are not aware of the secure MIP binding information between the HoA and
the CoA.
In MIPv6, the use of the HoA as a unicast source address when sending direct
to the CN is prevented and the MN must instead only use the HoA when reverse
tunnelling packets to the CN via the HA. Route Optimisation can then be used
to securely install a Binding Cache Entry (BCE) in the CN so that the CN and
MN can then directly communicate using the CCoA of the MN as a network
address. The Home Address Destination Option and the Type 2 Routing Header is
then used to enable the network layer to forward packets whilst maintaining
the HoA as the transport layer view of the MN address. Unfortunately, Route
Optimisation has significant security issues and places a significant burden
on the MN during hand-off. For this reason it is likely to be inappropriate
in many circumstances and a lightweight method of optimising one leg of the
path might therefore be useful.
One potential mechanism is to use the MN HoA as a source address on a foreign
network, but add the CCoA of the MN into the CAO within a Hop By Hop Header,
to affect all routers that wish to undertake ingress filtering. All such
routers must first check for the existence of the CAO. Its presence
informs the router that the ingress filtering should be performed on the
address in the CAO option rather than on the packet source address. In
addition, the MN must only issue such packets from the network on which the
CCoA is valid. All IPv6 Access Routers MUST implement ingress filtering on
the source address but MAY, along with any other IPv6 router, be enhanced to
support redirected ingress filtering checks on the CAO in the Hop By Hop
header. Routers implementing CAO based ingress filtering MUST check the
validity of the address in the CAO within the Hop By Hop Header and
discard any packet with an incorrect Option value. In the absence of the CAO
in the Hop By Hop Header, the ingress filtering is performed on the
packet source address. An incorrect CAO / source address is an IPv6 unicast
address that is received on the wrong interface according to unicast routing.
An alternative mechanism is to once again use the MN HoA as a source address
but this time include the CAO within a Destination Header. This requires that
unicast ingress filtering and multicast RPF checks in routers need to occur
independently of the IPv6 header processing rules. This is reasonable given
A.W. O'Neill Expires Mar 2003 [Page 4]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
that a MN cannot be trusted to request its own packets to be policed and
therefore offers a potentially lightweight alternative to the Hop By Hop
Header.
An ingress access router that supports a redirected ingress filtering check,
using the CAO, SHOULD advertise this capability in its router advertisement.
This is so that a MN can avoid trying to send packets directly from a
foreign network that does not support the CAO. A MN SHOULD NOT include a CAO
unless this capability has been advertised. In addition, an access router MAY
indicate if the whole visited domain supports the CAO option throughout that
domain so that the MN can aggressively use the CAO at each new access router
in an operator's domain during hand-off.
4.2. The Mobile Source Tracking Problem
A MN that uses its HoA as a source address might also wish to inform
appropriate CNs of its current CCoA, and of CCoA changes, for a range of
reasons. This is true whether the MN is at home, sending natively from a
foreign network or reverse-tunnelling from that foreign network to its home
network. The CN can then maintain an Inverse Binding Cache Entry for the MN
that tracks its movement and address details of its locations. The IBCE can
be built in multiple ways and with different levels of confidence in the
binding information.
Applications can then have an API with the IBCE and hence subscribe to
mobility events or to CCoA specific information. For example, the presence of
an unchanging CAO provides the CN with a very good reason to support RO with
this MN due to the likely low rate of binding updates from such a slow moving
/ stationary MN. In addition, being optionally informed of the new CCoA by
the MN enables the CNs to automatically track the movement of the MN through
the topology. Applications might also wish to delay sending new packets for a
short time whilst the MN is undertaking a hand-off, or receivers might wish
to perform less aggressive buffer management for real-time applications.
Sessions with specific MNs might also be scoped such that service would only
be provided to MNs when either at home, or when they are at CCoAs under
specific prefixes such as the home or local domain. This draft does not
motivate the new mechanisms on the above specific examples but instead is
using them simply to indicate the potential usefulness of the API to the
location information.
5. High-level Processing Rules for the CAO
5.1. Option Enforcement Points and Ingress Filtering
IPv6 header processing rules state that the header options within an
extension header are processed by nodes according to 'defined' rules of that
header. So Hop By Hop Header options, for example, are processed by all hops.
In addition, header processing rules state that such processing nodes must
process the options according to the three most significant bits of the
option type, where for example, code 110 means that the packet should be
dropped if the option is unrecognised and the option cannot be modified on
route.
A.W. O'Neill Expires Mar 2003 [Page 5]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
Clearly though a router that wishes to police the contents of packets, for
policy and firewall reasons, cannot rely on a MN creating packets with
suitable header types that will enable the enforcement point to check out all
the options in a defined manner according to the extension header processing
rules. For an arbitrary enforcement point to be fully capable of correctly
checking extension header options, every packet from every node would need to
carry all options within a Hop By Hop header, with the option type code at
'111'. This would naturally result in an arbitrarily located option
enforcement point discarding packets with options that it did not understand,
and whose threats it cannot assess, as well as modifying options it did not
like. This however is clearly not practical as it removes much of the
functionality of option processing.
Therefore an arbitrary option enforcement point must be able to
examine packet options both by ignoring extension header processing rules
that would normally prevent it from examining all options, as well as
ignoring the option type code and instead treating all options as '110' by
default. The likely exception is for end to end options that are within a
Destination Header, and either below any routing header that itself is not
end to end (ie type 2 ok), or absent a routing header. Only if the option
enforcement point fully understands the option will it likely apply
additional enforcement processing, including rewriting the option value (as
if option code 'XX1') and recalculating the CRC to match. This draft neither
requests nor recommends such behaviour by a general OEP on behalf of the CAO,
whose requirements are instead detailed below.
Now the option type for the CAO, given the above, is also '110' so that the
option will be discarded by a Defined processor of the option, if that node
does not understand the option. At an option enforcement point, the
option processing will also discard the packet by default if the CAO is not
understood. The discarder, whether a Defined processor of the option, or an
OEP, must generate an ICMP message back to the sender in the case of a
unicast packet, including the CAO and the reason for the discard, so that the
sender can distinguish between a node that does not support the CAO, and a
node that has explicitly discarded the packet due to a range of CAO errors
such as 'topologically incorrect (ingress filtering)' or incorrect binding
(in a HA). The option MUST not be modified by a Defined option processor, but
an enforcing processor such as an option enforcement point MAY modify the CAO
if it fully understands the CAO semantics.
The following is then the expected behaviour through nodes such as access
routers and other general OEPs;
If a legacy node is neither CAO-aware nor a Defined option processor, then
it will pass the CAO unless it is an Option Enforcement Point in which
case the packet will be dropped.
If the legacy node is a Defined option processor but is not CAO-aware then
it will drop the packet as a result of normal CAO processing rules.
If the router is CAO-aware but not a Defined option processor, then it is
an option enforcement point that may undertake CAO-aware ingress
filtering. If it does so, then the packet will be passed or dropped based
on the topological correctness of the CAO contents. Other option
enforcement rules might also be applied to the CAO to decide on the
A.W. O'Neill Expires Mar 2003 [Page 6]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
packets fate including passing it if the legacy ingress filtering process
succeeds on the packet source address. Given that the CAO is only used to
bypass the ingress filtering check, passing a packet on this check should
be safe for any OEP.
If the router is CAO-aware and a Defined option processor then the node
can also support CAO-based ingress filtering. The packet will then be
discarded on the topological correctness of the CAO and other such rules
in this draft, and the option will not be modified by the node as
indicated by the option type.
If any node is a legacy ingress filtering node, which means it does not
support CAO-aware ingress filtering, then the arriving packet might also
be dropped or passed as a result of an incorrect source address.
The use of the CAO within a Destination Header is preferred to its use within
a Hop By Hop Header because the latter will require all nodes on the path to
be CAO aware for the packet to be correctly forwarded. In contrast, the use
of the Destination Header requires only the 'Destinations' to be CAO-aware,
along with any Option Enforcement Points on the path. Henceforth, this draft
will only discuss the CAO in the Destination Header but in all cases the Hop
By Hop Header can also be used. The Destination Header may be utilised above
or below the Routing Header. When above the routing header it will be
inspected by all destinations visited according to the routing header. When
below the Router header and optionally below an ESP header, only the ultimate
destination will process the CAO in the Destination Header. The appropriate
choice by the MN is to by default place the CAO within a Destination Header
above any routing header and ESP header. Specific situations do exist however
when the CAO can be safely encrypted. If the Destination Header is below any
ESP header then only the MN can verify that the CAO is correct and the
existence of the ESP header ensures the CAO has not been modified on route.
It is a minimum expectation of this draft that all IPv6 access routers
undertake ingress filtering on the packet source address and will discard
topologically incorrect source addresses. It is recommended by this draft
that all IPv6 access routers support CAO based ingress filtering. It is
required by this draft that all such access routers indicate their support
for CAO in their Router Advertisements, to avoid a MN attempting that which
is unavailable and as a result risking packet discard. It is recommended by
this draft that the Router Advertisement indicate whether or not the
operators domain supports CAO processing so that the MN can aggressively use
the MN HoA as a source address. It is also required by this draft that a HA
advertise its capability to support CAO processing to the MN through Router
Advertisements on the home network, and through suitable advisory and error
messages during MIP signalling. The details of these messages are for further
study.
5.2. Existing MIPv6 Processing Rules for the HoA Source Address
The following nomenclature is used to describe the supporting figures in this
draft when describing the use of the CAO.
A.W. O'Neill Expires Mar 2003 [Page 7]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
MN - Mobile Node
CN - Correspondent Node
HA - Home Agent
HoA - Home Address from HA
CCoA - Co-located Care of Address from foreign network
HAR - Home Access Router (default router on the home network)
FAR - Foreign Access Router (default router on the foreign network)
OEP - A general Option Enforcement Point that passes CAO packets.
R - A general core router on the path of the packet..
^ - the destination node according to the current destination address
> - a node traversed by that packet
[ - an encapsulating node
] - a decapsulating node
I - a node that undertakes a legacy ingress filtering check on source
address.
E - an option enforcement point that supports enhanced CAO-based ingress
filtering.
H - a Defined node that supports enhanced CAO-based ingress filtering
X - a node that discards a packet due to an incorrect source address
S - an option enforcement point that snoops and passes the CAO unaffected.
Figure 1 shows a schematic of the possible forwarding paths between the MN
and the CN, when the MN is on its home or a foreign network, and the MN uses
its HoA as a source address. The FAR, HAR and HA are at least option
enforcement points but may also be Defined option processors. The FAR and HAR
are CAO aware ingress filtering nodes.
____ _____ ___ ____ _____ ___ ____
| | | | | | | | | | | | | |
| MN | | FAR | | R | | HA | | HAR | | R | | CN |
|____| |_____| |___| |____| |_____| |___| |____|
A -------------------------------------------------->I--------->--------->^
B ------------------>IX
C [=================>I==========>=========>]H------->I--------->--------->^
Figure 1: Existing processing Rules
In flow A, the HAR examines the packet source address and because it is valid
will be forwarded to the CN.
In flow B, the FAR examines the packet source address and because it is
invalid on the foreign network (not from a prefix on the FAR) then the packet
will be dropped.
In flow C, the MN is reverse tunnelling so the MN will encapsulate in the
CCoA which will pass source address ingress filtering examination in the FAR.
The HA decapsulates, checks the CCoA source address against the registered
binding, and forwards the successful packet to the CN. The HAR examines the
packet source address which again passes because it is the MN HoA.
A.W. O'Neill Expires Mar 2003 [Page 8]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
5.3. Modified Processing Rules for the Foreign Network
In figure 2 we examine the basic changes brought about by this draft.
____ _____ ___ ____ _____ ___ ____
| | | | | | | | | | | | | |
| MN | | FAR | |OEP| | HA | | HAR | | R | | CN |
|____| |_____| |___| |____| |_____| |___| |____|
B' ------------------>E--------->E------------------------------>--------->^
Figure 2: Modified processing Rules from the Foreign Network.
In case B', the MN is again on the foreign network but this time uses the
Destination Header to carry the CAO containing the MN CCoA. This means that
only a router on the path that chooses to enforce options (as an OEP) can
undertake CAO based ingress filtering. Any such router, that does not
understand the CAO, will drop the packet by default, but may pass the packet
if the CAO is topologically correct. Therefore, if all the Option Enforcement
Points between the MN and the CN are all CAO aware then this will ensure that
the MN can send directly to the CN and avoid reverse tunnelling to the HA.
The FAR MUST advertise its support for the CAO enhanced ingress filtering in
the Router Advertisement and the MN should only use the HoA source address
directly with the CN if this advertisement is received.
5.4. MN Location Exchange
Figure 3 illustrates the different forms of communication that a MN can now
undertake as a result of this draft, and illustrates how the MN can in
addition provide the CN with its location. The MN needs to set a flag, the
filter flag (F), in the CAO to indicate whether or not the CAO or the source
address is to be used for ingress filtering. If the filter flag is set then
the ingress filtering is on the contents of the CAO whilst if it is not set
then the ingress filtering is on the source address. The diagram also
includes the cases when the MN tries to lie about its location to illustrate
the level of confidence that the CN can place in the contents of the CAO.
Note that the CAO need only contain a topologically correct address. A MN can
choose to set the P bit in the CAO, include only the access router prefix
(most significant 64 bits) and hide the MNs current EUI-64. This is useful if
the MN HoA does not itself include that EUI-64, the MN therefore wishes to
hide its terminal information from the CN, and/or the MN wishes to deny the
CN reachability to its CCoA, yet reveals its topological location and share
its movement history and mobility events with the CN. When the P bit is not
set, the CN is informed that the contained CCoA is a valid communications
address. The P bit setting must therefore be policed by the HA and access
routers whilst also policing the CCoA contents and the other CAO flags. The
MN may include the address of its default router whilst also setting the P
Bit whereas if just the prefix is included then the lower 64 bits are zeroed.
A.W. O'Neill Expires Mar 2003 [Page 9]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
____ _____ ___ ____ _____ ___ ____
| | | | | | | | | | | | | |
| MN | | FAR | |OEP| | HA | | HAR | | R | | CN |
|____| |_____| |___| |____| |_____| |___| |____|
A ------------------------------------------------->E--------->I--------->^
No CAO (packet delivered but location hidden)
CAO=HoA, F=0 (to support legacy ingress filtering nodes)
CAO=HoA, F=1 (will pass CAO aware OEPs)
CAO=fake, F=0 (not allowed by HAR)
CAO=fake, F=1 (will be dropped during CAO checks in any node)
B' ------------------>E--------->E----------------------------->I--------->^
No CAO (packet dropped at FAR due to incorrect source address)
CAO=CCoA, F=1 (to preserve the topologically incorrect source address)
CAO=fake, F=1 (a false location causes the packet to be dropped)
CAO=fake, F=0 (not allowed by FAR)
C [=================>I==========>=========>]H------->E-------->I--------->^
No CAO (packet delivered but location hidden)
CAO=CCoA, F=0 (to avoid discard due to the topologically incorrect CAO)
CA0=CCoA, F=1 (will be discarded during CAO checks in any node)
CAO=HoA, F=0/1 (not allowed by HA)
CAO=fake, F=0 (not allowed by HA)
CAO=fake, F=1 (not allowed by HA & dropped during CAO checks in any node)
Figure 3: MN location exchange
In case A, the MN is at home and can optionally put a CAO into a Destination
Header containing the HoA of the MN. The filter flag is best set to F=0 but
MAY be F=1. The HAR MUST be able to check and recognise either a source
address or a CAO that contains an address that is not from the home network.
In case B', similar processing rules apply except that the omission of the
CAO is no longer possible and hence the CN always learns the CCoA and the
EUI-64 of the MN. The FAR must be able to check and recognise a CAO that
contains an address that is not from the foreign network.
In case C, the MN is reverse tunnelling and the HA is used to assist the HAR
in being able to distinguish between a packet from a foreign MN that can have
a CAO=(CCoA=foreign, F=0) and a home MN that cannot (i.e. MN is lying about
its location). The HAR can distinguish between packets from a MN and those
from the HA due to the link-layer addresses and the RA from the HA. However,
if this link-layer information is not considered sufficient for all cases,
then the MN MUST use a type 0 routing header containing the CN address and
set the inner packet destination address to that of the HA. The HA is then a
Defined processor of the CAO and after swapping the CN address into the
destination address, the HA address will remain in the RH which will be
received by the HAR. The HAR must be configured with, or learn securely the
HA addresses on the home network, so that packets checked by the HA can be
distinguished at L3, from those that have been sent directly by MNs or
indirectly via MNs pretending to be HAs. The HAR then discards packets where
the CAO=(CCoA=foreign, F=0) except if received via a trusted HA.
A.W. O'Neill Expires Mar 2003 [Page 10]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
5.5 CAO Specific Processing Rules at the CN
The inclusion of a Care of Address option within either a Hop by Hop or a
Destination Header does not affect the destination node's processing of this
single packet but can create or modify state in the correspondent node in the
form of an Inverse Binding Cache Entry (IBCE). The CN MAY inspect the
evolving contents of the CAO and as a result MAY build an Inverse Binding
Cache Entry (IBCE). This IBCE can be used by the CN to track the location of
the MN in the topology if the MN so desires and for the networking stack and
high-layer processes to be aware of hand-off activity and MN location.
Specifically, the CAO can contain flags, that signal mobility events to the
CN such as the M flag (movement) when a hand-off is starting on the old CCoA.
However, the presence of a Care of Address option in a received packet MUST
NOT alter the contents of the receiver's Route Optimisation Binding Cache and
MUST NOT cause any changes in the routing of subsequent packets sent by this
receiving node without additional activity.
The contents of the CAO in an Hop By Hop option header has been fully
verified by the routing infrastructure as being topologically correct. The
contents of the CAO in a Destination header has been partially verified by
the routing infrastructure and fully verified by the home or foreign network.
In either case, this does not prevent a 'man in the middle' attacker within
the infrastructure or on the access link of the CN from modifying the
contents of the CAO and replacing it with a topologically correct CAO at that
location, which henceforth will still pass CAO based ingress filtering on
route to the CN. Additional security processes are therefore required for the
CN to fully trust the MN location for Route Optimisation purposes, which are
not the subject of this draft. In all other cases, the IBCE is simply used
for MN location tracking and provides little incentives for an attacker to go
to great expense just to affect the contents of the IBCE.
____ _____ ___ ____ _____ ___ ____
| | | | | | | | | | | | | |
| MN | | FAR | |OEP| | HA | | HAR | |OEP| | CN |
|____| |_____| |___| |____| |_____| |___| |____|
A ^------------------------------------------------S<----------S<----------
B' ^-----------------S<---------S<---------H<-------S<----------S<----------
C ^-----------------S<---------S<---------H<-------S<----------S<----------
Figure 4: CAO reflection.
In the absence of an SA to authenticate or encrypt the CAO within a
Destination Header, the CN can acquire additional confidence in the contents
of the CAO through the reflection process (figure 4). The CN MAY reflect back
the contents of a received CAO to a MN, using a Destination Header, within
session response packets, or when those are not available, MIP signalling
packets. This reflection MUST be undertaken immediately on receipt of a
triggering CAO to avoid the contents of the CAO becoming stale, which would
result in a failed verification and a discarded response packet. The receipt
of a reflected CAO informs the MN that the CN is maintaining an IBCE for the
A.W. O'Neill Expires Mar 2003 [Page 11]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
MN, as well as the current location of the MN contained in that IBCE at that
CN. The MN can therefore detect whether the CN has an incorrect location
created through an attack or simply as a result of a CN bug. The MN SHOULD
discard packets containing an incorrect CAO entry and return an ICMP message
back to the CN, reporting the failure of the CAO. The ICMP message MUST
include the erroneous CAO and the reason for the failure. The MN MAY
alternatively process the packet and send a new CAO to the CN immediately.
The CN may also use a reflected CAO entry of 'all 0' to autonomously request
a CAO update from the MN. The reflection process ensures that an attacker
must be on both paths to be able to modify both the inbound and the outbound
CAO. The Reflected CAO is also ameniable to end to end security, whilst the
use of the triggering CAO for ingress filtering and RPF redirection generally
prevents this. However, the CN may well prefer to have both the MN and its HA
verify the reflected CAO as Defined processors, which then requires the CN to
use a routing header and place the Destination Header above that routing
header.
The combination of a triggering CAO in an extension header followed
by a reflected CAO in a Destination Header, enacted periodically during a
session, gives the CN a high level of confidence that its IBCE does indeed
contain the current and evolving location of the MN. In both these cases, and
potentially in other cases, the IBCE may assist with subsequent installation
of Route Optimisation between the MN and the CN. A session in which the MN
and CN are periodically and mutually verifying the MN location (HoA/CoA
binding) may provide significant levels of confidence in advance of the Route
Optimisation procedure and in so doing potentially reduce the additional
message exchanges presently envisaged in the base MIPv6 spec. Essentially,
the CAO is a proactive binding tracking mechanism whilst the COT(I)/HOT(I)
sequence is a reactive mechanism enacted at the point of hand-off.
The IBCE contents might also be useful for identifying candidate sessions for
the installation of route optimisation because a MN with a stable or slow
moving location is preferable to one with high-mobility dynamics due to the
significant security and signalling load (bandwidth/latency costs) required
with RO each time the MN undertakes a hand-off. Finally, the movement
information of the MN in the IBCE can be used for policy and application
control of sessions that are affected by either location, roaming or mobility
events.
The specific additional security requirements necessary to complement the CAO
processing for its use in Route optimisation is not covered by this draft.
A.W. O'Neill Expires Mar 2003 [Page 12]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
6. Format and Usage Rules for the Care of Address Option
The Care of Address option is encoded in type-length-value (TLV) format
as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R F P T H M Reserved bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
TBA
Option Length
This field MUST be set to 16.
R bit
When unset this indicates that this is the CAO of the sender.
When set this indicates that this is the CAO of the receiver and the
CAO has been reflected.
F bit
When set it indicates that the ingress filtering MUST be undertaken
on the address in the CAO.
When unset it means that the ingress filtering MUST be conducted on
the packet source address.
P bit
When set, this indicates that the Care of Address field includes the
prefix of the MN only.
H bit
When set this indicates that the CAO will be verified by the MN HA
and may be used by a CN to indicate that the location may be fake.
M bit
When set this indicates that the MN is starting a hand-off from the
location address included in the CAO.
Care of Address
The present Care of Address (location) of the mobile node, which can be
either the MN CCoA or the HoA. It can be either the full address of the
location, the prefix of the access router or a fake address.
A.W. O'Neill Expires Mar 2003 [Page 13]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
A CAO with the R bit unset can appear in either the Hop By Hop or
Destination Headers in a packet, but not both at the same time. Within the
same packet, a reflected CAO with the R bit set MAY also be included in a
Destination Header. A CAO with the R bit set SHOULD NOT appear in a Hop By
Hop Header. Therefore, the Care of Address Option with the same R bit
setting, MUST NOT appear twice in the same packet header. A CAO with the R
bit unset can appear at most N times within a N-fold encapsulated packet. A
CAO with the R bit set can also appear at most N times within a N-fold
encapsulated packet.
IPv6 requires that options appearing in a Hop-by-Hop Options
header or Destination Options header be aligned in a packet so that
multi-octet values within the Option Data field of each option fall
on natural boundaries (i.e., fields of width n octets are placed at
an integer multiple of n octets from the start of the header, for
n = 1, 2, 4, or 8) [11]. The alignment requirement [11] for the Care of
Address option is 8n+6.
The Care of Address Option MAY be included in a Hop by Hop Header when;
- the MN is at home, or at a foreign network and either sends directly to
the CN or reverse tunnels to the CN via its HA, and
- the MN uses its HoA as the source address
The Care of Address Option MAY be included in a Destination Header when;
- the MN is at home, or at a foreign network and either sends directly to
the CN or reverse tunnels to the CN via its HA, and
- the MN uses its HoA as the source address.
The Care of Address Option MAY be reflected in a Destination Header when;
- the CN has received a CAO from the MN,
- the CN has created an IBCE for the MN, and
- the CN is sending to that MN HoA either directly, or
- the CN is sending to that MN HoA via its HA.
Multicast addresses, link-local addresses, loopback addresses, IPv4
mapped addresses, and the unspecified address, MUST NOT be used
within a Care of Address option.
The Care of Address option in the Hop By Hop Header MUST be placed as
follows:
- Before the Destination Header, if that header is present
- Before the Routing Header, if that header is present
- Before the Fragment Header, if that header is present
- Before the AH Header or ESP Header, if either one of those
headers is present
A.W. O'Neill Expires Mar 2003 [Page 14]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
The Care of Address option in the Destination Header SHOULD be placed as
follows:
- After any Hop By Hop Header
- Before the Routing Header, if that header is present
- Before the Fragment Header, if that header is present
- Before the ESP /AUTH Header, if this header is present
This enables the Routing Header to formally control which nodes, such as
the HA and MN, process the CAO in the Destination Header but means that
the CAO cannot be encrypted. The HA and any other OEP MAY also snoop the
CAO in unencrypted packets that pass through it as part of existing MIP
operations.
The Care of Address option in the Destination Header MAY be placed as
follows:
- After any Hop By Hop Header
- After the Routing Header, if that header is present
- After the Fragment Header, if that header is present
- After the ESP Header, if this header is present
This enables the CAO contents to be encrypted and ensures only the CN can
process the CAO. The appropriate rules for the AH header have not been
included merely for simplicity reasons but it is clear that ESP and the
Auth header can be used to authenticate the contents of the CAO and build
trust in the IBCE at the CN.
7. Security Considerations
The Care of Address Option provides an optional facility for the MN to send
directly to the CN yet still potentially pass ingress filtering, and /or to
inform the CNs of its topological movement. This draft does not specifically
recommend, nor suggest standardisation of, the usage of such information by
the CN network and higher layers.
The source address of such packets is the HoA of the MN, and the HoA also
serves as the return address. The MN can include the CAO in such packets but
this option does not in any way affect the routing of subsequent packets. The
packet source address and the returned packets destination address are always
the same, being equal to the MN HoA. Packets containing the CAO do not
therefore offer the redirection threats that were originally offered by MNs
originating packets from the CCoA, and including the Home Address Option
(HAO). This redirection threat resulted is such packets being banned in the
base spec unless the MN/CN have securely installed a BCE in the CN, and this
ban forces a MN to have to reverse tunnel packets to the HA in the absence of
RO.
A.W. O'Neill Expires Mar 2003 [Page 15]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
If the MN wishes to hide its location it can simply not include a CAO.
Packets are not being rerouted based on the CAO and even if they were, it
would only affect its own communication so the MN has little incentive to lie
about its location and its mobility events.
The CAO processing rules ensure that the MN cannot abuse the CAO system and
significantly mislead the CN. The access routers on both home and foreign
networks must specifically prevent a MN from including an address into the
CAO that is not its own and that has not been policed by the HA, but is valid
at the access router and hence would have passed CAO based ingress filtering
checks. An attacker on the same network as the MN can potentially try to send
packets using the HoA and CCoA of another MN but clearly cannot otherwise
intercept, or interfere with, the communications between the MN and the CN.
This is true whether or not the CAO is added and is simply an additional
requirement on the access router to be able to deny such opportunities to
attackers.
Ongoing communications between a MN and a CN based on the HoA, provides the
CN with confidence that the MN is reachable at the HoA at some arbitrary
subnet via the HA. The inclusion of the CAO in a subset of packets from that
MN provides the CN with a reasonable level of confidence that the MN is at
that CCoA. A man in the middle attacker can at best modify the CAO and the
CRC of a packet, but in doing so can neither hijack communications nor
reroute packets. This is because return packets are still routed via the HA
and will be correctly delivered to the MN at its presently registered CoA.
The attacker could install an invalid CAO into a packet that might well fail
upstream ingress filtering checks. This would cause the packet to be
discarded but such an attacker could have removed the packet itself, so the
addition of the CAO simply opens more subtle ways of discarding packets at
significant expense to the attacker. The attacker can add a topologically
correct address into the CAO from its location on the path to the CN, and
then change it back on the return path but this offers nothing directly to
the attacker at significant cost to itself. Additional security processes are
however clearly needed to enable the IBCE to be used for Route Optimisation.
The use of the IBCE for Route Optimisation is not covered in this draft in
detail and therefore a detailed security analysis of this has not been
undertaken in this document.
8. Notice Regarding Intellectual Property Rights
Flarion's submissions will conform with RFC 2026. Flarion may seek patent
protection on some or all of the technical information submitted by its
employees in connection with the IETF's standards process. If part(s) of a
submission by Flarion is (are) included in a standard and Flarion owns
patent(s) and/or pending patent application(s) that are essential to
implementation of such included part(s) in said standard, Flarion is prepared
to grant a license on fair, reasonable, reciprocal (license back) and non-
discriminatory terms on such included part(s).
A.W. O'Neill Expires Mar 2003 [Page 16]
INTERNET-DRAFT MIPv6 Care of Address Option Sep 2002
9. Acknowledgements
Many thanks to George Tsirtsis for reviews of this document and for
motivating improvements in the design of CAO enhanced ingress filtering.
10. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[MIPv4] C. Perkins, Ed., 'IP Mobility Support for IPv4', RFC 3344, August
2002.
[MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", Internet-Draft,
draft-ietf-mobileip-ipv6-18.txt (work in progress), 22 March 2002.
[MIP-multicast] A. O'Neill, 'Mobility Management and IP Multicast',
Internet-draft, draft-oneill-mip-multicast-00.txt (work in progress), 5 July
2002.
Appendix A: CAO based RPF Check
In general, all routers in a network will be multicast enabled and as such
will undertake multicast RPF checks. A CAO based RPF check uses the contents
of the CAO rather than the multicast source address for the RPF check. This
requires either that all multicast routers must be option enforcement points
and to enable them to process the CAO option, or that the Hop By Hop Header
be mandated for all multicast packets issued by MNs when away from home. The latter is not unreasonable given all modes are likely to be multicast routers, and any that are not will be tunnelled over and hence such nodes will also not see the Hop By Hop header.
Author's Addresses
Alan O'Neill
Flarion Technologies
Phone: +1 908 947 7033
Email: oneill@flarion.com
A.W. O'Neill Expires Mar 2003 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 17:20:54 |