From: Sam Hartman <hartmans-ietf@mit.edu>
To: Ross Callon <rcallon@juniper.net>
Cc: sandy@tislabs.com (Sandy Murphy), adrian@olddog.co.uk,
ccamp@ops.ietf.org, dbrungard@att.com, derek@ihtfp.com
Subject: Re: Security considerations with
draft-ietf-ccamp-rsvp-restart-ext-07
References: <016001c743a1$c52e9af0$76849ed9@your029b8cecfe>
<5.0.0.25.2.20070130153346.04c50a00@zircon.juniper.net>
Date: Tue, 06 Feb 2007 14:10:36 -0500
In-Reply-To: <5.0.0.25.2.20070130153346.04c50a00@zircon.juniper.net> (Ross
Callon's message of "Tue, 30 Jan 2007 15:59:52 -0500")
Message-ID: <tsltzxzp0er.fsf@cz.mit.edu>
I think we may need a conference call on this. What times would work
for people next week?
Also, let me make a concrete proposal to move forward. I suspect that
this will not be acceptable to the WG, but hopefully it will be a
starting point for discussion and will make it clear that I'm not
asking you to redesign RSVP so that malicious routers can do no
damage.
It seems clear from the discussions to date that many path messages
will be reasonable to use with this mechanism. Adrian has tried to
argue that all path messages are safe to use with this mechansim; I
think Sandy and I have not been convinced by his arguments.
One way to move forward would be to analyze every object that can
appear in a path message now and in the future and make sure they are
safe with this mechanism. Adrian has indicated that he'd like to
avoid that work.
So, I wonder if we can limit the analysis work to that which is
actually required. I propose that we establish an IANA registry of
objects that can appear in path messages. For each object we indicate
whether restart is permitted and give a reference to the spec
containing restart security considerations for that object.
Restarting nodes must not use the procedures in this draft if they
receive a path message with an object for which restart permitted is
no (or for which no analysis has been done); downstream nodes MUST NOT
engage in these procedures if analysis has been done for an object in
the path message and restart is not permitted.
That would at least allow us to spread out the analysis over time.
Also, especially for things already existing, I'm not looking at
detailed documentation. If the CCAMP folks today are quite sure all
their existing objects create no significant new vulnerabilities, then
say that and register them all in this document.