Adrian, you have reply-to set to you, so this is going to you only. If
that is not what you wanted and you want the other recipients to see the
message, let me know and I will resend.
Doesn't matter. Reply-all is always an acceptable option. Given that one
of
your comments seems to be addressing other's not me, it might be good to
send it more widely.
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.
Thanks.
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.
Clearly I need to read the security terminology RFC to get the difference
between trust (security) and allowed actions (policy). Can you point me at
it to save me having to search.
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?]
No. It assuredly could not.
Of course, a bogus Resv could do that, but we already have to admit that
the
Resv might be bogus.
Or rather, we discount the possiblity of anyone subverting the running
code
on a router.
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.
Well, read the draft :-) It is going to:
- Check the information against the data plane in order to
discard obsolete data plane state. Issues are:
- Old data plane state will be falsely retained
This is such a small issue that it is not very important,
besides, how did the neighbor guess the existence of
the state?
- Old data plane state will be deleted in error. This is
important because it interupts traffic. But, the neighbor
could have done that itself.
There is a tiny thing here that the neighbor can possibly
cause the restarting node to appear to be at fault, but
we can assume that the restarting node would log such
events (and might not even tear state without management
intervention).
- Use the information to generate its next Path message that
it sends back to the downstream neighbor.
Note that the utility of this function is that when the
downstream neighbor restarts, it can get a refresh from its
upstream neighbor.
The consequence of a lie here is just a reminder to the lier
of what its lie was.
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.
I have to say that the request "justify yourself" is hugely frustrating. I
know it is difficult to do this type of cross-area review because it is
not
possible to be an expert in the details of every protocol. And it is
really
useful to have issues raised like: have you considered what would happen
if
XYZ? But at some point, there has to be an acceptance that, yes, the
protocol experts have though about this and they are comfortable.
If we have to document the fact that such a situation would be benign for
every possible setting of every field in every protocol object currently
defined we will clearly produce several tens of pages of I-D. If this is
what is required then I think that we might as well give up on the idea of
publishing specifications.
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.
Let me give an example. An ftp implementation is per spec in all respects
except that whenever you send "get foo" it returns the contents of the
file
bar. It seems to me that there is nothing that the peer ftp implementation
can do within the scope of ftp to rectify or even detect this. Only the
application of other features (such as file encryption and file tagging)
can
help and this is outside the scope of ftp.
So with RSVP-TE. An application can do lots of things to verify that its
LSP
is correctly connected and passing the right data unmollested, but that is
the job of the application not of the protocol.
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.
Frankly, no-one will do this (although I seem to be being partially
dragged
into it through email exchanges with Sam :-). It would cost too much
money.
If that means that the I-D is blocked from publication then maybe some
people will laugh at the IETF. But I don't suppose it will change much:
this
stuff is implemented, deployed, and through various interop tests.
Adrian