As discussed at the mobile-ip WG meeting on Tuesday morning, in length
at the mobile-ip mailing list, and in some length at the this mailing
list, there has emerged a need to encode functional, security related
semantics into IP addresses. The purpose of this short note is to try
to describe the situation in general terms, thereby giving *background*
to the discussion on Thursday at the ipv6 WG meeting.
Note that the discussion on Thursday morning is about *reserving*
space in the interface ID for possible future extensions. This note
is about a possible *use* of part of that space. It makes sense
keeping the discussion of whether or not to reserve space separate
from the discussion about use.
The situation
=============
Consider two hosts, Alice and Bob, that do not know each other. For
some reason, Alice wants to contact Bob. Thus, she goes to DNS (or
whatever), learns Bob's address, and sends a packet (e.g. TCP SYN) to
Bob. Bob receives the packet and starts processing it.
Now, when Bob receives the packet sent by Alice, he has no other
knowledge about Alice but the packet itself. In particular, the only
information he has about Alice is the source IP address in the packet.
However, there seem to be situations (I'll return to them in a moment)
where he needs to learn a little bit more about Alice before he can
answer in a proper way. Clearly, Bob has a few options how he can
proceed and learn more about Alice:
a) He can go to DNS, do a reverse lookup, and hope to learn something
useful. However, this may be expensive in terms of time and
number of packets, causing packets sent to the DNS server that
serves the reverse map for Alice's address, and thereby somewhat
dangerous from the Denial-of-Service point of view. Additionally,
secure DNS is not widely deployed, and therefore he usually can't
fully trust the results. Anyhow, this is the method that most
hosts use today.
b) He can try to use some other infrastructure, such as AAA, and try
to get some information about Alice from there. However, this
method requires that Alice participates in the same
infrastructure, which, in general, is unlikely for a number of
years to come. Secondly, this method has the same drawbacks as
DNS lookups, generating delay and extra traffic.
c) He can send a probe to Alice, checking that there indeed is
somebody who answers in the said address. TCP SYN ACK is
basically such a probe, and so are the new Mobile IPv6 RR packets
(HoTI, CoTI, HoT, CoT). The drawback of this method is that
doesn't *prove* anything else but that Alice (or somebody
impersonating her) is really there (which is an important
property, but orthogonal to the other the other pieces of
information about Alice).
d) He can have a look at the address, and try to deduce something
from the address itself. Currently, he can learn whether Alice is
using a link local, site local or global address, whether Alice's
address is supposed to contain a globally unique interface ID,
etc.
Now, the whole need and idea is to extend d) so that Bob can learn
more about Alice by just looking at the address. This would be very
benefial for busy servers, and especially in situations where the
server may be facing a resource exhausting denial-of-service attack.
Note, however, that extending d) does not mean, in any way, that the
other options could not or should not be used in the future.
Security point of view
======================
Security is a very important issue here. Firstly, as will be
discussed below, there are situations where the method must be
resistant to resource consumption amplifying denial-of-service
attacks, basically ruling out DNS and AAA/other infra in those
situations. Secondly, there are situations where the information
about Alice must be reliable, i.e. authentic and integral. Secure DNS
and AAA could fulfil this latter need, but only at the expense of
added delay & traffic, and possible DoS/reflection, as noted above.
The need for reliable information is especially important for security
protocols. Here we come to the so called "bindding down" argument.
That is, let us assume that there exist some default security protocol
that all IPv6 hosts are assumed to support. Furthermore, let us
assume that there *does* exist some more secure protocols for the same
purpose, but some hosts do not support these more secure protocols,
for example, since the more secure protocols impose more computational
requirements or are otherwise more costly. In this situation the
hosts must be able to do a selection between the default, less secure
protocol and the more secure protocols. That is, if Bob supports both
the default protocol and (at least one) more secure protocol, he must
be able to determine if Alice supports the more secure protocol so
that he can take the more secure protocol into use. Furthermore, he
cannot ask Alice, since an attacker impersonating as Alice would lie,
and say that Alice supports only the default, less secure protocol.
In other words, there must be a method, independent on Alice's
actions, that securely gives Bob reliable information about the
protocols Alice supports. If such a method does not exist, and there
is an attacker that can break one of the protocols, the attacker can
claim that Alice supports only the protocol that it is able to break,
thereby making it impossible for Bob to use the other more secure
protocols.
This is the essense of the bidding down attack: an attacker that is
able to break one of a number of security protocols can impersonate
Alice to Bob unless Bob can learn, independent of Alice, what
protocols Alice supports.
See http://playground.sun.com/mobile-ip/WG-archive/frm05357.html
and http://www.piuha.net/~jarkko/publications/mipv6/Bidding_down.txt
for more details.
Note that with respect to the bidding down attack the discussing about
allowing Bob to determine, by looking at the address, whether Alice is
satisfied with the default protocol or not. That allows Bob to
continue quickly in the default case. What to do, in exact terms, in
the non-default case (other than not using the default protocol) is
beyond the scope of this note. Especially, we are *not* suggesting
that there should be additional bit(s) reserved for specific needs.
Specific needs
==============
Currently there seems to be only one situation where we want to
introduce a default, not-so-good-but-good-enough security protocol
that anybody can use, with the anticipation that in the future there
will be a number of better-and-more-secure variants. This is the
Mobile IPv6 situation, where Return Routability (RR) will be the
baseline security protocol. However, the situation is in no way
specific to Mobile IP. There will clearly be other needs too, e.g.,
secure multicast or anycast might have the same need.
In the case of Mobile IP, we definitely want to have a method where it
is possible to tell whether a given Mobile Node wants to use RR or
not. In this case, the most secure security protocol is to disallow
the function completely, i.e., say that Mobile IP Route Optimization
MUST NOT be used for this host. For example, stationary hosts most
probably want to forbid Mobile IP Route Optimization. However, if we
want universal deployment for Mobile IPv6, the default clearly cannot
be to disallow Mobile IP. Instead, the default case clearly needs to
be the lowest common denominator, Return Routability (RR), and it is
up to each host to separately indicate when it wants to use some more
secure protocol, including the no-RO at all choice.
The suggestion
==============
Now, Mobile IPv6 Security Design Team has discussed whether it would
be possible to allocate a bit (or a bit pattern) on the IPv6 64 bit
Interface Identifier field, with the intention of later defining a
method that allows peer hosts to securely find out what security
protocols, and perhaps other functional features, the host using the
address supports. That is, if the bit is cleared, the host is happy
to rely on the default security protocols and semantics, as defined in
the base IPv6 RFCs. Thus, its peers are allowed to use the default
semantics and protocols when dealing with this host. If the bit is
set, on the other hand, the host instructs its peers that the host is
not happy with the default semantics and protocols, and instructs the
peers to look for more information. The exact way of how to look for
this information is to be defined later.
Note that an active attacker at the path between Alice and Bob is able
to clear a set bit. However, that changes the address, and Alice is
not going to answer to any possible replies sent by Bob. Thus, the
bit prevents the attacker from impersonating as Alice and fooling Bob
to use the less secure protocol.
The immediate intention at the mobile-ip WG is to the define the
Return Routabilility (RR) security method as the default Mobile IP
Route Optimization methods, to be used by all hosts that have the said
bit cleared. If the bit is set, the corresponding hosts must go to
find out what Mobile IP security method the mobile node supports. If
the corresponding node cannot find out this information securely, it
MUST NOT use Return Routability. This effectively blocks the bidding
down attack, as discussed above.
--Pekka Nikander
on the behalf of the MIPv6 Security Design Team
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
