Melinda, Thanks for your comments.
> Still, I'm just not sure it's a great idea to get ahead of the > architecture/framework/whatever. Agreed. I do not think security framework should get ahead of arch/framework either, and don't think that was intended either. We normally start the security framework a bit later in the development when arch/framework is quite stable. Here is the reason for this update: The 00 draft was out there already; there have been a lot of discussions on the list around security issues recently, including the trust models, some discussion are triggered by the draft, some are raised simply because the needs to discuss security considerations. Thought it would be good to capture the points in the document. But it would not/cannot progress ahead of the arch/framework. All references on terminology, architecture must be based on the base framework. About the 'trusted', 'untrusted', they are not new. The terms are used in IETF RFCs/drafts all the time. I think it helps to first establish the reference points from which direction/zone the security threat are coming from, then talk about threads and requirements. > Also, I don't think that the document assumes an adversarial > environment, or at least it's not written as such. For example, > in section 5.1 list item 1, you say: "When a protocol is used for the > service auto-provisioning/discovery, the information from endpoint > shall not be spoofed or altered", when the actual requirement > should probably be along the lines of "The NVO3 provisioning and > discovery process MUST (or SHOULD, possibly) be authenticated > and integrity-protected to protect against injection attacks > against the NVO3 infrastructure," etc. Good point, will use it, thx. The current draft is far from complete, a lot more work need to be done. > Also, RFC 2119 language for the requirements. Agreed. Thanks, Luyuan > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Melinda Shore > Sent: Tuesday, July 17, 2012 3:07 PM > To: [email protected] > Subject: Re: [nvo3] FW: New Version Notification for draft-wei-nvo3- > security-framework-01.txt > > On 7/17/12 10:41 AM, Luyuan Fang (lufang) wrote: > > Security models have been updated to reflect the discussion on the > > list with two different scenarios, and the new figures may be more > > readable. There are other update/additions throughout the document > > as well. > > The difficulty with doing a document like this given the current state > of the working group is that there is no framework yet, and no working > group consensus about some fairly basic architectural and technical > questions. Putting a security framework before a framework seems odd > at best, but mostly likely to lead to a situation in which it's too > general to be useful. > > However, given that it was written anyway, I have to say that I've > never been particularly comfortable with the notion of a trusted > network and find it particularly troubling in this context, given > that tenants complicate the scenario quite a bit. They are not > fully trusted but not fully untrusted, either, and presumably have > increased access to the underlying network over what someone not > in a business relationship with the data center would have. > > Also, I don't think that the document assumes an adversarial > environment, or at least it's not written as such. For example, > in section 5.1 list item 1, you say: "When a protocol is used for the > service auto-provisioning/discovery, the information from endpoint > shall not be spoofed or altered", when the actual requirement > should probably be along the lines of "The NVO3 provisioning and > discovery process MUST (or SHOULD, possibly) be authenticated > and integrity-protected to protect against injection attacks > against the NVO3 infrastructure," etc. > > Also, RFC 2119 language for the requirements. > > Still, I'm just not sure it's a great idea to get ahead of the > architecture/framework/whatever. > > Melinda > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
