Re: about draft-nordmark-multi6-noid-00

[masataka ohta <mohta@necom830.hpcl.titech.ac.jp>]

Erik;

> > Red herring.
> >
> > Encapsulation and notification formats are a merely minor issue
> > of multihoming.

> Thanks for sharing, but being able to do this without making security
> worse than in the current Internet is a challenge. See 
> draft-nordmark-multi6-threats for an initial cut at the threats that we
> need to be concerned about.

The threat ID is an abstract nonsense.

The only thing to be secured w.r.t. multi6 is a set of
locators of a peer.

That is, all that is required is to share a cookie at the
start of the communication, to be used later to authenticate
locator set changes.

Note that when the set is stable, no new mechanism is necessary.
For example, that SMTP clients today try all the addresses
of all the servers of a domain is a form of end to end
multihoming, which is no security threat.

In addition, it is, of course, necessary, not to make a
protocol a DOS amplifier, but it is a generic requirement
to all the protocols and is not multi6 specific.

> You might believe that security is a minor issue that can be added
> as an afterthought but experience has shown that this
> is not the most efficient and expedient way to design secure enough protocols.

Security is a minor issue to be taken care of easily from the
beginning.

> > It should also be noted that changes on host identification
> > (from IP address to something else such as FQDN) means a
> > protocol change at upper (at least at the transport) layers
> > that "all upper layer protocols can operate unmodified" is
> > a false statement.

> I honestly disagree.

Protocol is defined by the packet content on the wire, not
by API.

That a packet of a protocol is modified within a host is a
host internal implementation issue having nothing to do with
the protocol.

You preserve API, not the protocol.

> > It is really a wast of bandwidth to read poor proposals not
> > understanding requirements described in my drafts long ago.
>
>
> The tone of your note in general and this sentence in particular makes
> me wonder what you want to accomplish in this working group.
> Can we please have a civil discussion!!!

I wonder what you want to accomplish in this working group.

It is no useful to have a harmonized discussion to reach a
peaceful compromise on a set of useless drafts.

> > Do read the drafts.

> I did. And I understood them I think. But they didn't seem to address key
> important issues like redirection attacks - saying "cookie-based weak security 
> for a host authorize changes of locators of its peer." is missing all the
> details of the complexity of providing this without introducing new (DoS)
> attacks, and is probably too weak since it would make redirection attacks much
> easier to perform and harder to detect than in today's Internet.

I'm afraid you merely underestimate the security threats in
today's Internet.

In your threat ID, you wrote:

: Any system that is along the path from the source to the destination
: host can be compromised and used to redirect traffic.  Systems may be
: added to the best path to accomplish this.  Further, even systems
: that are on multi-access links that do not provide security can also
: be used to redirect traffic off of the normal path.

and the cookie approach do not give protection against attacks
from hosts on the path, which is no worse.

The Internet today is not so secure. Under certain assumption,
redirection attacks are easy and hard to detect.

							Masataka Ohta