Subject: [mobile-ip] I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 15 Nov 2001 17:58:59 +0100 (CET)

Here is a pointer to a mildly provocative I-D suggesting to
use tunneling instead of home address options and routing headers
for your perusal.

   Erik

>----------------Begin Forwarded Message----------------<

Date: Thu, 15 Nov 2001 07:04:40 -0500
From: [email-masked]
Subject: I-D ACTION:draft-nordmark-mobileip-mipv6-hindsight-00.txt
To: IETF-Announce@, @

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: MIPv6: from hindsight to foresight?
	Author(s)	: E. Nordmark
	Filename	: draft-nordmark-mobileip-mipv6-hindsight-00.txt
	Pages		: 14
	Date		: 14-Nov-01
	
This document captures the authors personal opinions and is intended
to serve as input to the discussion in the Mobile IP Working Group.
It proposes several, in may cases completely independent, things
which might be deemed radical changes to Mobile IPv6 based on
watching Mobile IPv6 evolve over the last 5 years.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nordmark-mobileip-mipv6-hindsight-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-nordmark-mobileip-mipv6-hindsight-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-nordmark-mobileip-mipv6-hindsight-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
>----------------End Forwarded Message----------------<

---

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Nov 2001 19:35:46 +0200 (EET)

> use tunneling instead of home address options and routing headers

A few comments:

1.2

--8<--
   Replace the use of the Home Address option conceptually with
   tunneling.  Avoid an increase in packet size by specifying a new
   tunneling header which omits the destination address, since in this
   case the inner and outer destination addresses would be identical.
--8<--

IMO, possible increase in size (the increase could be like ~16 bytes or 
so) is not crucial.  The other issues regarding tunneling (for example, 
hop limit handling) are.

--8<--
   There is also one idea that could be added to Mobile IPv6 at a later
   stage, which is to make the movement detection more explicit.  The
   idea is to configure the routers on each link to advertise a single
   global IPv6 address as the "identity" of the link in each Router
   Advertisement.  This can be done by defining a new Neighbor Discovery
   option.  Thus a Mobile Node when it receives a Router Advertisement
   can immediately tell whether it has moved - the global identity will
   be different for each link.
--8<--

Couldn't the mobile node gather (most of) this information from available
data already?

1) If the prefix in new and old location are the same, the movement can 
be distinguished from router source address; it has to have been DAD'ed, 
as the two routers have to be on-link and reachable respective to each 
other.

2) If the prefix in new and old location is different, you have moved or
the router has been reconfigured.

In case of multiple advertised prefixes this gets more complicated:
 A) if all prefixes are the same in old and new, see 1)
 B) if none of the prefixes are the same in old and new, see 2)
 C) if some prefixes have changed or removed, the situation is unclear.
   - if the source address is different, we have moved
   - if the source address is the same, we probably haven't moved, but it 
is safer to assume we have.
--8<--
4.  USE REGULAR TUNNELING BETWEEN MOBILE NODES

   Currently when two mobile nodes are communicating using route
   optimization the packet ends up containing a destination options
   extension header with a home address option, which gets padded out to
   24 bytes, and a routing header which is also 24 bytes.  The
   suggestion to conceptually use tunneling instead means that for this
   mobile to mobile communication an extra IPv6 header is all that is
   needed.  In addition to the conceptual simplifications of using
   tunneling there is an added bonus in this case; saving of 8 bytes per
   packet.
--8<--

A problem with tunneling like this is that every node that would support 
route optimization would have to accept and (more or less) blindly 
decapsulate such packets.

Tunneling is always hazardous.  An example of a case with 6to4 is 
presented in:

http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4-security-00.txt

If this approach is adopted, it must be carefully analyzed.  It might also 
be wise to adopt a MIPv6-specific (or rather Route Optimization -specific) 
format for this. 

For example, one could require that the destination address of an incoming 
tunneled packet must be the home address of the node.  This is easy to 
check.  Source address is more difficult, unless you can make basically 
similar assumptions than with the safe use of home address option: there 
exists a binding cache entry for it, the packet is somehow authenticated 
etc.

Certain precautions seem to be discussed under 5.4.

--8<--
5.3.  Receiving Rules

   A conceptual way of describing the receive side behavior is to expand
   the above extension headers to a regular IPinIP header and then
   process that IPinIP header by the usual rules.  Such a scheme allows
   the sending implementation to use IPinIP in all cases and the use of
   IPinIPnoSRC and IPinIPnoDST are optimizations that the sender can use
   to save bytes on the wire.

   For IPinIPnoSRC this step involves replacing the IPinIPnoSRC header
   with an IPinIP header and copying the source address from the outer
   IP header into that new header while copying the Address field in the
   IPinIPnoSRC to the destination field in the new header and updating
   the payload length etc.

   The same step for IPinIPnoDST just copies the outer IP destination
   into the new inner header and takes the new inner header source from
   the above Address field.
--8<--

Am I correct that we're talking about:

Receiving:

[ IPv6 Header with nxthdr=IPinIPnoSRC ]
  [ IPinIPnoSRC, nxthdr = payload ] 
    [ payload ]

Which would be expanded to:
[ IPv6 Header with nxthdr=IPv6 ] 
  [ IPv6, nxthdr = payload ] *)
    [ payload ]

And passed on to ip_input or whatever as:

  [ IPv6, nxthdr = payload ]         
    [ payload ]

(this sounds rather complex, but three steps instead of just two seem to 
be necessary to ensure ipip decapsulation code will not let anything 
unwanted fall through the cracks -- intermediate nodes such as firewalls 
can easily obtain the final datagram by just replacing cutting out 
IPinIPnoSRC and having certain values in the removed header replace the 
values in the real IPv6 header).

*) here, missing IPv6 values would be collected from somewhere.
Most important of these is Hop Limit.  I'm assuming it would be taken from 
the outer IPv6 header.  So this would be IPinIP tunneling where tunnels 
would be modeled as "equal-hop", not "single-hop".

Equal hop is more secure in single hop in certain scenarios as there you 
can't, for example, inject packets with hop limit = 255 to the 
destination, fooling certain hop limit security precautions.

I didn't analyze rules in 5.4 in detail, but as an overview, they seem to
be properly extensive.  However, if the similar rules were to be applied
to RH/HAO, the end result from the end-nodes would be pretty similar.  On
the other hand, it would be much more easier for the intermediate nodes to
separate this route optimized traffic, which was one of my gripes in RH-HA
draft.

Generic note:

It seems that when a MN wants to talk to a CN, it first needs to send BU
through Home Agent to CN.  No additonal packets can be sent (except via
HA) until BU has been acknowledged, and then it is safe to try tunneling.
If HA is on the other side of the globe, this might take a while.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 19 Nov 2001 22:53:05 +0100 (CET)

> Couldn't the mobile node gather (most of) this information from available

It could try to infer it but that relies on heuristics and guesswork.

> as the two routers have to be on-link and reachable respective to each 

The problem is that RFC 2461 allows different sets of routers to advertise
different subsets of the prefixes and there can be lots of
prefixes in use on a subnet. Thus the Router Advertisement that is sent
frequently (more frequently than once a second) might not contain any 
prefixes because including them all would use up a lot of bandwidth.

> the router has been reconfigured.

Or different routers on the link advertise different prefixes.
Or a renumbering is starting by advertising new prefixes (e.g. using
the router renumbering RFC)

>  A) if all prefixes are the same in old and new, see 1)

But can't tell this from receiving a single RA. Need to wait for all the RAs
from all the routers.

> decapsulate such packets.

Not blindly - see section 5.4.

> be wise to adopt a MIPv6-specific (or rather Route Optimization -specific) 

I don't see the need to have different formats to capture the purpose
of the tunneling. But the policy at the decapsulating end for what
packets get decapsulated, whether or not the resulting packets can be
forwarded, etc are different depending on what tunneling is used for.

> Certain precautions seem to be discussed under 5.4.

Yes. Those are the proposed rules for mobile-ip use of tunneling.
They are a bit stronger that the rules in your draft I think.

In any case, I suspect we need rules close to these even independent
whether tunneling packet formats are used for mipv6 or whether we use 
routing headers and home address options.

>   [ IPv6, nxthdr = payload ] *)

Yes, the is the expanded IPinIP headers.
At this point in time you'd conceptually need to check whether the
packet can be accepted and decapsulated.

> values in the real IPv6 header).

I think an implementation can optimize this and not construct the intermediate
step provided it behaves the same way e.g. does the same checks. 
But in terms of describing it conceptually it makes sense to describe
it as three steps.

> would be modeled as "equal-hop", not "single-hop".

There is a draft-deering-<something> in the I-D queue that proposes a better
header format (same size) and carries the first 8 bytes of the IPv6
header.

> separate this route optimized traffic, which was one of my gripes in RH-HA

Yep. Also, as you pointed out in your draft the RH rules would need special
care. With encapsulation there is no "segments left != 1" case to
worry about etc.

> If HA is on the other side of the globe, this might take a while.

I think that is the safe approach.
It is also somewhat "symmetric" in that until the BU is done the traffic to
the MN will go through the HA.

If there is an application where a CN sends one packet to a MN causing the MN
to immediately start sending a media stream then the delay or reverse
tunnel through the HA might be an issue. But all protocols I've seen
do some initial handshake that takes at least one roundtrip. During that
roundtrip the BU can take place as well.

  Erik

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 20 Nov 2001 07:13:11 +0200

> But can't tell this from receiving a single RA. Need to wait for all the RAs

Eventually if you renumber you *have* moved in the IP sense, even
if you still are on the same physical link.

But I have a question to Erik. What happens if you renumber, don't
you need to change the link identifier as well? If no, how do we ensure
the identifiers stay globally unique? If yes, what do you announce in
an RA while this renumbering is taking place, the new, old, or both
identifiers?

Jari

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Nov 2001 09:19:43 +0200 (EET)

> It could try to infer it but that relies on heuristics and guesswork.

Ok, you have a point here.  However, this whole issue seems rather funny
because MIPv6 re-defined the minimum unsolicited router advertisement
interval to be ridiculously low.  If two routers advertise the same
prefix, I don't see why you should need to know (on IP layer) you might
have moved.  And if the prefix changes, sending the notification to HA
etc. takes relatively long -- in scenarios where it is expected that MN's
move quickly, the advertising interval could be set to something like 0.1
seconds, for example.

> forwarded, etc are different depending on what tunneling is used for.

Sorry wrong very unclear wording.  I meant that the packets should have to 
be distinguishable from regular IPinIP packets in the network (think 
firewall: "Aha! someone is using route optimization.. well the receiving 
rules are quite secure, I'll let it through, IPinIP I wouldn't").  But 
naturally, they would be due to the header value.

> routing headers and home address options.

Yes.  Which is why it would be good to consider at more length what makes
this better (or worse) than the current mechanisms with added security.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 Nov 2001 10:35:55 +0100 (CET)

> if you still are on the same physical link.

Site renumbering is likely to consist of many steps spread out over some
amount of time - a week wouldn't be unreasonable for a medium size site.
This consists of at least first introducing new prefixes on each link
and at some later point in time retiring the old prefixes.

Triggering movement detection when observing a new prefix being advertised
might just cause undue glitches in communication (due to discarding
the default router list etc) when the old prefixes and default routers
are still doing just fine.

Thus having an explicit movement detection ID instead of overloading other
information gives better control without restricting the operator to using
a single prefix per link.

> an RA while this renumbering is taking place, the new, old, or both

The operator decides when to have the visiting MNs pick new CoAs
presumably by deprecating the old prefix (some time after starting to
advertise the new prefix).
Presumably at the same time the new ID would start being advertised.
I guess this case could be "optimized" by allowing multiple IDs per
RA and during the overlap announcing both. That way the MNs can tell
the difference between a movement (no overlap) and renumbering (two IDs in RA
during the overlap).
But I think having the MNs treat that instance of renumbering as a movement
i.e. no optimization should be fine.

There might also be strategies that the routers can use to select the ID 
automatically. The routers, unless explicitly configured otherwise,
can pick the preferred global on-link prefix that they (or some other router
on the link) advertise as the ID.
In that case when a new router comes up it might need to listen for RAs for
a while in order to pick the same ID as the rest of the routers.

 Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 Nov 2001 10:50:20 +0100 (CET)

> move quickly, the advertising interval could be set to something like 0.1

Yep. The low interval is intended to be used on link-layers where there
is no reasonable link layer indication that the MN might have moved.
If such an indication exists and is reasoanbly reliable it is better to
have the MNs send a RS when getting that L2 indication.
(But have to be careful to avoid a noisy L2 indication causing a flood of 
RS messages from all MNs.)

> naturally, they would be due to the header value.

Current use of IPinIP tunneling e.g. for VPNs has very strict decapsulation
rules so I don't understand why folks would have these concerns.

What we need to provide are easy means for firewall folks to be able
to distringuish between packets that can potentially cause very different
forms of damage. Thus distiguishing between routing headers and tunneling
makes sense to me.
But distinguishing between tunneling whether used for A or B given that
both A and B have strict rules for when to depcapsulate packets doesn't
sound useful.
(There will always be paranoid people who will not let through anything
but outbound tcp connections to port 80, and we can't make it a design
goal to try to make this look like a http exchange.)
So just don't make it too hard for them to tell different things apart.

> this better (or worse) than the current mechanisms with added security.

Which current mechanisms? The mipv6 draft which says to accept any ha option?

Apart from your draft on rh-ha there is nothing that talks about
the security issues with routing headers and home address options.

I don't this is largely orthogonal to adding security to BU processing.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Nov 2001 12:40:31 +0200 (EET)

> forms of damage. Thus distiguishing between routing headers and tunneling

Yes.

> both A and B have strict rules for when to depcapsulate packets doesn't

We're in agreement here.

> I don't this is largely orthogonal to adding security to BU processing.

Well, IMO the possibilities are:

1) "Accept anything" 
2.a) "Retrofit existing mechanism for security"
2.b) "Redesign more logically and securely"

I've tried hard to get requirements that would disallow 1) to the 
SecReqs.. perhaps that'll come in the next revision...

If the total obtained security between 2.a) and 2.b) is roughly the same
(or could be roughly the same), the focus turns to other issues, such as:

 - which is already implemented and tested
 - which looks better and "more right"
 - etc. etc.

Assuming we'd have to either enhance RH/HAO or to revamp the mechanism
completely, which benefits (and drawbacks) would there be for each?  The
benefits wrt. "accept anything" are interesting (and mostly already
covered), but not a deciding factor here.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 Nov 2001 13:23:52 +0100 (CET)

> SecReqs.. perhaps that'll come in the next revision...

Yes, I also think #1 is a non-option and that the security requirements
need to describe that at some high level.
(However, I don't know how to capture the various details you've described
about routing header issues in an abstract requirement sense without actually
describing the exact routing header mechanisms and the detailed issue.)

> covered), but not a deciding factor here.

I hope that the discussed on the mailing list can actually help flush out
the pros and cons of 2a and 2b. 

   Erik