idnits 2.17.1 draft-ietf-ripv2-md5-auth-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-27) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 148: '...e number. The sequence number MUST be...' RFC 2119 keyword, line 211: '...be calculated, but MAY be set to zero....' RFC 2119 keyword, line 275: '...st, the receiver SHOULD be ready to ac...' RFC 2119 keyword, line 281: '...e key and Key-ID MUST represents a tro...' RFC 2119 keyword, line 297: '...is specification SHOULD NOT be stored ...' (15 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 (January 1997) is 9964 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) == Unused Reference: '1' is defined on line 418, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 421, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 424, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1388 (ref. '1') (Obsoleted by RFC 1723) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '2') ** Obsolete normative reference: RFC 1389 (ref. '3') (Obsoleted by RFC 1724) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 1704 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1636 (ref. '6') ** Obsolete normative reference: RFC 1826 (ref. '7') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. '8') (Obsoleted by RFC 2406) Summary: 18 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRAFT RIP-II MD5 Authentication January 1997 4 RIP-II MD5 Authentication 5 draft-ietf-ripv2-md5-auth-00.txt 7 Wed Jan 8 23:54:15 PST 1997 9 Fred Baker 10 Cisco Systems 11 fred@cisco.com 13 Status of this Memo 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, and 17 its Working Groups. Note that other groups may also distribute working 18 documents as Internet Drafts. 20 Internet Drafts are valid for a maximum of six months and may be 21 updated, replaced, or obsoleted by other documents at any time. It is 22 inappropriate to use Internet Drafts as reference material or to cite 23 them other than as a "work in progress". 25 DRAFT RIP-II MD5 Authentication January 1997 27 1. Use of Imperatives 29 Throughout this document, the words that are used to define the 30 significance of particular requirements are capitalized. These words 31 are: 33 MUST 35 This word or the adjective "REQUIRED" means that the item is an 36 absolute requirement of this specification. 38 MUST NOT 40 This phrase means that the item is an absolute prohibition of this 41 specification. 43 SHOULD 45 This word or the adjective "RECOMMENDED" means that there may exist 46 valid reasons in particular circumstances to ignore this item, but 47 the full implications should be understood and the case carefully 48 weighed before choosing a different course. 50 SHOULD NOT 52 This phrase means that there may exist valid reasons in particular 53 circumstances when the listed behavior is acceptable or even 54 useful, but the full implications should be understood and the case 55 carefully weighed before implementing any behavior described with 56 this label. 58 MAY This word or the adjective "OPTIONAL" means that this item is 59 truly optional. One vendor may choose to include the item because 60 a particular marketplace requires it or because it enhances the 61 product, for example; another vendor may omit the same item. 63 DRAFT RIP-II MD5 Authentication January 1997 65 2. Introduction 67 Growth in the Internet has made us aware of the need for improved 68 authentication of routing information. RIP-II provides for 69 unauthenticated service (as in classical RIP), or password 70 authentication. Both are vulnerable to passive attacks currently 71 widespread in the Internet. Well-understood security issues exist in 72 routing protocols [4]. Clear text passwords, currently specified for 73 use with RIP-II, are no longer considered sufficient [5]. 75 If authentication is disabled, then only simple misconfigurations are 76 detected. Simple passwords transmitted in the clear will further 77 protect against the honest neighbor, but are useless in the general 78 case. By simply capturing information on the wire - straightforward 79 even in a remote environment - a hostile process can learn the password 80 and overcome the network. 82 We propose that RIP-II use an authentication algorithm, as was 83 originally proposed for SNMP Version 2, augmented by a sequence number. 84 Keyed MD5 is proposed as the standard authentication algorithm for RIP- 85 II, but the mechanism is intended to be algorithm-independent. While 86 this mechanism is not unbreakable (no known mechanism is), it provides a 87 greatly enhanced probability that a system being attacked will detect 88 and ignore hostile messages. This is because we transmit the output of 89 an authentication algorithm (e.g., Keyed MD5) rather than the secret 90 RIP-II Authentication Key. This output is a one-way function of a 91 message and a secret RIP-II Authentication Key. This RIP-II 92 Authentication Key is never sent over the network in the clear, thus 93 providing protection against the passive attacks now commonplace in the 94 Internet. 96 In this way, protection is afforded against forgery or message 97 modification. It is possible to replay a message until the sequence 98 number changes, but the sequence number makes replay in the long term 99 less of an issue. The mechanism does not afford confidentiality, since 100 messages stay in the clear; however, the mechanism is also exportable 101 from most countries, which test a privacy algorithm would fail. 103 Other relevant rationales for the approach are that Keyed MD5 is being 104 used for OSPF cryptographic authentication, and is therefore present in 105 routers already, as is some form of password management. A similar 106 approach has been standardized for use in IP-layer authentication. [7] 108 DRAFT RIP-II MD5 Authentication January 1997 110 3. Implementation Approach 112 Implementation requires three issues to be addressed: 114 (1) A changed packet format, 116 (2) Authentication procedures, and 118 (3) Management controls. 120 3.1. RIP-II PDU Format 122 The basic RIP-II message format provides for an 8 byte header with an 123 array of 20 byte records as its data content. When Keyed MD5 is used, 124 the same header and content are used, except that the 16 byte 125 "authentication key" field is reused to describe a "Keyed Message 126 Digest" trailer. This consists in five fields: 128 (1) The "Authentication Type" is Keyed Message Digest Algorithm, 129 indicated by the value 3 (1 and 2 indicate "IP Route" and 130 "Password", respectively). 132 (2) A 16 bit offset from the RIP-II header to the MD5 digest (if no 133 other trailer fields are ever defined, this value equals the RIP-II 134 Data Length). 136 (3) An unsigned 8-bit field that contains the Key Identifier or Key-ID. 137 This identifies the key used to create the Authentication Data for 138 this RIP-II message. In implementations supporting more than one 139 authentication algorithm, the Key-ID also indicates the 140 authentication algorithm in use for this message. A key is 141 associated with an interface. 143 (4) An unsigned 8-bit field that contains the length in octets of the 144 trailing Authentication Data field. The presence of this field 145 permits other algorithms (e.g., Keyed SHA) to be substituted for 146 Keyed MD5 if desired. 148 (5) An unsigned 32 bit sequence number. The sequence number MUST be 149 non-decreasing for all messages sent with the same Key ID. 151 The trailer consists of the Authentication Data, which is the output of 152 the Keyed Message Digest Algorithm. When the Authentication Algorithm 153 is Keyed MD5, the output data is 16 bytes; during digest calculation, 154 this is effectively followed by a pad field and a length field as 156 DRAFT RIP-II MD5 Authentication January 1997 158 defined by RFC 1321. 160 DRAFT RIP-II MD5 Authentication January 1997 162 3.2. Processing Algorithm 164 When the authentication type is "Keyed Message Digest", message 165 processing is changed in message creation and reception. 166 0 1 2 3 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Command (1) | Version (1) | Routing Domain (2) | 170 +---------------+---------------+-------------------------------+ 171 | 0xFFFF | AuType=Keyed Message Digest | 172 +-------------------------------+-------------------------------+ 173 | RIP-II Packet Length | Key ID | Auth Data Len | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Sequence Number (non-decreasing) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | reserved must be zero | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | reserved must be zero | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | | 182 / (RIP-II Packet Length - 24) bytes of Data / 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | 0xFFFF | 0x01 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 / Authentication Data (var. length; 16 bytes with Keyed MD5) / 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 In memory, the following trailer is appended by the MD5 algorithm and 191 treated as though it were part of the message. 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | sixteen octets of MD5 "secret" | 195 / / 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | zero or more pad bytes (defined by RFC 1321 when MD5 is used) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | 64 bit message length MSW | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | 64 bit message length LSW | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 DRAFT RIP-II MD5 Authentication January 1997 207 3.2.1. Message Generation 209 The RIP-II Packet is created as usual, with these exceptions: 211 (1) The UDP checksum need not be calculated, but MAY be set to zero. 213 (2) The authentication type field indicates the Keyed Message Digest 214 Algorithm (3). 216 (3) The authentication "password" field is reused to store a packet 217 offset to the Authentication Data, a Key Identifier, the 218 Authentication Data Length, and a non-decreasing sequence number. 220 The value used in the sequence number is arbitrary, but two suggestions 221 are the time of the message's creation or a simple message counter. 223 The RIP-II Authentication Key is selected by the sender based on the 224 outgoing interface. Each key has a lifetime associated with it. No key 225 is ever used outside its lifetime. Since the key's algorithm is related 226 to the key itself, stored in the sender and receiver along with it, the 227 Key ID effectively indicates which authentication algorithm is in use if 228 the implementation supports more than one authentication algorithm. 230 (1) The RIP-II header's packet length field indicates the standard 231 RIP-II portion of the packet. 233 (2) The Authentication Data Offset, Key Identifier, and Authentication 234 Data size fields are filled in appropriately. 236 (3) The RIP-II Authentication Key, which is 16 bytes long when the 237 Keyed MD5 algorithm is used, is now appended to the data. For all 238 algorithms, the RIP-II Authentication Key is never longer than the 239 output of the algorithm in use. 241 (4) Trailing pad and length fields are added and the digest calculated 242 using the indicated algorithm. When Keyed MD5 is the algorithm in 243 use, these are calculated per RFC 1321. 245 (5) The digest is written over the RIP-II Authentication Key. When MD5 246 is used, this digest will be 16 bytes long. 248 The trailing pad is not actually transmitted, as it is entirely 249 predictable from the message length and algorithm in use. 251 DRAFT RIP-II MD5 Authentication January 1997 253 3.2.2. Message Reception 255 When the message is received, the process is reversed: 257 (1) The digest is set aside, 259 (2) The appropriate algorithm and key are determined from the value of 260 the Key Identifier field, 262 (3) The RIP-II Authentication Key is written into the appropriate 263 number (16 when Keyed MD5 is used) of bytes starting at the offset 264 indicated, 266 (4) Appropriate padding is added as needed, and 268 (5) A new digest calculated using the indicated algorithm. 270 If the calculated digest does not match the received digest, the message 271 is discarded unprocessed. If the neighbor has been heard from recently 272 enough to have viable routes in the route table and the received 273 sequence number is less than the last one received, the message likewise 274 is discarded unprocessed. When connectivity to the neighbor has been 275 lost, the receiver SHOULD be ready to accept either: 276 - a message with a new key, or 277 - a message with the same or higher sequence number than the last 278 received sequence number. 280 A router that has forgotten its current sequence number but is forced to 281 use the same key and Key-ID MUST represents a troubling end case. If 282 the router has no stable storage through which it can preserve the 283 sequence number across a failure, re-use of the key represents a 284 potential security flaw. Router vendors are encouraged to provide 285 stable storage for keys, key lifetimes, Key-IDs, and the related 286 sequence numbers. 288 Acceptable messages are now truncated to RIP-II message itself and 289 treated normally. 291 4. Management Procedures 293 4.1. Key Management Requirements 295 It is strongly desirable that a hypothetical security breach in one 296 Internet protocol not automatically compromise other Internet protocols. 297 The Authentication Key of this specification SHOULD NOT be stored using 299 DRAFT RIP-II MD5 Authentication January 1997 301 protocols or algorithms that have known flaws. 303 Implementations MUST support the storage of more than one key at the 304 same time, although it is recognized that only one key will normally be 305 active on an interface. They MUST associate a specific lifetime (i.e., 306 date/time first valid and date/time no longer valid) and a key 307 identifier with each key, and MUST support manual key distribution 308 (e.g., the privileged user manually typing in the key, key lifetime, and 309 key identifier on the router console). The lifetime may be infinite. 310 If more than one algorithm is supported, then the implementation MUST 311 require that the algorithm be specified for each key at the time the 312 other key information is entered. Keys that are out of date MAY be 313 deleted at will by the implementation without requiring human 314 intervention. Manual deletion of active keys SHOULD also be supported. 316 It is likely that the IETF will define a standard key management 317 protocol. It is strongly desirable to use that key management protocol 318 to distribute RIP-II Authentication Keys among communicating RIP-II 319 implementations. Such a protocol would provide scalability and 320 significantly reduce the human administrative burden. The Key ID can be 321 used as a hook between RIP-II and such a future protocol. Key 322 management protocols have a long history of subtle flaws that are often 323 discovered long after the protocol was first described in public. To 324 avoid having to change all RIP-II implementations should such a flaw be 325 discovered, integrated key management protocol techniques were 326 deliberately omitted from this specification. 328 4.2. Key Management Procedures 330 As with all security methods using keys, it is necessary to change the 331 RIP-II Authentication Key on a regular basis. To maintain routing 332 stability during such changes, implementations MUST be able to store and 333 use more than one RIP-II Authentication Key on a given interface at the 334 same time. 336 Each key will have its own Key Identifier, which is stored locally. The 337 combination of the Key Identifier and the interface associated with the 338 message uniquely identifies the Authentication Algorithm and RIP-II 339 Authentication Key in use. 341 As noted above in Section 2.2.1, the party creating the RIP-II message 342 will select a valid key from the set of valid keys for that interface. 343 The receiver will use the Key Identifier and interface to determine 344 which key to use for authentication of the received message. More than 345 one key may be associated with an interface at the same time. 347 DRAFT RIP-II MD5 Authentication January 1997 349 Hence it is possible to have fairly smooth RIP-II Authentication Key 350 rollovers without losing legitimate RIP-II messages because the stored 351 key is incorrect and without requiring people to change all the keys at 352 once. To ensure a smooth rollover, each communicating RIP-II system 353 must be updated with the new key several minutes before the current key 354 will expire and several minutes before the new key lifetime begins. The 355 new key should have a lifetime that starts several minutes before the 356 old key expires. This gives time for each system to learn of the new 357 RIP-II Authentication Key before that key will be used. It also ensures 358 that the new key will begin being used and the current key will go out 359 of use before the current key's lifetime expires. For the duration of 360 the overlap in key lifetimes, a system may receive messages using either 361 key and authenticate the message. The Key-ID in the received message is 362 used to select the appropriate key for authentication. 364 4.3. Pathological Cases 366 Two pathological cases exist which must be handled, which are failures 367 of the network manager. Both of these should be exceedingly rare. 369 During key switchover, devices may exist which have not yet been 370 successfully configured with the new key. Therefore, routers SHOULD 371 implement (and would be well advised to implement) an algorithm that 372 detects the set of keys being used by its neighbors, and transmits its 373 messages using both the new and old keys until all of the neighbors are 374 using the new key or the lifetime of the old key expires. Under normal 375 circumstances, this elevated transmission rate will exist for a single 376 update interval. 378 In the event that the last key associated with an interface expires, it 379 is unacceptable to revert to an unauthenticated condition, and not 380 advisable to disrupt routing. Therefore, the router should send a "last 381 authentication key expiration" notification to the network manager and 382 treat the key as having an infinite lifetime until the lifetime is 383 extended, the key is deleted by network management, or a new key is 384 configured. 386 5. Conformance Requirements 388 To conform to this specification, an implementation MUST support all of 389 its aspects. The Keyed MD5 authentication algorithm MUST be implemented 390 by all conforming implementations. MD5 is defined in RFC-1321. A 391 conforming implementation MAY also support other authentication 392 algorithms such as Keyed Secure Hash Algorithm (SHA). Manual key 393 distribution as described above MUST be supported by all conforming 395 DRAFT RIP-II MD5 Authentication January 1997 397 implementations. All implementations MUST support the smooth key 398 rollover described under "Key Change Procedures." 400 The user documentation provided with the implementation MUST contain 401 clear instructions on how to ensure that smooth key rollover occurs. 403 Implementations SHOULD support a standard key management protocol for 404 secure distribution of RIP-II Authentication Keys once such a key 405 management protocol is standardized by the IETF. 407 6. Acknowledgments 409 This work was done by the RIP-II Working Group, of which Gary Malkin is 410 the Chair. This suggestion was originally made by Christian Huitema on 411 behalf of the IAB. Jeff Honig (Cornell) and Dennis Ferguson (ANS) built 412 the first operational prototype, proving out the algorithms. The 413 authors gladly acknowledge significant inputs from each of these 414 sources. 416 7. References 418 [1] Malkin, Gary, "RIP Version 2 Carrying Additional Information", RFC 419 1388, January 1993. 421 [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 422 1992. 424 [3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1389, 425 Xylogics, Inc., Advanced Computer Communications, January 1993. 427 [4] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM 428 Computer Communications Review, Volume 19, Number 2, pp.32-48, 429 April 1989. 431 [5] N. Haller, R. Atkinson, "Internet Authentication Guidelines", 432 RFC-1704, October 1994. 434 [6] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB 435 Workshop on Security in the Internet Architecture", RFC-1636, June 436 1994. 438 [7] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. 440 DRAFT RIP-II MD5 Authentication January 1997 442 [8] R. Atkinson, "IP Encapsulating Security Payload", RFC-1827, August 443 1995. 445 8. Security Considerations 447 This entire memo describes and specifies an authentication mechanism for 448 the RIP-II routing protocol that is believed to be secure against active 449 and passive attacks. Passive attacks are clearly widespread in the 450 Internet at present. Protection against active attacks is also needed 451 because active attacks are becoming more common. 453 Users need to understand that the quality of the security provided by 454 this mechanism depends completely on the strength of the implemented 455 authentication algorithms, the strength of the key being used, and the 456 correct implementation of the security mechanism in all communicating 457 RIP-II implementations. This mechanism also depends on the RIP-II 458 Authentication Key being kept confidential by all parties. If any of 459 these incorrect or insufficiently secure, then no real security will be 460 provided to the users of this mechanism. 462 Specifically with respect to the use of SNMP, compromise of SNMP 463 security has the necessary result that the various RIP-II configuration 464 parameters (e.g. routing table, RIP-II Authentication Key) manageable 465 via SNMP could be compromised as well. Changing Authentication Keys 466 using non-encrypted SNMP is no more secure than sending passwords in the 467 clear. 469 Confidentiality is not provided by this mechanism. Recent work in the 470 IETF provides a standard mechanism for IP-layer encryption. [8] That 471 mechanism might be used to provide confidentiality for RIP-II in the 472 future. Protection against traffic analysis is also not provided. 473 Mechanisms such as bulk link encryption might be used when protection 474 against traffic analysis is required. 476 The memo is written to address a security consideration in RIP-II 477 Version 2 that was raised during the IAB's recent security review [6]. 479 9. Chairman's Address 481 Gary Scott Malkin 482 Xylogics, Inc. 483 53 Third Avenue 484 Burlington, MA 01803 485 Phone: (617) 272-8140 487 DRAFT RIP-II MD5 Authentication January 1997 489 EMail: gmalkin@Xylogics.COM 491 10. Authors' Addresses 493 Fred Baker 494 Cisco Systems 495 519 Lado Drive 496 Santa Barbara, California 93111 497 Phone: (805) 681 0115 498 Email: fred@cisco.com 500 DRAFT RIP-II MD5 Authentication January 1997 502 Table of Contents 504 1 Use of Imperatives .............................................. 2 505 2 Introduction .................................................... 3 506 3 Implementation Approach ......................................... 4 507 3.1 RIP-II PDU Format ............................................. 4 508 3.2 Processing Algorithm .......................................... 6 509 3.2.1 Message Generation .......................................... 7 510 3.2.2 Message Reception ........................................... 8 511 4 Management Procedures ........................................... 8 512 4.1 Key Management Requirements ................................... 8 513 4.2 Key Management Procedures ..................................... 9 514 4.3 Pathological Cases ............................................ 10 515 5 Conformance Requirements ........................................ 10 516 6 Acknowledgments ................................................. 11 517 7 References ...................................................... 11 518 8 Security Considerations ......................................... 12 519 9 Chairman's Address .............................................. 12 520 10 Authors' Addresses ............................................. 13