idnits 2.17.1 draft-ietf-netconf-rfc5539bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 29, 2014) is 3739 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-netmod-snmp-cfg-03 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-01) exists of draft-kwatsen-netconf-server-00 -- Obsolete informational reference (is this intentional?): RFC 4742 (Obsoleted by RFC 6242) -- Obsolete informational reference (is this intentional?): RFC 5539 (Obsoleted by RFC 7589) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group M. Badra 3 Internet-Draft LIMOS Laboratory 4 Obsoletes: 5539 (if approved) A. Luchuk 5 Intended status: Standards Track SNMP Research, Inc. 6 Expires: August 2, 2014 J. Schoenwaelder 7 Jacobs University Bremen 8 January 29, 2014 10 Using the NETCONF Protocol over Transport Layer Security (TLS) 11 draft-ietf-netconf-rfc5539bis-05 13 Abstract 15 The Network Configuration Protocol (NETCONF) provides mechanisms to 16 install, manipulate, and delete the configuration of network devices. 17 This document describes how to use the Transport Layer Security (TLS) 18 protocol to secure the exchange of NETCONF messages. This document 19 obsoletes RFC 5539 and it adds an optional mechanism to establish the 20 underlying TCP connection from the NETCONF server to the NETCONF 21 client (call home). 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 2, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 59 2. NETCONF over TLS . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Connection Initiation . . . . . . . . . . . . . . . . . . 3 61 2.1.1. Client to Server . . . . . . . . . . . . . . . . . . . 4 62 2.1.2. Server to Client (Call Home) . . . . . . . . . . . . . 4 63 2.1.3. Port Number Usage . . . . . . . . . . . . . . . . . . 4 64 2.2. Message Framing . . . . . . . . . . . . . . . . . . . . . 5 65 2.3. Connection Closure . . . . . . . . . . . . . . . . . . . . 5 66 2.4. X.509-based Authentication, Identification and 67 Authorization . . . . . . . . . . . . . . . . . . . . . . 5 68 2.4.1. Server Identity . . . . . . . . . . . . . . . . . . . 5 69 2.4.2. Client Identity . . . . . . . . . . . . . . . . . . . 6 70 2.5. Pre-Shared-Key-based Authentication, Identification 71 and Authorization . . . . . . . . . . . . . . . . . . . . 7 72 2.6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 7 73 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 76 6. Contributor's Address . . . . . . . . . . . . . . . . . . . . 9 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 80 Appendix A. Change Log (to be removed by RFC Editor before 81 publication) . . . . . . . . . . . . . . . . . . . . 10 82 A.1. draft-ietf-netconf-rfc5539bis-05 . . . . . . . . . . . . . 10 83 A.2. draft-ietf-netconf-rfc5539bis-04 . . . . . . . . . . . . . 11 84 A.3. draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . . 11 85 A.4. draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . . 11 86 A.5. draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 The NETCONF protocol [RFC6241] defines a mechanism through which a 92 network device can be managed. NETCONF is connection-oriented, 93 requiring a persistent connection between peers. This connection 94 must provide integrity, confidentiality, peer authentication, and 95 reliable, sequenced data delivery. 97 This document defines "NETCONF over TLS", which includes support for 98 certificate and pre-shared key (PSK)-based authentication and key 99 derivation, utilizing the protected ciphersuite negotiation, mutual 100 authentication, and key management capabilities of the TLS (Transport 101 Layer Security) protocol, described in [RFC5246]. It also provides 102 an optional mechanism to establish the underlying TCP connection from 103 the NETCONF server to the NETCONF client (call home). 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 1.1. Applicability Statement 111 The "call home" technique described in Section 2.1.2 of this document 112 MUST only be used for a NETCONF server to initiate a connection to a 113 NETCONF client, as described in this document. 115 The reason for this restriction is that different protocols have 116 different security assumptions. This specification requires NETCONF 117 clients and servers to verify the identity of the other party before 118 the NETCONF session is started. Further, strong cryptographic 119 authentication is used for both the NETCONF client and server. This 120 reduces the risk that a malicious party could impersonate a NETCONF 121 server and contact the NETCONF client using the "call home" 122 technique. Protocols other than NETCONF might not be so well 123 protected. 125 2. NETCONF over TLS 127 Since TLS is application-protocol-independent, NETCONF can operate on 128 top of the TLS protocol transparently. This document defines how 129 NETCONF can be used within a TLS session. 131 2.1. Connection Initiation 133 In many deployments, the NETCONF client will initiate the connection 134 to a NETCONF server as described in Section 2.1.1. However, in order 135 to use NETCONF in environments where middleboxes [RFC3234] prevent 136 the client from establishing the connection, the server may initiate 137 the connection as described in Section 2.1.2 (call home). 139 2.1.1. Client to Server 141 The peer acting as the NETCONF client MUST act as the TLS client. 142 The TLS client actively opens the TLS connection and the TLS server 143 passively listens for the incoming TLS connection on the TCP port 144 6513. The TLS client MUST therefore send the TLS ClientHello message 145 to begin the TLS handshake. Once the TLS handshake has finished, the 146 client and the server MAY begin to exchange NETCONF messages. Client 147 and server identity verification (as described in Section 2.4 and 148 Section 2.5) is done before the message is sent. This means 149 that the identity verification is completed before the NETCONF 150 session has started. 152 2.1.2. Server to Client (Call Home) 154 The peer acting as the NETCONF server first actively opens a TCP 155 connection to the NETCONF client using the default port number YYYY. 156 Once the connection has been established, the NETCONF client, which 157 has accepted the incoming TCP connection, takes initiative. It from 158 now on MUST act as the TLS client and it therefore sends the TLS 159 ClientHello message to begin the TLS handshake. Once the TLS 160 handshake has finished, the client and the server MAY begin to 161 exchange NETCONF messages. Client and server identity verification 162 (as described in Section 2.4 and Section 2.5) is done before the 163 message is sent. This means that the identity verification 164 is completed before the NETCONF session has started. 166 2.1.3. Port Number Usage 168 A NETCONF client and a NETCONF server provide two different services. 169 The NETCONF server executes RPC requests and manipulates local 170 datastores while the NETCONF client invokes RPC requests. It is 171 possible to have both a NETCONF server and a NETCONF client running 172 on the same node. 174 The well-known port number 6513 is used by NETCONF servers to listen 175 for connections established by NETCONF clients. NETCONF clients 176 connect to the server on the server port 6513 in order to execute RPC 177 calls on the server. 179 The port number YYYY is used by NETCONF clients that support call- 180 home to listen for incoming connections. A NETCONF server using 181 call-home will connect to a NETCONF client in order to let the client 182 subsequently initiate RPC calls. 184 2.2. Message Framing 186 All NETCONF messages MUST be sent as TLS "application data". It is 187 possible that multiple NETCONF messages be contained in one TLS 188 record, or that a NETCONF message be transferred in multiple TLS 189 records. 191 The previous version [RFC5539] of this document used the framing 192 sequence defined in [RFC4742], under the assumption that it could not 193 be found in well-formed XML documents. However, this assumption is 194 not correct [RFC6242]. In order to solve this problem, this document 195 adopts the framing protocol defined in [RFC6242] as follows: 197 The message MUST be followed by the character sequence 198 ]]>]]>. Upon reception of the message, the receiving peer's 199 TLS Transport layer conceptually passes the message to the 200 Messages layer. If the :base:1.1 capability is advertised by both 201 peers, the chunked framing mechanism defined in Section 4.2 of 202 [RFC6242] is used for the remainder of the NETCONF session. 203 Otherwise, the old end-of-message-based mechanism (see Section 4.3 of 204 [RFC6242]) is used. 206 2.3. Connection Closure 208 A NETCONF server will process NETCONF messages from the NETCONF 209 client in the order in which they are received. A NETCONF session is 210 closed using the operation. When the NETCONF server 211 processes a operation, the NETCONF server SHALL 212 respond and close the TLS session as described in [RFC5246] Section 213 7.2.1. The NETCONF server MUST NOT process any NETCONF messages 214 received after the operation. 216 2.4. X.509-based Authentication, Identification and Authorization 218 Implementations MAY optionally support TLS certificate-based 219 authentication [RFC5246]. If the implementation supports TLS 220 certificate-based authentication, then the following sections apply. 222 2.4.1. Server Identity 224 If the certificate presented by a NETCONF server has passed 225 certification path validation [RFC5280] to a configured trust anchor, 226 the NETCONF client MUST carefully examine the certificate presented 227 by the server to determine if it meets the client's expectations. 228 Particularly, the NETCONF client MUST check its understanding of the 229 NETCONF server hostname against the server's identity as presented in 230 the server Certificate message, in order to prevent man-in-the-middle 231 attacks. 233 Matching is performed according to the rules and guidelines defined 234 in [RFC6125]. If the match fails, the NETCONF client MUST either ask 235 for explicit user confirmation or terminate the connection and 236 indicate the NETCONF server's identity is suspect. 238 Additionally, NETCONF clients MUST verify the binding between the 239 identity of the NETCONF servers to which they connect and the public 240 keys presented by those servers. NETCONF clients SHOULD implement 241 the algorithm in Section 6 of [RFC5280] for general certificate 242 validation, but MAY supplement that algorithm with other validation 243 methods that achieve equivalent levels of verification (such as 244 comparing the NETCONF server certificate against a local store of 245 already-verified certificates and identity bindings). 247 If the NETCONF client has external information as to the expected 248 identity of the NETCONF server, the hostname check MAY be omitted. 250 2.4.2. Client Identity 252 The NETCONF server MUST verify the identity of the NETCONF client to 253 ensure that the incoming request to establish a NETCONF session is 254 legitimate before the NETCONF session is started. 256 The NETCONF protocol [RFC6241] requires that the transport protocol's 257 authentication process MUST result in an authenticated NETCONF client 258 identity whose permissions are known to the server. The 259 authenticated identity of a client is commonly referred to as the 260 NETCONF username. 262 The username provided by the NETCONF over TLS implementation will be 263 made available to the NETCONF message layer as the NETCONF username 264 without modification. If the username does not comply to the NETCONF 265 requirements on usernames [RFC6241], i.e., the username is not 266 representable in XML, the TLS session MUST be dropped. 268 2.4.2.1. Deriving NETCONF Usernames from X.509 Certificates 270 After completing the TLS handshake, the NETCONF server attempts to 271 derive a NETCONF username from the X.509 certificate presented by the 272 NETCONF client. If the NETCONF server cannot derive a valid NETCONF 273 username from the presented certificate, then the NETCONF server MUST 274 close the TLS connection, and MUST NOT accept NETCONF messages over 275 it. The NETCONF server uses the algorithm defined in 276 [I-D.ietf-netmod-snmp-cfg] to extract a NETCONF username from the 277 X.509 certificate presented by the NETCONF client. The cert-to-name 278 list in the ietf-netconf-server YANG module, defined in 279 [I-D.kwatsen-netconf-server], specifies how a NETCONF server 280 transforms a certificate into a NETCONF username. 282 2.5. Pre-Shared-Key-based Authentication, Identification and 283 Authorization 285 Implementations MAY optionally support TLS Pre-Shared Key (PSK) 286 authentication [RFC4279]. RFC4279 describes pre-shared key 287 ciphersuites for TLS. The description of the psk-maps container in 288 the ietf-netconf-server YANG module, defined in 289 [I-D.kwatsen-netconf-server], specifies how a NETCONF server 290 associates a TLS pre-shared key with a NETCONF username. 292 2.6. Cipher Suites 294 Implementations of the protocol specified in this document MAY 295 implement any TLS cipher suite that provides mutual authentication 296 [RFC5246]. However, implementations MUST support TLS 1.2 [RFC5246] 297 and are REQUIRED to support the mandatory-to-implement cipher suite, 298 which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to 299 apply to future versions of TLS; in which case, the mandatory-to- 300 implement cipher suite for the implemented version MUST be supported. 302 3. Security Considerations 304 The security considerations described throughout [RFC5246] and 305 [RFC6241] apply here as well. 307 This document in its current version does not support third-party 308 authentication (e.g., backend Authentication, Authorization, and 309 Accounting (AAA) servers) due to the fact that TLS does not specify 310 this way of authentication and that NETCONF depends on the transport 311 protocol for the authentication service. If third-party 312 authentication is needed, SSH transport can be used. 314 An attacker might be able to inject arbitrary NETCONF messages via 315 some application that does not carefully check exchanged messages. 316 When the :base:1.1 capability is not advertised by both peers, an 317 attacker might be able to deliberately insert the delimiter sequence 318 ]]>]]> in a NETCONF message to create a DoS attack. If the :base:1.1 319 capability is not advertised by both peers, applications and NETCONF 320 APIs MUST ensure that the delimiter sequence ]]>]]> never appears in 321 NETCONF messages; otherwise, those messages can be dropped, garbled, 322 or misinterpreted. More specifically, if the delimiter sequence is 323 found in a NETCONF message by the sender side, a robust 324 implementation of this document SHOULD warn the user that illegal 325 characters have been discovered. If the delimiter sequence is found 326 in a NETCONF message by the receiver side (including any XML 327 attribute values, XML comments, or processing instructions), a robust 328 implementation of this document MUST silently discard the message 329 without further processing and then stop the NETCONF session. 331 Finally, this document does not introduce any new security 332 considerations compared to [RFC6242]. 334 4. IANA Considerations 336 Based on the previous version of this document, RFC 5539, IANA has 337 assigned a TCP port number (6513) in the "Registered Port Numbers" 338 range with the service name "netconf-tls". This port will be the 339 default port for NETCONF over TLS, as defined in Section 2.1.1. 340 Below is the registration template following the rules in [RFC6335]. 342 Service Name: netconf-tls 343 Transport Protocol(s): TCP 344 Assignee: IESG 345 Contact: IETF Chair 346 Description: NETCONF over TLS 347 Reference: RFC XXXX 348 Port Number: 6513 350 This document requests that IANA assigns a TCP port number in the 351 "Registered Port Numbers" range with the service name 352 "netconf-tls-ch". This port will be the default port for NETCONF 353 over TLS when the NETCONF server calls home, as defined in 354 Section 2.1.2. Below is the registration template following the 355 rules in [RFC6335]. 357 Service Name: netconf-tls-ch 358 Transport Protocol(s): TCP 359 Assignee: IESG 360 Contact: IETF Chair 361 Description: NETCONF over TLS (call home) 362 Reference: RFC XXXX 363 Port Number: YYYY 365 5. Acknowledgements 367 A significant amount of the text in Section 2.4 was lifted from 368 [RFC4642]. 370 The authors like to acknowledge Martin Bjorklund, Olivier Coupelon, 371 Mehmet Ersue, Miao Fuyou, David Harrington, Alfred Hoenes, Simon 372 Josefsson, Eric Rescorla, Dan Romascanu, Kent Watsen, Bert Wijnen and 373 the NETCONF mailing list members for their comments on this document. 374 Charlie Kaufman, Pasi Eronen, and Tim Polk provided a the thorough 375 review of previous versions of this document. Stephen Hanna wrote 376 the initial text for the applicability statement. 378 Juergen Schoenwaelder and was partly funded by Flamingo, a Network of 379 Excellence project (ICT-318488) supported by the European Commission 380 under its Seventh Framework Programme. 382 6. Contributor's Address 384 Ibrahim Hajjeh 385 Ineovation 386 France 388 EMail: ibrahim.hajjeh@ineovation.fr 390 7. References 392 7.1. Normative References 394 [I-D.ietf-netmod-snmp-cfg] 395 Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for 396 SNMP Configuration", draft-ietf-netmod-snmp-cfg-03 (work 397 in progress), November 2013. 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 403 for Transport Layer Security (TLS)", RFC 4279, 404 December 2005. 406 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 407 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 409 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 410 Housley, R., and W. Polk, "Internet X.509 Public Key 411 Infrastructure Certificate and Certificate Revocation List 412 (CRL) Profile", RFC 5280, May 2008. 414 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 415 Verification of Domain-Based Application Service Identity 416 within Internet Public Key Infrastructure Using X.509 417 (PKIX) Certificates in the Context of Transport Layer 418 Security (TLS)", RFC 6125, March 2011. 420 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 421 Bierman, "Network Configuration Protocol (NETCONF)", 422 RFC 6241, June 2011. 424 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 425 Shell (SSH)", RFC 6242, June 2011. 427 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 428 Cheshire, "Internet Assigned Numbers Authority (IANA) 429 Procedures for the Management of the Service Name and 430 Transport Protocol Port Number Registry", BCP 165, 431 RFC 6335, August 2011. 433 7.2. Informative References 435 [I-D.kwatsen-netconf-server] 436 Watsen, K. and J. SchoeCnwaelder, "A YANG Data Model for 437 NETCONF Server Configuration", 438 draft-kwatsen-netconf-server-00 (work in progress), 439 January 2014. 441 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 442 Issues", RFC 3234, February 2002. 444 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 445 Transport Layer Security (TLS) with Network News Transfer 446 Protocol (NNTP)", RFC 4642, October 2006. 448 [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 449 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 450 December 2006. 452 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 453 RFC 5539, May 2009. 455 Appendix A. Change Log (to be removed by RFC Editor before publication) 457 A.1. draft-ietf-netconf-rfc5539bis-05 459 o Removed the YANG configuration data model since it became a 460 separate document. 462 o Added reference to RFC 3234 plus editorial updates. 464 A.2. draft-ietf-netconf-rfc5539bis-04 466 o Added the applicability statement proposed by Stephen Hanna. 468 o Added call-home configuration objects and a tls-call-home feature. 470 o Rewrote the text such that the role swap happens right after the 471 TCP connection has been established. 473 A.3. draft-ietf-netconf-rfc5539bis-03 475 o Added support for call home (allocation of a new port number, 476 rewrote text to allow a NETCONF client to be a TLS server and a 477 NETCONF server to be a TLS client). 479 o Merged sections 2 and 3 into a new section 2 and restructured the 480 text. 482 o Extended the IANA considerations section. 484 o Using the cert-to-name mapping grouping from the SNMP 485 configuration data model and updated the examples. 487 o Creating an extensible set of YANG (sub)modules for NETCONF 488 following the (sub)module structure of the SNMP configuration 489 model. 491 A.4. draft-ietf-netconf-rfc5539bis-02 493 o Addressed remaining issues identified at IETF 85 495 * Harmonized the cert-maps container of the YANG module in this 496 draft with the tlstm container in the ietf-snmp-tls sub-module 497 specified in draft-ietf-netmod-snmp-cfg. Replaced the children 498 of the cert-maps container with the children copied from the 499 tlstm container of the ietf-snmp-tls sub-module. 501 * Added an overview of data model in the ietf-netconf-tls YANG 502 module. 504 * Added example configurations. 506 o Addessed issues posted on NETCONF WG E-mail list. 508 o Deleted the superfluous tls container that was directly below the 509 netconf-config container. 511 o Added a statement to the text indicating that support for mapping 512 X.509 certificates to NETCONF usernames is optional. This is 513 analogous to existing text indicating that support for mapping 514 pre-shared keys to NETCONF usernames is optional. Resource- 515 constrained systems now can omit support for mapping X.509 516 certificates to NETCONF usernames and still comply with this 517 specification. 519 o Clarified the document structure by promoting the sections of the 520 document related to the data model. 522 o Updated author's addresses. 524 A.5. draft-ietf-netconf-rfc5539bis-00 526 o Remove the reference to BEEP. 528 o Rename host-part to domain-part in the description of RFC822. 530 Authors' Addresses 532 Mohamad Badra 533 LIMOS Laboratory 535 Email: mbadra@gmail.com 537 Alan Luchuk 538 SNMP Research, Inc. 539 3001 Kimberlin Heights Road 540 Knoxville, TN 37920 541 US 543 Phone: +1 865 573 1434 544 Email: luchuk@snmp.com 545 URI: http://www.snmp.com/ 546 Juergen Schoenwaelder 547 Jacobs University Bremen 548 Campus Ring 1 549 28759 Bremen 550 Germany 552 Phone: +49 421 200 3587 553 Email: j.schoenwaelder@jacobs-university.de 554 URI: http://www.jacobs-university.de/