Submission / Trust Issues in NSI
Attached is a ppt that describes 4 trust areas in NSI. It is meant as a way to help discussion. I think some trust discussion should be in the eventual document. John
Hello: All of these are important issues and should be addressed as part of using an NSI. However, in my opinion, all of these issues are out of scope for the basic definition of the NSI. All IT resources must be surrounded by various trust domains. However, there are thousand of activities developing these types of techniques. The basic architecture should be agnostic about trust techniques used. Thanks. At 02:55 PM 4/13/2010, John Vollbrecht wrote:
Attached is a ppt that describes 4 trust areas in NSI. It is meant as a way to help discussion. I think some trust discussion should be in the eventual document.
John
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Joe Mambretti, Director tel 312.503.0735 International Center for Advanced Internet Research fax 312.503.0745 750 North Lake Shore Drive, Suite 600 www.icair.org Northwestern University, Chicago, Illinois 60611
Hi Joe - I agree that the way trust is implemented is out of scope. The intent of this is to start a discussion on what the trust requirements for NSI is. In particular, this is meant to identify three main issues which I summarize here in case the PPT doesn't make this overview clear. 1) Trust between either end of the NSI is required. Identification of NSAs at each end is also necessary. The protocol might support both as a single operation, or might treat them independently. 2) Attributes of the original requestor of a circuit may need to be down a chain of NSAs so the bottom NSA can use the attribute to evaluate its policy to decide whether to grant the request for resources it controls. Passing these attributes must be done in a way that allows the bottom NSA to trust the attributes it gets. This seems doable, but probably requires some special handling of these attributes as they go from NSA to NSA. I describe a way that I think will work to show that it seems possible, but this is not meant to define the way that it will work. 3) Trust between the reservation/ scheduler and the control plane is needed so that when a provisioning request is made the control plane is sure the resource is reserved for the owner of this request. This might be done in a number of ways, and I describe two approaches to doing this. In order for the standard to support interoperable implementations it is necessary for it to define how trust will be supported between implementations. This does not mean inventing the trust mechanisms (in fact this is clearly out of scope), but it seems to me it does mean defining which can or should or must be used. Does this make sense? John On Apr 13, 2010, at 4:56 PM, Joe Mambretti wrote:
Hello:
All of these are important issues and should be addressed as part of using an NSI. However, in my opinion, all of these issues are out of scope for the basic definition of the NSI. All IT resources must be surrounded by various trust domains. However, there are thousand of activities developing these types of techniques. The basic architecture should be agnostic about trust techniques used.
Thanks.
At 02:55 PM 4/13/2010, John Vollbrecht wrote:
Attached is a ppt that describes 4 trust areas in NSI. It is meant as a way to help discussion. I think some trust discussion should be in the eventual document.
John
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Joe Mambretti, Director tel 312.503.0735 International Center for Advanced Internet Research fax 312.503.0745 750 North Lake Shore Drive, Suite 600 www.icair.org Northwestern University, Chicago, Illinois 60611
Hello: This are all fine issues. However, they are secondary to the basic design of the architecture. Consider this in the context of designing a house. You first have to determine what type of house should/could be designed. Then you can address the security issues related to it. Also, other dynamic provisioning projects already have effective, working code addressing these issues. They should not be discussed as new considerations. Thanks. At 11:34 AM 4/15/2010, John Vollbrecht wrote:
Hi Joe -
I agree that the way trust is implemented is out of scope. The intent of this is to start a discussion on what the trust requirements for NSI is. In particular, this is meant to identify three main issues which I summarize here in case the PPT doesn't make this overview clear.
1) Trust between either end of the NSI is required. Identification of NSAs at each end is also necessary. The protocol might support both as a single operation, or might treat them independently.
2) Attributes of the original requestor of a circuit may need to be down a chain of NSAs so the bottom NSA can use the attribute to evaluate its policy to decide whether to grant the request for resources it controls. Passing these attributes must be done in a way that allows the bottom NSA to trust the attributes it gets. This seems doable, but probably requires some special handling of these attributes as they go from NSA to NSA. I describe a way that I think will work to show that it seems possible, but this is not meant to define the way that it will work.
3) Trust between the reservation/ scheduler and the control plane is needed so that when a provisioning request is made the control plane is sure the resource is reserved for the owner of this request. This might be done in a number of ways, and I describe two approaches to doing this.
In order for the standard to support interoperable implementations it is necessary for it to define how trust will be supported between implementations. This does not mean inventing the trust mechanisms (in fact this is clearly out of scope), but it seems to me it does mean defining which can or should or must be used.
Does this make sense?
John
On Apr 13, 2010, at 4:56 PM, Joe Mambretti wrote:
Hello:
All of these are important issues and should be addressed as part of using an NSI. However, in my opinion, all of these issues are out of scope for the basic definition of the NSI. All IT resources must be surrounded by various trust domains. However, there are thousand of activities developing these types of techniques. The basic architecture should be agnostic about trust techniques used.
Thanks.
At 02:55 PM 4/13/2010, John Vollbrecht wrote:
Attached is a ppt that describes 4 trust areas in NSI. It is meant as a way to help discussion. I think some trust discussion should be in the eventual document.
John
_______________________________________________ nsi-wg mailing list <mailto:nsi-wg@ogf.org>nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Joe Mambretti, Director tel 312.503.0735 International Center for Advanced Internet Research fax 312.503.0745 750 North Lake Shore Drive, Suite 600 www.icair.org Northwestern University, Chicago, Illinois 60611
Joe Mambretti, Director tel 312.503.0735 International Center for Advanced Internet Research fax 312.503.0745 750 North Lake Shore Drive, Suite 600 www.icair.org Northwestern University, Chicago, Illinois 60611
This is a ppt that I sent earlier that describes basic trust/ authentication/ authorization issues for NSI. I can make this into a doc if that would be useful. John Begin forwarded message:
From: John Vollbrecht <jrv@internet2.edu> Date: April 13, 2010 3:55:37 PM GMT-04:00 To: NSI WG <nsi-wg@ogf.org> Cc: John Vollbrecht <jrv@internet2.edu> Subject: Submission / Trust Issues in NSI
Attached is a ppt that describes 4 trust areas in NSI. It is meant as a way to help discussion. I think some trust discussion should be in the eventual document.
John
Hello: As I indicated when this was sent earlier, I think that these topics are out of scope for this initiative. Thanks At 09:48 AM 5/26/2010, John Vollbrecht wrote:
This is a ppt that I sent earlier that describes basic trust/ authentication/ authorization issues for NSI. I can make this into a doc if that would be useful.
John
Begin forwarded message:
From: John Vollbrecht <jrv@internet2.edu> Date: April 13, 2010 3:55:37 PM GMT-04:00 To: NSI WG <nsi-wg@ogf.org> Cc: John Vollbrecht <jrv@internet2.edu> Subject: Submission / Trust Issues in NSI
Attached is a ppt that describes 4 trust areas in NSI. It is meant as a way to help discussion. I think some trust discussion should be in the eventual document.
John
This is a ppt that I sent earlier that describes basic trust/ authentication/ authorization issues for NSI. I can make this into a doc if that would be useful.
John
Begin forwarded message:
From: John Vollbrecht <<mailto:jrv@internet2.edu>jrv@internet2.edu> Date: April 13, 2010 3:55:37 PM GMT-04:00 To: NSI WG <<mailto:nsi-wg@ogf.org>nsi-wg@ogf.org> Cc: John Vollbrecht <<mailto:jrv@internet2.edu>jrv@internet2.edu> Subject: Submission / Trust Issues in NSI
Attached is a ppt that describes 4 trust areas in NSI. It is meant as a way to help discussion. I think some trust discussion should be in the eventual document.
John
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
Joe Mambretti, Director tel 312.503.0735 International Center for Advanced Internet Research fax 312.503.0745 750 North Lake Shore Drive, Suite 600 www.icair.org Northwestern University, Chicago, Illinois 60611
participants (2)
-
Joe Mambretti -
John Vollbrecht