[Nml-wg] [Nsi-wg] Tutorial Topologies

[Freek Dijkstra]

Hi Chin,

Sorry for not responding sooner.
Off-list, you brought up the following issue. I hope it is OK to quote
you on-list. You brought up an important issue.

>> Thanks for sending out the topologies.
>>
>> I tried importing them into the topology service that Ahmed
>> implemented (at http://lstest.es.net), but ran a couple of issues, one
>> small, and the other a bit more involved.
>>
[...]
>> As for the more involved issue, our parser is unable to distinguish
>> between what is a reference, and what is not, so for example:
>>
>> Excerpt from aruba.xml:
>>         <!-- Aruba - Bonaire -->
>>         <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort">
>>             <nml:PortGroup id="urn:ogf:network:aruba.example:2013:aruba-bonaire">
>>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>                 <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2012/10/ethernet#vlan">1780-1783</nml:LabelGroup>
>>                 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias">
>>                     <nml:PortGroup id="urn:ogf:network:bonaire.example:2013:aruba-bonaire"/>
>>                 </nml:Relation>
>>             </nml:PortGroup>
>>         </nml:Relation>
>>
>> Excerpt from bonaire.xml:
>>         <!-- bonaire - aruba -->
>>         <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort">
>>             <nml:PortGroup id="urn:ogf:network:bonaire.example:2013:aruba-bonaire">
>>                 <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2012/10/ethernet#vlan">1780-1783</nml:LabelGroup>
>>                 <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias">
>>                     <nml:PortGroup id="urn:ogf:network:aruba.example:2013:aruba-bonaire"/>
>>                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>                 </nml:Relation>
>>             </nml:PortGroup>
>>         </nml:Relation>
>>
>> After we import the aruba.xml topology into the topology server, when
>> we import bonaire.xml, our server doesn't know Bonaire's aliased
>> "aruba-bonarie" port group is a reference, and overwrites Aruba's entry.

This very issue is covered in section 4.3 of GFD.206. This is a verbatim
quote of that section:

> 4.3 Combining Object Descriptions
> 
> A given object may have multiple attributes and relations. These
> attributes and relations may be described in different places in a
> syntax. It is up to the parser to combine all attributes and
> relations.
> 
> NML currently does not have a mechanism to check if a given
> description of an object is complete. Thus, it does not distinguish
> between a full description of an object or merely a pointer to an
> object.
> 
> Parsers should be aware that the NML descriptions do not provide any
> guarantee regarding the integrity nor the authenticity of the
> description. Parsers are advised to use external mechanism to avoid
> that an erroneous description of an object in one (possibly
> malicious) topology description pollutes a correct description of the
> same object in another topology description.

So basically, the idea is that the second (reference) description does
not overwrite the original description, but augments it, combining the two.

Either solution (replacing or augmenting a description) raises some
security issues, in that an attacker may add false descriptions of STP,
in order to insert malicious information in the topology. For that
reason, it is highly recommended that NSI implementations take the
source of information into account, and are very selective in accepting
information from a domain, that describes information about another
topology. I believe NSI has some mechanisms to

In fact, the whole isAlias construct is made specifically to make it
easier to reference between sources of information. So my recommendation
is not to accept any information about a STP or Port, from another
domain, except as the destination of an "isAlias" relation.


>> I had a couple of thoughts on this, but they may be a complete hack
>> and ugly.
>>
>> 1. If an "empty" element (that has no further nested elements, e.g.
>> Bonaire's "aruba-bonarie" port group) matches an existing "non-empty"
>> element (e.g. Aruba's "aruba-bonarie" port group), it is assumed to be
>> a reference.  This might make things like modify complicated, but
>> maybe if we can make the assumption that only "non-empty" elements can
>> modify existing elements, that might work.
>>
>> 2. Use the "isAlias" relation to assume referencing.  This will only
>> be specific to NML/NSI, but then it may be acceptable compromise.

The second one is true for all relations:

<nml:SomeObject id="A">
  <nml:Relation type="http://....#someRelation">
    <nml:OtherObject id="B">

In this case, A the _source_ and B is the _domain_ of the relation. B is
always a reference. This object B can contain some more information, but
I strongly recommend to be careful to accept any information from any
source other than the domain. (judged by the nsi:managedBy relation from
topology to NSA).

Hope this helps!

Freek


-- 
SURFsara has a new telephone number: + 31 20 800 1300.

Freek Dijkstra
| Group Leader | Network Innovation & Support | SURFsara |
| Science Park 140 | 1098 XG Amsterdam | +31 20 800 1320 |
| Freek.Dijkstra at surfsara.nl | www.surfsara.nl |

Available on Mon | Tue | Thu | Fri |