Re: MAST and mip based solution

[Dave Crocker <dhc@dcrocker.net>]

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>