To: adrian@olddog.co.uk
Subject: Re: Security considerations with
draft-ietf-ccamp-rsvp-restart-ext-07
Cc: ccamp@ops.ietf.org, dbrungard@att.com, derek@ihtfp.com,
hartmans-ietf@mit.edu, rcallon@juniper.net, sandy@tislabs.com
In-Reply-To: <044201c740e3$06b30d60$f4849ed9@your029b8cecfe>
Message-Id: <20070129182515.97C343F4EA@pecan.tislabs.com>
Date: Mon, 29 Jan 2007 13:25:15 -0500 (EST)
From: sandy@tislabs.com (Sandy Murphy)
(I replied to Adrian directly because he had reply-to set to himself only,
but he assures me that a reply-all is OK. So here is my reply. Then I'll
send his response.)
--Sandy
The email thread is presented in time order, oldest email first. I trust
that the originators of the emails will not feel that their conversations
are being put into the public domain egregiously.
I managed to avoid insulting anyone in those messages, so I'm fine. :-)
My comments in line. I hope I've managed to help indicate what you should
do and why.
Thus there is a bidirectional full trust model between neighbors.
Given that the trust model is full and bidirectional, this I-D cannot
modify
the trust model.
It should be said that a trust model is not only who you trust but
what they are trusted to do. So just saying that you trust the same
people in either case is not sufficient; you must look at whether the
actions are equivalent in each case. Which, by the way, is what you
address in the following, so you are on the right track.
Now, as I said, the damage you could do for any one LSP is subtly
different.
That is, during LSP setup, the maliscious LSR would have been limited to
doing damage as a recipient of a Path message and sender of a Resv. With
this I-D it is able to tell the upstream (restarting) LSR that the Path
message it sent previously was different from the one it actually sent.
What
new damage could this do?
It doesn't change any of the behavior at any downstream LSR because the
malicious LSR could already have lied in the Path message that it sent
downstream.
It doesn't change anything at the malicious LSR because that LSR is
always
free to be malicious in its own way.
It doesn't change anything upstream of the restarting LSR because the
restart information is not propagated further upstream.
The fact that restart info does not propagate does not mean that
changes in behavior do not propagate. [Hm: could soft-state refresh
behavior to upstreams be affected by something in the bogus PATH
info?]
All it can do is tell the restarting LSR that the LSP parameters have
changed. So what?
Your "So what?" rhetorical question deserves an answer. Surely there
would be no need for a new protocol if the restarting LSR was not
going to do *something* with the info it receives. Bogus info about
the Path is going to produce some behavior different from the
legitimate info, or we'd have no need to be exchanging that info
anyway. Just on that basis, an answer to "So what?" of "Nothing"
should be viewed with scepticism, unless accompanied by some
reasoning. [The draft specifically points out the ability to recover
the Explicit Route Object, which sure doesn't sound benign to the
uninitiated.]
Unfortunately, it looks like determining the way the behavior could be
different and how much harm that could do would be a matter of
reviewing 3209 and 3473 and understanding the use of many RSVP
objects, not only the ERO but also those mentioned in "Such Path state
may include (but is not restricted to) the Protection object, the
Admin Status object, the Session Attribute object, the Notify Request
object, the Sender Tspec object" and who know what all else. In other
words, would best be done by someone who knew such stuff.
Based on a security review by Derek Atkins and comments from Sandy
Murphy,
...
I think that you need to see the security review by Derek and comments
by Sandy.
Please note that my comments were not about this draft, but about a
suggestion by Adrian that byzantine behavior by legitimate
participants did not need to be considered. I did not say that I
thought that there WAS a problem. Indeed, I had not read the draft
and so had little reason think that there was a problem.
If anyone can contribute to this debate to make suggestions on how we
could
resolve this issue then that would be most welcome.
Recommendation: Find someone to answer the "So what" question. Find
someone to verify the "not propagated further upstream" assertion wrt
behavior. Have them write their conclusion down, especially the "why"
parts.
--Sandy