Hi Henrick, Your e-mail is quite enlightening with respect to requirements. Mu comments follow inline. On 11/11/2013 1:42 μμ, 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.
I believe that XML sig could prevent/detect any potential tampering.
* There should be a mechanism to prevent (well filter/detect) NSAs from publishing topologies, where ids overwrite other ids (injection). I believe XACML can offer the desired filtering capabilities...
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)
Not necessarily..
* That it peers with the NSAs of the respective topologies (and can hence setup circuits on it) I believe you/we might need different attributes for this on your capability exchange.. (much as it is with the BGP) * 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. And the history repeats itself with the cross-signing..
Of course DeIC could publish their own topology, but it is difficult to see what is gained by having NORDUnet relay it. NORDUnet may act as a "trusted integrator".
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?
I believe that it is possible to tweak this in limited distribution.. by an attribute.. (a Well Known one or a custom one) as it was the case with BGP communities.
Since topology is - inherently - meant for distribution, it is difficult to restrict the distribution of it. (See my previous comment.. and you can act as aggregator..) 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.
Cheers, Dimitris
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
-- Dimitrios K. Kalogeras Electrical Engineer Ph.D. Network Engineer NTUA/GR-Net Network Management Center _____________________________________ skype: aweboy voice: +30-210-772 1863 fax: +30-210-772 1866 e-mail: D.Kalogeras@noc.ntua.gr