Jerry,

Thanks for following up on the discussion this morning. I had a different conclusion, maybe this email can help solicit opinions from others on the call this morning.
Clarifications below.

Jerry Sobieski
April 13, 2011 7:53 PM

Hi all-

An issue occurs to me:

First...
Given that each Network has exactly one NSA, then the implication is
that no two different NSAs can claim to represent/be the same network.

That is what the NSI architecture and the group had agreed upon. The NSA is logical here - i.e. multiple servers could be used to implement that NSA function, it does not prevent that.

Since our discussion today decided that the Network Name (used in
tuples) and the NSA_ID (used in messages) were identical, it follows
then that every NSA RA requesting a connection must be identified by an
NSA_ID that being a Network name also must be globally unique. Even
simple user codes just requesting an adhoc connection become RAs by
definition...and therefore are required to get a globally unique NSAID.
For simple user requests, this seems onerous...is this really
necessary?

Has there a construction of NSA_ID been discussed? I do not see why one is onerous and other is not. As you brought up before, there are multiple standard ways to come up with global identifiers that the R&E and other Internet communities have discussed, we need to choose the right one that is doable.

I think Tomohiro's point today in suggesting the NSA_ID, Network name merger was more fundamental:
1. There is no difference between Network Name (in tuple) and NSA ID. Since a NSA_ID uniquely represents the resources, the ID to be used in Tuples is the NSA_ID. There is no need to have Network Name.
2. Even though RA-PA conversations are local, and define the local conversation identifier not being unique. For pathfinding purposes, the NSA_ID has been discussed as the globally unique identifier. In other words, the properties of the proposed Network Name have already been associated with the NSA_ID in the previous discussions. This is what is causing the confusion IMHO. There is no reason to have two different unique names with the same properties. They represent one and the same thing.

There are some security issues that need to be universally addressed. Impersonation, Man-in-the-middle attack etc are well know techniques, and the protocol needs to provide mechanisms to prevent against that regardless whether it be a network name or NSA_ID. There will be other associated decisions on what security mechanisms to make mandatory or advisable so they are implemented based on bilateral or unilateral policy.

To the group,

The fact that we are continuing this discussion online is very healthy and will help with speed of finalizing the protocol, we cannot accomplish all discussion that we need in the Wed morning call. I encourage all of you to participate and state your opinions as these new concepts are discussed and finalized.

Inder

p.s. Also, there are many deployment models - a simple user can have a network NSA represent it (federating NSA?) - so it does not need to have unique NSAID - but this discussion is for a different place/time. We have allowed provisions for manually provisioned networks to work with NSI Connection Service enabled networks as well.

The Network names definitely need to be globally unique as they are part
of a global topology model. And by implication the NSAs representing
those networks should be uniquely addressible (though I contend they
need/ought not be defined as the same thing). The the CS protocol,
however, only talks between PA and RA. There is no inherent global
scope in this relationship, and as we concluded in Hong Kong, this
relationship only needs to be locally unique.

I believe it would significantly simplify user codes if user RAs could
dispense with constructing a verifyably global unique NSA_IDs, and
simply ask the PA to respond with a locally unique NSAID that will work
for the life of this connection conversation.

Second, what if an "NSA" deliberately hijacks an established Network
name [NSA-ID]? How do we insure this does not occur? How do we
authenticate an NSA as being the proper agent to represents a specific
[real] network domain?

Thoughts? (I know we have authenticated sessions between trusted NSAs,
but that doesn't in itself associate a network with an NSA...or more
accurately, it doesn't preclude that agent from acting as another
Network.) I think we need some specific language on this...

Regards
Jerry
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg

--
Inder Monga
510-486-6531
http://www.es.net
Follow us on Twitter: ESnetUpdates/Twitter
Visit our blog: ESnetUpdates Blog
Facebook: ESnetUpdates/Facebook