Network Working Group Jari Arkko
INTERNET-DRAFT Ericsson
<draft-arkko-mipv6-bu-security-00.txt> October 2001
Issues in Protecting MIPv6 Binding Updates
1. 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 docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or made obsolete 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 may be found at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories may be found at
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as <draft-
arkko-mipv6-by-security-00.txt>, and expires March 1, 2001. Please
send comments to the author or to Mobile IP working group.
2. Abstract
The Mobile IP working group is currently searching for a security
solution that enables semi-secure, weak authentication between IPv6
Mobile Nodes and Correspondent Nodes in the the global Internet. Sub-
sequent Binding Updates messages will then be cryptographically
integrity protected to prevent abuse of the mechanisms for route opti-
mization. This memo assumes a suitable authentication mechanism
exists, and discusses various alternatives on how the BUs can be pro-
tected. We note that there are multiple alternatives. In particular,
the solution space is more fine grained than "Use IPsec for every-
thing" and "Don't Use IPsec At All". Fair amount of detail is neces-
sary to explain how the solutions work, whether any standard exten-
sions are needed, what kind of APIs are needed between stack parts,
what the implications are to piggybacking, how the solutions fit situ-
ations where strong authentication is also a requirement, and so on.
3. Contents
1. Status of this Memo..................................1
2. Abstract.............................................1
3. Contents.............................................1
J. Arkko Expires April 2002 [Page 1]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
4. Introduction.........................................2
5. Main Requirements....................................3
6. Solutions............................................4
6.1. Application Specific Protection......................5
6.2. Existing IPsec AH with a New Next Header Value.......6
6.3. IPsec AH with Policy Extensions......................8
6.4. Application Specific Protection with Optional IPsec..9
7. Piggybacking Binding Updates.........................11
7.1. Implications to Protecting BUs with IPsec............11
7.2. Implications to IPsec Protection of Other Traffic....11
7.3. Bandwidth Implications...............................12
7.4. QoS Implications.....................................13
7.5. Other Implications...................................14
7.6. Other Solutions to the Piggybacking Problem..........15
8. Comparison of Solutions..............................16
8.1. Requirements Fulfillment.............................17
8.2. Header Overhead......................................18
8.3. Computational Overhead...............................18
8.4. Memory and State Requirements........................20
8.5. IANA Requirements....................................21
8.6. Standardization Work.................................21
8.7. Evolution of Authentication Protocols................21
8.8. Error Situations.....................................22
8.9. Optimizations for Busy Servers.......................22
8.10. Address Ownership....................................23
8.11. Implementation Aspects...............................23
9. Conclusions..........................................24
10. Further Work.........................................26
11. Acknowledgements.....................................27
12. References...........................................27
13. Author's Address.....................................28
4. Introduction
The Mobile IP working group is currently searching for a security
solution that enables weak authentication between IPv6 Mobile Nodes
(MNs) and a Correspondent Nodes (CNs) in the the global Internet. It
is necessary to accept less than perfect security in this situation,
because strong authentication between previously unknown peers would
require a global Public Key Infrastructure (PKI). With current state
of the art, this is neither possible nor desirable.
The purpose of the weak authentication mechanism is to establish a
Binding Security Association (BSA) between the MN and the CN for the
secure exchange of Binding Updates (BUs). The main content of such
BSAs are the keying material derived as a part of the authentication
mechanism. BUs will be cryptographically integrity protected to pre-
vent abuse of the mechanisms for route optimization. The main reason
for creating such BSAs is actually optimization: after a possibly
multi-round authentication protocol has been run, keying material can
be created to enable subsequent protection using the BSA, avoiding the
need to rerun the authentication.
J. Arkko Expires April 2002 [Page 2]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
This memo assumes a suitable authentication mechanism exists, and dis-
cusses various alternatives on how the BUs can be protected. Further-
more, we discuss how strong authentication can optionally be used in
those situations where suitable trust infrastructure exists, such as
inside corporate networks.
Even if we discuss the relationship of the BU protection to authenti-
cation and key agreement, this memo relies only on the ability of
these mechanisms to produce BSAs. Technical details of how they are
performed are outside the scope of this memo and must be discussed
elsewhere.
The motivation for writing this memo is to provide a concrete set of
proposals for BU integrity protection, in one document together with a
comparison of their pros and cons.
The memo is outlined as follows. In Chapter 5, we discuss a very high
level set of requirements, without going to the details on exactly
what weak authentication means as this is already discussed in [2]. In
Chapter 6, we introduce the alternative ways on how we think the BUs
can be protected. Chapter 7 is devoted to the discussion of how piggy-
backing affects the solutions. Chapter 8 compares the alternatives
against each other in terms of their security, efficiency, use of pre-
cious protocol numbers, requirements for new standardization work, and
other criteria. Chapter 9 concludes with some of the main findings.
In this memo we assume that the authentication mechanisms indeed pro-
duce BSAs and the optimization to not rerun authentication is a neces-
sary one.
5. Main Requirements
The main requirements that are relevant from the point of view of this
memo are the following:
>> R1: It MUST be possible to integrity protect BUs against in-transit
modifications or forgery.
>> R2: It MUST be possible to protect the BUs against replay attacks.
(This is a requirement, though binding updates themselves contain a
mechanism against replay attacks.)
>> R3: It MUST NOT be possible for nodes to use their own BSAs to send
BUs on the behalf of other nodes.
>> R4: It SHOULD be possible to derive BSAs for BU integrity protec-
tion from weak authentication. (While this draft assumes the BSAs are
derived, we note that this is an optimization and therefore in general
we do not require BSAs.)
>> R5: It MUST be possible to derive BSAs for BU integrity protection
from strong authentication. (By 'strong authentication' we mean
mainly IKE, but other possibilities can also be considered.)
J. Arkko Expires April 2002 [Page 3]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
>> R6: It SHOULD be possible to use alternative integrity algorithms.
All implementations MUST implement one designated algorithm for inter-
operability reasons. This is a corollary of requirement 4 in [2]. Note
that this requirement speaks of the actual BU protection. Authentica-
tion part needs also several mechanisms, as indicated by R4 and R5.
Interestingly enough, this requirement set looks very different from
that defined in [2]. This is mainly because in this memo we only con-
sider the BU protection, and do not go to the details of what the
requirements for the weak authentication are. However, we note that
the possible inclusion of requirements R2 and R5 to [2] should be con-
sidered. It seems clear that R2 is a requirement, while R5 is perhaps
controversial, and should be discussed.
6. Solutions
In this chapter we discuss various solutions for the protection of the
BUs. We note that there are multiple alternatives. In particular, the
solution space is more fine grained than "Use IPsec for everything"
and "Don't Use IPsec At All". Furthermore, all the solutions have to
be described in a fair amount of detail in order to make it clear
exactly how they can work, and how they can work together with both
weak and strong authentication, and the evolution of protocols for
strong authentication.
The alternative solutions that will be discussed are listed below:
- Application specific protection, i.e. the use of the mechanism
defined in the -14 version of the Mobile IPv6 draft [1].
- Existing IPsec AH with a new next header value for BUs. In this
alternative we can use the current versions of IPsec AH and IP Secu-
rity Architecture since BUs are not piggybacked to other packets.
- IPsec AH with policy extensions. Certain extensions to the current
requirements for security policy data bases and SA selectors are
needed in order to protect BUs that are embedded in the Destinations
Options header of packets possibly containing also other payloads.
- Application specific protection with optional, additional IPsec pro-
tection. For instance, we use the -14 mechanism and the weak authenti-
cation in all situations, but apply also IPsec and IKE within a corpo-
rate network.
These four alternatives correspond the different philosophical
approaches to the problem. The first alternative treats the Mobile IP
security problem as a separate issue that should be solved indepen-
dently of other problems, and at exactly the manner that suits Mobile
IP the best way. The second alternative tries to maximize reuse of
existing solutions, while possibly making compromises on what kind of
functionality can be offered. The third alternative also reuses
existing solutions, but does not settle for compromises. Finally, the
fourth approach looks upon the specific Mobile IP solutions and gen-
eral corporate network security solutions as complementary to each
J. Arkko Expires April 2002 [Page 4]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
other.
It doesn't seem possible to treat the above list completely indepen-
dently from the way the authentication is handled. For instance, it is
possible to use strong authentication but there are several different
ways how we can provide it. Therefore, the list below shows what kind
of authentication mechanisms can be combined with the above solutions:
- Nothing. It should still be possible to use unsecured BUs.
- The sole use of a new weak authentication protocol.
- The use of a new protocol capable of both weak and strong authenti-
cation.
- The use of a new weak authentication protocol and an existing strong
authentication protocol. If an existing protocol is used unmodified,
this limits the BU protection mechanism to those supported by the
authentication protocol already. In practice, only IPsec AH could be
used for BU protection if the authentication protocol is kept as is.
- The use of a new weak authentication protocol and an enhancement of
an existing strong authentication protocol. This would allow both the
use of IPsec AH and the application specific mechanism defined in the
-14 draft [1].
Assuming multiple authentication methods can be used (e.g. nothing,
weak, and strong), how does one know which one to choose? Currently,
there doesn't seem to be any other answer to this than configuration.
On a particular network, for instance, all machines could be config-
ured to use only strong authentication. Making the selection becomes
harder if multiple authentication methods need to be enabled simulta-
neously. For instance, strong authentication is always required within
a corporate network but to the rest of the world we allow also weak
authentication. Typically, VPN-like mechanisms for representing poli-
cies on IP addresses and networks can be used here.
In some recent discussions the use of very simple authentication tech-
niques such as return routability has been brought up. While this memo
does not address that type of solutions we indicate that IPsec-based
SAs are fundamentally limited to provide security only through shared
secrets. This is the current assumption also in the -14 draft. It
appears possible to use simpler types of security as well, such as
some methods in Michael Roe's proposal [18]. If these simpler methods
are found suitable, then neither the current -14 nor the IPsec models
are appropriate. But as discussed earlier, the shared secrets are used
as an optimization, and it remains to be seen if acceptable solutions
can be found without this optimization.
6.1. Application Specific Protection
In this mechanism, the Binding Update and its acknowledgement options
are kept in the Destination Options header, and contain an SPI and an
integrity check vector. (The options always contain a sequence number
J. Arkko Expires April 2002 [Page 5]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
as well.) All operations on these security related fields are per-
formed within the Mobile IP implementation itself, and no effects out-
side the Destination Options header can be seen. Further details on
this mechanism are described [1].
No specific user actions are needed in order to configure this mecha-
nism, beyond possibly turning security on. All BUs and their acknowl-
edgements will be required protection, by the software taking care of
the mobile IP functionality. In this mechanism, it would also be pos-
sible to allow both secured and unsecured BUs during the deployment
phase of secure Mobile IPv6. This would also have to be configured,
either as an always allowed but optional security, or on a per network
basis.
In the case that strong authentication is also desired for BUs, the
configuration becomes much harder. There are no key distribution mech-
anisms currently designed to key -14 BSAs.
As the BUs are kept in the Destination Option header, no next protocol
numbers are consumed by this mechanism, but an option number is con-
sumed. It is possible to piggyback the BUs on regular TCP or other
payload traffic, and there are no effects to upper layers.
If this mechanism is used together with traffic flows that for other
reasons use IPsec, the rules governing the addition and removal of the
Destination Options must be constructed so that the Mobile IPv6 pro-
cessing offers the same packet for the IPsec AH ICV calculations. This
doesn't seem to be a problem.
The authentication and key agreement protocol can be run independent
of the BUs, or even within the BU packets.
It is not possible to use existing strong authentication protocols
unchanged in this solution.
6.2. Existing IPsec AH with a New Next Header Value
In this approach, the Binding Updates and their acknowledgements are
sent in packets separate from actual payload traffic, with a new pro-
tocol number (or a UDP port). IPsec SAs are used for the BSAs. AH is
used to protect the BUs, though the SAs are created using a weak
authentication protocol and not IKE.
The policy database for IPsec is set up so that packets destined to
the particular host with the BU protocol number require the use of a
particular SA. This SA is the one that was created for BU traffic to
that host. Otherwise the packets are dropped. The weak authentication
protocol creates the SAs when the Mobile IPv6 signaling needs them.
Like all other IP and higher layer processing, IPsec policy matching
is performed on the used home addresses rather than Care-of-Addresses
(see section 10.1 in [1]). This means that a particular IPsec SA can
be used even if the MN moves and changes its CoA, and that a particu-
lar SPD entry can only be used by the right host. In this case the so
called address ownership problem [10] does not exist, since the SPD
J. Arkko Expires April 2002 [Page 6]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
entries and the SAs have been created only through the authentication
protocol, and the SPD entries require the use of a specific address in
a specific SA.
A typical SPD would contain entries such as the ones below:
1. mn1 to here with proto=BU => use SA1
2. here to mn1 with proto=BU => use SA2
3. mn2 to here with proto=BU => use SA3
4. here to mn2 with proto=BU => use SA4
5. proto=BU => drop
In this example the CN at address "here" has had a contact with two
mobile nodes at addresses "mn1" and "mn2". Two pairs of SAs have been
created to protect the signaling to these, SA1/SA2 and SA3/SA4. All BU
traffic to these nodes is protected using these SAs, and any other BU
traffic is simply dropped. (Note that as a mobile node sees a need to
send BUs to another node, it first runs the authentication protocol
which will establish these rules.)
The organization of the SPD presented above is just one possible one.
In this case an API is required to dynamically update the policy data
base from the Mobile IP implementation. In an another type of organi-
zation, a single BU-related general policy rule would be sufficient,
and the correct SAs would be picked with selectors. IPsec has the con-
cept of "selectors", which are tied to each SA. The purpose of the
selectors is to specify which SA to use within a set of SAs. A typical
VPN policy, for instance, might say that all traffic must be encrypted
with IPsec. However, since a host may communicate with several other
hosts, one SA pair is not sufficient to under this general rule.
Instead, a number of SA pairs are established, and the selectors are
used to determine which particular SA to use for a particular destina-
tion address. These checks are applied to packets in both directions.
In the case of protecting BUs in this alternative, the selectors of
each SA would be set to the particular addresses used in the communi-
cations. In the example the selectors would correspond to checking
that the e.g. packets sent through SA1 had "mn1" and "here" as their
source and destination addresses, respectively. This organization
would require the IPsec implementation to understand a new type of a
policy entry, one that should not initiate IKE negotiations even if no
SA exists.
The user's configuration set-up is interesting. One alternative in
doing this is to set up a specific Mobile IPv6 policy entry, but the
policies could also be set automatically from the Mobile IPv6 soft-
ware, which would probably be easier in terms of configuration. In any
case, the user can turn on or off the protection, and could also do so
on a per-network or host basis. However, it would not be easy to allow
security as an optional service since standard IPsec policy data bases
always either demand or disallow security.
A single protocol number is needed for the BUs in this alternative.
The same number could be used for both BUs and their acknowledgements.
No option numbers are needed. Given that the IPsec policy data base
J. Arkko Expires April 2002 [Page 7]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
is set up to use the protocol number as a decision factor, it is not
possible to send the BUs and payload data in the same packets.
In this alternative, IPsec can be used also for other purposes, to
protect the payload traffic. The policy database must be constructed
so that the BU protection rules and other rules do not overlap.
All authentication mechanisms are possible in this solution, including
the use of existing protocols such as IKE [4]. It isn't necessary to
modify the existing protocols. The Mobile IP implementation can look
at the SPD when it needs to create a new SA. If a regular IKE-based
rule already exists for the particular other host, the SA establish-
ment is left to IKE. If not, the weak authentication protocol is run
and an SA and the corresponding SPD entry are created.
6.3. IPsec AH with Policy Extensions
In this approach, the current model used for representing BUs is
retained, but IPsec policy rules are extended beyond the requirements
of the current standard. The extension is necessary in order for it to
be possible to represent rules about BUs in Destination Options. Cur-
rently, IPsec standard requires only the possibility to construct pol-
icy rules based on addresses, protocols (IPv6 next header numbers),
and port numbers.
The policy database for IPsec is set up in a manner similar to the
previous alternative, except that the policies look at the options
part, not the protocol numbers. That is, one of the SAs that have been
created for the protection of the BUs must be used if the BU option
appears in the packet, or otherwise the packets are dropped. The weak
authentication protocol creates the SAs when the Mobile IPv6 signaling
needs them. The concept of "selectors" also needs to be used. The
selectors are tied to each SA, and their purpose is to specify which
particular SA to use within a set of SAs. The selectors would be set
to the particular addresses used in the communications. This prevents
a node from sending other node's binding updates inside its own SA.
Again, home addresses are used the policy matching.
The user's configuration set-up in this alternative is similar to the
previous alternative: the configuration could be done through an
explicit Mobile IPv6 entry in the policy table, or automatically from
the Mobile IPv6 software. The latter would probably be easier in terms
of configuration. Again, the user can turn on or off the protection,
either globally or on a per-network or host basis. It would not be
easy to allow security as an optional service.
As the BUs are kept in the Destination Option header, no next protocol
numbers are consumed by this mechanism, but an option number is con-
sumed. It is possible to piggyback the BUs on regular TCP or other
payload traffic, and there are no effects to upper layers.
IPsec can be used also for other purposes, to protect the payload
traffic. However, this requires the construction of the policy entries
in a manner that takes in account the possibility that a packet
J. Arkko Expires April 2002 [Page 8]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
matches both the BU rules, and some other rules, such as in the case
of important TCP traffic that also happens to carry a piggybacked BU.
Unlike in the case of separate protocol number, these is no easy way
to avoid such overlap in this case. However, given the new, extended,
policy rule specifications, these situations must be taken care of in
the policies themselves, i.e. the user will dictate what kind of secu-
rity will apply to e.g. BUs, TCP, and BUs piggybacked to TCP
A typical SPD would contain entries such as the ones below:
1. neta to here with proto=TCP => IPsec with IKE
2. neta to here with proto=* and BU option => IPsec with weak authentication
3. here to neta with proto=TCP => IPsec with IKE
4. here to neta with proto=* and BU option => IPsec with weak authentication
5. * to here with proto=* and BU option => IPsec with weak authentication
6. here to * with proto=* and BU option => IPsec with weak authentication
7. * to here with proto=* => pass
8. here to * with proto=* => pass
In this example the CN at address "here" allows traffic with the net-
work "neta". Traffic that has TCP is protected with the normal IPsec
means, regardless of whether there are possible Binding Updates (rules
1 and 3). Traffic that has only the BU option but no TCP, is protected
using weak authentication (rules 2 4). For all other addresses, only
the packets containing BU options are protected, regardless of upper
layer protocol numbers (rules 5 and 6).
As the CN communicates with MNs, the weak authentication protocol cre-
ates new entries under the given policy rule sets (2, 4, 5, and 6 in
our example). The SAs have selectors that ensure the correct SA was
used. The selectors would correspond to checking that the e.g. an
address "hosta1" within "neta" uses its own SA, not someone else's SA.
This means that the selectors for the SAs are more specific than the
policy entries, as is described in 4.4.1 option a in [11]. For
instance, assuming SAs have been created with hosts hosta1 and hosta2
within neta, the following SA entries and selectors would be found
under the policy rules 2 and 4:
2: policy = neta to here with proto=* and BU option
SA1: hosta1 to here with proto=* and BU option
SA3: hosta2 to here with proto=* and BU option
4: policy = here to neta with proto=* and BU option
SA2: here to hosta1 with proto=* and BU option
SA4: here to hosta2 with proto=* and BU option
The Mobile IP implementation requires an access to the IPsec SA
database in this alternative. The SPD can stay static, but the IPsec
implementation must understand that it may not e.g. start IKE negoti-
ations based on the "weak authentication" policy rules.
6.4. Application Specific Protection with Optional IPsec
In this alternative, two different protection mechanisms are applied
independently of each other. For instance, we use the -14 mechanism
J. Arkko Expires April 2002 [Page 9]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
and the weak authentication in all situations, but apply additionally
also IPsec and IKE where a suitable PKI exists, such as in corpora-
tions. This may lead to the use of two security headers protecting
partially the same packet. On the other hand the independence of the
Mobile IP and IP security solutions relieves the need to extend policy
rules, or to open APIs between the two stack parts.
The Binding Update and its acknowledgement options are kept in the
Destination Options header, and contain an SPI and an integrity check
vector. All operations on these security related fields are performed
within the Mobile IP implementation itself, and no effects outside the
Destination Options header can be seen. Further details on this mecha-
nism are described [1]. An independent protection is provided by stan-
dard IPsec/IKE means for the traffic specified in the SPD. Given that
standard SPD granularity is used, the IPsec protection does not neces-
sarily apply only to the BUs, but also to other traffic. This may,
however, be in line with security requirements as we will discuss
later.
There are two aspects to the user configuration in this alternative.
First, it becomes necessary to configure the Mobile IP security which
is likely to consist of turning on/off the security protection. As
described in section 5.1, it may also be possible to to allow both
secured and unsecured BUs which would also have to be configured. The
IPsec security policies are in this alternative set up in a normal
manner, by the user's manual configuration (the automatic procedures
for creating SPD entries outlined in section 5.2 do not apply).
An example of a configuration is presented below. In this example BU
protection is on everywhere, and all traffic to and from network
"neta" shall be protected with IPsec:
MIP configuration:
- BU security: on for *
IPsec SPD configuration:
1. neta to here => use IPsec/IKE
2. here to neta => use IPsec/IKE
3. * => pass
As the BUs are kept in the Destination Option header, no next protocol
numbers are consumed by this mechanism, but an option number is con-
sumed.
It is possible to piggyback the BUs on regular TCP or other payload
traffic, and there are no effects to upper layers. However, the IPsec
policies can't be expressed in enough detail to protect just the BUs.
This solution allows the granularity of the weak BU protection and the
strong protection to be different. That is, it isn't necessary to
protect solely the BU packets. Typically, an organization that has a
PKI and likes to protect their BU traffic would typically run strong
security on all of their traffic (possibly excluding some flows, such
as those to port 80). This means that while BU protection is applied
J. Arkko Expires April 2002 [Page 10]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
only packets that contain the BUs, IPsec would typically be applied on
all traffic. IKE or other IPsec authentication protocols would be run
in order to create SAs upon the first contact of two peers, and all
traffic - including weakly protected BUs - would run inside the IPsec
tunnels between the peers.
7. Piggybacking Binding Updates
The Binging Updates are currently specified to be sent within the IPv6
Destination Options. As has been described above, there are some limi-
tations on how IPsec policies can be used to protect such options.
There has been a discussion in the Working Group about the possibili-
ties to rethink the position of the Binding Updates in the packets.
Placed in its own separate packet, the protection of the Binding
Updates would be easier with IPsec. However, in doing so we lose the
ability to piggyback Binding Updates on payload packets, which may be
an important function in reducing packet counts, contention for the
physical medium, and so on. Also, if not allowed from the beginning it
may be hard to add the piggybacking functionality later. Yet piggy-
backing causes also problems, and could be seen as extra complexity.
In order to understand the consequences of removing piggybacking, this
chapter studies the consequences of either allowing or disallowing
piggybacking. The following aspects will be studied:
- Effects to the use of IPsec in the context of Binding Updates.
- Effects to the use of IPsec of other traffic.
- Effects to the amount of bandwidth consumed.
- Effects to header compression on low-bandwidth links.
- Effects to QoS mechanisms.
7.1. Implications to Protecting BUs with IPsec
The use of piggybacking precludes the use of IPsec with current stan-
dards, as the granularity of the policy mechanisms does not allow sep-
arating packets that have important options.
As described in section 5.3, it is possible extend these mechanisms.
(Implementors have also reported on the mailing list [19, 20] that
they have made local (not visible on the wire) modifications to their
implementations to allow piggybacking with IPsec. This is however pos-
sible only if you have access to the IPsec implementation.)
7.2. Implications to IPsec Protection of Other Traffic
Note that the effects of piggybacking are more related to the trans-
port of two different items within one packet, than to the storage of
one item within the options header. The current policy mechanisms are
unable to handle multiple items with potentially differing security
needs. Therefore, substituting options for a new intermediate header
J. Arkko Expires April 2002 [Page 11]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
type doesn't by itself solve the policy problem. If piggybacking is
needed, then policy conditions relating both to BUs and the payload
traffic will be necessary, allowing users to dictate how the various
combinations of these will be protected. If piggybacking isn't
needed, a slightly simpler policy mechanism suffices, as it would only
be necessary to match individual messages, not combinations of BUs and
other traffic. (Current IPsec policy mechanisms would suffice if a
separate protocol number (or port) was used for BUs; IPsec extensions
would be needed if they still were contained in the Destination
Options.)
Does piggybacking have other effects to protecting the payload traf-
fic, assuming either application layer protection or enhanced IPsec
policy processing handles the BU protection? The enhanced policy pro-
cessing certainly allows the users to pick their own security poli-
cies. However, it is still possible that fundamental conflicts occur
in how the user wants the traffic to be protected. For instance, in
order to protect the BU part, AH would be needed but the payload traf-
fic could need confidentiality protection through ESP. It appears that
these conflicts can be handled by providing both AH and ESP protec-
tion, as allowed by the current specifications [11].
Finally, it has also been suggested [9] that the use of piggybacking
could be selected by the sender of the BU, based on the existing secu-
rity policies. The sending node would select piggybacking only if no
security headers are needed. Another idea taking this a bit further is
that the the piggybacking could only be allowed if the security policy
towards the other node requires all protocols to use the same SA [3].
7.3. Bandwidth Implications
The number of BUs sent by a MN varies, and in case it talks with sev-
eral CNs, each movement may generate similarly several BUs. In this
sense the amount of space consumed by the BUs does matter.
Sending the BUs as separate packets causes an immediate need to send
an extra packet which implies a certain number of extra transferred
bits. On LAN networks the effect of this is an extra 40 byte IPv6
header. This is probably not noticeable, unless a central server keeps
a very large number of binding cache entries. In order for the extra
overhead to reach a substantial fraction of the traffic of a central
server, the server must receive much binding update traffic compared
to the amount of traffic resulting from its transactions. For
instance, consider a server that on average receives a BU on every
tenth request and has request size of 100 and response size of 200
bytes. The overhead cause by extra BU messages for this server would
be ((40+40)/10) / (100+300) = 2.7%.
However, the most pressing issues in bandwidth conservation are proba-
bly not in larger servers or LAN traffic but in hosts operating behind
cellular or other highly constrained interfaces. There, an additional
40 bytes is a significant cost even if not sent often. But the esti-
mation of the difference between piggybacked and separated packet is
harder since on these interfaces advanced header compression
J. Arkko Expires April 2002 [Page 12]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
mechanisms and other techniques are typically used. As an example, we
have considered the ROHC header compression schemes [12]. Its adop-
tion in various cellular standards as a compression mechanism justi-
fies its use as an example.
The techniques in ROHC allow collapsing the IP and transport layer
headers when they don't change or change predictably between packets.
Interestingly, ROHC is capable of dealing with options as a difference
that can be sent without requiring the full IPv6 header to be
repeated. This means that when ROHC is used, piggybacked BUs only
cause extra bandwidth usage that is close to proportional of the size
of the BU headers.
When a separate packet is sent with a new protocol number, the first
time ROHC needs to send a full IPv6 header as well as the BU itself.
Subsequent Binding Updates can be compressed, and the payload stream
continues to be compressed independently of the new BU stream. There-
fore, in the case of ROHC, piggybacking is in the long run roughly
equivalent to the non-piggybacked case. There is a difference for the
first packet, of roughly 40 bytes.
At present, ROHC has special support for RTP, UDP, and some of the
basic IPv6 extension headers. It compresses other extension headers in
a generic way. ROHC will be able to compress the BUs partially or
completely away regardless of whether they are in a separate header or
inside the Destination Options [21].
While not directly relevant for the piggybacking discussion, we should
note that ROHC supports both AH and ESP [12, section 5.8]. Small
changes in these and other IPv6 extension headers can be sent as dif-
ferences.
The DOCSIS PHS is another example of a compression mechanism. It uses
bit masks to signal identical fields, and would appear to be able to
work well both with at least non-piggybacked traffic, provided that
separate contexts again would be held for BUs and other streams.
DOCSIS also allowed more than one frame to be sent on a single trans-
mission opportunity. This allows non-piggybacked traffic to use the
same opportunity, not changing the number of sent bits but reducing
delay even if the BUs are sent separately.
The use of header compression for Binding Updates is also affected by
movements. Unless there is a context transfer between base stations,
compression state of the BU sender is lost in any case at the time the
BU is sent. BU receivers will still be able to use compression, how-
ever.
7.4. QoS Implications
When Mobile IP signaling and payload traffic are combined in the same
packets Quality-of-Service (QoS) conflicts may occur, as the user may
have wanted to assign different priorities to them. The relevance of
this can be questioned, as the growth of the packets is only marginal
J. Arkko Expires April 2002 [Page 13]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
and the packet could reasonably be expected to be tagged with the flow
label of the payload regardless of the additional options. Also, the
sender has the possibility to send packets separately if the QoS poli-
cies are in conflict. However, such separation is only possible for
the sender and not for any of the routers in between. (The routers are
in some architectures responsible for the QoS tasks.)
A more serious QoS problem appears in cellular networks where specific
channels have been allocated for the host to send and receive e.g.
multimedia streams. Any TDM-like slot allocation scheme may need such
QoS reservations. Such channels have been calculated to be able to
carry exactly the stream (even taking in account ROHC and other header
compression techniques) but nothing else. An additional signaling pay-
load appended to the stream would essentially force the packet to be
dropped, or routed through best effort channels. In the case of con-
versational services, the latter alternative would also in practice
mean losing the whole packet, because it would be unlikely to arrive
in time to be useful.
As far as an individual cellular terminal is concerned, it can make
smart decisions about when to piggyback and when to not. However, this
option does not necessarily exist for the other end of the communica-
tions; a MN carelessly sending a piggybacked BU along a stream to its
correspondent cellular host might cause the BU information and a frac-
tion of the stream to be lost.
Specifically reserved tight channels are a fact of life. However, it
is perhaps fair to note that making IP run inside them is already dif-
ficult even without piggybacked BUs. Header and other compression
mechanisms produce variable length results, and the in the case of
Mobile IP the channel reservation may have to take in account not just
the BUs, but also other options. What is different, however, in the
case of BUs is first of all their size - at least two dozen bytes -
which may make it hard for them to fit the slack, and it is undesir-
able to reserve so much extra space. Secondly, BUs are dynamically
changing while e.g. Home Address options are other similar headers are
static. Static headers in general are always compressed away, and in
any case predicting their size is easier.
Piggybacking may also interact with resource reservations at the IP
layer, such as those performed by RSVP.
7.5. Other Implications
It has been said that piggybacking is used today also as a facility to
send the BUs at an appropriate time, conveniently along other traffic.
The intent is to not send binding updates until it is proven that fur-
ther traffic to the Correspondent Node exist. On the other hand, it
appears that this convenient mechanism can't be used all of the time,
given that it only works in one direction, and does not allow for
optimized routing of packets sent by the CN. For this reason typical
implementations wait a while and send the BU in any case if no other
traffic has appeared [19].
J. Arkko Expires April 2002 [Page 14]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
We also note that in both piggybacked and separate packet solutions we
can achieve the same goals. A BU should be sent at a suitable time,
specified in the standards or left to the optimization logic of vari-
ous implementations. With piggybacking, a BU can be attached to the
packet that is destined to the CN. Without piggybacking, the appear-
ance of a packet destined to the CN would trigger the sending of
another packet along it. Similar functionality exists today on all
IPv6 stacks to send address resolution messages and other control
traffic, so it seems that it on most stacks it should be possible to
generate new packets based upon seeing traffic to a particular desti-
nation.
One difference between the piggybacked and the separate packet solu-
tions is that in the latter we can not guarantee that the BU arrives
at the CN before the payload packet. The BUs are used in the route
optimization functionality - which is optional - and decided on a
case-by-case anyway by implementations. Therefore, the payload traffic
will get to the other end and back regardless of the BUs. If the sep-
arate BUs are delayed behind the payload packets, it is possible that
the payload response comes through an unoptimized route. However, let
us assume that the first two packets along a router are going to be
reordered. In the piggybacked solution this means that the regular
packet gets to the destination first, following the packet that has
the piggybacked BU. In this situation one packet needs to be routed
through the home. In the non-piggybacked solution the BU and the first
payload packet get reordered, and again one the result is that one
packet needs to be routed through the home.
As has been discussed earlier, it is also possible that the addition
of the BUs may cause the packets to be routed differently, and may
already imply delayed reception. On the other the BU packets - small
packets - may easily get different treatment than the regular packets,
making it slightly more likely that a reordering will occur. In con-
clusion, there does not seem to be a fundamental difference in this
regard.
Firewalls and other similar devices should be able to process piggy-
backed packets, even if they have BU options in them. If they do not
let such traffic through they will also not let regular Mobile IP Home
Address options through, blocking all traffic. If the BUs are sent in
separate packets, the firewalls have to have rules to allow this traf-
fic in.
A similar situation to the BU problem appears in the case of RSVP and
the Router Alert options [17]. In this case IPsec was not used and the
option was kept as an option.
7.6. Other Solutions to the Piggybacking Problem
It has also been suggested that a more general purpose multi-payload
IPv6 mechanism could be developed [13]. This would allow adding piggy-
backing later in as an option, and could tackle the IPsec problems in
a general way and without delaying the Mobile IPv6 standardization.
J. Arkko Expires April 2002 [Page 15]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
One worry around this solution is that the Mobile IPv6 implementation
may not have enough capabilities to direct the merging of packets.
For instance, if the merging is implemented as a general IP layer
function, it is not guaranteed that BUs get merged unless two packets
are actually seen simultaneously. As the first packet may already be
partially out from an interface, it is not clear that the function
will see these packets early enough. However, it appears that this
problem can be solved by having the Mobile IP code perform the merging
when it detects a need to send a BU.
A more serious problem in this solution comes from the partial deploy-
ment, which obviously can't be avoided as such multi-payload schemes
are not a part of current IPv6. How does a node know when the receiver
supports this feature and when not? It may be possible to use
responses, errors, or the lack of these as an indication of the
receiver's support. However, it is not clear what kind of implications
this has for the additional messaging, start-up times, and so on.
8. Comparison of Solutions
The following criteria are used in evaluating the pros and cons of the
presented solutions:
- Requirements fulfillment. For instance, do the solutions allow both
weak and strong authentication?
- The header overhead of the solution, and the number of extra packets
required.
- The computational overhead of the solution. (Note that public key
cryptography, Diffie-Hellman, and other overhead related to authenti-
cation is not under discussion here. It is assumed that the user orga-
nizations select between the heavier strong authentication protocols
and the lighter weak authentication protocols. The comparison of par-
ticular authentication protocols such as BAKE [6], SUCV [7] and others
[18] also isn't the subject of this memo.)
- The memory and state requirements of the solution.
- The necessity to allocate Destination Option or Next Header numbers
from IANA.
- The required standardization work.
- Are the mechanisms future proof, as the current strong authentica-
tion protocols evolve to new ones (which is expected to happen with
the Son-of-IKE effort).
- Ability to handle error situations.
- Ability to optimize behaviour for busy servers.
- Ability to ensure that the right BSAs are used for the right BUs.
J. Arkko Expires April 2002 [Page 16]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
- Implementation aspects.
8.1. Requirements Fulfillment
Like the other alternatives, the application specific solution ful-
fills the requirements for integrity protection and replay protection,
the former through the -14 mechanisms and the latter through the BU
replay counters.
This alternative also allows the use of a new weak authentication pro-
tocol, or a new protocol capable of both weak and strong authentica-
tion. The use of an existing strong authentication protocol isn't
directly possible, an enhancement of both the protocol standards and
the implementation would be necessary. The enhancement necessary for
e.g. IKE [4] would involve adding a new protocol along the side of AH
and ESP with possible other parameters such as algorithm identi-
fiers. This would be an extension of the current IPsec DoI [5].
The -14 mechanisms can satisfy the requirement to be able to use dif-
ferent algorithms. However, at the moment [1] does not define even a
single algorithm, let alone alternatives.
The IPsec based alternatives fulfill the requirements for integrity
protection and replay protection, both through AH mechanisms. Note
that an additional layer of replay protection exists at the BU mes-
sages. It isn't possible to remove the fields related to this, as
IPsec provides only replay protection but not sequenced delivery. For
the Mobile IP route optimization to work, sequenced delivery is also
needed.
Existing IPsec AH can use both weak and strong authentication proto-
cols. There is no need to modify the strong authentication protocols,
or the IPsec stack in order to make this possible. However, a local
API must exist between the new weak authentication protocol and the
IPsec implementation in order to set up suitable policy entries and
SAs.
IPsec AH with extended policy rules allows the use of a new weak
authentication protocol, or a new protocol capable of both weak and
strong authentication. The use of an existing strong authentication
protocol isn't directly possible, an enhancement of both the protocol
standards and the implementation would be necessary. The use of a new
weak authentication protocol and an enhancement of an existing strong
authentication protocol. The enhancement necessary for e.g. IKE [4]
would involve an extension of the client identifiers to support the
extended policies capable of differentiating IPv6 Destination Options.
It is not possible to use existing strong authentication protocols
unchanged in this solution.
All IPsec AH based solutions satisfy the requirement on being able to
use different algorithms. A set of standard, mandatory algorithms
exists, as well as many optional ones.
J. Arkko Expires April 2002 [Page 17]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
The use of both application specific and IPsec mechanisms fulfills the
requirements for integrity protection and replay protection.
Various combinations of authentication protocols could be used in this
alternative, but one particular combination seems most suited. Namely,
a new weak authentication protocol could be used to key exclusively
the application specific protection of BUs, and an optional strong
authentication protocol would build SAs that use IPsec around them.
8.2. Header Overhead
In the application specific solution, the integrity protection related
parts in the BUs contain the authentication data length, SPI, and
authentication data fields. The length of the last field is not
given, but assuming a typical 96 bit field is used, the total overhead
from this is 17 bytes.
IPsec AH-based solutions add the SPI, sequence number, next protocol,
and MAC fields. The total number of additional bytes is 24.
For the combined use of both application specific and AH mechanisms
there is a fixed cost of 17 bytes in all BU messages. An additional
cost of 24 bytes is applied to those messages that use also the
IPsec/IKE-based security. Therefore, a total of 41 bytes overhead may
be reached in the worst case.
The number of packets in the application specific, extended IPsec, and
combined alternatives are the same as piggybacking can be employed. In
the use of existing IPsec AH there are N additional packets, where N
is the number of BUs and their acknowledgements sent.
8.3. Computational Overhead
The application specific scheme runs a cryptographic hash over speci-
fied fields, typically 62 bytes assuming there are no BU suboptions.
The nature of the cryptographic hash hasn't been specified, but we can
safely assume it is similar to mechanisms used elsewhere such as HMAC
MD5.
The number of bytes used in the input to the hash function has signif-
icance, though the hash functions typically have some amount of static
cost so that the computational overhead is not linear with respect to
the number of input bytes. In one implementation of HMAC MD5, a four-
fold increase in the size of the packet increased the amount of time
spent by 33%.
The same implementation achieved speeds of around 60 Mbit/s, or
100,000 MACs/s for an input of size 62 bytes, on a Pentium 600 MHz
machine. Increasing the size fourfold changed these numbers to 170
Mbit/s and 75,000 MACs/s. Similar numbers are also available for other
implementations [14]. These numbers indicate that a relatively large
number of BUs can be treated with typical computer systems; likely far
more than is required for anything else except the busiest servers. On
a smaller devices such as handheld cellular devices, the available
J. Arkko Expires April 2002 [Page 18]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
power is much smaller but so is also the number of BUs that need to be
treated; it is hard to imagine why a device with a constrained inter-
face towards the Internet would have to process even 1 BU/s.
IPsec uses also standard cryptographic hash functions, which we
assumed would also be used in the application specific protection. In
contrast to the BU suboption, however, the hash is run over the whole
packet. Assuming the size of a BU protocol running directly on top of
IP would be roughly the same as in a BU option, the total number of
input bytes would be 40 from the IPv6 header, 18 from the Home Address
option, 24 from AH, plus 10 from the BU protocol, i.e. 92.
These numbers imply that the pure cryptographic operations necessary
in this alternative are roughly equivalent to those needed for BU pro-
tection in the application specific manner. In addition there are
IPsec-related tasks such as policy matching and header processing
which are harder to quantify. Implementations also differ much in this
respect, as some may be using sequential searches and others trees.
One good software-based IPsec implementation reports the speed of 65
Mbit/s with AH HMAC_MD5 in transport mode, on a Pentium 800 Mhz
machine, and 82 MBit/s when policies were being checked but none of
the packets needed security. The unsecured IP performance was 85
Mbit/s [14] on the same machine.
In any case, these numbers again indicate sufficient capacity to deal
with BUs under most normal circumstances, possibly with the exception
of the busiest servers. A crucial factor is the amount of BU traffic
vs. other traffic. Let us assume 10 KB regular traffic interrupted by
a 0.1 KB BU, and a system that would handle 10 Mbit/s BUs. Even if the
reference used above didn't describe the packet sizes used in the
test, it seems safe to assume that a single CPU would be able to han-
dle this load. But under these assumptions, the system would also be
handling 1 GBit/s other traffic. If there's only 1 KB (one large
packet) of traffic between the BUs, then this number would be 100
MBit/s.
The computational overhead for extended IPsec is similar to that of
existing IPsec, except that now also the payload contents may be
included in the hash calculations. Assuming the average original
packet size of, say, 300 bytes, this makes the real packet size with
all options and AH to be 352. This is also the input to the hash func-
tion.
Given our earlier measurement data, it doesn't seem that the size of
the packets matters as much as might be expected. Some increase in CPU
demands will be seen, however.
In the combined use of application specific and IPsec solutions, the
computational overhead at the minimum is the same as in the applica-
tion specific protection, i.e. running a hash over 62 bytes. In case
IPsec/IKE-based security is used in addition, then an additional sec-
ond hash needs to be calculated. Assuming again the 300 byte average
original packet size, this amounts to running a hash over 369 bytes.
J. Arkko Expires April 2002 [Page 19]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
Again, the size of the input to the hash operations does not seem to
have significant importance. However, the number of operations is
important and in this situation there are two. The two hashes are cal-
culated, however, only within the protected network communications.
8.4. Memory and State Requirements
In the application specific solution, a security association data
structure is needed for every BSA established to protect the BUs. The
current assumption is that the BSAs are unidirectional, but unlike the
IPsec solution they could also be bidirectional and thereby halving
the memory requirements. Note that there may in any case be multiple
concurrent BSAs per each MN in order to allow for smooth rekeying.
Each BSA must contain information about the used integrity key (typi-
cally at least 20 bytes), the SPI (4 bytes), lifetime (4 bytes), algo-
rithm (under 1 byte) and an implementation dependent amount of admin-
istrative information, such as pointers to Binding Cache entries,
statistics, and other relevant information.
Security association data structures are needed also for the IPsec
SAs. IPsec SAs are a bit more general-purpose than application spe-
cific SAs, including for instance encryption keys, selectors, lifetime
and statistics information, and other similar data. Typical implemen-
tations use memory in the order of, say, 400 bytes for each SA. An
implementation optimized for memory usage could cut this down to
around 170 bytes, most of which is spent on the IPv6 addresses needed
for the destination and selector addresses.
In addition to the SA information, the IPsec implementations (may)
need to add policy entries related to each specific host. These need
both memory, and execution time for each packet. Typical implementa-
tions would perhaps use a similar amount of space for a policy entry
as they do for an SA. On a MIP-specific solution, we didn't need this
as the policy is hardcoded to the processing of the BUs.
There isn't much information available on how large number of SAs and
policy entries typical implementations support. Special hardware
devices can support tens of thousands of simultaneous connections
[15]. A central question is the support for a large number of SAs in
typical server OS implementations. Smart implementations can provide
logarithmic-time processing of security rules and SA databases [16],
but some implementations may be built more around VPN access scenarios
(small number of SAs) rather than end-to-end security towards multiple
directions.
There may be optimizations available for devices that do not want to
support IPsec in general and only want to support it for BU protec-
tion. In this case it is possible to eliminate execution time overhead
for other packets, and to use the Binding Cache entries and BSAs as
the sole packet matching mechanism.
The memory and state requirements for combined application specific
and IPsec alternative is (roughly) a sum of the requirements for the
two mechanisms.
J. Arkko Expires April 2002 [Page 20]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
8.5. IANA Requirements
The application specific solution requires a Destination Option number
to be allocated for the BUs.
The existing IPsec AH solution requires a new IPv6 next header value -
a more valuable resource - to be allocated.
With an extension to the IPsec policies, only the Destination Option
value needs to be allocated.
In the combined use of IPsec and the application specific mechanism
the situation is the same, and only the Destination Option value needs
to be allocated.
8.6. Standardization Work
No standardization work outside the Mobile IP WG is needed for the
application specific solution. However, if an existing strong authen-
tication protocol needs to be used also, then it needs to be extended.
This likely needs IPsec WG involvement. Of course, strong authentica-
tion could also be built in to the Mobile IP specific protocols.
In the use of existing IPsec, no standardization work outside the
Mobile IP WG is needed. Even if strong authentication protocols need
to be used, they can be used as is.
The extension of IPsec to cover individual Destination Options would
need an action from the IPsec WG for a small extension to both IPsec
and its key management mechanisms.
The combined use of application specific solution and IPsec requires
no standardization actions, even if strong authentication is needed.
All solutions relying on IPsec AH may suffer from the possible action
in the IPsec WG to deprecate AH. This has been discussed from time to
time, mainly under the argument of reducing the complexity of IPsec.
If this happens it may be possible use ESP instead of AH [3].
8.7. Evolution of Authentication Protocols
Here we discuss the effects of evolving authentication protocols.
Such evolution takes place on two fronts. First, as the weak authenti-
cation area is a new one, we can expect new and better protocols to
appear for this purpose. Secondly, also the current strong authentica-
tion protocols and IPsec are under evolution, such as the work on Son-
of-IKE which has been prompted by the complexity of IKE.
The application specific solution can - if designed right - accommo-
date new weak authentication protocols easily. It is necessary to pro-
vide a clean separation between the BU protection and the authentica-
tion protocol, but this should be easy.
J. Arkko Expires April 2002 [Page 21]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
The application specific solution can also accommodate existing strong
authentication, provided that they are extended to support the BU pro-
tection protocols. The ability of this solution to follow the evolu-
tion of such strong authentication protocols depends heavily on the
interest of their developers to retain non-IPsec support in the proto-
col if it is extended, simplified, or redesigned. It is therefore not
fully certain that new protocols also allow the same thing.
The use of existing IPsec is more certain to be possible even if the
keying protocols evolve. If IPsec is extended to cover also individual
Destination Options, new keying protocols should also be able to do
this. Unless there is a desire to simplify things, but one could
expect that such simplification could be foreseen as the extension
itself is discussed.
The combined use of application specific protection and IPsec allows
evolution both in the weak and in the strong authentication protocols.
8.8. Error Situations
Application layer mechanisms in general have more context information
available regarding various error situations than IP layer solutions.
IPsec discards packets if they are in any way unexpected. The question
regarding BU protection is if there are any situations where other
treatment of BU protection error cases is needed than discarding.
For instance, if the last message of an authentication protocol would
happen to arrive after the first protected BU has been sent, IPsec
would simply discard the packet while an application specific mecha-
nism might store it in the anticipation of completing the authentica-
tion soon. It isn't clear how important this case is, however. There
might also be some DoS implications on doing this.
Another problem appears with weak authentication protocols that piggy-
back the authentication / key agreement messages in the final BU that
is sent from the MN to the CN. Here, the BSA should exist as the
packet is being processed, but the BSA will actually be created only
after looking a the authentication option in the packet. For the
application specific security, it is easier to e.g. process BU subop-
tions in a specific order, but for IPsec AH the processing happens at
a predefined order. Some weak authentication schemes such as [6] do
not have a problem with this, because they have specified an ordering
that allows the BSA establishment to take place before the BSA is cre-
ated. Some others such as [18] make use of BU suboptions, making it
harder to create an IPsec SA at the same time the option itself is
being processed. The practical effects of this issue is that the use
of IPsec forces either a separated authentication packet, or an order-
ing of the Destination Option and AH headers.
8.9. Optimizations for Busy Servers
It is possible that on some busy servers the computation or memory
loads exceed the capabilities of the hardware. It is possible though
for server manufacturers to add a feature that enables the device to
J. Arkko Expires April 2002 [Page 22]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
age BUs faster and/or refuse weak authentication and optimized routing
if the load grows too high.
The optimizations for IPsec are similar to those for application spe-
cific protection of BUs. The main optimization is reducing the number
of BSAs, and the use of optimized routing.
In the combined alternative, similar optimizations exist for the
application specific protection as has been described earlier. For the
additional IPsec protection, there aren't such possibilities. The
security policies require the use of IPsec for the traffic within the
part of the network that is expected to be protected.
8.10. Address Ownership
In all alternatives, it is assumed that the authentication protocol
somehow determines the right of a particular peer to claim ownership
of a particular address. For instance, BAKE relies on the difficulty
of an eavesdropper to simultaneously see messages along different
paths to prove a weak form of address ownership [6]. An BSA is estab-
lished after the determination is made.
This is, however, not enough. It is also necessary to ensure that sub-
sequent communications do not violate the address ownership. For
instance, a MN might establish a legitimate BSA with a CN, and then
use this BSA to send a binding update for another MN.
In the application specific solution, it is necessary to ensure that
the BSA is used only with respect to the same Home Address that was
used also for the authentication part. Currently, this hasn't been
specified in the draft, but could easily be added.
In the case of IPsec, the dynamic updates to the SPD and/or the selec-
tors in the SAD must be used to create the same effect. The individ-
ual policy entries, or the selectors of each SA would be set to the
particular addresses used in the communications. Note that like all
other IP and higher layer processing, IPsec policy matching is per-
formed on the used home addresses rather than Care-of-Addresses. This
means that the given SA can only be used with the original Home
Address.
In the case of combined use of application specific and IPsec mecha-
nisms, both solutions presented above are used together.
8.11. Implementation Aspects
The application specific solution can be programmed in isolation from
the rest of the IPv6 stack. No new APIs are needed for the security
part. Security association lookup can be performed using the same data
structures that are used for finding Binding Cache entries. (We do
need to allow for multiple BSAs towards the same peer, but given that
they would typically be just 1 or 2 it doesn't appear to require a
very optimized search tree.)
J. Arkko Expires April 2002 [Page 23]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
On the busiest servers, it might be necessary to provide some hard-
ware-level acceleration mechanisms. Some existing hardware chips
could be used for this purpose, though some other chips are more tai-
lored towards specific IPsec processing, and are not applicable.
If IPsec is used, then an API is needed towards the SPD and/or the
SAD, so that the Mobile IPv6 implementation can add/delete entries
from them.
It is also necessary to ensure that the IPsec implementation is capa-
ble of handling large amounts of SPD and SAD entries efficiently, if
the stack is going to be used in servers that have many clients. This
may mean improving the SPD matching mechanisms and/or SAD lookup. In
the case of normal IPsec processing, there doesn't exist a similar
Binding Cache entry that was used in an optimized lookup in the appli-
cation specific solution. (However, there may be possibilities to
optimize this even for IPSec when just BU protection but not general
IPsec functionality is needed, as discussed in section 8.4.)
IPsec implementations may take advantage of existing hardware chips,
and their use in current and future products.
IPsec implementations in general are more complex than providing just
the -14 mechanisms.
9. Conclusions
The purpose of this memo is to mainly list the solutions and their
respective advantages and disadvantages. We do not make a recommenda-
tion here to select a particular solution as some of the pros and cons
are not easy to weight against each other. We hope, however, that
this memo helps the Mobile IP Working Group to see the complete situa-
tion, and reach a consensus on how the solutions weigh against each
other.
However, the author would like to offer a few observations:
- It is crucial for the selection that we decide what the minimum
level of security offered will be. If the WG wants to have security
where keying material is not created at all, it appears that only
application specific solutions are possible (possibly combined with
IPsec). Note that the keying material generation in e.g. BAKE is
intended to be an optimization, caching the knowledge that a certain
type of return routability was verified. Without the keying material,
a BAKE-like check needs to be performed for all BUs.
- Another crucial decision is the 'philosophical approach' we want to
take. The approaches are discussed in the beginning of chapter 6.
- In header overhead, the application specific solution is the small-
est one, though the difference is not big (17 versus 24 bytes). If
both application specific and IPsec mechanisms are used, the overhead
is large but only when strong authentication is also applied.
J. Arkko Expires April 2002 [Page 24]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
- Preliminary results regarding the effects of piggybacking indicate
that typical header compression mechanisms result in similar bandwidth
usage for both piggybacked and non-piggybacked cases. Essentially, the
changing components of packets need to be sent. However, these results
depend a lot on the particular situation, compression end-point loca-
tion, and so on. Also, the effect for stationary BU receivers is dif-
ferent than for BU senders that may have to start with a new compres-
sion context after movements. It should be noted that there are com-
plexity, QoS channel reservation, and other issues with piggybacking
so it is not clear that it is always desireable.
- In particular, piggybacking makes cellular network channel reserva-
tions hard and/or inefficient. Such reservations are necessary on some
networks, and it is not possible to reserve space for occasional
Mobile IP signaling in them.
- Strong authentication should be allowed as an option for certain
organizations. In those organizations, there is likely a need for
securing other traffic as well, and it might be wise to consider not
duplicating the configuration effort etc. for Mobile IP and other
applications.
- Adding strong authentication support to protocols such as BAKE may
not be easy. Relatively complex PKI protocols have to be managed, some
organizations would prefer legacy authentication schemes which would
make even the PKI approach insufficient, etc.
- IPsec allows easier evolution in the authentication protocols. For
instance, organizations that require strong authentication could use
legacy as well as PKI-based authentication through IPSRA solutions.
The modification of e.g. IKE to support also the application specific
protection is not a recommended approach.
- It is possible to use IPsec for BU protection without modifications
to the IPsec standards. However, Mobile IPv6 will have to be changed
to use a separate protocol number for the BUs and not allow piggyback-
ing. In this alternative, a new IPv6 protocol number (or UDP port)
would have to be allocated, which can be considered a more valuable
resource than the current Destination Option values.
- It is also possible to extend IPsec policy mechanisms and then keep
Mobile IPv6 unchanged. However, while the modifications are small
there are currently a number of other things on the table in the IPsec
WG, and therefore making these extensions might cause a delay.
- There doesn't seem to be a huge performance difference among the
solutions in the sense of cryptographic computations. Possible perfor-
mance differences can be found in the policy matching area, where
IPsec needs to do work that is more straightforward in the application
specific solution (though it still needs to be done). It is hard to
quantify these, however, as the implementations differ in how effi-
ciently they have solved the issue. This is relevant mainly for very
large servers with large Binding Caches.
J. Arkko Expires April 2002 [Page 25]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
- Optimizations for busy servers are possible in all presented alter-
natives. IPsec demands more memory per BSA, though.
- Address ownership issues can be solved all of the presented alterna-
tives.
- IPsec is more complex to implement than the pure application spe-
cific solution. On the other hand, one can take advantage of existing
hardware and software support on a number of products. This situation
may continue in the future as well, as BU protection may not be in
sufficiently high demand to force server vendors to have hardware sup-
port for it.
- In complexity, the main focus should be paid to the key management
parts rather than the IPsec or -14 parts, because that's where most
complexity lies. An added complexity in the BU protection part may be
justifiable if a larger complexity reduction can be achieved then on
the key management part.
10. Further Work
The author seeks feedback from the Mobile IP and security communities
to verify that the presented solutions are complete, secure, and can
be implemented.
This memo discusses only the BU protection issue and leaves the weak
authentication mechanisms to be discussed by other work. Likewise, we
take no stand in the selection or future development of strong authen-
tication mechanisms such as IKE, Son-of-IKE, KINK, and others.
The security between the Home Agent and the Mobile Node isn't covered
in this memo, even if it also involves the use of Binding Updates. It
is likely that strong security could be applied in this context, given
that there the home and the mobile have a pre-arranged relationship.
The current version of this memo discusses only the use of IPSec AH.
It may be possible to use also ESP as is discussed in [3]. This might
become necessary if we get an indication that the AH protocol would be
deprecated (which is periodically discussed by the IPSec WG).
Hiding the home address of mobile nodes hasn't been considered as a
requirement for this work. There might be some possibilities for doing
this through the placement of the BUs after an ESP header. However,
this would need to be done for all traffic and not just the BUs. Also,
what has been stated in this document about the policy rules and
selectors that match the home address would no longer hold.
Michael Thomas has suggested that existing strong authentication pro-
tocols such as IKE could be used as-is even for the weak authentica-
tion, by employing self-signed certificates. The main drawback of
using exclusively these protocols for this purpose is that too many
roundtrips would be required.
J. Arkko Expires April 2002 [Page 26]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
11. Acknowledgements
The author would like to thank Charlie Perkins, Michael Thomas, Pekka
Nikander, Phil Roberts, Thomas Narten, Hesham Soliman, Glenn Morrow,
Lars-Erik Jonsson, Erik Nordmark, and members of the Mobile IP mailing
list for extensive discussions about the issues on the mailing list.
Credit for all solutions and their respective pros and cons is fully
due to the participants in these discussions.
12. References
[1] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-
mobileip-ipv6-14.txt. Work In Progress, IETF, July 2001.
[2] P. Nikander, D. Harkins, B. Patil, P. Roberts, E. Nordmark, T.
Narten, A. Mankin, "Threat Models introduced by Mobile IPv6 and
Requirements for Security in Mobile IPv6", draft-team-mobileip-
mipv6-sec-reqts-00.txt. Work In Progress, IETF, July 2001.
[3] M. Thomas, "ESP Protected Binding Updates", draft-thomas-mobileip-
esp-bu-00.txt (unpublished). July, 2001.
[4] D. Harkins and D. Carrel, "The Internet Key Exchange", RFC 2409,
November 1998.
[5] D. Piper, "The Internet IP Security Domain of Interpretation for
ISAKMP", RFC 2407, November 1998.
[6] P. Nikander, C. Perkins, "Binding Authentication Key Establishment
Protocol for Mobile IPv6", draft-perkins-bake-01.txt. Work In
Progress, IETF, July 2001.
[7] G. Montenegro, C. Castelluccia, "SUCV Identifiers and Addresses",
draft-montenegro-sucv-01.txt. Work In Progress, IETF, July 2001.
[8] M. Thomas, D. Oran, "Home Agent Cookies for Binding Updates",
draft-thomas-mobileip-ha-cookies-00.txt. Work In Progress, IETF, July
2001.
[9] J. Rajahalme, on the Mobile IP mailing list, August 21st, 2001.
[10] P. Nikander, "An Address Ownership Problem in IPv6", draft-nikan-
der-ipng-address-ownership-00.txt. Work In Progress, IETF, February
2001.
[11] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol" RFC 2401, BBN Corp, @Home Network, November 1998.
[12] C. Bormann et al, "RObust Header Compression (ROHC): Framework
and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, TZI/Uni
Bremen, Matsushita, Univ. of Arizona, Ericsson, Cisco, Nokia, NTT
DoCoMo, July 2001.
J. Arkko Expires April 2002 [Page 27]
INTERNET-DRAFT MIPv6 BUSec 10 October 2001
[13] R. Elz, "The IPv6 Payload Header", Work In Progress, IETF, April,
1996.
[14] SSH Communications Security, "SSH IPSEC Express Performance",
http://www.ssh.com/products/ipsec/performance.cfm.
[15] Netscreen, "Meeting the Security Needs of the Broadband Inter-
net", http://www.netscreen.com/products/ns1000_wpaper.html.
[16] SSH Communications Security, "SSH IPSEC Express Specifications",
http://www.ssh.com/products/ipsec/specs.cfm.
[17] D. Katz, "IP Router Alert Option". RFC 2113, February 1997.
[18] M. Roe, "Authentication of Mobile IPv6 Binding Updates and
Acknowledgments", draft-roe-mobileip-updateauth-00.txt. Work In
Progress, IETF, August 2001.
[19] R. Wakikawa, on the Mobile IP mailing list, October 4th, 2001.
[20] F. Dupont, on the Mobile IP mailing list, October 4th, 2001.
[21] Lars-Erik Jonsson, private communication, October 8th, 2001.
13. Author's Address
Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland
Phone: +358 40 5079256 (mobile)
+358 9 2992480 (office)
EMail: Jari.Arkko@ericsson.com
J. Arkko Expires April 2002 [Page 28]