Subject: [nvo3] FW: New Version Notification for draft-wei-nvo3-security-framework-01.txt

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 17 Jul 2012 18:41:46 +0000

An updated version of nvo3-security-framework draft is available.
http://www.ietf.org/id/draft-wei-nvo3-security-framework-01.txt

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. 
Appreciate your comments.

Thanks,
Luyuan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 16, 2012 7:39 PM
To: Luyuan Fang (lufang)
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for draft-wei-nvo3-security-framework-01.txt

A new version of I-D, draft-wei-nvo3-security-framework-01.txt
has been successfully submitted by Luyuan Fang and posted to the
IETF repository.

Filename:	 draft-wei-nvo3-security-framework
Revision:	 01
Title:		 NVO3 Security Framework
Creation date:	 2012-07-16
WG ID:		 Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-wei-nvo3-security-framework-01.txt
Status:          http://datatracker.ietf.org/doc/draft-wei-nvo3-security-framework
Htmlized:        http://tools.ietf.org/html/draft-wei-nvo3-security-framework-01
Diff:            http://tools.ietf.org/rfcdiff?url2=draft-wei-nvo3-security-framework-01

Abstract:
   This document provides a security framework for overlay based
   network virtualization. It describes the security reference model,
   the security threats and security requirements.

The IETF Secretariat

---

From: Melinda Shore <[email-masked]>
Date: Tue, 17 Jul 2012 11:06:56 -0800

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

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 17 Jul 2012 19:58:06 +0000

Melinda,

Thanks for your comments.

> 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. 

> 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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Melinda Shore
> Sent: Tuesday, July 17, 2012 3:07 PM
> To: [email-masked]
> Subject: Re: [nvo3] FW: New Version Notification for draft-wei-nvo3-
> security-framework-01.txt
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Melinda Shore <[email-masked]>
Date: Tue, 17 Jul 2012 12:09:53 -0800

On 7/17/12 11:58 AM, Luyuan Fang (lufang) wrote:
> 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.

They are, but to be honest I don't think I've seen them used like
this, anywhere.  It was certainly the case that, for example,
rserpool tried to make similar assumptions about the security of
so-called "trusted networks" and was, uh, gently corrected.

And as I mentioned the last time around, and was not answered,
there's a question of scoping here:  do you really want this
draft only to be applicable to cases when there's a high degree
of "trust" of all devices connected to a given overlay?

Melinda

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 17 Jul 2012 21:25:36 +0000

> of "trust" of all devices connected to a given overlay?

No. 
Working with the "untrusted" must be supported, it just means the security threats from the untreated need to be considered and mitigated.
If only working in the trusted zone, there is much less needs to do the doc.

Thanks,
Luyuan  

> Sent: Tuesday, July 17, 2012 4:10 PM
> To: Luyuan Fang (lufang)
> Cc: [email-masked]