[Nsi-wg] NML Security Requirements

[Jerry Sobieski]

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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20131114/f3c0e44b/attachment.html>