-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 protected] >> [mailto:[email protected]] 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 protected] Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQiE0uAAoJECnERZXWan7EKVsP/jktulzPsyQEfYeyeTrzNRWh Zvvut2dgyAo9p325ASp3xIyWR3rsYHdIxzaZd7GrWXIeL2wyRgxxCy+lLDXo2QJt 9Q8ER1CoQR7qjSvkh8vwPGb1QRBPEp+CbDf+NUbC8ppTjxmoj1hWJVrQaTVQE7xR PDpheA/zilBAjaGGR8xiWQ8VfuoljzihlN0rh+UPCV+aLorFxX/Ycv6c5c3FTTuH qZ+dQXObBYcc9LG/Po20jbZIS/SbCmm++Uo0+9QuuRsZoVOPwCogDbEEwCEFRsjP Kw/cV5GvOar0WlJEkNOvAoTbkyyqEejGD9u0+zaEeJNw6UjYHDvuA844ns3XhVKu rrloYbjgBSKatnZQ8PWsl1nGeifMiMVdmxF7bmNCyp2lafcjE1TsSprF/fCtoxz0 kKk9AoV1JWT+Kq9hjm64FExGieTJI1beSo1ansmduZQe/l72a4xF+U0TqNjW5NqE 8NC3w/5nqbKVo2G8R87bj4qD6kGhcf8bAyBcxZ20L+3u4e+UN8/m7lYyZoZZJeYT jBOkBUC8HxRaUgq9x9do6pmYcEY/bs6KZVMYwERIInB6n9354dvNgfit1xpVeeL4 n1s4f882grc3oYuZR77wROn6jOrHBKtEnWBdfZZz69wTxvOI+Qq/PenaUOZAlxh+ A1YdtSEWDNZX/5MyfcoK =hjna -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
