Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-09

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 24 Oct 2012 13:19:00 -0700

Sorry, I just realized that I forgot to answer this email.  See below.

On 09/27/2012 06:04 PM, Songhaibin wrote:
> Hi Marc,
> 
> Thank you very much for the feedback. See inline.
> 
>> -----Original Message----- From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Marc Petit-Huguenin Sent: 
>> Wednesday, September 26, 2012 12:52 AM To: Rosen, Brian Cc: P2PSIP WG 
>> Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-diagnostics-09
>> 
> I carefully read this I-D, and I found a lot of nits, which make it 
> difficult to read.  I think that this draft is ready to be submitted to
> the IESG, but I would like to start a discussion on one specific point, 
> security.
> 
> 
>> Thanks, the document will double checked and updated.
> 
> The draft is very light on the discussion about who is authorized to do 
> what. Obviously some of the information that can be requested are
> sensitive, and I am afraid that without having a mechanism for
> authorization in the document, implementers will be reluctant to add it to
> their implementation.
> 
> 
>> Good point!
> 
> I think especially of SOFTWARE_VERSION, but there can be future
> Diagnostics Kinds that are not for general availability.
>> So I would suggest to define in the spec an
> additional mechanism to restrict the access to some Kinds:
> 
> The idea would be to add an extension in the configuration file to
> authorize access to these Diagnostics Kinds only to a specific list of
> Node-IDs (in a similar way that signer node-IDs are authorized to sign kind
> and configuration elements in signer and king-signer elements.
> 
> 
>> This should work. Could this lead to the over dynamic of the
>> configuration file?

First of all, I do not think that changing relatively often the configuration
file is a bad thing - that certainly would exercise part of an implementation
that will be required to work perfectly in case of problem - for example to
blacklist nodes, change a signer certificate or even change the CA certificate.

Then, at least for the usage of SOFTWARE_VERSION that I foresee, there should
not be a need for too many modifications of the list of nodes authorized to
query this value.  My main use case for SOFTWARE_VERSION is to check that
RELOAD implementations in an overlay do not come from the same vendor, so a
problem during an software upgrade cannot kill the whole overlay.  This
function will be initiated by nodes that are under the control of the same
people who manage the bootstrap and enrollment servers, servers that are part
of the configuration file.  So I do not expect more updates related to this
function than there could be for maintaining the enrollment and bootstrap servers.

>> Another option is for each Kind, just stored these signed IDs as a value
>> in the overlay.

That would require that the node does a Fetch before responding to a
SOFTWARE_VERSION query.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug