[Nsi-wg] Question about message attrbutes..

Tue Aug 9 10:03:06 CDT 2011

Hey John-   Let me try to answer some of these scenarios:

On 8/9/11 8:59 AM, John MacAuley wrote:
> Going through the effort of provisioning a peer NSA and associated 
> public key certificates would indicate to me that I have set up a 
> level of trust with that NSA and am willing to accept any messages 
> sent to me as part of that trust establishment.  However, do we 
> believe that the processing of that message may be influenced based on 
> the NSA from which it arrived, or is this purely based on the original 
> user associated with the message?
Neither, if we are pedantic about terms here:-)  Authorization of the 
request is based upon the credentials that are associated with the 
request (not the NSA or the message per se).  It matters not from which 
NSA the request came, nor does it matter if the credentials presented 
are those of the original requester or not.   All an NSA knows is what 
it finds in the inbound request message.  Its impossible (as currently 
defined) to know the provenance of that request or the provided 
credentials from just the request itself.   (This does open up a 
discussion about possibly extending the query to work *up* the tree to 
find the provenance of a request rather than just down the tree as 
currently defined - under authorization of course. ...This is v2.0 though.)
> Of course, I may put administrative limits on the number of messages 
> received per second/hour/day, but I can't restrict the actual 
> processing of CS messages once received?
There are a lot of ways and reasons to block NSA-to-NSA communication.   
We need to make sure that the protocol - particularly the MTL - handles 
all such situations in a finite state machine.   I.e. if communications 
is blocked, the protocol should be able to handle it appropriately.   I 
think the MTL returns a "undeliverable message" exception to the sending 
NSA if the session cannot be established and the message queued for the 
remote NSI processing.  Right?   As long as the protocol can deal with 
rejection or failure to communicate in a predictable fashion, we are 
ok.   We just can't abide surprises.
>
> I have always taken the position that authorization of the CS message 
> and access to local resources needs to be based on the user 
> credentials supplied in the message.  I believed a user should get a 
> similar experience within the network regardless of the path his/her 
> message takes through the NSA tree.  For example, if Bob issues a 
> message to his local NSA A which then passes the message to NSA B and 
> then on to NSA C where the connection is authorized and reserved, I do 
> not think it should be possible to fail that same message if routing 
> sent the message from A->D->C.  If A has a trusted relationship with B 
> and D, and B and D have a trusted relationship with C, why would we 
> get different behaviours from a CS protocol perspective if B and D are 
> just transit NSA?
First, messages aren't authorized, *requests* are authorized.   messages 
are just containers.

More to th epoint:  NSA Bob's reservation request is authorized at A 
according to the associated authorization credentials found in the 
message (presumably "userid=Bob") and NSA A's local authorization 
policy.  Assuming it passes A's authorization, then NSA A then issues a 
subsequent reservation request message to B, presumably (but not 
necessarilly) containing the same userid authorization.   NSA B 
authorizes the specific request from A according to the authorization 
credntials presented, and B's local authorization policy.  (Note- B may 
have different authorization profiles from A)   This sequence could go 
on forever.   NSA A could pass along userid=Bob credentials, or NSA A 
could alternatively decide to use a different set of credentials it 
deems appropriate for this request.   So, B does not know (or care IMO) 
who is the ultimate RA...all B knows is that a request came from A 
containing a particular set authorization credentials.   B will act on 
that information alone.

If Bob's userid is recognized at NSA C, then Bob can just send the 
request directly to C.   IF for some reason Bob cannot contact C (e.g. 
no session authorization, or Bob does not know of C at all) then Bob is 
at the mercy of NSA A and/or NSA B.   We do not punch thru an NSA's 
security simply because it does not provide a local segment or we expect 
some down stream network to actually provide the resources.  In our 
model, messages do not transparently transit any NSA - all messages are 
processed at each NSA.  The service requests carried in the messages 
cause a tree to be constructed.  In the case above, the service tree 
includes Bob (ultimate RA), NSA A, NSA B, and NSA C (ultimate PA).    If 
NSA A elects to build a different tree by either transiting network D or 
bypassing B and D altogether and going directly to C, that is NSA A's 
internal choice and Bob has little (if any) formal control over it.
>
> Should NSA D be able to enforce a policy that says I will not route 
> messages from NSA A to NSA C?  This implies that trust is not 
> transitive from a CS messaging perspective even though the reservation 
> would ultimately succeed.  I guess we need to step back and ask why 
> would NSA A use NSA D to route a message to NSA C?  Obviously NSA D 
> incorrectly advertised to NSA A the reachability to NSA C.
Ah you make *WAY* too many assumptions.   First, advertising 
reachability - NSI has no current idea of advertising any routing or 
topology.   An NSA *magically* knows of a topology map - we make no 
assertions of how it learned that information or its validity.   Second, 
trust is not a protocol issue.  Authorization policies embody the 
trust:  Each NSA has the power to allow or deny *any* transaction across 
its network based soley on its own local policies.   "Trust" is 
established when two networks mutually agree to implement a common set 
of policies that allow certain transactions to occur between them.  They 
trust each other.    By definition, if local policy does not allow 
certain interactions, then those interactions are not trusted.  And vice 
versa: if two networks trust one another, it is measured by their mutual 
adoption of appropriate common/shared authorization strategies (Policies).
>
> Hmmm... Okay, I have talked myself into the need for an NSA to enforce 
> local policy rules based on the source and destination NSA.  I may 
> want to stop a public facing NSA from routing through to a private 
> network segment, however, I should never advertise that private 
> segment to the public facing NSA to try and avoid false positives on 
> path computation.
:-)   There is an old monty python skit where an old lady claims victory 
in an argument "See there!  I'm running rings around you logically!"

Best regards
Jerry
>
> John.
>
> On 2011-08-08, at 11:33 PM, Inder Monga wrote:
>
>> Jerry and John,
>>
>>>> NSA-to-NSA authorization is a local implementation issue based on 
>>>> the establishment of trust, however, I believe Mary's accepted 
>>>> proposal was to do user based authorization on each message using 
>>>> the user context provided in the security parameters.
>>> Hmm...This sounds rather murky.  What do you mean based on 
>>> establishment of trust?   If you mean an NSA is free to accept or 
>>> reject another NSA's session on purely local whim (i.e. arbitrary 
>>> local policy) then we should be specific and clear about it.    
>>> (BTW- I actually agree with this:-)
>> Trust could be based on a simple thing as "administrative 
>> configuration" or more extensive process?
>>
>> Inder
>>
>>>
>>> I presume then that there is a userid in the sessionSecurityID field 
>>> somewhere?    Can we spec this out in detail for the coders what the 
>>> "user" authorization profile info will look like in the security 
>>> attribute?
>>>
>>>> We really do not have the concept of a long duration session in the 
>>>> NSI protocol.  Each message exchange is a discrete event in which 
>>>> an NSA can connect, authenticate, send, and tear down the transport.
>>> Ok, this makes me fidgety, but its not an issue at the moment.
>>>
>>> Thanks for elaborating...all is clearer now.
>>> Jerry
>>>>
>>>> John.
>>>>
>>>> On 2011-08-08, at 4:01 PM, Jerry Sobieski wrote:
>>>>
>>>>> John - this may be for you...
>>>>>
>>>>> In reviewing this issue on the RA/PA... I went looking at the UML 
>>>>> doc Guy circulated as it is a bit easier to read than the raw WSDL...
>>>>>
>>>>> The messages all have the requesterNSAID and the providerNSAID 
>>>>> fields, directly folowed by the "sessionSecurityID".   This is the 
>>>>> only field I see for security attributes.
>>>>>
>>>>> I thought our conclusion was that there would be two security 
>>>>> layers: a NSA _/session/_ level authentication/authorization 
>>>>> credentials, and a /_request_/ level authorization credential that 
>>>>> would authorize the particular action requested relative to the 
>>>>> resource or information context of the request.  Does this 
>>>>> sessionSecirity field do double duty authenticating the remote NSA 
>>>>> *and* authorizing the particular service request?
>>>>>
>>>>> I trust the MTL to authenticate the messaging, as the NSI layer 
>>>>> should never see messages from an unauthenticated NSA.   But the 
>>>>> NSI layer does need the authorization credentials in order to 
>>>>> properly evaluate the primitive... The authorization of an NSI 
>>>>> request is not an MTL function.   So I am just a bit unsure how 
>>>>> this field is planned to be used within the WSDL.
>>>>>
>>>>> Thoughts/Comments?
>>>>> Jerry
>>>>> _______________________________________________
>>>>> nsi-wg mailing list
>>>>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>>>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>> ------------------------------------------------------------------------
>>>
>>> John MacAuley <mailto:john.macauley at surfnet.nl>
>>> August 8, 2011 4:38 PM
>>>
>>>
>>> Jerry,
>>>
>>> We delegated the issue of NSA-to-NSA authentication to the transport 
>>> layer.  We will also validate message integrity and that the message 
>>> is coming form the expected NSA. NSA-to-NSA authorization is a local 
>>> implementation issue based on the establishment of trust, however, I 
>>> believe Mary's accepted proposal was to do user based authorization 
>>> on each message using the user context provided in the security 
>>> parameters.  We really do not have the concept of a long duration 
>>> session in the NSI protocol.  Each message exchange is a discrete 
>>> event in which an NSA can connect, authenticate, send, and tear down 
>>> the transport.
>>>
>>> John.
>>>
>>>
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>> ------------------------------------------------------------------------
>>>
>>> Jerry Sobieski <mailto:jerry at nordu.net>
>>> August 8, 2011 1:01 PM
>>>
>>>
>>> John - this may be for you...
>>>
>>> In reviewing this issue on the RA/PA... I went looking at the UML 
>>> doc Guy circulated as it is a bit easier to read than the raw WSDL...
>>>
>>> The messages all have the requesterNSAID and the providerNSAID 
>>> fields, directly folowed by the "sessionSecurityID".   This is the 
>>> only field I see for security attributes.
>>>
>>> I thought our conclusion was that there would be two security 
>>> layers: a NSA _/session/_ level authentication/authorization 
>>> credentials, and a /_request_/ level authorization credential that 
>>> would authorize the particular action requested relative to the 
>>> resource or information context of the request.  Does this 
>>> sessionSecirity field do double duty authenticating the remote NSA 
>>> *and* authorizing the particular service request?
>>>
>>> I trust the MTL to authenticate the messaging, as the NSI layer 
>>> should never see messages from an unauthenticated NSA.   But the NSI 
>>> layer does need the authorization credentials in order to properly 
>>> evaluate the primitive... The authorization of an NSI request is not 
>>> an MTL function.   So I am just a bit unsure how this field is 
>>> planned to be used within the WSDL.
>>>
>>> Thoughts/Comments?
>>> Jerry
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> -- 
>> Inder Monga
>> 510-486-6531
>> http://www.es.net <http://www.es.net/>
>> Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd>
>> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3>
>> Facebook: ESnetUpdates/Facebook <http://bit.ly/d2Olql>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110809/bc52f7c2/attachment-0001.html 