[Nsi-wg] NML Security Requirements

[Dimitris Kalogeras]

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 at 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 at noc.ntua.gr