He is concerned that the extensions in this I-D change the trust model in RSVP-TE, and I am trying to convince him that there is already a bidirectional full trust model between neighbors without which basic RSVP-TE signaling could not work. Thus (I say) this I-D does not change the existing trust model although it reverses the flow of information for a specific LSP.
Further (I say) even a malicious LSR neighboring a restarting LSR could do very little more damage during restart than it could do during normal LSP processing.
If anyone want to see the contents of this discussion, please shout. Adrian----- Original Message ----- From: "Sam Hartman" <hartmans-ietf@mit.edu>
To: "Sandy Murphy" <sandy@tislabs.com>Cc: <adrian@olddog.co.uk>; <asatyana@cisco.com>; <secdir@mit.edu>; <ccamp@ops.ietf.org>; <dimitri.papadimitriou@alcatel.be>; <iesg@ietf.org>; <lberger@labn.net>; <ancaz@cisco.com>
Sent: Tuesday, January 23, 2007 2:44 AM Subject: Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06
"Sandy" == Sandy Murphy <sandy@tislabs.com> writes:Sandy> asatyana@cisco.com, secdir@mit.edu, lberger@labn.net, Sandy> ancaz@cisco.com, iesg@ietf.org >> This leaves us with only the mistake, and generally we don't >> make extensive protocol changes to handle the potential for >> broken implementations. Sandy> Yes, we will always have errors, in implementation, in Sandy> configuration, in operation, we can't hope to protect Sandy> against all of those, etc. Sandy> However, it is prudent to spend some time analyzing how Sandy> much damage to the protocol operation could result from a I agree with Sandy here. I think that analysis of what damage can be done by a malicious peer so that we can understand whether the proposed trust model is justified.