Subject: Re: [mobile-ip] Routing header Vs tunneling

From: Erik Nordmark <[email-masked]>
Date: Sun, 9 Dec 2001 00:45:39 +0100 (CET)

> >     b. Home Address Option/Routing Header vs Tunnelling
> 
> I think we should modify 'b' to say " Home Address Option
> vs Tunnelling" because Pekka has suggested a solution for
> the routing header problem in his
> draft-savola-ipv6-rh-ha-security-01.txt

The intent of the presenters was actually to use Pekka Savola's draft
to talk about the security requirements for HAOpt and routing headers,
and not go into a discussion about whether the tunneling packet formats
are better or worse than the HAOpt and RH packet formats.

If the WG can come to closure on the requirements then we have one less
thing to worry about.

> Every host should follow these rules
> 
> Routing header MUST be processed if
> 	1. segleft is 1
> 	2. destination address and intermediate address both
> 	   belong to the same interface of the host that
> 	   received the packet.
> Routing header MUST not be processed if
> 	1. the address to be swapped does not belong to
> 	   the same interface as the destination address
> 	   on the IPv6 header.
> 
> if a IPv6 host follows the above rules, is there still a
> security problem? if not, I suggest we drop the issue of
> router header Vs tunneling and use routing header with the
> above two rules.

As I just sent to the ipv6 list, I think the overloading of routing headers
make it harder for firewalls to differentiate between MIPv6 use of
routing headers as opposed to other routing headers (those where the different
hops are for different nodes). This was pointed out in Pekka's draft if
I remember correctly.

I don't know how important this concern is.
What does the WG think about that concern?

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Dec 2001 22:13:12 +0100

=> I believe the concern will be for other/new usages of routing headers
if firewall implementors support only the MIPv6 special case...
Another reason to move this thread to the proper WG!

Thanks

[email-masked]

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 11 Dec 2001 00:11:28 +0100

> Another reason to move this thread to the proper WG!

Agree. This might put me on Glenn Morrow's FUD list, but here's an
extreme position:

I think this is where the IESG must step in. Yes, the MIP wg can go continue
using RH/HAO, but I think it has been successfully demonstrated that
tunneling with the zill/deering extensions can accomplish the same thing.
It is the IESG's job to avoid proliferation of duplicate mechanisms. Better
one well-known mechanism than a slew of them. Definitely true for
security and firewalls point of view, so it can be couched in those terms.

Notice that this nearly happened in IPv4 with Dave Johnson's minimal
encapsulation (rfc2004) but it didn't gain much ground cuz only the MIP wg was pushing
it. This new zill/deering option is now outside the MIP wg, where it should be.
MIP wg should just adopt it, help spec it, push to put it on the fast-track and get it done.

And yes, we should deprecate RH/HAO. Anything to make mobility less 'weird' and
more in line with non-mobile wg's (IPv6) will save us problems down the road.

asbestos shields on,

-gabriel

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 10 Dec 2001 15:45:07 -0800

Hello Gabriel,

> > Another reason to move this thread to the proper WG!

As I mentioned before, this particular use of the routing header is
specific to Mobile IPv6, and thus should be handled in the mobile-ip
working group.  Moreover, I think that whatever uses the routing
header will have, will each be specific for a particular purpose.
Thus, I do not think that it makes sense to create anything more
than very general guidelines within some over-arching working group
effort.

> tunneling with the zill/deering extensions can accomplish the same thing.

It was already successfully demonstrated long before the Zill/Deering
draft.  I don't think that anyone has ever tried to argue that encapsulation
was incapable of these operations.  In fact, Mobile IPv4 had several
LSR-based attempts, and we certainly know that encapsulation can do
the same task in the context of IPv4.

> security and firewalls point of view, so it can be couched in those terms.

The mechanism you refer to is not on any standards track as far as I know.
It might take quite a while to get it done.  Furthermore, the encapsulation
mechanisms do nothing to solve any security problems, and probably make
the problems ever-so-slightly worse just because of their greater generality.

> MIP wg should just adopt it, help spec it, push to put it on the fast-track and get it done.

It is a different case, not least because in IPv6 the encapsulation endpoint would
be at the mobile node.  This means more bytes over the air.

> more in line with non-mobile wg's (IPv6) will save us problems down the road.

If we make everything sufficiently in-line with non-mobile protocols, we are
likely to get non-mobility.  But I know you didn't mean that.  On the other hand,
I would have thought that using Draft Standard IPv6 mechanisms was "O.K."
according to almost any reasonable engineering criterion.  Plus, they are in
fact known to work after years of interoperability testing.

> asbestos shields on,

I'm not sure whether it's braver to go for complete upheaval and
catharsis, and join in the fray, or to try to take the shortest most direct
route towards completion.  I'm going to stick with the latter.  I don't
have any shields, though, and it feels pretty crispy around here.
I do know that catharsis "feels good" for a while, and might be
satisfying, until the devil which had been residing in the details
begins to re-establish its dominance over results once again.

Given a bit of shared purpose, I think we have the tools at hand to
satisfy the demands which were placed on us last year about this
time, and I think we ought to go down that road as expediently
as possible.

Regards,
Charlie P.