idnits 2.17.1 draft-przygienda-bgp-md5-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Introduction' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 45: '... MUST This word or the adjective ...' RFC 2119 keyword, line 49: '... MUST NOT This phrase means that the ...' RFC 2119 keyword, line 52: '... SHOULD This word or the adjective ...' RFC 2119 keyword, line 68: '... MAY This word or the adjective ...' RFC 2119 keyword, line 140: '...on code with value 1 MAY be used by an...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (5 November 1997) is 9669 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AF97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Atk95' -- Possible downref: Non-RFC (?) normative reference: ref. 'BA97' ** Obsolete normative reference: RFC 2178 (ref. 'Moy97') (Obsoleted by RFC 2328) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'Riv92') ** Obsolete normative reference: RFC 1771 (ref. 'RL95') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'RL97' ** Downref: Normative reference to an Informational RFC: RFC 1810 (ref. 'Tou95') Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Przygienda 3 INTERNET DRAFT Bell Labs, Lucent Technologies 4 5 November 1997 6 BGP-4 MD5 Authentication 7 9 Status of This Memo 11 This document is an Internet Draft, and can be found as 12 draft-przygienda-bgp-md5-00.txt in any standard internet drafts 13 repository. Internet Drafts are working documents of the Internet 14 Engineering Task Force (IETF), its Areas, and its Working Groups. 15 Note that other groups may also distribute working documents as 16 Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material, or to cite them other than as a 22 ``working draft'' or ``work in progress.'' 24 Please check the I-D abstract listing contained in each Internet 25 Draft directory to learn the current status of this or any other 26 Internet Draft. 28 Abstract 30 This memo describes MD5 authentication scheme for BGP-4 routing 31 protocol analogous to the one proposed for SNMP Version 2 and RIP-2. 32 The mechanism provides greatly enhanced probability for a system 33 attacked to detect and ignore messages received. A sequence number 34 improves additionally the resistance against replay attacks. 36 1. Use of Imperatives 38 Throughout this document, the words that are used to define the 39 significance of particular requirements are capitalized. These words 40 are: 42 Internet Draft BGP-4 MD5 Authentication 5 November 43 1997 45 MUST This word or the adjective "REQUIRED" means that the item is 46 an 47 absolute requirement of this specification. 49 MUST NOT This phrase means that the item is an absolute prohibition of 50 this specification. 52 SHOULD This word or the adjective "RECOMMENDED" means that there may 53 exist valid reasons in particular circumstances to ignore 54 this 55 item, but the full implications should be understood and the 56 case 57 carefully weighed before choosing a different course. 59 SHOULD NOT This phrase means that there may exist valid reasons in 60 particular circumstances when the listed behavior is 61 acceptable 62 or even useful, but the full implications should be 63 understood 64 and the case carefully weighed before implementing any 65 behavior 66 described with this label. 68 MAY This word or the adjective "OPTIONAL" means that this item is 69 truly optional. One vendor may choose to include the item 70 because a particular marketplace requires it or because it 71 enhances the product, for example; another vendor may omit 72 the 73 same item. 75 2. Introduction 77 Recent developments in the Internet has introduced a stronger 78 need for improved authentication of routing information. RIP-2 79 and OSPF provide originally for unauthenticated service and 80 clear-text password authentication. Both are not sufficient to 81 withstand attacks currently widespread in the Internet. In case 82 of disabled authentication only misconfiguration can be detected 83 and clear password protections can be intercepted easily by an 84 hostile attacker. Recently, both OSPF [Moy97] and RIP-2 [BA97] 85 (1) 86 added additional mechanisms using well-known MD-5 signature 87 algorithms [Riv92] that is considered to be secure and fast 88 enough 89 for protection of routing protocol data units [Tou95]. BGP-4 90 [RL95, RL97] contains already authentication information marker 91 in the message header that can be used for a MD5 signature. Its 92 fixed length however prevents a more generic approach using keyed 94 ___________________________________________ 95 1. on which large parts of this document are based 97 Przygienda Expires 10 May 1998 99 algorithms generating more than 128 bits long signatures without 100 redefining its meaning. 102 This memo proposes an authentication algorithm, as was originally 103 proposed for SNMP Version 2, augmented by a sequence number. Keyed 104 MD5 is chosen here as the authentication algorithm for BGP-4. 105 This mechanism will provide a greatly enhanced probability that a 106 system being attacked will detect and ignore hostile information. 107 This property derives from the fact that only the output of an 108 authentication algorithm (e.g., Keyed MD5) rather than the secret 109 Authentication Key is transmited. This output is a one-way 110 function of a message and a secret Authentication Key. Again, the 111 Authentication Key is never sent over the network unencrypted, 112 therefore providing protection against passive attacks. 114 Protection against forgery or message modification is inherent to 115 this scheme. A sequence number is provided that makes a replay 116 attack much harder. It is possible to replay a message until 117 the sequence number changes. The mechanism does not provide 118 confidentiality. The messages are not encrypted. Such a protection 119 is provided in other protocols such as PNNIv2 [AF97] or IETF's recent 120 work [Atk95] and could be considered in the future. 122 Keyed MD5 is being used for OSPF cryptographic authentication 123 [Moy97], and is therefore present in routers already, as is some form 124 of password management. 126 3. Method Description 128 The method requires three issues to be addressed: 130 1. Changed packet formats, 132 2. Authentication procedures, and 134 3. Management controls. 136 3.1. OPEN Message Extensions 138 The OPEN message in BGP-4 specifies an optional parameter that 139 is specifically reserved for authentication purposes. For MD-5 140 purposes the authentication code with value 1 MAY be used by an 141 implementation. In case this authentication code is used, the OPEN 142 message contains the parameter and it MUST be formatted the following 143 way: 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+ 148 | Auth. Code | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | reserved 0 | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 The meaning of fields specified reads as: 155 1. The "Authentication Code" is Keyed Message Digest Algorithm, 156 indicated by the value 1. 158 All other octets are reserved and MUST be set to 0. 160 3.2. Message Header Format 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Auth. Type | 0x000000 | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Auth Data Len | 0x000000 | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Sequence Number | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Key ID | 0x000000 | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Length | Type | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 The message header format for the OPEN and subsequent UPDATE and 177 KEEPALIVE messages MUST have the marker formatted in the following 178 way: 180 1. The "Authentication Type" is Keyed Message Digest Algorithm, 181 indicated by the value 1. 183 2. An unsigned 8-bit field that contains the length in octets of the 184 trailing Authentication Data field. The presence of this field 185 permits other algorithms (e.g., Keyed SHA) to be substituted for 186 Keyed MD5 if desired. 188 3. An unsigned 32 bit sequence number. The sequence number MUST be 189 non-decreasing for all messages sent with the same Key ID. 191 4. An unsigned 8-bit field that contains the Key Identifier or 192 Key-ID. This identifies the key used to create the Authentication 193 Data for this BGP-4 message. In implementations supporting more 194 than one authentication algorithm, the Key-ID also indicates 195 the authentication algorithm in use for this message. A key is 196 associated with a session. 198 The trailer consists of the Authentication Data, which is the output 199 of the Keyed Message Digest Algorithm. When the Authentication 200 Algorithm is Keyed MD5, the output data is 16 bytes; during digest 201 calculation, this is effectively followed by a pad field and a length 202 field as defined by [Riv92]. 204 3.3. UPDATE and KEEPALIVE Message Trailer 206 The OPEN and all subsequent UPDATE and KEEPALIVE messages MUST be 207 trailed after length padded to 32-bit boundary with the indicated 208 length of authentication data. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | BGP Header 214 + ............... 215 | BGP Data 216 + ............... 217 | Padding to 32-bit boundary with reserved 0 octets 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 + 0xFFFF | 0x0001 | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 / Authentication Data (var. length; 16 bytes with Keyed MD5) / 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 In memory, the following trailer is appended by the MD5 algorithm and 225 treated as though it were part of the message. 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | sixteen octets of MD5 "secret" | 229 / / 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | zero or more pad bytes (defined by RFC 1321 when MD5 is used) | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | 64 bit message length MSW | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | 64 bit message length LSW | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 3.4. Message Generation 241 The BGP-4 packet is created as usual, except that the marker is set 242 to contain the authentication type (1), the authentication data 243 length, the sequence number and the Key Identifier. 245 The value used in the sequence number is arbitrary, but two 246 suggestions are the time of the message's creation or a simple 247 message counter. 249 The BGP-4 Authentication Key is selected by the sender based on the 250 session. Each key has a lifetime associated with it. No key is ever 251 used outside its lifetime. 253 1. The BGP-4 header's packet length field indicates the standard 254 BGP-4 portion of the packet. 256 2. The Authentication Data Offset, Key Identifier, and 257 Authentication Data size fields are filled in appropriately. 259 3. The BGP-4 Authentication Key, which is 16 bytes long when the 260 Keyed MD5 algorithm is used, is now appended to the data. For 261 all algorithms, the BGP-4 Authentication Key is never longer than 262 the output of the algorithm in use. 264 4. Trailing pad and length fields are added and the digest 265 calculated using the indicated algorithm. When Keyed MD5 is the 266 algorithm in use, these are calculated per [Riv92]. 268 5. The digest is written over the BGP-4 Authentication Key. When 269 MD5 is used, this digest will be 16 bytes long. 271 The trailing pad is not actually transmitted, as it is entirely 272 predictable from the message length and algorithm in use. 274 3.5. Message Reception 276 When the message is received, the process is reversed: 278 1. The digest is set aside, 280 2. The appropriate algorithm and key are determined from the value 281 of the Key Identifier field, 283 3. The BGP-4 Authentication Key is written into the appropriate 284 number (16 when Keyed MD5 is used) of bytes starting at the 285 offset indicated, 287 4. Appropriate padding is added as needed, and 289 5. A new digest calculated using the indicated algorithm. 291 If the calculated digest does not match the received digest, 292 the message is discarded and appropriate Authentication failed 293 NOTIFICATION sent. The connection is closed subsequently. 295 If the sequence number is not zero and smaller than the last received 296 one, the message is discarded and appropriate Authentication failed 297 NOTIFICATION sent. The connection is closed subsequently. 299 A router that has forgotten its current sequence number but remembers 300 its key and Key-ID MUST send its next packet with a sequence number 301 of zero. This leaves a small opening for a replay attack although 302 appropriate procedures can be provided by an implementation to report 303 excessive zero key usage. Router vendors are encouraged to provide 304 stable storage for keys, key lifetimes, Key-IDs, and the related 305 sequence numbers. 307 Acceptable messages are now truncated to a BGP-4 message itself and 308 treated normally. 310 4. New UPDATE Message Error Subcode 312 A new UPDATE Message Error subcode with the value 12 - Authentication 313 Failure MUST be understood by all implementations supporting keyed 314 authentication. 316 5. Management Procedures 318 5.1. Key Management Requirements 320 It is strongly desirable that a hypothetical security breach in 321 one Internet protocol not automatically compromise other Internet 322 protocols. The Authentication Key of this specification SHOULD NOT 323 be stored using protocols or algorithms that have known flaws. 325 Implementations MUST support the storage of more than one key at 326 the same time, although it is recognized that only one key will 327 normally be active on a session. They MUST associate a specific 328 lifetime (i.e., date/time first valid and date/time no longer valid) 329 and a key identifier with each key, and MUST support manual key 330 distribution (e.g., the privileged user manually typing in the 331 key, key lifetime, and key identifier on the router console). The 332 lifetime may be infinite. If more than one algorithm is supported, 333 then the implementation MUST require that the algorithm be specified 334 for each key at the time the other key information is entered. Keys 335 that are out of date MAY be deleted at will by the implementation 336 without requiring human intervention. Manual deletion of active keys 337 SHOULD also be supported. 339 It is likely that the IETF will define a standard key management 340 protocol. It is strongly desirable to use that key management 341 protocol to distribute BGP-4 Authentication Keys among communicating 342 BGP-4 implementations. Such a protocol would provide scalability 343 and significantly reduce the human administrative burden. The Key 344 ID can be used as a hook between BGP-4 and such a future protocol. 345 Key management protocols have a long history of subtle flaws that 346 are often discovered long after the protocol was first described 347 in public. To avoid having to change all BGP-4 implementations 348 should such a flaw be discovered, integrated key management protocol 349 techniques were deliberately omitted from this specification. 351 5.2. Key Management Procedures 353 As with all security methods using keys, it is necessary to change 354 the BGP-4 Authentication Key on a regular basis. To maintain routing 355 stability during such changes, implementations MUST be able to store 356 and use more than one BGP-4 Authentication Key for a given session at 357 the same time. 359 Each key will have its own Key Identifier, which is stored locally. 360 The combination of the Key Identifier and the session associated with 361 the message uniquely identifies the Authentication Algorithm and 362 BGP-4 Authentication Key in use. 364 The party creating the BGP-4 message will select a valid key from 365 the set of valid keys for that session. The receiver will use 366 the Key Identifier and session to determine which key to use for 367 authentication of the received message. More than one key may be 368 associated with a session at the same time. 370 Hence it is possible to have fairly smooth BGP-4 Authentication 371 Key rollovers without losing legitimate BGP-4 messages because the 372 stored key is incorrect and without requiring people to change all 373 the keys at once. To ensure a smooth rollover, each communicating 374 BGP-4 system must be updated with the new key several minutes before 375 the current key will expire and several minutes before the new key 376 lifetime begins. The new key should have a lifetime that starts 377 several minutes before the old key expires. This gives time for each 378 system to learn of the new BGP-4 Authentication Key before that key 379 will be used. It also ensures that the new key will begin being 380 used and the current key will go out of use before the current key's 381 lifetime expires. For the duration of the overlap in key lifetimes, 382 a system may receive messages using either key and authenticate the 383 message. The Key-ID in the received message is used to select the 384 appropriate key for authentication. 386 5.3. Pathological Cases 388 Two pathological cases exist which must be handled, which are 389 failures of the network manager. Both of these should be exceedingly 390 rare. 392 During key switchover, devices may exist which have not yet been 393 successfully configured with the new key. Therefore, routers SHOULD 394 implement (and would be well advised to implement) an algorithm 395 that detects the set of keys being used by its neighbors, and 396 transmits its messages using both the new and old keys until all of 397 the neighbors are using the new key or the lifetime of the old key 398 expires. Under normal circumstances, this elevated transmission rate 399 will exist for a single update interval. 401 In the event that the last key associated with an session expires, 402 it is unacceptable to revert to an unauthenticated condition, and 403 not advisable to disrupt routing. Therefore, the router should send 404 a "last authentication key expiration" notification to the network 405 manager and treat the key as having an infinite lifetime until the 406 lifetime is extended, the key is deleted by network management, or a 407 new key is configured. 409 6. Conformance Requirements 411 To conform to this specification, an implementation MUST support 412 all of its aspects. The Keyed MD5 authentication algorithm MUST 413 be implemented by all conforming implementations. MD5 is defined 414 in [Riv92]. A conforming implementation MAY also support other 415 authentication algorithms such as Keyed Secure Hash Algorithm (SHA). 416 Manual key distribution as described above MUST be supported by all 417 conforming implementations. All implementations MUST support the 418 smooth key rollover described under "Key Change Procedures." 420 The user documentation provided with the implementation MUST contain 421 clear instructions on how to ensure that smooth key rollover occurs. 423 Implementations SHOULD support a standard key management protocol 424 for secure distribution of BGP-4 Authentication Keys once such a key 425 management protocol is standardized by the IETF. 427 7. Security Consideration 429 This memo describes and specifies an authentication mechanism for the 430 BGP-4 routing protocol that is believed to be secure against active 431 and passive attacks. 433 Users need to understand that the quality of the security provided by 434 this mechanism depends completely on the strength of the implemented 435 authentication algorithms, the strength of the key being used, and 436 the correct implementation of the security mechanism in communicating 437 BGP-4 implementations. This mechanism also depends on the BGP-4 438 Authentication Key being kept confidential by all parties. If any of 439 these incorrect or insufficiently secure, then no real security will 440 be provided to the users of this mechanism. 442 Specifically with respect to the use of SNMP, compromise of 443 SNMP security has the necessary result that the various BGP-4 444 configuration parameters (e.g. routing table, BGP-4 Authentication 445 Key) manageable via SNMP could be compromised as well. Changing 446 Authentication Keys using non-encrypted SNMP is no more secure than 447 sending passwords in the clear. 449 Confidentiality is not provided by this mechanism. 451 8. Acknowledgements 453 Large parts of this memo are based or has been taken over from the 454 RIP-2 MD-5 authentication [BA97]. 456 References 458 [AF97] ATM-Forum. Private Network-Network Interface Specification 459 Version 2.0. ATM Forum, work in progress, 1997. 461 [Atk95] R. Atkinson. IP Encapsulating Security Payload. Internet 462 Engineering Task Force, August 1995. 464 [BA97] F. Baker and R. Atkinson. RIP-2 MD5 Authentication. 465 Internet Engineering Task Force, January 1997. 467 [Moy97] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force, 468 July 1997. 470 [Riv92] R. Rivest. The MD5 Message-Digest Algorithm, RFC 1321. 471 Internet Engineering Task Force, April 1992. 473 [RL95] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4), 474 RFC 1771. Internet Engineering Task Force, March 1995. 476 [RL97] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). 477 Internet Draft, 1997. 479 [Tou95] J. Touch. Report on MD5 Performance, RFC 1810. Internet 480 Engineering Task Force, June 1995. 482 Authors' Addresses 484 Tony Przygienda 485 Bell Labs, Lucent Technologies 486 101 Crawfords Corner Road 487 Holmdel, NJ 07733-3030 488 prz@dnrc.bell-labs.com