idnits 2.17.1 draft-gupta-ospf-ospfv2-sec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Aug 2009) is 5368 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 4835 (ref. 'N6') (Obsoleted by RFC 7321) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'I1') (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Gupta 3 Internet Draft Juniper Networks 4 Document: draft-gupta-ospf-ospfv2-sec-01.txt N. Melam 5 Intended Status: Proposed Standard Juniper Networks 6 Expires: Feb 2010 Aug 2009 8 Authentication/Confidentiality for OSPFv2 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before November 17 10, 2008. The person(s) controlling the copyright in some of this 18 material may not have granted the IETF Trust the right to allow 19 modifications of such material outside the IETF Standards Process. 20 Without obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be modified 22 outside the IETF Standards Process, and derivative works of it may 23 not be created outside the IETF Standards Process, except to format 24 it for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire in Feb, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document describes means and mechanisms to provide 59 authentication/confidentiality to OSPFv2 using IPsec (IP Security). 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC-2119 [N7]. 67 Table of Contents 69 1. Introduction...................................................2 70 2. Transport Mode vs Tunnel Mode..................................3 71 3. Authentication.................................................3 72 4. Confidentiality................................................4 73 5. Distinguishing OSPFv2 from OSPFv3 [N2].........................4 74 6. IPsec Requirements.............................................4 75 7. Key Management.................................................5 76 8. SA Granularity and Selectors...................................7 77 9. Virtual Links..................................................8 78 10. Rekeying......................................................8 79 10.1 . Rekeying Procedure......................................8 80 10.2 . KeyRolloverInterval.....................................9 81 10.3 . Rekeying Interval.......................................9 82 11. IPsec rules..................................................10 83 12. Entropy of Manual Keys.......................................11 84 13. Replay Protection............................................11 85 Security Considerations..........................................11 86 IANA Considerations..............................................12 87 Normative References.............................................12 88 Informative References...........................................13 89 Acknowledgments..................................................13 90 Authors' Addresses...............................................13 92 1. 93 Introduction 95 OSPF (Open Shortest Path First) Version 2 [N1] defines the fields 96 AuType and Authentication in its protocol header to provide security. 97 These fields do not provide any confidentiality and also the 98 authentication provided by these fields is weak [specific problems 99 here]. 101 The demands for securing the routing protocols have increased since 102 the OSPFv2 protocol was designed. This document describes how IP 103 Security (Encapsulating Security Payload and Authentication Header 104 protocols) can be used to provide integrity, authentication, and/or 105 confidentiality to OSPFv2. 107 It is assumed that the reader is familiar with OSPFv2 [N1], 108 Authentication Header (AH) [N5], Encapsulating Security Payload (ESP) 109 [N4], the concept of security associations, tunnel and transport mode 110 of IPsec, and the key management options available for AH and ESP 111 (manual keying [N3] and Internet Key Exchange (IKE)[I1]). 113 2. 114 Transport Mode vs Tunnel Mode 116 The transport mode Security Association (SA) is generally used 117 between two hosts or routers/gateways when they are acting as hosts. 118 The SA must be a tunnel mode SA if either end of the security 119 association is a router/gateway. Two hosts MAY establish a tunnel 120 mode SA between themselves. OSPFv2 packets are exchanged between 121 routers. However, since the packets are locally delivered, the 122 routers assume the role of hosts in the context of tunnel mode SA. 123 All implementations confirming to this specification MUST support 124 transport mode SA to provide required IPsec security to OSPFv2 125 packets. They MAY also support tunnel mode SA to provide required 126 IPsec security to OSPFv2 packets. 128 3. 129 Authentication 131 Implementations conforming to this specification MUST support 132 authentication for OSPFv2. 134 In order to provide authentication to OSPFv2, implementations MUST 135 support ESP and MAY support AH. 137 If ESP in transport mode is used, it will only provide authentication 138 to OSPFv2 protocol packets excluding the IP header and IP options. 140 If AH in transport mode is used, it will provide authentication to 141 OSPFv2 protocol packet, selected portions of IP header and selected 142 IP options. 144 When OSPFv2 authentication is enabled, 146 o OSPFv2 packets that are not protected with AH or ESP MUST be 147 silently discarded. 149 o OSPFv2 packets that fail the authentication checks MUST be 150 silently discarded. 152 4. 153 Confidentiality 155 Implementations conforming to this specification SHOULD support 156 confidentiality for OSPFv2. 158 If confidentiality is provided, ESP MUST be used. 160 When OSPFv2 confidentiality is enabled, 162 o OSPFv2 packets that are not protected with ESP MUST be silently 163 discarded. 165 o OSPFv2 packets that fail the confidentiality checks MUST be 166 silently discarded. 168 5. 169 Distinguishing OSPFv2 from OSPFv3 [N2] 171 The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89) and 172 OSPF distinguishes them based on the OSPF header version number. 173 However, current IPsec standards do not allow using arbitrary 174 protocol-specific header fields as the selectors. Therefore, the 175 OSPF version field in the OSPF header cannot be used in order to 176 distinguish OSPFv2 packets from OSPFv3 packets. As OSPFv2 is only 177 for IPv4 and OSPFv3 is only for IPv6, the version field in the IP 178 header can be used to distinguish OSPFv2 packets from OSPFv3 packets. 180 6. 181 IPsec Requirements 183 In order to implement this specification, the following IPsec 184 capabilities are required. 186 Transport mode 187 IPsec in transport mode MUST be supported. [N3] 189 Multiple Security Policy Databases (SPDs) 190 The implementation MUST support multiple SPDs with a specific SPD 191 selection function. [N3] 193 Selectors 194 The implementation MUST be able to use source address, destination 195 address, protocol, and direction as selectors in the SPD. 197 Interface ID tagging 198 The implementation MUST be able to tag the inbound packets with 199 the ID of the interface (physical or virtual) via which it 200 arrived. [N3] 202 Manual key support 203 Manually configured keys MUST be able to secure the specified 204 traffic. [N3] 206 Encryption and authentication algorithms 208 The implementation MUST NOT allow the user to choose stream 209 ciphers as the encryption algorithm for securing OSPFv2 packets 210 since the stream ciphers are not suitable for manual keys. 212 Except when in conflict with the above statement, the key words 213 "MUST", "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that 214 appear in the [N6] document for algorithms to be supported are to 215 be interpreted as described in [N7] for OSPFv2 support as well. 217 Dynamic IPsec rule configuration 218 The routing module SHOULD be able to configure, modify and delete 219 IPsec rules on the fly. This is needed mainly for securing 220 virtual links. 222 Encapsulation of ESP packet 223 IP encapsulation of ESP packets MUST be supported. For 224 simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. 226 Different SAs for different Differentiated Services Code Points 227 (DSCPs) 228 As per [N3], the IPsec implementation MUST support the 229 establishment and maintenance of multiple SAs with the same 230 selectors between a given sender and receiver. This allows the 231 implementation to associate different classes of traffic with the 232 same selector values in support of Quality of Service (QoS). 234 7. 235 Key Management 237 OSPFv2 exchanges both multicast and unicast packets. While running 238 OSPFv2 over a broadcast interface, the authentication/confidentiality 239 required is "one to many". Since IKE is based on the Diffie-Hellman 240 key agreement protocol and works only for two communicating parties, 241 it is not possible to use IKE for providing the required "one to 242 many" authentication/confidentiality. This specification mandates 243 the usage of Manual Keying with current IPsec implementations. 244 Future specifications can explore the usage of protocols like 245 Kerberized Internet Negotiation of Keys/Group Secure Association Key 246 Management Protocol (KINK/GSAKMP) when they are widely available. In 247 manual keying, SAs are statically installed on the routers and these 248 static SAs are used to authenticate/encrypt packets. 250 The following discussion explains that it is not scalable and is 251 practically infeasible to use different security associations for 252 inbound and outbound traffic to provide the required "one to many" 253 security. Therefore, the implementations MUST use manually 254 configured keys with the same SA parameters (Security Parameter Index 255 (SPI), keys etc.,) for both inbound and outbound SAs (as shown in 256 Figure 3). 258 A | 259 SAa ------------>| 260 SAb <------------| 261 | 262 B | 263 SAb ------------>| 264 SAa <------------| Figure: 1 265 | 266 C | 267 SAa/SAb ------------>| 268 SAa/SAb <------------| 269 | 270 Broadcast 271 Network 273 If we consider communication between A and B in Figure 1, everything 274 seems to be fine. A uses security association SAa for outbound 275 packets and B uses the same for inbound packets and vice versa. Now 276 if we include C in the group and C sends a packet using SAa, then 277 only A will be able to understand it. Similarly, if C sends a packet 278 using SAb, then only B will be able to understand it. Since the 279 packets are multicast and they are going to be processed by both A 280 and B, there is no SA for C to use so that both A and B can 281 understand them. 283 A | 284 SAa ------------>| 285 SAb <------------| 286 SAc <------------| 287 | 289 B | 290 SAb ------------>| 291 SAa <------------| Figure: 2 292 SAc <------------| 293 | 294 C | 295 SAc ------------>| 296 SAa <------------| 297 SAb <------------| 298 | 299 Broadcast 300 Network 302 The problem can be solved by configuring SAs for all the nodes on 303 every other node as shown in Figure 2. So A, B, and C will use SAa, 304 SAb, and Sac, respectively, for outbound traffic. Each node will 305 lookup the SA to be used based on the source (A will use SAb and SAc 306 for packets received from B and C, respectively). This solution is 307 not scalable and practically infeasible because a large number of SAs 308 will need to be configured on each node. Also, the addition of a 309 node in the broadcast network will require the addition of another SA 310 on every other node. 312 A | 313 SAo ------------>| 314 SAi <------------| 315 | 316 B | 317 SAo ------------>| 318 SAi <------------| Figure: 3 319 | 320 C | 321 SAo ------------>| 322 SAi <------------| 323 | 324 Broadcast 325 Network 327 The problem can be solved by using the same SA parameters (SPI, Keys, 328 etc.) for both inbound (SAi) and outbound (SAo) SAs as shown in 329 Figure 3. 331 8. 332 SA Granularity and Selectors 334 The user SHOULD be given the choice of sharing the same SA among 335 multiple interfaces or using a unique SA per interface. 337 9. 338 Virtual Links 340 A different SA than the SA of the underlying interface MUST be 341 provided for virtual links. The source IP address of the OSPF 342 packets sent over the virtual links does not belong to the same 343 subnet as the interface running OSPFv2. The source IP address of all 344 the other OSPF packets, however, lies in the same subnet. This 345 difference in the IP source address differentiates the packets sent 346 on virtual links from other OSPFv2 interface types. 348 As the virtual link end point IP addresses are not known, it is not 349 possible to install SPD/Security Association Database (SAD) entries 350 at the time of configuration. The virtual link end point IP 351 addresses are learned during the routing table computation process. 352 The packet exchange over the virtual links starts only after the 353 discovery of the end point IP addresses. In order to protect these 354 exchanges, the routing module must install the corresponding SPD/SAD 355 entries before starting these exchanges. Note that manual SA 356 parameters are preconfigured but not installed in the SAD until the 357 end point addresses are learned. 359 10. 360 Rekeying 362 To maintain the security of a link, the authentication and encryption 363 key values SHOULD be changed from periodically. 365 10.1 366 . Rekeying Procedure 368 The following three-step procedure SHOULD be provided to rekey the 369 routers on a link without dropping OSPFv2 protocol packets or 370 disrupting the adjacency. 372 (1) For every router on the link, create an additional inbound SA for 373 the interface being rekeyed using a new SPI and the new key. 375 (2) For every router on the link, replace the original outbound SA 376 with one using the new SPI and key values. The SA replacement 377 operation should be atomic with respect to sending OSPFv2 packets 378 on the link so that no OSPFv2 packets are sent without 379 authentication/encryption. 381 (3) For every router on the link, remove the original inbound SA. 383 Note that all routers on the link must complete step 1 before any 384 begin step 2. Likewise, all the routers on the link must complete 385 step 2 before any begin step 3. 387 One way to control the progression from one step to the next is for 388 each router to have a configurable time constant KeyRolloverInterval. 389 After the router begins step 1 on a given link, it waits for this 390 interval and then moves to step 2. Likewise, after moving to step 2, 391 it waits for this interval and then moves to step 3. 393 In order to achieve smooth key transition, all routers on a link 394 should use the same value for KeyRolloverInterval and should initiate 395 the key rollover process within this time period. 397 At the end of this procedure, all the routers on the link will have a 398 single inbound and outbound SA for OSPFv2 with the new SPI and key 399 values. 401 10.2 402 . KeyRolloverInterval 404 The configured value of KeyRolloverInterval should be long enough to 405 allow the administrator to change keys on all the OSPFv2 routers. As 406 this value can vary significantly depending upon the implementation 407 and the deployment, it is left to the administrator to choose the 408 appropriate value. 410 10.3 411 . Rekeying Interval 413 This section analyzes the security provided by manual keying and 414 recommends that the encryption and authentication keys SHOULD be 415 changed at least every 90 days. 417 The weakest security provided by the security mechanisms discussed in 418 this specification is when NULL encryption (for ESP) or no encryption 419 (for AH) is used with the HMAC-MD5 authentication. Any other 420 algorithm combinations will at least be as hard to break as the ones 421 mentioned above. This is shown by the following reasonable 422 assumptions: 424 o NULL Encryption and HMAC-SHA-1 Authentication will be more secure 425 as HMAC-SHA-1 is considered to be more secure than HMAC-MD5. 427 o NON-NULL Encryption and NULL Authentication combination is not 428 applicable as this specification mandates authentication when OSPFv2 429 security is enabled. 431 o Data Encryption Security (DES) Encryption and HMAC-MD5 432 Authentication will be more secure because of the additional security 433 provided by DES. 435 o Other encryption algorithms like 3DES and the Advanced Encryption 436 Standard (AES) will be more secure than DES. 438 RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5 439 signature option. The analysis provided in RFC 3562 is also 440 applicable to this specification as the analysis is independent of 441 data patterns. 443 11. 444 IPsec rules 446 The following set of transport mode rules can be installed in the SPD 447 to provide the authentication/confidentiality to OSPFv2 packets. 449 Outbound Rules for interfaces running OSPFv2 security: 451 No. source destination protocol action 452 1 intfPrefix any OSPF apply 454 Outbound Rules for virtual links running OSPFv2 security: 456 No. source destination protocol action 457 2 src/32 dst/32 OSPF apply 459 Inbound Rules for interfaces running OSPFv2 security: 461 No. source destination protocol action 462 3 intfPrefix any ESP/OSPF or AH/OSPF apply 463 4 intfPrefix any OSPF drop 465 Inbound Rules for virtual links running OSPFv2 security: 467 No. source destination protocol action 468 5 src/32 dst/32 ESP/OSPF or AH/OSPF apply 469 6 src/32 dst/32 OSPF drop 471 "intfPrefix" means the prefix of the interface that OSPFv2 is running 472 on. For example, if the IP address of the interface where OSPFv2 is 473 configured is 192.0.2.1/24, the value of "intfPrefix" would be 474 "192.0.2.0/24". 476 For outbound rules, action "apply" means encrypting/calculating ICV 477 and adding an ESP or AH header. For inbound rules, action "apply" 478 means decrypting/authenticating the packets and stripping the ESP or 479 AH header. 481 Rules 4 and 6 are to drop the insecure OSPFv2 packets without ESP/AH 482 headers. 484 ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet 485 secured with ESP or AH. 487 Rules 1, 3 and 4 are meant to secure the unicast and multicast OSPF 488 packets that are not being exchanged over the virtual links. These 489 rules MUST only be installed in the security policy database (SPD) of 490 the interface running OSPFv2 security. 492 Rules 2, 5 and 6 are meant to secure the packets being exchanged over 493 virtual links. These rules are installed after learning the virtual 494 link end point IPv6 addresses. These rules MUST be installed on at 495 least the interfaces that are connected to the transit area for the 496 virtual link. These rules MAY alternatively be installed on all the 497 interfaces. If these rules are not installed on all the interfaces, 498 clear text or malicious OSPFv2 packets with the same source and 499 destination addresses as the virtual link end point IPv6 addresses 500 will be delivered to OSPFv2. Though OSPFv2 drops these packets 501 because they were not received on the right interface, OSPFv2 502 receives some clear text or malicious packets even when the security 503 is enabled. Installing these rules on all the interfaces insures 504 that OSPFv2 does not receive these clear text or malicious packets 505 when security is turned enabled. On the other hand, installing these 506 rules on all the interfaces increases the processing overhead on the 507 interfaces where there is no other IPsec processing. The decision of 508 installing these rules on all the interfaces or on just the 509 interfaces that are connected to the transit area is a private 510 decision and doesn't affect the interoperability in any way. Hence 511 it is an implementation choice. 513 12. 514 Entropy of Manual Keys 515 The implementations MUST allow the administrator to configure the 516 cryptographic and authentication keys in hexadecimal format rather 517 than restricting it to a subset of ASCII characters (letters, numbers 518 etc.). A restricted character set will reduce key entropy 519 significantly as discussed in [I2]. 521 13. 522 Replay Protection 524 Since it is not possible using the current standards to provide 525 complete replay protection while using manual keying, the proposed 526 solution will not provide protection against replay attacks. 528 Detailed analysis of various vulnerabilities of the routing protocols 529 and OSPF in particular is discussed in [I3] and [I2]. The conclusion 530 is that replay of OSPF packets can cause adjacencies to be disrupted, 531 which can lead to a DoS attack on the network. It can also cause 532 database exchange process to occur continuously thus causing CPU 533 overload as well as micro loops in the network. 535 Security Considerations 536 This memo discusses the use of IPsec AH and ESP headers in order to 537 provide security to OSPFv2 for IPv6. Hence, security permeates 538 throughout this document. 540 OSPF Security Vulnerabilities Analysis [I2] identifies OSPF 541 vulnerabilities in two scenarios -- one with no authentication or 542 simple password authentication and the other with cryptographic 543 authentication. The solution described in this specification 544 provides protection against all the vulnerabilities identified for 545 scenarios with cryptographic authentication with the following 546 exceptions: 548 Limitations of manual key: 550 This specification mandates the usage of manual keys. The following 551 are the known limitations of the usage of manual keys. 553 o As the sequence numbers cannot be negotiated, replay protection 554 can not be provided. This leaves OSPF insecure against all the 555 attacks that can be performed by replaying OSPF packets. 557 o Manual keys are usually long lived (changing them often is 558 a tedious task). This gives an attacker enough time to discover 559 the keys. 561 o As the administrator is manually configuring the keys, there is 562 a chance that the configured keys are weak (there are known weak 563 keys for DES/3DES at least). 565 Impersonating attacks: 567 The usage of the same key on all the OSPF routers connected to a link 568 leaves them all insecure against impersonating attacks if any one of 569 the OSPF routers is compromised, malfunctioning or misconfigured. 571 Detailed analysis of various vulnerabilities of routing protocols is 572 discussed in [I3]. 574 IANA Considerations 575 This document has no IANA considerations. 577 This section should be removed by the RFC Editor to final 578 publication. 580 Normative References 582 [N1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 584 [N2] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for 585 IPv6", RFC 5340, July 2008. 587 [N3] Kent, S. and K. Seo, "Security Architecture for the Internet 588 Protocol", RFC 4301, December 2005. 590 [N4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 591 December 2005. 593 [N5] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 595 [N6] Manral, V., "Cryptographic Algorithm Implementation for 596 Encapsulating Security Payload (ESP) and Authentication Header 597 (AH)", RFC 4835, April 2007. 599 [N7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 600 Levels", BCP 14, RFC 2119, March 1997. 602 Informative References 604 [I1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 605 December 2005. 607 [I2] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities 608 Analysis", Work in Progress. 610 [I3] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing 611 Protocols", Work in Progress. 613 [I4] Leech, M., "Key Management Considerations for the TCP MD5 614 Signature Option", RFC 3562, July 2003. 616 [I5] Gupta, M. and N. Melam, "Authentication/Confidentiality for 617 OSPFv3", RFC 4552, June 2006. 619 Acknowledgments 621 This document is widely derived from Authentication/Confidentiality 622 to OSPFv3 [I5]. 624 Authors' Addresses 626 Mukesh Gupta 627 Juniper Networks 628 1194 N. Mathilda Ave 629 Sunnyvale, CA 94089 630 Phone: 408-936-4197 631 EMail: mukesh@juniper.net 632 Nagavenkata Suresh Melam 633 Juniper Networks 634 1194 N. Mathilda Ave 635 Sunnyvale, CA 94089 636 Phone: 408-505-4392 637 EMail: nmelam@juniper.net