idnits 2.17.1 draft-tran-karp-mrmp-02.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 (October 22, 2012) is 4203 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 (-16) exists of draft-yeung-g-ikev2-05 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-06) exists of draft-ietf-bfd-generic-crypto-auth-03 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-ldp-hello-crypto-auth-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Tran 3 Internet-Draft B. Weis 4 Intended status: Standards Track Cisco Systems 5 Expires: April 25, 2013 October 22, 2012 7 The Use of G-IKEv2 for Multicast Router Key Management 8 draft-tran-karp-mrmp-02 10 Abstract 12 The G-IKEv2 key management protocol protects group traffic, usually 13 in the form of IP multicast communications between a set of network 14 devices. This memo defines extensions to G-IKEv2 allowing it to 15 protect routing protocols between a group of network devices. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 25, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2. Overview of Group Key Management . . . . . . . . . . . . . . . 3 54 3. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Header and Payload Formats . . . . . . . . . . . . . . . . . . 6 56 4.1. Group Security Association Payload . . . . . . . . . . . . 6 57 4.1.1. GSA TEK Policy . . . . . . . . . . . . . . . . . . . . 6 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 66 1. Introduction 68 The G-IKEv2 protocol [I-D.yeung-g-ikev2] has been defined to 69 distribute group policy and keys to a group of network devices. It 70 uses IKEv2 protocols, incorporating payloads similar to GDOI 71 [RFC6407]. This memo describes a mode of using G-IKEv2 to protect 72 routing protocols (e.g., OSPF, PIM) and is known as G-IKEv2 for 73 Multicast Router Key Management (G-IKEv2-MRKM). Two models of group 74 security are discussed. 76 1.1. Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [RFC2119]. 82 2. Overview of Group Key Management 84 When a group of network devices need to communicate using multicast 85 communications, the devices need to share keying material and the 86 policy associated with that keying material. A group key management 87 (GKM) protocol is used to securely distribute this keying material 88 and associated policy. Typically each network device (also known as 89 a group member (GM)) needing to participate in the group "registers" 90 to a group controller/key server (GCKS), during which mutual 91 authentication and authorization occur. The GCKS also distributes 92 current group policy and keying material to the group member over an 93 authenticated and encrypted session. 95 Many routing protocols are designed such that each participating 96 network device sources network packet that one or more peers receive, 97 often using link-local multicast addresses. Using GKM terminology, 98 this is an M-to-N communication model [RFC3740], which provides for 99 many senders and receivers. However, varying group security models 100 are possible. Two relevant examples are: 102 o Multiple-sender security associations. Each network devices 103 protects packets using the same keying material and policy, 104 distributed by a single GCKS. When network devices require high 105 reliability a single GCKS is not sufficient, so may require an 106 election among currently available authorized members to choose a 107 GCKS before network communications can be protected. This 108 approach is taken in [I-D.hartman-karp-mrkmp]. A simpler approach 109 may be found by requiring all election messages to be 110 authenticated, which effectively sets up a full mesh of 111 authenticated connections. 113 o Single-sender security associations. Each network device sending 114 routing protocol packets acts as its own key server, essentially 115 converting an M-to-N communication model to M 1-to-N groups (where 116 M is the number of authorized members participating in the routing 117 protocol). A full mesh of authenticated connections is again 118 required, but the lack of an election protocol may result in a 119 simpler system. 121 The methods in the memo support both Multiple-sender security 122 associations and single-sender security associations. 124 The G-IKEv2 GKM protocol provides for a GM receiving security 125 associations from a GCKS in two IKEv2 exchanges: the IKE_SA_INIT 126 exchange [RFC5996] to setup the encrypted session, and the GSA_AUTH 127 exchange [I-D.yeung-g-ikev2] (similar in construction to the IKEv2 128 IKE_AUTH protocol) to authenticate, authorize, and distribute group 129 policy. 131 3. Exchanges 133 The exchange of private keying material between two network devices 134 using a dedicated key management protocol is a common requirement. 135 There is no need to define an entirely new protocol for routing 136 protocols having this requirement when existing mature protocol 137 exchanges and methods have been vetted. This memo extends the 138 G-IKEv2 protocol exchanges, state machine, and policy definitions. 140 The following two exchanges enable the group member to register to 141 the key server to get the policy, traffic selector and keys used to 142 communicate with others group member. 144 The IKE_SA_INIT exchange is a two-message exchange allows the group 145 member and key server devices to negotiate cryptographic algorithms, 146 exchange nonces, and do a Diffie-Hellman exchange [DH]. At the 147 conclusion of the IKE_SA_INIT, the group member (e.g., router) and 148 key server can exchange private messages. For the details of this 149 exchange, refer to IKE_SA_INIT in RFC 5996. 151 Group Member(Initiator) Key Server (Responder) 152 ----------------------- ---------------------- 153 HDR, SAi1, KEi, Ni --> 154 <-- HDR, SAr1, KEr, Nr, [CERTREQ,] 156 Figure 1: IKEv2 IKE_SA_INIT Exchange 158 Next, the group member and key server devices perform a GSA_AUTH, 159 which is substantially the same as the IKE_AUTH exchange defined in 160 RFC 5996, except that the SA, TSi, TSr payloads in IKE_AUTH are not 161 used. Policy and traffic selectors are pushed from the key server to 162 group member using new payloads GSA and KD. For the details of the 163 rest of the exchange please refer to Section 4 of 164 [I-D.yeung-g-ikev2]. Section Section 4 of this document includes 165 additional GSA definitions specifically for the purpose of protecting 166 routing protocol traffic. 168 Group Member (Initiator) Key Server (Responder) 169 ------------------------ ---------------------- 170 HDR, SK {IDi, [CERT,] [CERTREQ,] 171 [IDr,] AUTH, IDg} --> 172 <-- HDR, SK {IDr, [CERT,] AUTH, 173 GSA, KD} 175 Figure 2: G-IKEv2 GSA_AUTH Exchange 177 In the GSA_AUTH exchange, the group member sends the identification 178 of the group to which it wants to join or register. The key server 179 authenticates and authorizes the group member and pushes the policy, 180 traffic selector in GSA payload, and the key in the KD payload to the 181 group member. At the successful conclusion of the GSA_AUTH exchange, 182 the group member has policy and keying material to securely 183 communicate with others group members that also registered with the 184 key server. With this IKEv2 SA established between GM and KS, the GM 185 can request for policy and keys of an additional group using the 186 GSA_CLIENT_SERVER exchange. In the GSA_CLIENT_SERVER exchange, the 187 GM will send group ID that it wants to join, where the key server 188 response will include policy (GSA) and key material (KD). 190 Group Member (Initiator) Key Server (Responder) 191 ------------------------ ---------------------- 192 HDR, SK {IDg} --> 193 <-- HDR, SK { GSA, KD, [D ]} 195 Figure 3: G-IKEv2 GSA_CLIENT_SERVER Exchange 197 Once a GSA_AUTH has completed the group member and key server MAY 198 destroy the G-IKEv2 SA. However when the number of group members is 199 small, as is usually the case for routing protocol participants, it 200 is RECOMMENDED for them to maintain the G-IKEv2 association SA for 201 the key server to notify group members that they should re-register 202 in order to obtain new group policy. This notify exchange replaces a 203 separate rekey mechanism optimized for large group. 205 In some cases, a GCKS may need to change the group policy and/or 206 rekey before current keys expire. In cases where the G-IKEv2 rekey 207 protocol is not used the GCKS can send an INFORMATIONAL exchange with 208 a Notify payload directing the group member to re-register using a 209 REGISTER_REQUESTED status notify message (value TBD). This event 210 triggers a GSA_CLIENT_SERVER exchange, as described above. The 211 response to GSA_CLIENT_SERVER from the KS may include Delete payloads 212 instructing the group member to delete old SAs. Alternatively, the 213 GCKS policy may support the G-IKEv2 group maintenance channel and the 214 GCKS can distribute a GSA_REKEY exchange with new policy and keying 215 material (see Section 3.3 of [I-D.yeung-g-ikev2]). 217 4. Header and Payload Formats 219 The protocol defined in this memo uses IKEv2 and G-IKEv2 payload 220 definitions. However, new security policy definitions are described 221 to support security transforms and policy defined by routing protocol 222 documents. When a routing protocol indicates the use of ESP or AH, 223 existing G-IKEv2 SA Payload types suffice. 225 4.1. Group Security Association Payload 227 The Group Security Association (GSA) payload contains one or more 228 sets of policy that a router is willing to use to protect a routing 229 protocol. It is identical to the GSA payload described in Section 230 4.3 of [I-D.yeung-g-ikev2]. This memo makes no changes to this 231 payload. 233 4.1.1. GSA TEK Policy 235 One of the GSA types is the Traffic Encryption Key (TEK) policy. The 236 TEK describes the Traffic Encryption Policy defined by a supported 237 security protocol. Some routing protocol definitions (i.e., OSPFv3 238 [RFC4552], LMP [RFC4204], and PIM [RFC5796]) describe the use of ESP 239 and AH, which are supported by existing G-IKEv2 TEK policy 240 definitions. However, a number of routing protocol specific security 241 transforms exist and these require new TEK definitions. 243 Section 4.5 of [I-D.yeung-g-ikev2] defines the TEK payload as a 244 Protocol-ID followed by a TEK Protocol-Specific Payload, replicated 245 in Figure 4 for reference. 247 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 250 ! Type ! RESERVED ! Length ! 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 252 ! Protocol-ID ! TEK Protocol-Specific Payload ! 253 +-+-+-+-+-+-+-+-+ ~ 254 ~ ! 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 257 Figure 4: GSA TEK Payload 259 This memo extends the list of Protocol-ID values to include a set of 260 routing protocols that use group keys, shown in Figure 5. 262 Protocol-ID Value 263 ----------- ----- 264 RESERVED 0 265 GSA_PROTO_IPSEC_ESP 1 266 GSA_PROTO_IPSEC_AH 2 267 GSA_PROTO_OSPFv2 TBD1 268 GSA_PROTO_OSPFv3 TBD2 269 GSA_PROTO_IS_IS TBD3 270 GSA_PROTO_LDP_HELLO TBD4 271 GSA_PROTO_RSVP_TE TBD5 272 GSA_PROTO_BFD TBD6 274 Figure 5: Routing Protocol-ID Values 276 4.1.1.1. TEK Protocol-Specific Payload 278 The policy for each of the new Protocol-ID types defines in this memo 279 are sufficiently similar that a single Routing Protocol (RP) 280 protocol-specific payload that can be defined to convey the required 281 policy. Figure 6 defines the RP-TEK payload. 283 1 2 3 284 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 ! SPI Size | SPI (variable) ~ 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 288 | | 289 ~ ~ 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 ~ | 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 296 | | 297 ~ ~ 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 300 ! TEK Attributes ~ 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 303 Figure 6: RP TEK Protocol-Specific Payload 305 The RP-TEK fields are defined as follows: 307 o SPI Size (1 octet) - Equal to the size, in octets, of the SPI 308 defined by the corresponding protocol. 310 o SPI (variable) - The SPI defined by the GCKS representing this 311 TEK. In many cases, the SPI is referred to as a Key ID by routing 312 protocol specifications. 314 o Source & Destination Traffic Selectors - The traffic selectors 315 describe the source and the destination of the protecting traffic. 316 The format and values are defined in IKEv2 [RFC5996], section 317 3.13.1. 319 o Transforms - One or more substructures specifying the transform 320 information. The format is defined in IKEv2 [RFC5996], section 321 3.3.2. 323 o TEK Attributes - Contains TEK policy attributes associated with 324 the group. The following sections describe the possible 325 attributes. Any or all attributes may be optional, depending on 326 the group policy. [RFC5996], section 3.3.5. 328 Attributes 329 Attribute Type Value Attribute Format 330 ------------------------------------------------------------ 331 Life Duration 1 TLV 333 Specifies the time-to-live for the overall security association. 334 When the TEK expires, all keys downloaded under the association (AH 335 or ESP) must be re-rekeyed. The life duration attribute defines the 336 actual length of the component lifetime in seconds that can be 337 protected. If unspecified, there is no lifetime defined for the TEK. 339 Attribute Type Value Attribute Format 340 ------------------------------------------------------------ 341 Replay Protection 2 TV 343 Some routing protocols (e.g., RSVP-TE) define multiple replay 344 protection methods. Possible values of the Replay Protection 345 attribute are: 347 +-------+---------+ 348 |Number |Name | 349 +-------+---------+ 350 | 0 |NONE | 351 | 1 |COUNTER | 352 | 2 |TIME | 353 +-------+---------+ 355 Figure 7: RP Replay Method Attributes 357 4.1.1.2. Transforms 359 Policy for each of the routing protocols differs, but it possible to 360 summarize the policy into one or more transform types. The following 361 sections describe this policy. 363 4.1.1.2.1. Integrity Algorithms 365 Routing protocols include an integrity algorithm, often but not 366 always an HMAC construction. The following table represents current 367 integrity algorithms specified by each routing protocol considered in 368 the KARP charter. 370 +--------+-------------------------------------------------+----------+ 371 | RP | Integrity Algorithm Name(s) | RFC | 372 +--------+---------------------------------+---------------+----------+ 373 | OSPFv2 |Keyed-MD5 | RFC 2328 | 374 | |HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512| RFC 5709 | 375 | OSPFv3 |HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512| RFC 6506 | 376 | IS-IS |HMAC-MD5 | RFC 5304 | 377 | |HMAC-SHA-1,HMAC-SHA-224,HMAC-SHA-256,HMAC-SHA-384| RFC 5310 | 378 | |HMAC-SHA-512 | RFC 5310 | 379 | LDP |HMAC-SHA-1,HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512| (LDP I-D)| 380 | RSVP-TE|HMAC-MD5 | RFC 2747 | 381 | BFD |Keyed-MD5, Keyed-SHA1,Meticulous-Keyed-SHA1 | RFC 5880 | 382 | |HMAC-SHA-256,HMAC-SHA-384,HMAC-SHA-512 | (BFD I-D)| 383 +-------+----------------------------------+---------------+----------+ 384 (LDP I-D) [I-D.ietf-mpls-ldp-hello-crypto-auth] (BFD I-D) 385 [I-D.ietf-bfd-generic-crypto-auth] 387 Figure 8: Survey of RP Integrity Algorithms 389 None of these are currently represented as current IKEv2 INTEG 390 transform values, primarily because the output has not been defined 391 by the routing protocol transforms to be truncated. Since these 392 transforms are mutually exclusive to the transforms defined in the 393 Transform Type 3 - Integrity Algorithm Transform IDs IKEv2 IANA 394 table, and to reduce confusion between IPsec integrity transform 395 values and routing protocol transform values, this memo defines a new 396 transform to describe the routing protocol integrity transforms. 397 Transform IDs for the RP-INTEG Transform attributes types are shown 398 in Figure 9. Attributes 400 +-------+-----------------------+ 401 |Number | Name | 402 +-------+-----------------------+ 403 | 0 |RP_AUTH_HMAC_MD5 | 404 | 1 |RP_AUTH_HMAC_SHA1 | 405 | 2 |RP_AUTH_HMAC_SHA2_224 | 406 | 3 |RP_AUTH_HMAC_SHA2_256 | 407 | 4 |RP_AUTH_HMAC_SHA2_384 | 408 | 5 |RP_AUTH_HMAC_SHA2_512 | 409 | 6 |RP_AUTH_KEYED_MD5 | 410 | 7 |RP_AUTH_KEYED_SHA1 | 411 | 8 |RP_AUTH_MET_KEYED_SHA1 | 412 +-------+-----------------------+ 414 Figure 9: RP-INTEG Transform IDs 416 4.1.1.2.2. Extended Sequence Numbers 418 Some routing protocol transforms have introduced a 64-bit sequence 419 number. This can be signaled using the Extended Sequence Numbers 420 Transform. No changes are required to the Extended Sequence Numbers 421 Transform. 423 5. IANA Considerations 425 G-IKEv2 [I-D.yeung-g-ikev2] defines a new registry. This memo adds 426 the following definitions to this registry. (TBD) 428 A new IKEv2 Transform (RP_INTEG) is defined for declaring routing 429 protocol integrity algorithms. 431 6. Security Considerations 433 This document describes a use case of group key management using 434 G-IKEv2. The security considerations in [I-D.yeung-g-ikev2] directly 435 apply to this memo. 437 7. Acknowledgements 439 Sam Hartman and Dacheng Zhang previously published the MRKMP protocol 440 [I-D.hartman-karp-mrkmp], which includes many operations and protocol 441 elements in common with this memo. 443 8. References 445 8.1. Normative References 447 [I-D.yeung-g-ikev2] 448 Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key 449 Management using IKEv2", draft-yeung-g-ikev2-05 (work in 450 progress), October 2012. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 456 "Internet Key Exchange Protocol Version 2 (IKEv2)", 457 RFC 5996, September 2010. 459 8.2. Informative References 461 [DH] Diffie, W. and M. Hellman, "New Directions in 462 Cryptography", IEEE Transactions on Information 463 Theory, V.IT-22 n. 6, June 1977. 465 [I-D.hartman-karp-mrkmp] 466 Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router 467 Key Management Protocol (MaRK)", 468 draft-hartman-karp-mrkmp-05 (work in progress), 469 September 2012. 471 [I-D.ietf-bfd-generic-crypto-auth] 472 Bhatia, M., Manral, V., and D. Zhang, "BFD Generic 473 Cryptographic Authentication", 474 draft-ietf-bfd-generic-crypto-auth-03 (work in progress), 475 October 2012. 477 [I-D.ietf-mpls-ldp-hello-crypto-auth] 478 Zheng, L., Chen, M., and M. Bhatia, "LDP Hello 479 Cryptographic Authentication", 480 draft-ietf-mpls-ldp-hello-crypto-auth-00 (work in 481 progress), August 2012. 483 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 484 Architecture", RFC 3740, March 2004. 486 [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, 487 October 2005. 489 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 490 for OSPFv3", RFC 4552, June 2006. 492 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and 493 Confidentiality in Protocol Independent Multicast Sparse 494 Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. 496 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 497 of Interpretation", RFC 6407, October 2011. 499 Authors' Addresses 501 Paulina Tran 502 Cisco Systems 503 170 Tasman Drive 504 San Jose, California CA 505 USA 507 Phone: +1 (408) 526-8902 508 Fax: 509 Email: ptran@cisco.com 510 URI: 512 Brian Weis 513 Cisco Systems 514 170 Tasman Drive 515 San Jose, California CA 516 USA 518 Phone: +1 (408) 526-4796 519 Fax: 520 Email: bew@cisco.com 521 URI: