idnits 2.17.1 draft-ietf-ripv2-md5-02.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 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. ** There are 14 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 22 instances of lines with control characters in the document. ** 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 158: '... calculated. If it is not, it MUST be...' RFC 2119 keyword, line 175: '...started) SHOULD be used. Since the ke...' RFC 2119 keyword, line 233: '...is specification SHOULD NOT be stored ...' RFC 2119 keyword, line 236: '...Implementations MUST support the stora...' RFC 2119 keyword, line 238: '...interface. They MUST associate a spec...' (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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 379, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 382, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 385, 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: 20 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RIP-II Cryptographic Authentication 2 draft-ietf-ripv2-md5-02.txt | 4 Wed Oct 11 1995 | 6 Fred Baker 7 Cisco Systems 8 fred@cisco.com 10 Randall Atkinson 11 Naval Research Laboratory 12 atkinson@itd.nrl.navy.mil 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, and 18 its Working Groups. Note that other groups may also distribute working 19 documents as Internet Drafts. 21 Internet Drafts are valid for a maximum of six months and may be 22 updated, replaced, or obsoleted by other documents at any time. It is 23 inappropriate to use Internet Drafts as reference material or to cite 24 them other than as a "work in progress". 26 1. Introduction 28 Growth in the Internet has made us aware of the need for improved 29 authentication of routing information. RIP-II provides for 30 unauthenticated service (as in classical RIP), or password 31 authentication. Both are vulnerable to passive attacks currently 32 widespread in the Internet. Well-understood security issues exist in 33 routing protocols [4]. Clear text passwords, currently specified for 34 use with RIP-II, are no longer considered sufficient [5]. 36 If authentication is disabled, then only simple misconfigurations are 37 detected. Simple passwords transmitted in the clear will further 38 protect against the honest neighbor, but are useless in the general 39 case. By simply capturing information on the wire - straightforward 40 even in a remote environment - a hostile process can learn the password 41 and overcome the network. 43 We propose that RIP-II use an authentication algorithm, as in SNMP 44 Version 2, augmented by a sequence number. Keyed MD5 is proposed as | 45 the standard authentication algorithm for RIP-II, but the mechanism is 46 intended to be algorithm-independent. While this mechanism is not 47 unbreakable (no known mechanism is), it provides a greatly enhanced 48 probability that a system being attacked will detect and ignore 49 hostile messages. This is because we transmit the output of an 50 authentication algorithm (e.g., Keyed MD5) rather than the secret | 51 RIP-II Authentication Key. This output is a one-way function of a 52 message and a secret RIP-II Authentication Key. This RIP-II 53 Authentication Key is never sent over the network in the clear, thus 54 providing protection against the passive attacks now commonplace in 55 the Internet. 57 In this way, protection is afforded against forgery or message 58 modification. It is possible to replay a message until the sequence 59 number changes, but the sequence number makes replay in the long term 60 less of an issue. The mechanism does not afford confidentiality, since 61 messages stay in the clear; however, the mechanism is also exportable 62 from most countries, which test a confidentiality algorithm would fail. 64 Other relevant rationales for the approach are that Keyed MD5 is used | 65 in SNMP Version 2, and is therefore present in routers already, as is 66 some form of password management. A similar approach has recently been | 67 standardised for use in IP-layer authentication [7]. | 68 2. Implementation Approach 70 Implementation requires three issues to be addressed: 72 (1) A changed packet format, 74 (2) Authentication procedures, and 76 (3) Management controls. 78 2.1. RIP-II PDU Format 80 The basic RIP-II message format provides for an 8 byte header with an 81 array of 20 byte records as its data content. When Keyed MD5 is used, | 82 the same header and content are used, except that the 16 byte 83 "authentication key" field is reused to describe a "Keyed Message 84 Digest" trailer. This consists in five fields: 86 (1) The "Authentication Type" is Keyed Message Digest Algorithm, 87 indicated by the value 3 (1 and 2 indicate "IP Route" and 88 "Password", respectively). 90 (2) A 16 bit offset from the RIP-II header to the record containing the 91 cryptogtaphic digest. This value effectively points to the end of 92 routing data in the packet.. 94 (3) An unsigned 8-bit field that contains the Key Identifier or Key-ID. 95 This identifies the key used to create the Authentication Data for 96 this RIP-II message. In implementations supporting more than one | 97 authentication algorithm, the Key-ID also indicates the | 98 authentication algorithm in use for this message. A key is | 99 associated with an interface. | 101 (4) An unsigned 8-bit field that contains the length in octets of the 102 trailing Authentication Data field. The presence of this field 103 permits other algorithms (e.g., Keyed SHA) to be substituted for | 104 Keyed MD5 if desired. | 106 (5) An unsigned 32 bit non-decreasing sequence number. 108 The trailer consists of the Authentication Data, which is the output of 109 the Keyed Message Digest Algorithm. When the Authentication Algorithm 110 is Keyed MD5, the output data is 16 bytes; during digest calculation, | 111 this is effectively followed by a pad field and a length field as 112 defined by RFC 1321. The field is contained in a record reminiscient 113 of other entiries, to be kind to ancient RIP implementations, but the 114 actual length of the digest varies by algorithm. 116 2.2. Processing Algorithm 118 When the authentication type is "Keyed Message Digest", message 119 processing is changed in message creation and reception. 120 0 1 2 3 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Command (1) | Version (1) | Routing Domain (2) | 124 +---------------+---------------+-------------------------------+ 125 | 0xFFFF | AuType=Keyed Message Digest | 126 +-------------------------------+-------------------------------+ 127 | RIP-II Packet Length | Key ID | Auth Data Len | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Sequence Number (non-decreasing) | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | reserved must be zero | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | reserved must be zero | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | | 136 / (RIP-II Packet length-24) bytes Data / 137 | | 138 +---------------+---------------+-------------------------------+ 139 | 0xFFFF | 0x01 | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 / Authentication Data (var. length; 16 bytes with Keyed MD5) / | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 The MD5 algorithm logically appends the following information to the 145 packet during the MD5 calculation. 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | zero or more pad bytes (defined by RFC 1321 when MD5 is used) | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | 64 bit message length MSW | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | 64 bit message length LSW | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 2.2.1. Message Generation 156 The RIP-II Packet is created as usual, with these exceptions: 158 (1) The UDP checksum need not be calculated. If it is not, it MUST be 159 set to zero. 161 (2) The authentication type field indicates the Keyed Message Digest 162 Algorithm (3). | 164 (3) The authentication "password" field is reused to store a packet 165 offset to the Authentication Data, a Key Identifier, the 166 Authentication Data Length, and a non-decreasing sequence number. 168 The value used in the sequence number is arbitrary, but two suggestions 169 are the time of the message's creation or a simple message counter. 171 The RIP-II Authentication Key is selected by the sender based on the 172 outgoing interface. Each key has a lifetime associated with it. No key 173 is ever used outside its lifetime. If more than one key is currently 174 alive, then the youngest key (the key whose lifetime most recently 175 started) SHOULD be used. Since the key's algorithm is an attribute of 176 the key, stored in the sender and receiver along with it, the Key ID 177 effectively indicates which authentication algorithm is in use if the 178 implementation supports more than one authentication algorithm. 180 (1) The RIP-II header's packet length field indicates the standard 181 RIP-II portion of the packet. 183 (2) The Authentication Data Offset, Key Identifier, and Authentication 184 Data size fields are filled in appropriately. 186 (3) The RIP-II Authentication Key, which is 16 bytes long when the 187 Keyed MD5 algorithm is used, is now appended to the data. For all | 188 algorithms, the RIP-II Authentication Key is never longer than the 189 output of the algorithm in use. 191 (4) Trailing pad and length fields are added and the digest calculated 192 using the indicated algorithm. When Keyed MD5 is the algorithm in use, | 193 these are calculated per RFC 1321. 195 (5) The digest is written over the RIP-II Authentication Key. When Keyed | 196 MD5 is used, this digest will be 16 bytes long. 198 The trailing pad is not actually transmitted, as it is entirely 199 predictable from the message length and algorithm in use. 201 2.2.2. Message Reception 203 When the message is received, the process is reversed: 205 (1) The digest is set aside, 207 (2) The appropriate algorithm and key are determined from the value of 208 the Key Identifier field, 210 (3) The RIP-II Authentication Key is written into the appropriate 211 number (16 when Keyed MD5 is used) of bytes starting at the offset | 212 indicated, 214 (4) Appropriate padding is added as needed, and 216 (5) A new digest calculated using the indicated algorithm. 218 If the calculated digest does not match the received digest, the message 219 is discarded unprocessed. If the neighbor has been heard from recently 220 enough to have viable routes in the route table and the received 221 sequence number is less than the last one received, the message likewise 222 is discarded unprocessed. The received sequence number must, of course, 223 be stored by neighbor and zeroed whenever it determines that 224 connectivity to the neighbor has been lost. Acceptable messages are now 225 truncated to RIP-II message itself and treated normally. 227 3. Management Procedures 229 3.1. Key Management Requirements 231 It is strongly desirable that a hypothetical security breach in one 232 Internet protocol not automatically compromise other Internet protocols. 233 The Authentication Key of this specification SHOULD NOT be stored using | 234 protocols or algorithms that have known flaws. | 236 Implementations MUST support the storage of more than one key at the 237 same time, although it is recognized that only one key will normally be 238 active on an interface. They MUST associate a specific lifetime (i.e., 239 date/time first valid and date/time no longer valid) and a key | 240 identifier with each key, and MUST support manual key distribution 241 (e.g., the privileged user manually typing in the key, key lifetime, and 242 key identifier on the router console). The lifetime MAY be infinite. 243 If more than one algorithm is supported, then the implementation MUST 244 require that the algorithm be specified for each key at the time the 245 other key information is entered. Keys that are out of date MAY be 246 deleted at will by the implementation without requiring human 247 intervention. Manual deletion of active keys SHOULD also be supported. 249 Note that there are four "times" that are important with respect to a 250 key: 252 + The time the system starts accepting received packets signed with 253 the key (KeyStartReceive). 254 + The time the system starts signing packets with the key 255 (KeyStartSign). 256 + The time the system stops signing packets with the key, which is to 257 say, the time it starts signing with the next key (KeyStopSign). 258 + The time the system stops accepting received packets signed with the 259 key (KeyStopReceive). 261 The times SHOULD be in the order listed, which is to say that none of 262 these times occurs before the one mentioned before it. There needs to 263 be some distance between starts and between stops in order to get a 264 seamless transition. Each system sends with whichever key has the most 265 recent "start" time, and makes its first attempt at validation of 266 incoming traffic with the same key. If this validation fails and 267 another (older) key is also active, the system should attempt to 268 validate with any other active keys it may possess. 270 Note that the concept of a "key lifetime" does not require a hardware 271 time of day clock or the use of NTP, although one or the other is 272 advised; it merely requires that the earliest and latest times that the 273 key is valid must be programmable in a way the router understands. 275 It is likely that the IETF will define a standard key management 276 protocol. It is strongly desirable to use that key management protocol 277 to distribute RIP-II Authentication Keys among communicating RIP-II 278 implementations. Such a protocol would provide scalability and 279 significantly reduce the human administrative burden. The Key ID can be 280 used as a hook between RIP-II and such a future protocol. Key 281 management protocols have a long history of subtle flaws that are often 282 discovered long after the protocol was first described in public. To 283 avoid having to change all RIP-II implementations should such a flaw be 284 discovered, integrated key management protocol techniques were 285 deliberately omitted from this specification. 287 3.2. Key Management Procedures 289 As with all security methods using keys, it is necessary to change the 290 RIP-II Authentication Key on a regular basis. To maintain routing 291 stability during such changes, implementations are required to store and 292 support the use of more than one RIP-II Authentication Key on a given 293 interface at the same time. 295 Each key will have its own Key Identifier, which is stored locally. The 296 combination of the Key Identifier and the interface associated with the 297 message uniquely identifies the Authentication Algorithm and RIP-II 298 Authentication Key in use. 300 As noted above in Section 2.2.1, the party creating the RIP-II message 301 will select a valid key from the set of valid keys for that interface. 302 The receiver will use the Key Identifier and interface to determine 303 which key to use for authentication of the received message. More than 304 one key may be associated with an interface at the same time. 306 Hence it is possible to have fairly smooth RIP-II Authentication Key 307 rollovers without losing legitimate RIP-II messages because the stored 308 key is incorrect and without requiring people to change all the keys at 309 once. To ensure a smooth rollover, each communicating RIP-II system 310 must be updated with the new key several minutes before they current key 311 will expire and several minutes before the new key lifetime begins. The 312 new key should have a lifetime that starts several minutes before the 313 old key expires. This gives time for each system to learn of the new 314 RIP-II Authentication Key before that key will be used. It also ensures 315 that the new key will begin being used and the current key will go out 316 of use before the current key's lifetime expires. For the duration of 317 the overlap in key lifetimes, a system may receive messages using either 318 key and authenticate the message. 320 Key storage SHOULD persist across a system restart, warm or cold, to 321 avoid operational issues. Key lifetime is an obvious issue, to be 322 solved by the implementation. Obvious solutions include the use of the 323 Network Time Protocol, hardware time of day clocks, or waiting some 324 period of time before emitting the initial RIP REQUEST to determine what 325 key other systems are signing with. The matter is left for the 326 implementor. 328 3.3. Pathological Cases 330 Two pathological cases exist which must be handled, which are failures 331 of the network manager. Both of these should be exceedingly rare. 333 During key switchover, devices may exist which have not yet been 334 successfully configured with the new key. Therefore, routers MAY 335 implement (and would be well advised to implement) an algorithm that 336 detects the set of keys being used by its neighbors, and transmits its 337 messages using both the new and old keys until all of the neighbors are 338 using the new key or the lifetime of the old key expires. Under normal 339 circumstances, this elevated transmission rate will exist for a single 340 update interval. 342 In the event that the last key associated with an interface expires, it 343 is unacceptable to revert to an unauthenticated condition, and not 344 advisable to disrupt routing. Therefore, the router should send a "last 345 authentication key expiration" notification to the network manager and 346 treat the key as having an infinite lifetime until the lifetime is 347 extended, the key is deleted by network management, or a new key is 348 configured. 350 4. Conformance Requirements 352 To conform to this specification, an implementation MUST support all 353 of its aspects. The Keyed MD5 authentication algorithm MUST be | 354 implemented by all conforming implementations. MD5 is defined in | 355 RFC-1321. A conforming implementation MAY also support other | 356 authentication algorithms such as Keyed Secure Hash Algorithm (SHA). | 357 Manual key distribution as described above MUST be supported by all 358 conforming implementations. All implementations MUST support the 359 smooth key rollover described under "Key Change Procedures." 361 The user documentation provided with the implementation MUST contain 362 clear instructions on how to ensure that smooth key rollover occurs. 364 Implementations SHOULD support a standard key management protocol for 365 secure distribution of RIP-II Authentication Keys once such a key 366 management protocol is standardized by the IETF. 368 5. Acknowledgments 370 This work was done by the RIP-II Working Group, of which Gary Malkin is 371 the Chair. This suggestion was originally made by Christian Huitema on 372 behalf of the IAB. Jeff Honig (Cornell) and Dennis Ferguson (ANS) built 373 the first operational prototype, proving out the algorithms. The 374 authors gladly acknowledge significant inputs from each of these 375 sources. 377 6. References 379 [1] Malkin, Gary, "RIP Version 2 Carrying Additional Information", RFC 380 1388, January 1993. 382 [2] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 383 1992. 385 [3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1389, 386 Xylogics, Inc., Advanced Computer Communications, January 1993. 388 [4] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM 389 Computer Communications Review, Volume 19, Number 2, pp.32-48, 390 April 1989. 392 [5] N. Haller, R. Atkinson, "On Internet Authentication", Request for 393 Comments 1704, DDN Network Information Center, October 1994. 395 [6] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB 396 Workshop on Security in the Internet Architecture", Request for 397 Comments 1636, DDN Network Information Center, June 1994. 399 [7] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. | 400 | 401 [8] R. Atkinson, "IP Encapsulating Security Payload", RFC-1827, | 402 August 1995. | 404 7. Security Considerations 406 This entire memo describes and specifies an authentication mechanism for 407 the RIP-II routing protocol that is believed to be secure against active 408 and passive attacks. Passive attacks are clearly widespread in the 409 Internet at present. Protection against active attacks is also needed 410 even though such attacks are not currently widespread. 412 Users need to understand that the quality of the security provided by 413 this mechanism depends completely on the strength of the implemented 414 authentication algorithms, the strength of the key being used, and the 415 correct implementation of the security mechanism in all communicating 416 RIP-II implementations. This mechanism also depends on the RIP-II 417 Authentication Key being kept confidential by all parties. If any of 418 these incorrect or insufficiently secure, then no real security will be 419 provided to the users of this mechanism. 421 Specifically with respect to the use of SNMP, compromise of SNMP 422 security has the necessary result that the various RIP-II configuration 423 parameters (e.g. routing table, RIP-II Authentication Key) managable via 424 SNMP could be compromised as well. Changing Authentication Keys using 425 non-encrypted SNMP is no more secure than sending passwords in the 426 clear. 428 Confidentiality is not provided by this mechanism. Recent work in the 429 IETF provides a standard mechanism for IP-layer encryption. [8] 430 That mechanism might be used to provide confidentiality for RIP-II in 431 the future. Protection against traffic analysis is also not provided. 432 Mechanisms such as bulk link encryption might be used when protection 433 against traffic analysis is required. 435 The memo is written to address a security consideration in RIP-II 436 Version 2 that was raised during the IAB's recent security review [6]. 438 8. Chairman's Address 440 Gary Scott Malkin 441 Xylogics, Inc. 442 53 Third Avenue 443 Burlington, MA 01803 444 Phone: (617) 272-8140 445 EMail: gmalkin@Xylogics.COM 447 9. Author's Address 449 Fred Baker 450 Cisco Systems 451 519 Lado Drive 452 Santa Barbara, California 93111 453 Phone: (805) 681 0115 454 Email: fred@cisco.com 456 Randall Atkinson 457 Information Technology Division 458 Naval Research Laboratory 459 Washington, DC 20375-5337 | 460 Phone: (202) 404-8590 | 461 Email: atkinson@itd.nrl.navy.mil | 462 Table of Contents 464 1 Introduction .................................................... 2 465 2 Implementation Approach ......................................... 3 466 2.1 RIP-II PDU Format ............................................. 3 467 2.2 Processing Algorithm .......................................... 4 468 2.2.1 Message Generation .......................................... 5 469 2.2.2 Message Reception ........................................... 6 470 3 Management Procedures ........................................... 6 471 3.1 Key Management Requirements ................................... 6 472 3.2 Key Management Procedures ..................................... 8 473 3.3 Pathological Cases ............................................ 8 474 4 Conformance Requirements ........................................ 9 475 5 Acknowledgments ................................................. 9 476 6 References ...................................................... 10 477 7 Security Considerations ......................................... 10 478 8 Chairman's Address .............................................. 11 479 9 Author's Address ................................................ 11