Hi Henrik (and all) -

I too doubt that we can really differentiate topology announcements by their "sensitivity".   I don't think we can control redistribution once a topology is announced publicly. If we announce more than one topology (on the basis of supposed sensitivity) we have to consider what will happen when a downstream agent leaks the information and other agents encounter two or more topologies claiming to describe the same Service Domain (or put another way - if *we* see two different topologies pertaining to the same NSI service domain - what should our NSA do?)

First, it is critically important that any topology that is announced (or encountered) be trustworthy- that we know firstly that it was indeed announced by the NSI Network it represents and has not been tampered with. Which requires authentication, which implies a trusted service or chain of authority.   We do not currently have a topology service authority.    I think this is probably fairly easy to solve, but it requires agreement and acceptance and someone to run the authority(s).    However it is done, it needs to be addressed and clearly defined so that we know our topology information came from a legitimate source.

IMO, when you advertise a topology, it is no longer in your control. It becomes impossible to prevent someone from redistributing it or sharing it downstream.   Thus differentiated announcements for a single service domain would be pointless.

However, there may still be multiple topologies in circulation at any time due to legitimate updates of the one topology and convergence delays. So, even though only one topology is current, there may be multiple copies out there in circulation.

*IF* you feel there are features that need to be differentiated publicly for some reason, then define different services. And then annouce two different service domains. Since the NSI topology model represents logical [service] domains - not physical infrastructure, many NSI service domains can be easily defined and advertised to express different topological capabilities. The internal NRM can sort the local engineering issues out under the covers.

So, I recommend the following rules as discussion points for topology announcement/redistribution:
1. All topology announcements must be able to be authenticated.
2. Each Topology announcement is timestamped as to when it is in effect.
2a. A topology should include a Time-to-Live and/or an Expiration Date (?)
3. Only complete topologies are announced. I.e. A topology announcement comprises the entire and complete topology that is officially publicly available for a given NSI Service Domain. ( No partial announcements or "updates" are defined at this stage.)
4. All topologies should be authenticated before they are used.   The authenticating server should indicate whether the announcement is authentic and if it is current. (i.e. should a stale topology be authenticated?)
4.5 If two announcements for the same NSI Service Domain are encountered, only the latest announcement is considered "current" and is the only topology that should be used.
5. A NSI Service Domain should announce only one current topology. And an NSI Service Domain should always announce a new topology if/when the announced topology has changed.
6. The minimum required topology that a NSI Service Domain *must* announce is:
    a. the NSI Network Service Domain Identifier (i.e. the <networkId>)
    b. the NSA that speaks for the domain
    c.. the SDPs this domain shares with neighbor domains in the data plane.
    d. a pointer to the Service Definition document that describes the Service Type of the domain.
    All other topology information is optional.
7. A topology server may announce *any* topology.   It is up to the receiving agent to authenticate the announcements associated with different service domains before using them.
8. An "Announcement" is posted publicly and may be a) pulled down by clients, or b) pushed to clients who have registered for updates.

THoughts?
Jerry

On 11/11/13 6:42 AM, Henrik Thostrup Jensen wrote:

So, requirements for secure topology distribution.

Personally, I don't quite believe in "requirements", as system design inherently contains tradeoffs between functionality, complexity, security, and usability (we usually only focus on the first). However it is topic that deservices some more light.

Some basic stuff:

* An NSA should be able to publish its topology, and others NSAs should be able
to retrieve it in such a way that it has not been tampered with.

* There should be a mechanism to prevent (well filter/detect) NSAs from
publishing topologies, where ids overwrite other ids (injection).

Any further requirements depend on what functionality it is we want have in
topology distribution and how topology and path finding should work (which is,
at least to me - still up in the air).

One thing, I think we should start making clear is what it means when an NSI
XML document has multiple (NML) topologies in it?
* Does it mean that it administrates the topology (I believe we agreed on this)
* That it peers with the NSAs of the respective topologies (and can hence setup circuits on it)
* That it is simply relaying information somehow

One solution that have come up to prevent injection / to allow an NSA to
publish topologies for altnernate domains (those two things are more or less
the same, but with very different intentions) is to sign the nml:Topology
element. E.g., the NORDUnet NSA could announce both the nordu.net topology and
the deic.dk (the danish NREN) topology. However, NORDUnet and DeIC are
different adminstrative organizations, and NORDUnet should not have their
certificate (hence I cannot use SUNET as an example). Certificates should not
be thrown around like that. Of course DeIC could publish their own topology,
but it is difficult to see what is gained by having NORDUnet relay it.

Furthermore we do not have an everyone-trusts-everyone model in NSI (which is a
good thing), but instead have transitive trust. There is no guarantie that
anyone else than your peers (whatever that means), actually knows your
certificate.

Further questions:

* Can topology information be sensitive? I.e. have limited distribution?

Since topology is - inherently - meant for distribution, it is difficult to
restrict the distribution of it. I suggest we try not to deal with this.
Remember, that termination points should not have to be listed, as there
might be an awful lot of them, and that the core point of topology exchange
is to facilitate pathfinding.

Best regards, Henrik

Henrik Thostrup Jensen <htj at nordu.net>
Software Developer, NORDUnet

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg