Subject: Non-member submission from [[email-masked] (Sandy Murphy)]

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 30 Jan 2007 21:16:16 -0000

From: "Sandy Murphy" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, January 29, 2007 6:44 PM
Subject: Re: Security considerations with 
draft-ietf-ccamp-rsvp-restart-ext-07

>> 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
>
>
>
>
>