Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06

[Dimitri.Papadimitriou@alcatel-lucent.be]

adrian - if this i-d has to be revisited wrt to the trust model
it implies there are a couple of other items that would fall in
to the same category

hence, the point is the following can we share that discussion
(i mean the off-line one) such as to assess the rationale and
arguments that led sam to this conclusion

thanks,
- d.
 




"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
23/01/2007 19:09
Please respond to "Adrian Farrel"
 
        To:     <ccamp@ops.ietf.org>
        cc: 
        Subject:        Re: [secdir] draft-ietf-ccamp-rsvp-restart-ext-06


FYI, I am having an off-line discussion with Sam Hartman during IESG 
review 
of this document (that has now advanced to 07) as he has raised a DISCUSS 
(you can see his issues in the I-D tracker).

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