assessment of security extended xml-based management · quest to a server (a netconf agent) which...

HAL Id: inria-00084004https://hal.inria.fr/inria-00084004

Submitted on 5 Jul 2006

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Assessment of security extended XML-basedManagement

Vincent Cridlig, Humberto Abdelnur, Radu State, Olivier Festor

To cite this version:Vincent Cridlig, Humberto Abdelnur, Radu State, Olivier Festor. Assessment of security extendedXML-based Management. [Research Report] 2006, pp.18. �inria-00084004�

https://hal.inria.fr/inria-00084004

https://hal.archives-ouvertes.fr

Assessment of security extended XML-based Management

V. Cridlig H. Abdelnur R. State O. Festor

July 5, 2006

Abstract

The emergence of new management paradigmshaving XML as a core foundation block demandsa comprehensive analysis of their security andperformance issues. This paper presents an ex-tension to the existing NetConf protocol. Thisextension consists of a security architecture andsome advanced XML specific features. We de-scribe a series of experiments addressing the per-formance and operational aspects of our devel-oped implementation and provide grounded an-swers to issues of significant relevancy to the re-search community.

1 Introduction

Flexible management paradigms based on XMLas an underlying core support emerged over thepast years and are currently becoming opera-tional. This fast paced evolution was possibledue to the XML data-level interoperability aswell as due to the large basis of supporting toolsand libraries existing for most programming lan-guages. Although much has been done, somefundamental questions related to the security ar-chitecture and more advanced XML specific op-erations are still open. Our work within thislandscape is centered on providing a securityframework for XML enabled management frame-works, implementing and validating the IETFendorsed Netconf protocol [10] and validating itsappropriateness for complex network manage-ment tasks (like for instance the configurationof the BGP routing plane). This is addressed inthe first section of our paper.

The second section of this paper introducessome proposed extensions to the Netconf config-uration protocol. These extensions are relatedto a security framework for Netconf, compres-sion and to the edit-config operation for addi-tional XSLT support. The third section of thepaper presents the benchmarking results of ourimplementation and its security extensions. Theimplementation itself is shortly described in sec-

tion 4, highlighting its modular architecture. Insection 5, an overview of the related works isgiven. Finally, section 6 concludes the paper.

2 Netconf

2.1 General architecture

Netconf is a XML-based network configurationprotocol, proposed by the IETF in order toachieve simplicity and management data hierar-chy. Netconf is stream-oriented and relies on aRemote Procedure Call (RPC) mechanism. Theclient (a Netconf manager) typically issues a re-quest to a server (a Netconf agent) which re-turns a reply rpc-reply. An rpc tag always em-beds a Network Management operation whichcan be one of get, get-config, edit-config, copy-config, lock, unlock, close-session or kill-session.

An important point is that a manager seesthe configuration data as a XML document, thusgiving him a very high, uniform, easy and clearabstraction level. The operations are conceptu-ally performed on that virtual or real document.No other communication channel is even neededsince all services can potentially be configuredthrough Netconf.

Before sending rpc operations, a managermust first establish a Netconf session on theagent. A session is carried over a TCP connec-tion and remains open until a close-session orkill-session is issued to the agent. In order to ini-tialize that session, each party sends a hello mes-sage containing its capabilities and a session-id isissued by the agent. This message is exchangedasynchronously over the TCP connection. Ca-pabilities are a feature that allows each partyto advertise its supported features (data model,vendor-specific operations, etc...). Each capabil-ity is identified using a unique URN identifier.Netconf defines a set of capabilities like, for in-stance, #xpath, #startup, #candidate that canbe extended with new ones.

Get and get-config operations allow to retrievedata from the Netconf agents and come with two

1

possible filtering methods. While the first one,subtree filtering, is specific to Netconf, the sec-ond one, XPath, is an independant technology.Figure 1 shows a very simple example that al-lows to retrieve the software packages installedin the agent. This list of RPM packages is partof the data model. The first request addressesthe desired data with an XPath expression. Thesecond one is based on subtree filtering.

Each method has its interest. XPath allows tobuild fine-grained request like /netconf/system-/rpm-list/rpm[contains(text(),’java’)] which se-lects all rpm elements that contain java intotheir text value. It is also possible to select thenumber of output nodes and the text value atdifferent XML level using multiple criteria. Sub-tree filtering allows to build a kind of templatedocument that is filled by the agent. It is legit-ime to wonder if one of the methods is moreperformant than the other, and this questionhas been actively debated in the IETF workinggroup (see https://psg.com/lists/netconf/). Wehave performed a series of experiments on thisissue and the results are discussed in this paper.

2.2 Extended Netconf

The current IETF specifications [10] representa pragmatic solutions for XML based networkmanagement, making for commonly agreed onstandard. We extended the IETF proposedspecifications with more advanced features re-lated to security, efficient data transmission andagent site filtering and scoping functionalities.These extensions and their experimental bench-marking are the main focus of this paper.

2.2.1 Security

Extending the Netconf protocol with advancedsecurity features is of crucial importance in amulti-party configuration environment, wherelarge scale infrastructures are managed by mul-tiple administrators having different competen-cies and security clearance levels. An illustra-tive example can be considered the manage-ment of the BGP [21] routing plane, used to in-terconnect routing domains called AutonomousSystems (AS), where each such domain can beroughly seen as a standalone administrative do-main. Within such a domain, a specific rout-ing policy is implemented to reflect managementand business requirements. Routing informationis exchanged between these domains using anexterior routing protocol. The most commonlyused is the BGP4, supporting basic route reach-

ability advertisement as well as more advancedfeatures related to traffic engineering tasks andpolicy driven routing. These features are pro-vided by a set of protocol extensions allowing tofilter route advertisements, tag specific routes inorder to drive the route selection process, and tosignal to a peering router local preferences.

These features allow to define a routing pol-icy for an AS. There is a central registry whereoperators can publish their routing policies andcheck the ones published by other operators.Unfortunately, as it is well known, this informa-tion is very often obsolete and outdated. Theserouting policies are essentially management dataand could be made accessible to peering part-ners if appropriate access control mechanismswere defined. The real world practice showsthat operators tend to implement these policiesat the relative low level of abstraction given byrouter configurations. The de-facto configura-tion files store in text format the configurationcommands. Expressing routing policies withcommands (compatible with Command Line In-terface, CLI [22]) is typically done with routemaps. If appropriate access control were to bedefined, an operator should be able to allow apeering partner to access in read only mode, onlythose policies related to the latter, without leak-ing additional information related to third partypotential competitors. As of today, such a sce-nario is impossible, and for illustration purposesconsider the scenario shown in Figure 2. Thisnetwork topology consists of three ASs: AS 1,AS 2 and AS 3. Routers R1, R2 and R3 belongto autonomous system AS 1, AS 2 and respec-tively AS 3. Both R1 and R2 are neighbors ofR3.

Figure 2: BGP sample topology

A subset of the BGP configuration for routerR3 is depicted in Figure 3 in a Command LineInterface (CLI) language. This BGP configura-tion expresses the following routing policy. First,R3 allows to route BGP packets only if the ASof the source is 3. It means that route advertise-ment from R1 and R2 will never be forwarded

<get−config> <source> <running/> </source> <filter type="subtree"> <netconf> <system> <rpm−list/> </system> </netconf> </filter> </get−config></rpc>

<rpc message−id="2"> <get−config> <source> <running/> </source> <filter type="xpath"> /netconf/system/rpm−list </filter> </get−config></rpc>

<rpc message−id="2">

<rpc−reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message−id="2"><netconf> <system> <rpm−list> <rpm>java−1.4.2−gcj−compat−devel−1.4.2.0−40jpp_31rh</rpm> <rpm>ant−jmf−1.6.2−3jpp_8fc</rpm> <rpm>jdepend−2.6−2jpp_3fc</rpm> <rpm>XSV−2.0−3</rpm> <rpm>totem−1.0.4−1</rpm> [...] </rpm−list> </system></netconf></rpc−reply>

netconf

system

rpm−list

rpm rpm rpm rpm rpm

java ant xsv totem xmlsec

XPath Subtree filtering

RESULT

Figure 1: Simple get-config examples for RPM list retrieval

by R3 to other routers. Consequently, R3 willnever give any information to R2 about the exis-tence of R1 and vice versa. Second, R3 adds 50to the weight of the route from R1 to R3. Third,R3 adds 100 to the weight of the route from R2to R3. Therefore R3 will rather use R1 than R3.

AS2

AS1

R3

router bgp 3 neighbor 192.68.80.1 remote−as 2 neighbor 192.68.80.1 route−map ROUTEMAP2 in neighbor 192.68.80.1 route−map ROUTEMAP3 out neighbor 172.32.20.2 remote−as 1 neighbor 172.32.20.2 route−map ROUTEMAP1 in neighbor 172.32.20.2 route−map ROUTEMAP3 out

route−map ROUTEMAP1 permit 10 set weight 50

route−map ROUTEMAP2 permit 10 set weight 100

ip as−path access−list ALLOWED_AS permit ^3_$

route−map ROUTEMAP3 permit 10 match as−path ALLOWED_AS

Manager m2

Manager m1

Figure 3: Network Sample CLI configuration

This configuration information is difficult toextend with a flexible access control (at the AS3site) allowing for instance to allow two managersfrom AS1 and respectively AS2 to read only thepolicies related to their own domains.

However, the same configuration settings, canbe expressed in an XML data model as shown

in Figure 4. Although XML configuration mightbe more difficult to deal with by an experiencedadministrator, there are some major advantagesfrom a security point of view. The hierarchicalstructure of an XML document can be used toimplement a flexible access control, where enti-ties could be allowed a per node or per subtreeaccess.

For instance in the previous example, we couldallow read only access to the route-map nodes.

Integrated Security Framework Figure 5shows our integrated security components pro-posed in [7]. The core is split into four main se-curity areas: authentication, integrity, confiden-tiality and access control. Each area is relatedto one or more adjacent techniques or concepts.For instance, XML-Encryption is dedicated toconfidentiality. Access control means a flexiblemechanism to manage access to resources. Theflexibility aspect is evaluated regarding the plat-form dynamicity and size. While dynamicity im-plies the capability to frequently modify the ac-cess rights, the size is dependant on the numberof devices and managers. Authentication is themechanism that guarantees that an entity is theone it claims to be. Integrity is the mechanismthat ensures that the management data in tran-sit has not been modified.

AS1

<bgprouter> <as−number>3</as−number> <neighbors> <neighbor> <ip−address>172.32.20.2</ip−address> <remote−as>1</remote−as> </neighbor> <neighbor> <ip−address>192.68.80.1</ip−address> <remote−as>2</remote−as> </neighbor> </neighbors> <address−families> <ipv4−address−family> <type>unicast</type> <neighbors> <neighbor> <ip−address>172.32.20.2</ip−address> <bind−filters> <route−map> <name>ROUTEMAP3</name> <direct>out</direct> </route−map> </bind−filters> </neighbor> <neighbor> <ip−address>192.68.80.1</ip−address> <bind−filters> <route−map> <name>ROUTEMAP3</name> <direct>out</direct> </route−map> </bind−filters> </neighbor> </neighbors> </ipv4−address−family> </address−families> </bgprouter>

</bgp>

Manager M1

<bgp>R3

/bgp/filters/route−map[map−tag=’ROUTEMAP1’]

read only

<filters> <as−path> <name>ALLOWED_AS</name> <state>permit</state> <regexp>^3_$</regexp> </as−path>

<map−tag>ROUTEMAP1</map−tag> <sequences> <seq−number>10</seq−number> <state>permit</state> <set> <weight>50</weight> </set> </sequences>

<route−map> <map−tag>ROUTEMAP2</map−tag> <sequences> <seq−number>10</seq−number> <state>permit</state> <set> <weight>100</weight> </set> </sequences> </route−map> <route−map> <map−tag>ROUTEMAP3</map−tag> <sequences> <seq−number>10</seq−number> <state>permit</state> <match> <as−path> <as−path−name>ALLOWED_AS</as−path−name> </as−path> </match> </sequences> </route−map> </filters>

<route−map>

</route−map>

Figure 4: Network Sample XML configuration

WAN

RBAC system

XML security

NetConf

role key for encryption and authentication

application level access control

CPa CPb

EQ

Key distribution center

K role

roleK

��

role

Figure 5: Conceptual security components

In order to address an efficient security plane,we consider a distributed Role Based AccessControl (RBAC [14]) type mechanism, in whichroles are distributed on the fly. However, accessis performed in a non-intermediated way, mean-ing that the architecture delivers tokens (confi-dentiality and authentication keys) to principals.To prove the ownership of tokens, an entity signsand cyphers the messages with the keys boundto the roles. In order to manage this dynamicity,we need a fast mechanism for the key exchangesystem. This is particularly obvious if role revo-cations are considered.

We consider in this article an XML-basedmanagement environment where agents use theNetconf protocol. We will give only a high levelpresentation of the general architecture. A de-tailed description can be found in [7]. There-fore, we propose the use of already defined XMLsecurity paradigms (XML-Signature [3], XML-Encryption [13]) to perform data access control.

Our security model for Network configurationis built around several main entities depicted onFigure 5. While configuration providers (CP)act like a data configuration source, the man-aged devices (EQ) run a Netconf agent whichreceives RPC requests from the different config-

uration providers. For instance, CPa and CPb

can load different partial configurations onto anagent configuration making for a multi-sourceconfiguration. These configurations are loadedwith respect to different access rights; an agentmust be able to decrypt incoming configurationsand to bind them to some access rights. We willdescribe in this section the mechanisms neededto meet these requirements. An RBAC man-ager is responsible for security mediation amongconfiguration providers and managed devices.This entity provides the different security ser-vices: authentication, data integrity, confiden-tiality and access control. The RBAC managerhosts RBAC policies which are dynamically de-ployed on our network entities.

RBAC allows high level and scalable accesscontrol process and configuration. The RBACmodel consists in a set of users, roles, per-missions (operations on resources) and sessions.The originality of the RBAC model is that per-missions are not granted to users but to roles,thus allowing an easy reconfiguration when auser changes his activity. A role describes ajob function or a position within an organiza-tion. The RBAC model allows the descriptionof complex access control policies while reducingerrors and administration costs. Introduction ofadministrative roles and role hierarchies makesit possible to considerably reduce the amountof associations representing permissions to usersallocation.

All agents store an RBAC policy describingthe permissions that a role is allowed to perform.Figure 16 is an example of such a permission set.In this model, the managers send their requestson behalf of a role. Therefore an agent is able toauthenticate and decrypt the requests because itknows the role in use. For each role, the archi-tecture provides one key for authentication andone key for encryption.

After the role authentication and decryption,an agent can start the access control step. Ac-cording to its local policy and to the role used,it can decide if the request is allowed or not.

In the following, a scenario showing securityusage, interests and consequences will be pre-sented in a BGP context. We will consider thetopology illustrated in Figure 4. In the sce-nario, the administrator of AS 3 defined tworoles: roleR1 for the router R1 and roleR2 forthe router R2. In order to allow R1 to read theroute-map ROUTEMAP1, a permission must beadded to the RBAC policy (see Figure 6). Next,this permission is associated to role roleR1.

There are some other XML-based access con-

<roles> <role id="5"> <name>roleR1</name> <junior−roles/> </role></roles><permission−assignements> <permission−assignement roleRef="5" permRef="10" id="1"/> [...]</permission−assignements><permissions> <permission id="10" type="+" op="r"> <scope>/bgp/filters/route−map[map−tag="ROUTEMAP1"]</scope> </permission> [...]</permissions>

Permission"route−map"

Role"R1"

Figure 6: XML-based RBAC policy

trol languages like, for instance, OASIS eXtensi-ble Access Control Markup Language (XACML)[25]. This standard allows to describe accesscontrol policies. OASIS also provides a spe-cific profile for RBAC [24]. The reason whywe did not write our policy with RBAC profileof XACML is that it has an important restric-tion compared with the original RBAC model.RBAC profile of XACML does not allow dynam-icity. It is not yet possible to activate and deac-tivate roles within a session. It means that allavailable roles for a given user are activated bydefault. Therefore, dynamic separation of dutyis not supported.

Our approach allows to grant privileges tosome entities and describes the protected re-sources with XPath language. All requests areauthenticated and encrypted with a key. Eachkey is bound to a role and a key distributionmechanism is leveraged. This architecture isbenchmarked later in the paper. A complete re-view of the security architecture can be found inour paper [7].

Another alternative is SSH ([27]), which how-ever does not include an access control mecha-nism. SSH is the candidate transport protocolfor Netconf, endorsed by the IETF. It is basedon PKI and therefore, allows authentication, in-tegrity and encryption. Like XML-Encryption,SSH supports many encryption algorithms like3DES or AES. A negotiation is used betweenthe client and server to choose the best availablealgorithm.

2.2.2 Extended filtering and scoping

If we consider the required Netconf request tomodify the filters configuration, illustrated inFigure 7.a, such that a final sequence has to beadded to every route-map whose map-tag is dif-ferent than ROUTEMAP2, then the possiblesolutions offered by the current Netconf specifi-cations are either to make several requests, (one

for each route-map see Figure 7.b) or to create amore complex request (as shown in Figure 7.c).Obviously, as more route-map and/or sequencesare to be added, the requests become very com-plex and cumbersome.

Our first extension to the default filteringmechanisms is to extend the syntax of the edit-config to allow a ”xpath” attribute in every XMLnode inside the <config> tag. For example, theequivalent request for the previous example isshown in Figure 8 (Looking into the Values).

Note that the number of route-maps in theconfiguration does not affect the size of the re-quest. So rather than explicitly use every valuethat has to match with the configuration, ourapproach allows to specify it in a XPath expres-sion.

Our second extension is to design a new op-eration similar to edit-config accepting a XSLTdocument rather than a XML as input. In thiscase the XSLT document will create a valid edit-config by transforming the actual XML configu-ration document in an standard edit-config XMLrequest. The equivalent configuration of the pre-vious example should look like shown in Fig-ure 8 (Pushing XSLT to generate the edit-configXML).

Note that this proposal has the same advan-tages than the first extension mechanism. Theresulting request document, which will be a stan-dard edit-config, is similar to the one shown inFigure 7 (XML Possible Request 2 ).

A variation of the second extension is to mod-ify the XML configuration by an XSLT request,but in this case, the input XSLT document willtransform the current XML configuration to thedesired one. An example is illustrated in Figure8 (Modify the XML configuration by an XSLT ).Such an approach suits well for configurationdeployement task in large scale networks, espe-cially when a master configuration file storedin XML (in an XML proprietary format likeJunosScript [18]) has to be adapted to a givennetwork device. From a conceptual point ofview, this approach is a limited active network-ing scheme, where only XSLT expressed code isinjected to be executed on an agent.

One issue that is not well specified in the Net-conf specification is how an agent should dealwith an edit-config request in the search of thenodes which have one ancestor with attributeoperation. Consider the example illustrated inFigure 9 (Ambiguity in the request).

The activated-group and the description maybe added to every neighbor or the descriptionmay be added to all the neighbors that have set

Figure 9: Proposal for resolve the Ambiguity Ex-ample

an activated-group as Group.Our extension is to resolve this ambiguity by

extending the specification of the edit-config andintroduce an attribute searchnode, in order tomake the request explicit. With this extension,the edit-config request for the example shown inFigure 9 (Ambiguity in the request) will mergeto every neighbor the activated-group and thedescription. The example of Specifying SearchNodes in the same figure adds the description toall the neighbors whose activated-group is equalto group.

2.2.3 Compression extension

As XML language introduces a potentially hugeverbosity (see Figure 4), use of compression candramatically save network bandwidth consump-tion. Moreover, it gives a simple way to avoidclear text transmissions.

Using compression is of interest, in particularin combination with security features. Since pro-cessing time for encryption increases fast withthe message size, compression before encryptioncan reduce encryption processing cost. These is-sues are illustrated and discussed on the basisof the performance tests presented in the nextsection.

3 Experimental perfor-

mance evaluation

To validate and evaluate the proposed securityarchitecture and the compression module, a pro-totype [8] has been implemented. The bench-marking tests are done locally on a Pentium 43.2GHz with 2 Go RAM, see Table 1.

In order to give an overview of the globalperformances, the agent can manage up to 17get-config requests per second when no loggingmechanism and no security is deployed. Whensecurity (encryption, RBAC) and compressionare enabled, the performance decreases to 8 re-

Figure 7: Motivation XML Example

Figure 8: XML Advanced Configuration Proposal

Description Caracteristics

RAM memory 2 Gigabytes

CPU Pentium 4, 3.2 GHz

OS Linux FC 4, kernel 2.6.12

python 2.4

security libraries PyXMLSec, paramiko

crypto. keys length 128 bits

Table 1: Test environment caracteristics

quests per second. For the benchmarking, weused only get-config operations. These repre-sent the worst case for security performance be-cause they require a low CPU consumption. Ifthe tests are done on complex requests, the CPUconsumption dedicated for security will be neg-ligible compared with the time to perform theNetconf request. With fast requests, it is possi-ble to highlight the influence of security mecha-nisms on the global processing time. However,we compare compression and encryption perfor-mances for both large as well as small sized XMLdocuments.

Figure 10 illustrates different use cases: (1)encryption + compression, (2) encryption, (3)compression, (4) default. The measures are donewithin the agent. For this test, 7 different get-config requests, applying either subtree filteringor XPath, are performed. Each of them is eval-uated 64 times and an average of the processingtime is computed. This average is representedon the figure. Each column relates to the totalprocessing time of a get-request.

The results show that compression and de-compression time is insignificant compared withthe global request processing time. Also RBACprocessing takes roughly 6% of the globaltime. Encryption represents 9.5% and decryp-tion 3.6%. Using both cryptography, compres-sion and access control consumes about 20% ofthe global time.

Figure 10: Global request processing time

Note that the total processing time increasesby a factor 60 if a XML Schema validator sys-tematically checks the received messages withthe Netconf XML schema. The total averageprocessing time is changing from 11 ms to 650ms. In such a case, the proportion of CPUtime dedicated to compression and security de-creases. CPU or memory consumption due toXPath technology is of minor importance com-pared with the use of a XML schema valida-tor. Filtering with XPath takes less then 1 ms.Checking the validity of a Netconf message withXML Schema takes more than 600 ms. Theseresults give an overview of the global perfor-mances of this implementation as well as theperformance of each functionnality relatively tothe others.

Table 2 displays the result response time fordifferent typical data retrieval tests. The agentand the manager are located on two devices con-nected to a hub and communicate over SSH. Forthis test only, the agent is located on a laptopcentrino 1.6GHz with 1 Gigabytes of memoryand runnning Fedora Core 4. The global requestprocessing time per agent remains the same asthe previous results, but on the manager side,the results are as follows. The manager is send-ing 1000 get-config requests using XPath capa-bility and then, the average response time iscomputed for each. The tested BGP configu-ration is realistic enough to be used in a realnetwork. While a test on a sample BGP config-uration gives a response time of 58.40 ms, a re-alistic BGP configuration is retrieved in around200 ms. These results assess the suitability ofNetconf for such tasks.

Management data Response time

network interfaces 38.73network routes 49.71BGP configuration 200.08RBAC policy 43.05

Table 2: Average response time in ms

3.1 On the use of compression

To illustrate the interest of compression, Fig-ure 11 considers different examples for severalmessage sizes. Please note that this scale is notuniform-sized. Due to the very heterogeneousdistribution of XML document sizes, a uniform-sized scale would have not fitted in the figurelayout. The sizes of many Netconf requests (get-

config using XPath, ok rpc-reply, copy usingftp) range roughly between 100 and 300 bytes.These Netconf messages don’t really take advan-tage of compression. We approximate to at least50% the pourcentage of such Netconf messagesamong all processed messages. The size of ahello message with 6 capabilities is 500 bytes.However, the size of a very small RBAC con-figuration (three users, four roles, 6 permissionsand few relationships between them) as well as aextremely basic network interface configurationare about 2500 bytes. Comparatively, the size ofa sample BGP configuration is about 5000 bytesbut can easily grow to 10000 bytes. The sizeof the full list of rpms on a typical machine is25000 bytes. The response size of a get-configon a Netconf agent implementing a larger datamodel can be evaluated to hundreds of kilobytes.While Figure 11 gives an overview of some typi-cal Netconf message or configuration sizes, someof them can be much greater than the given val-ues. For instance, an edit-config request couldreach more than 30 kilobytes.

Figure 12 shows the compression results on ar-bitrary XML documents. We limited our mea-surements to the original document size of 25kilobytes for which the compression rate reaches65%. These measurements prove the high inter-est in using compression, since compression sig-nificantly decreases the size of transported XMLconfigurations.

Figure 12 also gives the CPU time consump-tion of compression and decompression, depend-ing on the document size. The average time forcompression is 5 times greater than decompres-sion and increases slowly with the document size.In the worst case, which is when the processingtime request is very small (simple get-config forinstance), compression and decompression pro-cessing time take less than 1% of the total mes-sage processing.

To conclude on the use of compression, weobserved that bandwidth is used efficiently andCPU time consumption is not significant whencompared to the global processing time.

3.2 Integrity and confidentiality

Figure 13 gives the sizes of encrypted and de-crypted Netconf requests, depending on the orig-inal document size. The encryption algorithmsare tripledes-cbc and aes128-cbc and both usea 128 bits key. For the tests, we considered aset of sample XML documents having varioussizes, and applied 100 times each encryption al-gorithms for each document. Then, an average

is computed for each document. Applying thesealgorithms on our document set, we observe thatthe encrypted document size increases linearlywith the original document size. While the en-crypted document size is the same for both en-cryption algorithms, aes128-cbc consumes lessCPU than tripledes-cbc for both encryption anddecryption. Therefore, aes128-cbc, which is rec-ommended by NSA for strength reasons, is thebest choice.

Figure 13 also gives the CPU time consump-tion of the encryption and decryption process,depending on the document size. Encryptionand decryption take less than 3 ms for docu-ments sizes less than 10000 bytes. In the worstcase, the sum of these times represents 13% ofthe global Netconf processing time. Again, theworst case occurs when the time to build theXML response is very low. In that case, theCPU consumption proportion of encryption anddecryption is maximal.

3.3 Using both compression and

encryption

An experiment comparing the processing timeof compression, encryption and compres-sion+encryption on XML documents having dif-ferent sizes led us to the following conclusion:when the size of the document reaches a thresh-old, it is faster to perform first compression andthen encryption than to only encrypt the docu-ment. It means that beyond this threshold, us-ing both compression and encryption allows notonly to save network bandwidth but also to de-crease the agent CPU consumption at the sametime.

Figure 14 shows thatcompression+encryption line is crossingthe encryption line. This event happens whenthe document size reaches roughly 4 kilobytes,which is actually the size of a very simple BGPconfiguration.

3.4 Performance of XPath versus

subtree filtering

In order to compare the performances ofboth node selection methods, XPath and sub-tree filtering, we prepared 8 get-config re-quests with subtree filtering and their equiv-alent XPath based requests. The requestsare available in http://www.loria.fr/∽cridligv/-xpathSubtree.html. We used as many differentoptions as possible in subtree filtering requests:selection nodes, content match nodes, element

documentsize (bytes)

0 100 200 300 400 500 1000 2000 3000 4000 5000 10000 20000 30000

BGPconfiguration

RBACpolicyhello

delete−configrequest

InstalledRPMlist

configinterfacesnetworksimple

copy−config

errorok

edit−config request

XPath subtree filtering

get−config request

Figure 11: Overview of Netconf message sizes

0

5000

10000

15000

20000

25000

0 5000 10000 15000 20000 25000

docu

men

t siz

e (b

ytes

)

document size (bytes)

Document size with compression

with compressionwithout compression

0

500

1000

1500

2000

2500

0 5000 10000 15000 20000 25000

proc

essi

ng ti

me

(10^

-6 s

)


CPU time consumption for compression/decompression

compression timedecompression time

Figure 12: Compression results

0

5000

10000

15000

20000

25000

30000

35000

0 5000 10000 15000 20000 25000

docu

men

t siz

e (b

ytes

)


tripledes-cbc encryptionaes128-cbc encryption

without encryption

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

5500

6000

0 5000 10000 15000 20000 25000

proc

essi

ng ti

me

(10^

-6 s

)


Encryption time tripledes-cbcDecryption time tripledes-cbcEncryption time aes128-cbcDecryption time aes128-cbc

Figure 13: Encryption results

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

5500

0 5000 10000 15000 20000 25000

proc

essi

ng ti

me

(10^

-6 s

)


compression timeencryption time

Compression/Encryption time

Figure 14: CPU time consumption with differentcombinations

nodes. Each request is sent 10 times and thenan average time is computed. This experimentsshowed us how subtree filtering is adapted tobuild a customized document and how XPath isefficient to select nodes on more complex crite-ria (for instance, conditions on text node valueor node number). Subtree filtering is somewherebetween XPath and XSLT: it allows to selectnodes but also to apply a mask to the configura-tion. It is always possible to translate a subtreefiltering request to XPath but the philosophy isdifferent and both methods are useful and com-plementary.

The results displayed on Table 3 show thatsubtree filtering and XPath have similar aver-age processing time. Each request is made 1000times and an average is computed afterwards.The two filtering approaches are slightly dif-ferent. When XPath is adapted to select iso-lated data items, subtree filtering is more suit-able to build complex views made of differentparts of the config and to visualize them pre-viously in a template-like document. In orderto build a document made of completely dif-ferent parts with Xpath, a manager has to usea | symbol to join the various parts of the se-lected nodes. However, the subtree filtering canonly use absolute addressing while XPath allowsboth relative and absolute expressions like, forinstance, //iface[name=’eth0’] or /netconf/net-work/interfaces/iface[name=’eth0’]. The advan-tages of XPath are 1) it consumes less bandwidthsince the requests are much more compact thansubtree filtering and, 2) it does not require animportant effort from the managers.

To weight these results, it is important to notethat the total request processing time is muchhigher than the filtering processing time, what-

ever be the selection method. To conclude onfiltering, both approaches have their advantagesand are complementary.

3.5 RBAC model benchmarking

We have also assessed the impact of access con-trol on CPU time consumption. We imple-mented a RBAC policy with XPath as a resourceaddressing scheme. In our model, a Netconf re-quest is sent on behalf of a role. The agent isable to build the list of permissions for that roleand all its junior roles. The model implementsa role hierarchy: a role inherits the permissionsof all its junior roles. The results, illustrated onFigure 15, show the additional processing timeneeded for the access control mechanism. Thesevalues also outline the effect of access controlmechanism and the number of permissions. Theexperiments were performed with 0 to 9 permis-sions. As expected, the CPU time increases lin-early with the number of rules.

0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

0 1 2 3 4 5 6 7 8 9

proc

essi

ng ti

me

(10^

-6 s

)

permissions number

encryption time

Figure 15: Influence of permissions number

Figure 16 illustrates the set of permissionsused for the benchmarking. They are expressedusing the XPath syntax. As shown with the per-mission 1 (allowing read and write operations onall permissions with id equal to 5), the accesscontrol can also be performed on the access con-trol policy itself.

3.6 Integrated security vs SSH

In order to compare the performances betweenthe two different underlying secure applicationprotocols (our extended XML-based securityframework and SSH), a Netconf manager is us-ing both protocols and sending 1000 times the8th get-config requests using XPath of the Table

Filtering 1 2 3 4 5 6 7 8 9 10 11 12

Subtree 1171 1482 694 463 477 1503 2114 1371 919 775 1733 863

Xpath 1173 1039 1219 194 687 1286 2828 1973 852 916 1332 2368

Table 3: Performances of node selection methods in µs

<permissions>

<permission id="1" type="+" op="rw">

<scope>/netconf/security/rbac/permissions

/permission[@id=’5’]</scope>

</permission>


<scope>/netconf/interfaces</scope>

</permission>


<scope>/netconf/routing/bgp</scope>

</permission>


<scope>/netconf/system</scope>

</permission>

<permission id="5" type="+" op="r">

<scope>/netconf/log</scope>

</permission>


<scope>/netconf/security/test/users

</scope>

</permission>


<scope>/netconf/security/test/roles

/role[@id=’2’]</scope>

</permission>


<scope>/netconf/security/test/roles

/role[@id=’1’]/junior-roles</scope>

</permission>

Figure 16: Set of permissions

3. When running over SSH, the total time be-tween the emission of the first request and thereception of the last response is 16.77 seconds.When running over XML-Encryption, it takes15.62 seconds. Therefore, processing times arequite similar.

SSH session establishment is not taken into ac-count. Similarly, key distribution time for XML-Encryption is not measured here, since this is astationary phase test.

4 Prototyping of a Netconf

framework

This section gives an overview of the Netconftest platform. It consists of a command linemanager, a web-based manager and an agent.Only the implementation design of the two lastones is presented. In order to allow a moreand more completed data model, the architec-ture can be easily extended with plugins thatare called modules in this implementation. Adetailed overview of the implementation can befound in [6].

4.1 Netconf agent implementation

Figure 17 illustrates the architecture of our Net-conf agent. The agent is organized into sev-eral functional blocks. The Socket layer is incharge of assembling the incoming Netconf mes-sages and also sending prepared messages. TheRPC layer checks the <rpc> level, optionallycompress/decompress and encrypt/decrypt themessages. The Request layer function is to ex-tract the Netconf operation embedded in the<rpc> node. Then it calls the related method(get-config, edit-config, ...) from the Dispatcherblock.

The Dispatcher block is responsible for per-forming the requested operation. It uses threefunctional blocks that are called serially. TheModules Resolver is able to retrieve the list ofmodules that can handle the Netconf opera-tion. A Module Register Table, storing XPathexpressions related to each module, is parsed tobind the data received to the right XPath(). Amodules list is returned to the Dispatcher. All

WAN

Netconf operation

module (Content)

Singleton

Generic server

Operation

Server

Module

Rpcxmlsec_serverSSH_server

netconfdSessionManager

Session

moduleresolver

responsebuilder

responsefilter

Easy_Module route_Moduleif_Module

rbac_Module

asteriks_Module

...

bgp_Module

design pattern

Commanddesign pattern

module inheritancetree

Vendor_Module

multi−socketSSH or XMLSec

Get_config Edit_config Close_session Vendor_operation

Figure 17: Netconf agent functional architecture

these modules are queried by the XML ResponseBuilder to perform the operation. In the caseof a get-config and if security is activated, theXML Response Filter removes all the data thatthe role is not allowed to read.

In order to extend our agent with a new mod-ule, a developer must provide a class that in-herits a generic Module class and overrides theNetconf operations implemented in Module. TheModule class defines the methods signatures andreturns Netconf errors in case the method (forinstance get-config) is not implemented in thatparticular new module. The modules hierarchyis illustrated in Figure 18. The top level class isthe generic module implementation. In order tomake development of new modules easier, copy-config is generic and is implemented using edit-config. Other methods generate <rpc-error>

by default, in case the inheriting module doesnot implement the current method (even if itshould). A set of operational modules inheritdirectly from the Module class: one is dedicatedto network interfaces management, one enbalesBGP router management and one is for firewallrules. Easy Module is a more specific imple-mentation that can be inherited to help Netconfmodule developers. All modules must be regis-tered in a configuration file in order to be loadedinto memory at startup.

Figure 19 illustrates the code of a ”route”module. It inherits from Module class and im-plements a getConfig method. EnSuite soft-ware, which consists of the manager and theclients, is freely available in our web page:http://madynes.loria.fr/ensuite. For a completepresentation, the reader is refered to [6].

5 Related works

In an XML environment, the first network man-agement protocol to propose security mecha-nisms was Junoscript [18]. It relies on SecureShell (SSH [27]) to provide authentication andencryption independently of the XML applica-tion layer. It also provides mechanisms to man-ager identity authentication through a login/-password process. The main difference with ourapproach is that we provide an integrated se-curity management. ACL rules are integrateddirectly in the XML device configuration docu-ment and bound to RBAC roles instead of usersfor scalability issues. Contrary to SSH, wherekeys are independent of the application level, thekeys for authentication and confidentiality aredeeply bound to roles and exchanged dynami-cally in our architecture. In our approach, amessage emitted under a role is encrypted andauthenticated with the keys corresponding tothat role. This provides a flexible way to inte-grate authentication, confidentiality and accesscontrol in the same architectural plane.

Some intermediate solutions for XML man-agement were proposed with XML/SNMP gate-ways [26] [20]. These gateways allow XML-based managers to interact transparently withSNMP agents. This provides a quite flexible wayto build management application with all thepanel of XML tools. However, no security con-cerns were taken into account apart from usingHTTPS between the managers and the gateway.The use of SNMPv3 implies to define user ac-counts, key distribution and access control poli-cies. In [9], we extend these gateways with secu-rity features and provide an end-to-end security

Interface_Module

+ Public Method# Protected Method− Private Method

Firewall_Module


RBAC_Module


BGP_Module


Module

+ Public copy−config+ Public get−config+ Public edit−config

Easy_Module


ModuleResolver

register to

if if if if

Module XPath expression

BGP_Module

Firewall_Module /security/firewall

/config/network/bgp

Module Register Table

... ...

XMLconfiguration

Figure 18: Module inheritance in YencaP

continuum.

We give in this paragraph an overview of theXML security concepts which have been devel-oped mostly for the security needs of web ser-vices. Over the past years, some XML languageshave been defined to address a set of security re-quirements. Many existing security mechanismshave been adapted to XML languages so that itis now possible not only to encrypt but also todigitally sign all or parts of an XML document.The World Wide Web consortium published aset of recommendations that describe the syntaxof XML tokens and the way of handling such el-ements. In particular, XML-DigitalSignature [3]describes the syntax for digital signature and itslinked information such that the algorithms andkeys to use or the way to retrieve them. More-over, XML-Encryption [13] provides the guide-lines to generate encrypted XML elements andto link them with security credentials. XML-Canonicalization aims at describing the prepro-cessing of an XML element before it is either en-crypted or authenticated. Indeed, some equiv-alent XML elements can be written in differ-ent ways depending on the application that han-dles it. Several parts such as white spaces andnamespaces can be changed during the differentprocesses. This introduces some problems whenXML elements need to be hashed for authentica-tion. XML-Canonicalization [4] defines a set of

rules to format the elements in such a way thatit will always produce the same hash. Since wealso address distributed XML applications, weuse the XML security framework ([3, 13, 4]) toprotect Netconf messages.

Our approach differs from a centralized RBACpolicy in the sense that the policy is distributed.There is no central RBAC server evaluating allthe requests to perform access control on XMLdocuments. We rather use some rules integratedin XML documents. This approach is inspiredfrom SyncML [12] [2]. A similar approach hasbeen submitted recently in the Netconf mailinglist [1].

Lupu et al. presented in [17] [15], [16] somepolicy-based approaches to address the accesscontrol and organization issue in the context ofdistributed systems. The authors described inparticular the use of hierarchical roles to orga-nize the principals interacting with a system.They also described the relationships betweenthese roles. Our approach differs in that it usesan existing RBAC model, there is no central au-thorization server and it is deeply bound to cryp-tography.

Issues concerning SNMP protocol are pre-sented in [23]. The authors highlight three mainproblems arising when a manager is retrievinglarge amounts of MIB data. These problems arelatency, network overhead and table retrieval.

import os, string

from Ft.Xml.Domlette import NonvalidatingReader, implementation

from Ft.Xml import XPath, EMPTY_NAMESPACE

from Ft.Xml.Domlette import NonvalidatingReader, PrettyPrint

from Modules.modulereply import ModuleReply

from Modules.module import Module

class Route_Module(Module):

""" Main class of Route module. Allows routing table management. ""

def __init__(self,parameters):

""" Create an instance and initialize the structure needed by it."""

self.dict = ["Destination", "Passerelle", "Genmask", "Indic",

"Metric", "Ref", "Use", "Iface"]

def getConfig(self):

route = self.getRoute()

self.doc = implementation.createDocument(EMPTY_NAMESPACE, None, None)

element = self.doc.createElementNS(EMPTY_NAMESPACE,"route")

self.doc.appendChild(element)

for routeEntry in route:

entryelement = self.doc.createElementNS(EMPTY_NAMESPACE,"route-entry")

element.appendChild(entryelement)

for data in self.dict:

datanode = self.doc.createElementNS(EMPTY_NAMESPACE,data)

textNode = self.doc.createTextNode(routeEntry[data])

datanode.appendChild(textNode)

entryelement.appendChild(datanode)

modulereply = ModuleReply(replynode=self.doc.documentElement)

return modulereply

def getRoute(self):

route = []

res = os.popen3("route")

# Read stdout output

resultat = res[1].read()

lignes = string.split(resultat, "\n")

lignes = lignes[2:]

for ligne in lignes:

entry = string.split(ligne,’ ’)

for i in range(0,entry.count(’’)):

entry.remove(’’)

if entry != []:

routeEntry = {}

for i in range(0, len(self.dict)):

routeEntry[self.dict[i]] = entry[i]

route.append(routeEntry)

return route

Figure 19: Sample module code example

These are mainly due to the way operations suchas get-next and get-bulk are defined and also tothe data encoding. To deal with these issues, theauthors propose some alternative approaches byconsidering other encodings, compression, pro-tocols and an new get-subtree operation in or-der to optimize network bandwidth and CPUconsumption and easiness to build managementapplication.

In [5], the authors proposed a security per-formance analysis of SNMPv3. This analysisproves the expected performance degradationwhen moving from SNMPv2c to SNMPv3. Thisrelative degradation, due to the introduced se-curity features, is to be compared with the hugeimprovement introduced by security support.

In [19], some performances analysis relatedto Web Services to SNMP gateways are made.They also studied the influence of using secu-rity (HTTP vs HTTPS) and compression (zlibalgorithm) on the network bandwidth consump-tion. The authors propose an interesting studyby comparing protocol-level (Get, GetNext) andobject-level (GetIfTable) gateways and their in-fluence on bandwidth consumption.

In [11], a comparison between SNMP andCORBA is achieved. The study shows thatCORBA is more suitable (bandwidth consump-tion) for large data retrieval, while SNMPhas better performance for a context of smallamount of data exchange and limited devicememory.

6 Conclusion

This paper proposes a set of extensions for Net-conf configuration protocol along with a real lifeperformance evaluation. These extensions ad-dress security issues and introduce a new ap-proach for the edit-config operation.

The security framework that was proposed ina previous publication [7] is applied for a BGPcontext. It illustrates a flexible access controlpolicy that grants well-defined and controlledprivileges on BGP router configurations. Thisaccess control policy assesses who can read orwrite the configuration data expressed in XMLencoding and illustrates the suitability of XPathto address and protect such hierarchical XML re-sources. The architecture relies on a distributedencryption key system, each key being bound toa role. This means that the access control pol-icy is deeply integrated with the confidentialityand authentication service deployed with XMLsecurity standards in a full security framework

for Netconf.The second extension is relative to the use of a

existing XML technology to edit XML configu-ration data. It reviews the edit-config operationand more particularly the merge attribute andpoints out the advantages of using XSLT insteador complementarily. XSLT, which is specializedin transforming XML documents, is popular inthe developpers community and therefore couldbe enforced more easily by administrators or net-work management platform developers.

In the second part of the paper, the perfor-mance evaluation of the model is fully detailed.The results ensure the feasability of such a secu-rity framework, comparing the influence of dif-ferent options: encryption, compression, accesscontrol with our proposed security model and abrief comparison with SSH. The CPU time con-sumption dedicated to security is acceptable andcompression not only dramatically decreases thenetwork overhead introduced by XML encodingbut also speeds up the encryption processingtime. A comparison with another Netconf im-plementation would be helpful but no such otheropen-source implementation exists.

The last part overviews the design and archi-tecture of our free Netconf software suite (En-Suite, http://madynes.loria.fr/ensuite) whichconsists of a web-based manager and the agentitself. The agent allows plugins addition thanksto a modular architecture and supports SSH aswell as our own security model. It also sup-ports network interface, route, BGP configura-tion management.

References

[1] Sandeep Adwankar. NetConf Data Model.Internet Draft, July 2004.

[2] Open Mobile Alliance. SyncML Consor-tium. http://www.syncml.org.

[3] Mark Bartel, John Boyer, Barb Fox, BrianLaMacchia, and Ed Simon. XML-SignatureSyntax and Processing. W3C Recommen-dation, February 2002.

[4] John Boyer, Donald E. Eastlake, andJoseph Reagle. Exclusive XML Canonical-ization Version 1.0. W3C Recommendation,July 2002.

[5] A. Corrente and L. Tura. Security Perfor-mance Analysis of SNMPv3 with Respectto SNMPv2c. In Proceedings of the 2004

IEEE/IFIP Network Operations and Man-agement Symposium, NOMS 2004, pages729–742, 2004.

[6] V. Cridlig, H. Abdelnur, J. Bourdellon, andR. State. A NetConf Network ManagementSuite: ENSUITE. In Proceedings of the5thIEEE International Workshop on IP Oper-ations & Management (IPOM 2005), Octo-ber 2005.

[7] V. Cridlig, R. State, and O. Festor. AnIntegrated Security Framework for XMLbased Management. In Proceedings ofthe Ninth IFIP/IEEE International Sym-posium on Integrated Network Management(IM 2005), IFIP Conference Proceedings,May 2005.

[8] Vincent Cridlig and Radu State. Yencap.http://madynes.loria.fr/ensuite.

[9] Vincent Cridlig, Radu State, and OlivierFestor. Role based access control for XMLbased management gateway. In Submit-ted to the 15th IFIP/IEEE Distributed Sys-tems: Operations and Management, DSOM2004, December 2004.

[10] R. Enns. NETCONF Configuration Proto-col. Internet Draft, February 2005.

[11] Q. Gu and A. Marshall. Network Manage-ment Performance Analysis and ScalabilityTests: SNMP vs. CORBA. In Proceedingsof the 2004 IEEE/IFIP Network Operationsand Management Symposium, NOMS 2004,pages 701–714, 2004.

[12] Uwe Hansmann, Riku Mettala, Apra-tim Purakayastha, and Peter Thomp-son. SyncML: Synchronizing and ManagingYour Mobile Data. Prentice Hall PTR; 1stedition, September 2002.

[13] Takeshi Imamura, Blair Dillaway, andEd Simon. XML Encryption Syntax andProcessing. W3C Recommendation, De-cember 2002.

[14] R. Kuhn. Role Based Access Control. NISTStandard Draft, April 2003.

[15] E. Lupu, Z. Milosevic, and M. Sloman. Useof Roles and Policies for Specifying, andManaging a Virtual Enterprise. In NinthIEEE International Workshop on ResearchIssues on Data Engineering: InformationTechnology for Virtual Enterprises (RIDE-VE’99), March 1999.

[16] E. Lupu and M. Sloman. Reconciling RoleBased Management and Role Based AccessControl. In Second ACM Workshop on RoleBased Access Control (RBAC’97), pages135–142. ACM Press, November 1997.

[17] E. Lupu and M. Sloman. Towards a RoleBased Framework for Distributed SystemsManagement. Journal of Network and Sys-tems Management, 5(1):5–30, 1997.

[18] Tony Mauro. JUNOScript API Guidefor JUNOS Release 6.1. Juniper Net-works, 1194 North Mathilda Avenue. Sun-nyvale, CA 94089, USA, sonia saruba edi-tion, September 2003.

[19] Ricardo Neisse, Ricardo Lemos Vianna,Lissandro Zambenedetti Granville, MariaJanilce Bosquiroli Almeida, and Liane Mar-garida Tarouco. Implementation and Band-width Consumption Evaluation of SNMPto Web Services Gateways. In Proceedingsof the 2004 IEEE/IFIP Network Operationsand Management Symposium, NOMS 2004,pages 715–728, 2004.

[20] Yoon-Jung Oh, Hong-Taek Ju, Mi-JungChoi, and James Won-Ki Hong. Inter-action Translation Methods for XML/S-NMP Gateway. In Metin Feridun, Peter G.Kropf, and Gilbert Babin, editors, Proceed-ings of the 13th IFIP/IEEE InternationalWorkshop on Distributed Systems: Opera-tions and Management, DSOM 2002, vol-ume 2506 of Lecture Notes in Computer Sci-ence, pages 54–65. Springer, October 2002.

[21] Y. Rekhter and T. Li. A Border Gate-way Protocol 4 (BGP-4). STD 62,http://www.ietf.org/rfc/rfc1771.txt,March 1995.

[22] G. Sackett. Cisco Router Handbook.McGraw-Hill Companies; 2nd edition, De-cember 2000.

[23] Ron Sprenkels and Jean-Philippe Martin-Flatin. Bulk Transfers of MIB Data. TheSimple Times, 7(1):1–7, March 1999.

[24] OASIS Standard. Core and hierarchi-cal role based access control (RBAC)profile of XACML v2.0. http://docs.oasis-open.org/xacml/2.0/access control-xacml-2.0-rbac-profile1-spec-os.pdf, February2005.

[25] OASIS Standard. XACML 2.0 Core: eX-tensible Access Control Markup Language(XACML) Version 2.0. http://www.oasis-open.org, February 2005.

[26] Frank Strauß and Torsten Klie. To-wards XML Oriented Internet Manage-ment. In German S. Goldszmidt andJurgen Schonwalder, editors, Proceedings ofthe Eighth IFIP/IEEE International Sym-posium on Integrated Network Management(IM 2003), volume 246 of IFIP ConferenceProceedings, pages 505–518. Kluwer, March2003.

[27] T. Ylonen and C. Lonvick. SSH TransportLayer Protocol. Internet Draft, June 2004.

assessment of security extended xml-based management · quest to a server (a netconf agent) which...

Documents