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
