[Nsi-wg] Submission / Trust Issues in NSI

[Joe Mambretti]

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 at ogf.org>nsi-wg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100416/66ea8e12/attachment.html