Subject: New idea for Router Sol/Adv and Mobility

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 14 Feb 2001 15:10:12 -0800

Intro
-----
This post addresses section 9.8.3 and 10.{16,17} in the Mobile IPv6
draft,concerning Tunneled Router Solicitations and Advertisements. As I
posted on the Mobile IP mailing list, the procedure proposed in these
sections will not work when a MN is in the process of configuration and
without a Home Address. Below, I will recommend an alternate solution
which will cover this possibility.

Since I am posting this to the IPng mailing list, I will reiterate some
of the problem.

Background of Problem
---------------------
A Mobile Node, when configuring itself, may first configure its (global)
COA, then find its Home Agent's address, and send a Tunneled Router
Solicitation, in order to get prefix info to configure its normal Home
Address(es).

In 10.16, the MN without a HAddr encapsulates a RS using an inner source
address of 0::0 (unspecified). The HA receiving this packet is justified
in removing the outer layer without saving any state, meaning it would
then be presented with a packet coming from an unspecified address. This
is, at the least, problematic and annoying. The HA could be forced to
keep the outer source address (COA) around, which would solve this.

In 9.8.3, the draft instructs Home Agents to tunnel the RA to the MN
using the MN's COA using a routing header containing the address 0::0.
As Ken Powell pointed out:
> This also violates the addressing architecture, RFC 2373 section
> 2.5.2:
> 
>    The unspecified address must not be used as the destination address
>    of IPv6 packets or in IPv6 Routing Headers.

One possible solution is forming a temporary Home Address; however,
there is no advantage to doing this other than to provide routability.
If the temporary HAddr is already in use, the HA can not send a packet
to that address with a Routing Hdr, and so it does not solve the
problem.

Solution
--------
The solution to this problem involves two steps: relaxing a Neighbor
Discovery rule on the HA and MN, and creating a mobility processing rule
on the HA and MN. Now RS/RA can be sent without any special Mobile IP
headers, and look very similar to normal RS/RA, except that they are
routed unicast packets. This solution is very general, and uses the COA
and HA addr only, so it does not matter whether the MN does, or does
not, have an HAddr.

RELAXING TTL:
1. An unicast Router Solicitation arriving at an Home Agent is NOT
discarded if the TTL < 255 (off-link, from MN).
2. An unicast Router Advertisement arriving at a Mobile Node is NOT
discarded if the TTL < 255 (off-link, from HA)

MOBILITY PROCESSING:
1. The Home Agent receiving a Router Solicitation with TTL<255 (from off
link) knows that this is a request from a MN, and will include extra
Prefix Information as per the draft.
2. The Mobile Node receiving a Router Advertisement with TTL<255 knows
that this was sent from a HA and contains HA prefix info and it should
be processed differently by Mobile IP code to create HAddr(s).

Recap Of Changes From Current Draft
-----------------------------------
We are removing
 - encapsulation on RS
 - routing header on RA

We are adding
 - a rule that TTL<255 is allowed and specifies mobility signaling
 - RS and RA come into/out of COA on MN. HAddr is not used for this
info.

This buys us
 - mobile nodes without an HAddr are now routable
 - simplification and shortening of messages
 - 

Open Issues
-----------
SECURITY:
The Router Solicitation must be protected by an Authentication Header.
This is already a requirement.
The Router Advertisement should/may be encrypted. If it is not, note
that prefix information about the home network will be available for
inspection along the path the RA travels. This security issue is the
same as what exists in the current version.

I am open for comments on this idea.
-- 
T.J. Kniveton
NOKIA Research Center
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 15 Feb 2001 10:00:44 +0100

Hi,

> Open Issues

Is it? Where do you find that requirement? The RA needs authentication
though.

> I am open for comments on this idea.

I think this is a good way. Start-up procedure is a mess right now. The
basic arguments against a special solution for bootstrapping was that
the MN-HA RS/RA mechanism is used in other places too:
 1. MN sends an RS at any point in time to sync its prefix list with the
HA.
 2. RA pushes an RA to the MN due to changed information in the home
network.

Can we move to non-tunneled RSes/RAs for these cases as well?

Will we open up a security hole or possible denial-of service attack by
let's say flood a HA with RSes (that don't require authentication), now
that we can send them over multiple hops?

/Mattias

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 16 Feb 2001 10:40:44 +0100 (CET)

> and HA addr only, so it does not matter whether the MN does, or does

Are you proposing using these rules solely for the initial configuration
of the home addresses or do you see these as new rules as something that
would apply to all information carried in RAs and RSs between the HA
and the mobile away from home?

If it is the latter it might be cleaner to make this been different
ICMP types (e.g. Home Agent Solicitation and Home Agent Advertisement) that
would carry the ND options like the prefixes.

> Prefix Information as per the draft.

This is were having a different ICMP type would make things cleaner.

> same as what exists in the current version.

Encrypting the RA doesn't seem to be useful unless you restrict the COAs
that can be used to talk to the HA.

If somebody wants to discover the RA content they can just
1. set up an ESP security association between their address (COA) and the HA.
2. send a RS to the HA.
3. The HA will send the encrypted RA back to them and they decrypt it.

Thus I think it is a fundamental aspect of the problem (trying to allocate
a home address before doing a secured BU with the HA) that anybody can
discover whatever you send to a claimed COA for a mobile node.

  Erik