idnits 2.17.1 draft-ietf-netconf-call-home-04.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4253, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4253, updated by this document, for RFC5378 checks: 1997-03-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2, 2015) is 3370 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5539 (Obsoleted by RFC 7589) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Updates: 4253 (if approved) February 2, 2015 5 Intended status: Standards Track 6 Expires: August 6, 2015 8 NETCONF Call Home and RESTCONF Call Home 9 draft-ietf-netconf-call-home-04 11 Abstract 13 This document presents NETCONF Call Home and RESTCONF Call Home, 14 which respectively enable a NETCONF/RESTCONF server to initiate a 15 secure connection to a NETCONF/RESTCONF client. 17 Editorial Note (To be removed by RFC Editor) 19 This draft contains many placeholder values that need to be replaced 20 with finalized values at the time of publication. This note 21 summarizes all of the substitutions that are needed. Please note 22 that no other RFC Editor instructions are specified anywhere else in 23 this document. 25 Artwork in this document contains placeholder references for this 26 draft. Please apply the following replacement: 28 o "XXXX" --> the assigned RFC value for this draft 30 This document contains references to other drafts in progress, both 31 in the Normative References section, as well as in body text 32 throughout. Please update the following references to reflect their 33 final RFC assignments: 35 o draft-ietf-netconf-restconf 37 o draft-ietf-netconf-server-model 39 Artwork in this document contains placeholder values for ports 40 pending IANA assignment from "draft-ietf-netconf-call-home". Please 41 apply the following replacements: 43 o "PORT-X" --> the assigned port value for "netconf-ch-ssh" 45 o "PORT-Y" --> the assigned port value for "netconf-ch-tls" 47 o "PORT-Z" --> the assigned port value for "restconf-ch-tls" 48 The following two Appendix sections are to be removed prior to 49 publication: 51 o Appendix A. Change Log 53 o Appendix B. Open Issues 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at http://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on August 6, 2015. 72 Copyright Notice 74 Copyright (c) 2015 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (http://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 90 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 91 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 4 92 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4 93 1.4. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . 5 94 2. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 5 95 2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 5 96 2.2. Configuration Data Model . . . . . . . . . . . . . . . . 6 97 3. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 6 98 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 99 3.2. Server Identification and Verification . . . . . . . . . 7 100 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 101 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 102 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 103 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 104 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 105 7.2. Informative References . . . . . . . . . . . . . . . . . 11 106 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 107 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 12 108 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 12 109 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 12 110 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 12 111 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 12 113 1. Introduction 115 This document presents NETCONF Call Home and RESTCONF Call Home, 116 which respectively enable a NETCONF/RESTCONF server to initiate a 117 secure connection to a NETCONF/RESTCONF client. The NETCONF protocol 118 is described in [RFC6241] and the RESTCONF is described in 119 [draft-ietf-netconf-restconf]. 121 Both NETCONF Call Home and RESTCONF Call Home preserve the client/ 122 server roles of underlying transport, as when compared to standard 123 NETCONF and RESTCONF connections. Specifically, regardless if call 124 home is used or not, the SSH and TLS client/server roles are the 125 same. The SSH protocol is defined in [RFC4253] and the TLS protocol 126 is defined in [RFC5246]. 128 Ensuring consistency in the SSH and TLS roles is both necessary and 129 desirable. Ensuring consistency is necessary for the SSH protocol, 130 as SSH channels and subsystems can only be opened on the SSH server, 131 which thus must always be the NETCONF server, in order to support 132 NETCONF over SSH [RFC6242]. Ensuring consistency is desirable, for 133 both the SSH and TLS protocols, as it conveniently leverages 134 infrastructure that may be deployed for host-key or certificate 135 verification and user authentication. 137 1.1. Motivation 139 Call home is generally useful for both the initial deployment and on- 140 going management of networking elements. Here are some scenarios 141 enabled by call home: 143 o The network element may proactively call home after being powered 144 on for the first time in order to register itself with its 145 management system. 147 o The network element may access the network in a way that 148 dynamically assigns it an IP address and it doesn't register its 149 assigned IP addressed to a mapping service, thus complicating the 150 ability for a management system to connect to it. 152 o The network element may be deployed behind a firewall that 153 implements network address translation (NAT) for all internal 154 network IP addresses, thus complicating the ability for a 155 management system to connect to it. 157 o The network element may be deployed behind a firewall that doesn't 158 allow any management access to the internal network. 160 o The network element may be configured in "stealth mode" and thus 161 doesn't have any open ports for the management system to connect 162 to. 164 o The operator may prefer to have network elements initiate 165 management connections, believing it is easier to secure one open- 166 port in the data center than to have an open port on each network 167 element in the network. 169 As the NETCONF and RESTCONF protocols become increasingly popular for 170 programatic management of networking elements, having call home 171 support for these two protocols is particularly desirable. 173 1.2. Requirements Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [RFC2119]. 179 1.3. Applicability Statement 181 The techniques described in this document are suitable for network 182 management scenarios such as the ones described in Section 1.1. 183 However, these techniques SHOULD only be used for NETCONF Call Home 184 and RESTCONF Call Home, as described in this document. 186 The reason for this restriction is that different protocols have 187 different security assumptions. The NETCONF and RESTCONF protocols 188 require clients and servers to verify the identity of the other party 189 before starting the NETCONF/RESTCONF protocol (section 2.2 of 190 [RFC6241] and sections 2.4 and 2.5 of [draft-ietf-netconf-restconf]). 192 This contrasts with the base SSH and TLS protocols, which do not 193 require programmatic verification of the other party (section 9.3.4 194 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). 195 In such circumstances, allowing the SSH/TLS server to contact the 196 SSH/TLS client would open new vulnerabilities. Any use of call home 197 with SSH/TLS for purposes other than NETCONF or RESTCONF will need a 198 thorough, contextual security analysis. 200 1.4. Update to RFC 4253 202 This document updates the SSH Transport Layer Protocol [RFC4253] only 203 in removing the "The client initiates the connection" statement made 204 in Section 4 (Connection Setup). This document assumes that the 205 reference to "connection" refers to the underlying transport 206 connection (e.g., TCP), which the NETCONF server would initiate in a 207 call home connection using the SSH protocol, even though it will not 208 take on the role of the SSH client. Security implications related to 209 this change are discussed in Security Considerations (Section 4). 211 2. The NETCONF or RESTCONF Server 213 2.1. Protocol Operation 215 o The NETCONF/RESTCONF server initiates a TCP connection request 216 (SYN) to the NETCONF/RESTCONF client. The server SHOULD default 217 to connecting to one of the IANA-assigned ports defined in section 218 Section 5, but MAY be configured to use a non-default port. 220 o The TCP connection request is accepted and a TCP connection is 221 established. 223 o Using this TCP connection, the NETCONF/RESTCONF server MUST 224 immediately start using either the SSH-server [RFC4253] or the 225 TLS-server [RFC5246] protocol, depending on how it is configured. 226 For example, assuming the use of the IANA-assigned ports, the SSH- 227 server protocol is used for PORT-X and the TLS-server protocol is 228 used for either port PORT-Y or PORT-Z. 230 o Once the SSH or TLS connection is established, the NETCONF/ 231 RESTCONF server MUST immediately start using either the NETCONF- 232 server [RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] 233 protocol, depending on how it is configured. Assuming the use of 234 the IANA-assigned ports, the NETCONF-server protocol is used for 235 PORT-X or PORT-Y and the RESTCONF-server protocol is used for 236 PORT-Z. 238 o The NETCONF protocol's binding to SSH and TLS is defined in 239 [RFC6242] and [RFC5539] respectively. The RESTCONF protocol's 240 binding to TLS is is defined in [RFC7230]. 242 2.2. Configuration Data Model 244 How to configure a NETCONF or RESTCONF server to initiate a call home 245 connection is outside the scope of this document, as implementations 246 can support this protocol using proprietary configuration data 247 models. That said, a YANG [RFC6020] model for configuring both 248 NETCONF Call Home and RESTCONF Call Home is provided in 249 [draft-ietf-netconf-server-model]. 251 3. The NETCONF or RESTCONF Client 253 3.1. Protocol Operation 255 o The NETCONF/RESTCONF client listens for TCP connections from 256 NETCONF/RESTCONF servers. The client SHOULD default to listening 257 for connections on the IANA-assigned ports defined in section 258 Section 5, but MAY be configured to use a non-default port. 260 o The NETCONF/RESTCONF client accepts an incoming TCP connection 261 request and a TCP connection is established. 263 o Using this TCP connection, the NETCONF/RESTCONF client MUST 264 immediately start using either the SSH-client [RFC4253] or the 265 TLS-client [RFC5246] protocol, depending on how it is configured. 266 For example, assuming the use of the IANA-assigned ports, the SSH- 267 client protocol is used for PORT-X and the TLS-client protocol is 268 used for either port PORT-Y or PORT-Z. 270 o Once the SSH or TLS connection is established, the NETCONF/ 271 RESTCONF client MUST immediately start using either the NETCONF- 272 client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] 273 protocol, depending on how it is configured. Assuming the use of 274 the IANA-assigned ports, the NETCONF-client protocol is used for 275 PORT-X or PORT-Y and the RESTCONF-client protocol is used for 276 PORT-Z. 278 o The NETCONF protocol's binding to SSH and TLS is defined in 279 [RFC6242] and [RFC5539] respectively. The RESTCONF protocol's 280 binding to TLS is is defined in [RFC7230]. 282 3.2. Server Identification and Verification 284 Under normal circumstances, a NETCONF/RESTCONF client initiates the 285 connection to the NETCONF/RESTCONF server. This action provides 286 essential input used to verify the NETCONF/RESTCONF server's 287 identity. For instance, when using TLS, the input can be compared to 288 the domain names and IP addresses encoded in X.509 certificates. 289 Similarly, when using SSH, the input can be compared to information 290 persisted previously. 292 However, when receiving a call home connection, the NETCONF/RESTCONF 293 client does not have any context leading it to know the connection is 294 from a particular NETCONF/RESTCONF server. Thus the NETCONF/RESTCONF 295 client must derive the NETCONF/RESTCONF server's identity using 296 information provided by the network and the NETCONF/RESTCONF server 297 itself. This section describes strategies a NETCONF/RESTCONF client 298 can use to identify a NETCONF/RESTCONF server. 300 In addition to identifying a NETCONF/RESTCONF server, a NETCONF/ 301 RESTCONF client must also be able to verify the server's identity. 302 Verifying a NETCONF/RESTCONF server's identity is necessary under 303 normal circumstances but, due to call home being commonly used for 304 newly deployed NETCONF/RESTCONF servers, how to verify its identity 305 the very first time becomes a prominent concern. Therefore, this 306 section also describes strategies a NETCONF/RESTCONF client can use 307 to verify a NETCONF/RESTCONF server's identity. 309 The first information a NETCONF/RESTCONF client learns from a call 310 home connection is the IP address of the NETCONF/RESTCONF server, as 311 provided by the source address of the TCP connection. This IP 312 address could be used as an identifier directly, but doing so would 313 only work in networks that use known static addresses, in which case 314 a standard NETCONF/RESTCONF connection would have worked just as 315 well. Due to this limited use, it is not recommended to identify a 316 NETCONF/RESTCONF server based on its source IP address. 318 The next information a NETCONF/RESTCONF client learns is provided by 319 the NETCONF/RESTCONF server in the form of a host-key or a 320 certificate, for the SSH and TLS protocols respectively. Without 321 examining the contents of the host-key or certificate, it is possible 322 to form an identity for the NETCONF/RESTCONF server using it directly 323 (e.g., a fingerprint). This works because each NETCONF/RESTCONF 324 server is assumed to have a statistically unique public key, even in 325 virtualized environments. This strategy also provides a mechanism to 326 verify the identity of the NETCONF/RESTCONF server, in that a secure 327 connection can only be established with the NETCONF/RESTCONF server 328 having the matching private key. This strategy is commonly 329 implemented by SSH clients, and could be used equally well by TLS- 330 based clients, such as may be required when the NETCONF/RESTCONF 331 servers have self-signed certificates. This strategy is viable and 332 useful when the NETCONF/RESTCONF servers call home using either SSH 333 with standard RSA/DSA host-keys, or using TLS with self-signed 334 certificates. 336 Yet another option for identifying a NETCONF/RESTCONF server is for 337 its host key or certificate to encode its identity directly (e.g., 338 within the "Subject" field). However, in order to trust the content 339 encoded within a host-key or certificate, it must be signed by a 340 certificate authority trusted by the NETCONF/RESTCONF client. This 341 strategy's use of PKI enables a NETCONF/RESTCONF client to 342 transparently authenticate the NETCONF/RESTCONF server's certificate, 343 thus eliminating the need for manual authentication, as required by 344 the previously discussed strategies. Elimination of manual steps is 345 needed to achieve scalable solutions, however one can claim that this 346 merely pushes equivalent work to provisioning the NETCONF/RESTCONF 347 servers with signed certificates. This assessment is accurate in 348 general, but not in the case where the manufacturer itself provisions 349 the certificates, such as is described by [Std-802.1AR-2009]. When 350 NETCONF/RESTCONF servers are pre-provisioned this way, NETCONF/ 351 RESTCONF clients can transparently authenticate NETCONF/RESTCONF 352 servers using just the manufacturer's trust anchor and a list of 353 expected NETCONF/RESTCONF server identifiers, which could be provided 354 along with shipping information. This strategy is recommended for 355 all deployment scenarios. 357 In discussing the use of certificates, it is worth noting that TLS 358 uses X.509 certificates by default. However, to use X.509 359 certificates with SSH, both the NETCONF client and server must 360 support [RFC6187]. 362 4. Security Considerations 364 The security considerations described throughout [RFC6242] and 365 [RFC5539], and by extension [RFC4253], [RFC5246], and 366 [draft-ietf-netconf-restconf] apply here as well. 368 This RFC deviates from standard SSH and TLS usage by having the SSH/ 369 TLS server initiate the underlying TCP connection. For SSH, 370 [RFC4253] says "the client initiates the connection", whereas for 371 TLS, [RFC5246] says it is layered on top of "some reliable transport 372 protocol" without further attribution. 374 Not having the SSH/TLS client initiate the TCP connection means that 375 it does not have a preconceived notion of the SSH/TLS server's 376 identity, and therefore must dynamically derive one from information 377 provided by the network or the SSH/TLS server itself. Security 378 Considerations for strategies for this are described in Section 3.2. 380 An attacker could DoS the NETCONF/RESTCONF client by having it 381 perform computationally expensive operations, before deducing that 382 the attacker doesn't posses a valid key. This is no different than 383 any secured service and all common precautions apply (e.g., 384 blacklisting the source address after a set number of unsuccessful 385 login attempts). 387 5. IANA Considerations 389 This document requests that IANA assigns three TCP port numbers in 390 the "Registered Port Numbers" range with the service names "netconf- 391 ch-ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will 392 be the default ports for NETCONF Call Home and RESTCONF Call Home 393 protocols. Below is the registration template following the rules in 394 [RFC6335]. 396 Service Name: netconf-ch-ssh 397 Transport Protocol(s): TCP 398 Assignee: IESG 399 Contact: IETF Chair 400 Description: NETCONF Call Home (SSH) 401 Reference: RFC XXXX 402 Port Number: PORT-X 404 Service Name: netconf-ch-tls 405 Transport Protocol(s): TCP 406 Assignee: IESG 407 Contact: IETF Chair 408 Description: NETCONF Call Home (TLS) 409 Reference: RFC XXXX 410 Port Number: PORT-Y 412 Service Name: restconf-ch-tls 413 Transport Protocol(s): TCP 414 Assignee: IESG 415 Contact: IETF Chair 416 Description: RESTCONF Call Home (TLS) 417 Reference: RFC XXXX 418 Port Number: PORT-Z 420 6. Acknowledgements 422 The author would like to thank for following for lively discussions 423 on list and in the halls (ordered by last name): Andy Bierman, Martin 424 Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David 425 Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ 426 Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Hannes Tschofenig, 427 Sean Turner, Bert Wijnen. 429 7. References 431 7.1. Normative References 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, March 1997. 436 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 437 Protocol Architecture", RFC 4251, January 2006. 439 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 440 Authentication Protocol", RFC 4252, January 2006. 442 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 443 Transport Layer Protocol", RFC 4253, January 2006. 445 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 446 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 448 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 449 RFC 5539, May 2009. 451 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 452 Network Configuration Protocol (NETCONF)", RFC 6020, 453 October 2010. 455 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 456 Shell Authentication", RFC 6187, March 2011. 458 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 459 Bierman, "Network Configuration Protocol (NETCONF)", RFC 460 6241, June 2011. 462 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 463 Shell (SSH)", RFC 6242, June 2011. 465 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 466 Cheshire, "Internet Assigned Numbers Authority (IANA) 467 Procedures for the Management of the Service Name and 468 Transport Protocol Port Number Registry", BCP 165, RFC 469 6335, August 2011. 471 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 472 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 473 2014. 475 [draft-ietf-netconf-restconf] 476 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 477 Protocol", draft-ieft-netconf-restconf-04 (work in 478 progress), 2014. 480 7.2. Informative References 482 [Std-802.1AR-2009] 483 IEEE SA-Standards Board, "IEEE Standard for Local and 484 metropolitan area networks - Secure Device Identity", 485 December 2009, . 488 [draft-ietf-netconf-server-model] 489 Watsen, K. and J. Schoenwaelder, "NETCONF Server 490 Configuration Model", 2014, . 493 Appendix A. Change Log 495 A.1. 00 to 01 497 o The term "TCP connection" is now used throughout. 499 o The terms "network element" and "management system" are now only 500 used in the Motivation section. 502 o Restructured doc a little to create an Introduction section. 504 o Fixed reference in Applicability Statement so it would work 505 equally well for SSH and TLS. 507 o Fixed reported odd wording and three references. 509 A.2. 01 to 02 511 o Added call home support for the RESTCONF protocol. 513 o Fixed paragraph 3 of Security Considerations to equally apply to 514 the TLS protocol. 516 A.3. 02 to 03 518 o Tried to improve readability (issue #6) 520 o Removed "FIXME" in section 1.3 (issue #7) 522 o Added RFC Editor notes (issue #8) 524 o Removed "TCP session" term (issue #9) 526 o Improved language for usage of IANA-assigned ports (issue #10) 528 A.4. 03 to 04 530 o Replaced "verify credentials" with "verify identity" (issue #11) 532 Appendix B. Open Issues 534 All issues with this draft are tracked using GitHub issues. Please 535 see: https://github.com/netconf-wg/call-home/issues to see currently 536 opened issues. 538 Author's Address 540 Kent Watsen 541 Juniper Networks 543 EMail: kwatsen@juniper.net