Subject: MAST and mip based solution

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 14 Sep 2003 12:08:30 +0200

Hi Dave,

I really like the MAST draft, it is really clear and attempts to benefit
from already available work.
I also liked the roadmap proposed by P. Nikander (i think it was him).
Start with a solution based in MIP, with the minimum changes to mip and then
to evolve to an optimized solution which can be something like MAST.

so i think it is important to compare mast to a mip based solution (it seems
that everyone wants to compare mast with something :-)

I can identify the following relevant points (imho)
- Deployment. I think that it is clear that mip will be available much
sooner than a mast solution. Even if some changes are required in mip to
support mh, i think that the changes imposed to nodes outside the
multi-homed site will be very limited (if not, i don't know if a mip
solution makes much sense). So i think that it is reasonable to consider a
mip based solution as a short term solution
- Overhead/MTU. I think that one of the main benefits of mast over a mip
based solution is related to the overhead and MTU reduction imposed by mip.
I mean, mip requires the usage of the HoA dest option and the type 2 routing
header when using alternative addresses. This imposes overhead and implies
MTU reduction. MAST solves these issues, since packets only carry one
address. This is a desirable feature of a more longer term solution.

However, i think that mip signaling is really similar to the one required by
MAST. for instance bu messages contain alternative address information. I
mean, i think it should be interesting to evaluate if mip messages can be
used in a MAST implementation. Moreover, i think that the mip solution can
be optimized by just avoiding the usage of the HoA destination address and
the routing header.
I mean, once that the BU has been performed, you really don't need to carry
both addresses in every packet since this state information is already at
the end nodes. This is what MAST does. so a mip based solution can evolve
towards mast in this way, i.e. conserving the packet format for signaling
and improving certain aspects as this one. Clearly much more study is
required to see how this fits.

what do you think?

Finally, the main problem that i find in mast is, as always, the security. I
mean, mast is vulnerable to time shifting attack and can be used to generate
flooding attacks, so more stuff is needed, just as in a mip based solution.

Regards, marcelo

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 15 Sep 2003 12:02:29 +0200

On söndag, sep 14, 2003, at 12:08 Europe/Stockholm, marcelo bagnulo 

> mip based solution as a short term solution

But for an intermediary solution where MIP already exists, will that 
actually need any modification or adoption for trying to solve 
multihoming?

- kurtis -

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 15 Sep 2003 16:50:12 +0200

Hi Kurtis,

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Kurt Erik Lindqvist
> Enviado el: lunes, 15 de septiembre de 2003 12:02
> Para: [email-masked]
> CC: [email-masked]; [email-masked]
> Asunto: Re: MAST and mip based solution
>
>
>

I guess it would require some changes, the options that i can identfy are:

- Extend the maximum lifetime of binding entries (BCE) in the correspondent
nodes to some acceptable value for multi-homing support, for isntance a
couple of hours. The problem is that the current value is set to 7 minutes
and it is a security measure for preventing time shifting attacks.

- Use ICMP to differentiate a broken path from a time shifting attack. I
mean, mip uses return routability to prove address ownership. This means
that a node is entitled to use a given address if it can receive the packets
sent to this address. MIP return routability check is performed
periodically, so that time shifting attacks can be minimized (this means,
that it isn't enough that i can prove that once i could receive packets to a
certain address to prove that i own that address, instead i have to prove
that i can always recive packets to this address) (this implies that if an
attacker wants to pretend to own an address it must be intercepting the
packets to this address during the complete duration of the attack)
The problem is the return routability cannot be applied directly to the
multi-homed environment, becuase a mh host won't be able to prove address
ownership after an outage has occurred. So we need some way to differentiate
a path outage from a time shifting attack. This implies some form of network
to user signaling, informing that an outage has occurred. This is done using
icmp. The problem with this is icmp filtering. If icmp is filtered, the cn
will consider that an attack is in place and will drop the communication. So
this solution is as robust as icmp messaging... i am not sure if this is
good enough...

So possible changes are minor i guess, but i am not sure whether the
solution achieved is good enough

I am not sure that if this is a satisfactory answer to your question
tough....

Regards, marcelo

PS: i think this issues are pretty general, i mean they are true not only
for a mip based solution.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Sep 2003 10:44:00 -0700

Marcelo,

thanks for the comments on MAST;

mb> I also liked the roadmap proposed by P. Nikander (i think it was him).

I like it, but have to note that the Internet is not very good at following
roadmaps.

That is one reason I try very hard to reduce the dependencies that new work
has on other new work.  Development gets delays.  Deployment gets delayed.

mb> - Deployment. I think that it is clear that mip will be available much

Unless I am missing something very basic -- and I readily admit that that is
likely -- then MIP has problematic barriers to adoption.

These barriers come in 3 ways:

1. How much software has to be built or changed.

2. How much infrastructure has to be changed (new software and/or new
operational procedures.)

3. How difficult is it to use?

I think that MIP loses on all 3 counts.  It requires modification to the user
stacks, and requires enhancements to infrastructure software and operations.

The user platform must have a formal "home" network.

All of the bells and whistles are required for even the simplest use.

And mip works for mobility but not multihoming.  If it offered major
advantages over some of the alternative solutions, that might be fine.  But I
do not see those advantages.

mb> - Overhead/MTU. I think that one of the main benefits of mast over a mip
mb> based solution is related to the overhead and MTU reduction imposed by mip.

yes.  this benefit also applies to the transport-level solutions.

mb> However, i think that mip signaling is really similar to the one required by
mb> MAST. for instance bu messages contain alternative address information. I
mb> mean, i think it should be interesting to evaluate if mip messages can be
mb> used in a MAST implementation. Moreover, i think that the mip solution can
mb> be optimized by just avoiding the usage of the HoA destination address and
mb> the routing header.

You are talking in terms that look like an effort to "converge" two or more
designs.  That will be excellent, if it can happen.

The history of such efforts in the IETF is not all that positive, but I think
that attempts to synthesize different proposals together always produces
better understanding, if not fewer specifications.

mb> Finally, the main problem that i find in mast is, as always, the security. I
mb> mean, mast is vulnerable to time shifting attack and can be used to generate
mb> flooding attacks, so more stuff is needed, just as in a mip based solution.

As I've noted elsewhere, MAST is intentionally limited in what security it
tries to provide.  It can be made stronger and broader, but I think there
needs to be a very clear understanding of the reasons more security is
needed... for multiaddressing, rather than for overall enhancement of the
Internet.

As I have said, the latter goal is laudable... but it is an additional goal that is
not essential to multiaddressing support.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 18 Sep 2003 14:10:36 +0200

Dave,

> De: Dave Crocker [mailto:[email-masked]]
> Enviado el: miercoles, 17 de septiembre de 2003 19:44

[...]

> All of the bells and whistles are required for even the simplest use.

Well, i would like to mention a coouple of issues about this:

Note that the functionality that it is required (at least from my pov) is
onlt the CN functionality. I mean, the idea is to try to benefit from
capabilities that are being inlcuded in end-hosts code right now.
So CN capabilities are not the most complex part. for instance, al the home
network complexity is not included

The other thing is that i don't think that mip has artificial complexity.
I mean, mip is complex, agree. But my question is, how do you manage to
provide a solution with al the required functionality and that it doesn't
introduce new security vulnerabilities to the internet without all this
complexity.

You can argue that for instance MAST is much simpler (i choose mast just as
an example), but how simple will it be when you provide proper security
features. My guess is that it will be at least as complex as mip.

> do not see those advantages.

About mip for multi-homing.
Yes, mip has some issues when trying to use it for multi-homing.

If you assume that an end-host solution is required (i include here
solutions that use some form of proxy in the site's network), you will find
that it is very difficult to provide a solution that doesn?t introduce new
security issues.

As far as i can see, the only solution that provide this is HIP.
The problem with hip is that it is a bit too revolutionary and requires a
lot of changes, not only in code but also in paradigm. We need to gain
experience and moving to hip will take some time IMHO.
So we need a bridge.
An option is to use current ipv4 style, just as Kurtis proposed a long time
ago...
The other option is to use a solution that it is not as secure as we would
like.
But when considering adopting a transient solution that is not optimal,
probably you want to minimize the effort, so it can deployed as fast as
possible.
IMHO a mip based solution suits fine with this constraints.

Regards, marcelo

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 18 Sep 2003 09:16:23 -0500

> that it is very difficult to provide a solution that doesn?t
introduce new

[deleted down to ]

> The other option is to use a solution that it is not as secure as we
would

This is only my opinion, but I would expect we would get more
simplification from dropping the requirement to support simultaneous
movement at both ends than we would from relaxing security - the
requirement for a rendezvous function in the network comes from
simultaneous movement, and that gives us dependencies on network
infrastructure changes.

The vast majority of today's mobile ("portable") users have TCP
connections on IPv4 devices that break when they cross subnet
boundaries. Supporting movement at one end would be an improvement.
Supporting simultaneous movement at both ends would be lovely, but so
far, we haven't widely deployed a solution that provides that
capability. Meanwhile, they continue to run client-server applications
with short connection lifetimes because that's what works in today's
networks.

End-to-end MAST really could help us move to peer-to-peer applications
in many, but not all, environments. MIP is certainly a more complete
solution, and I'm not bashing MIP here, only suggesting that MAST may
really have a role for multihoming support, without reducing security.
MAST or HIP? I think that's the question for multihoming.

Just my opinion here, and not all that clearly thought out...

Spencer

Spencer

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 18 Sep 2003 16:57:13 +0200

Hi Spencer,

> nombre de Spencer Dawkins
> Enviado el: jueves, 18 de septiembre de 2003 16:16
> Para: [email-masked]

actually i would be satisfied if we could build a solution to provide just
multi-homing support (i.e a solution for multi-homing without support for
mobility (note that this is the charter of this wg :-)), but i think that
this is also very hard with the current security requirements.
So, i agree with you, simultaneous movement is really a plus plus...

> really have a role for multihoming support, without reducing security.

Here is where we disagree. I don´t think you can provide the current ipv4
level of security with mast if you don't use cryptographically generated
identifiers i.e. HIP.

But let's try to do it.
Let's try to define a security solution for MAST and see what happens (i am
willing to contribute)
But unless we come up with some new thinking here, we have a very similar
problem than what mip people had when they where designing mip, so problably
we will end up in the same place, with the same problems, but i guess we can
only be sure of this if we try.

> MAST or HIP? I think that's the question for multihoming.

For me there are many questions, but if you are considering end-host based
solutions, the question is mip-type or hip-type, meaning by mip-type those
solutions that don't use crypto identifiers and use other means to provide
security and hip-type those solutions that use crypto identifiers.

Regards, marcelo