Re: (a proposal of light-weight iTrace authentication) Re: Potential agenda for SF meeting

Hi, Marcus,

Marcus Leech wrote:
> I would say that this is "trust in the very weak sense".
> The question to ask is whether this is too weak to be of any use.
> The bad guy can potentially compromise part of the path between
> a DDoS source and its nearest router, which would mean that "YES"
> messages from this couldn't be trusted.

"trust in the very weak sense" --> yes

"usefulness of this level of trust" --> it depends.
(the below analysis might or might not make sense. comments
 are always welcome...)

	What the attacker really wants to achieve (or what
	we really want to protect against) is to trick the
	receiver to believe that a potential DDoS source is
	near a wrong/innocent router.

	Assume that the DDoS source is really near router A
	while the attacker tries to trick us to believe it is
	from router B.

	This implies that the attacker should compromise somewhere
	on the route path between the receiver and router B so it
	can intercept the request from the receiver and then
	replies an YES to the receiver. (I believe that this is
	the scenario you were talking about.)

	This is indeed possible and our option one will NOT be
	able to prevent it, but:

	(1). router A (the router close to the real source) can
	     still produce the right iTrace messages. Well, if you
	     also compromise a point between A and the receiver,
	     then you can block the iTrace messages. But, this will
	     happen even if you use public key signature.

	(2). remember we have the option #2, which you can use some
	     other mechanisms (such as human intervention) to
	     exchange the authenticated iTrace messages. If we
	     actually do that, we will be able to detect that this
	     situation had happened. And, then maybe we can start
	     to investigate what went wrong between B and the
	     receiver.

	(3). while the proposed solution is not perfect, it can
	     prevent attackers producing wrong iTrace messages from
	     the end-hosts (i.e., they can not intercept packets
	     on most of the route paths) effectively, which is the
	     most common case as I believe.

As I indicated our motivation earlier, we are here really trying to
avoid the need for running and managing an expensive mechanisms such
as PKI on every routers in the Internet, at least for the short term.

For deployment, this could be considered as the first or
intermediate step before we reach the fully rigorous stage.

-Felix