draft-ietf-ripv2-md5-01.txt   draft-ietf-ripv2-md5-02.txt 
RIP-II Cryptographic Authentication | RIP-II Cryptographic Authentication
draft-ietf-ripv2-md5-01.txt | draft-ietf-ripv2-md5-02.txt |
Fri Mar 17 11:41:29 PST 1995 Wed Oct 11 1995 |
Fred Baker Fred Baker
Cisco Systems Cisco Systems
fred@cisco.com fred@cisco.com
Randall Atkinson Randall Atkinson
Information Technology Division
Naval Research Laboratory Naval Research Laboratory
atkinson@itd.nrl.navy.mil atkinson@itd.nrl.navy.mil
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts. documents as Internet Drafts.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
use with RIP-II, are no longer considered sufficient [5]. use with RIP-II, are no longer considered sufficient [5].
If authentication is disabled, then only simple misconfigurations are If authentication is disabled, then only simple misconfigurations are
detected. Simple passwords transmitted in the clear will further detected. Simple passwords transmitted in the clear will further
protect against the honest neighbor, but are useless in the general protect against the honest neighbor, but are useless in the general
case. By simply capturing information on the wire - straightforward case. By simply capturing information on the wire - straightforward
even in a remote environment - a hostile process can learn the password even in a remote environment - a hostile process can learn the password
and overcome the network. and overcome the network.
We propose that RIP-II use an authentication algorithm, as in SNMP We propose that RIP-II use an authentication algorithm, as in SNMP
Version 2, augmented by a sequence number. MD5 is proposed as the Version 2, augmented by a sequence number. Keyed MD5 is proposed as |
standard authentication algorithm for RIP-II, but the mechanism is the standard authentication algorithm for RIP-II, but the mechanism is
intended to be algorithm-independent. While this mechanism is not intended to be algorithm-independent. While this mechanism is not
unbreakable (no known mechanism is), it provides a greatly enhanced unbreakable (no known mechanism is), it provides a greatly enhanced
probability that a system being attacked will detect and ignore hostile probability that a system being attacked will detect and ignore
messages. This is because we transmit the output of an authentication hostile messages. This is because we transmit the output of an
algorithm (e.g., MD5) rather than the secret RIP-II Authentication Key. authentication algorithm (e.g., Keyed MD5) rather than the secret |
This output is a one-way function of a message and a secret RIP-II RIP-II Authentication Key. This output is a one-way function of a
Authentication Key. This RIP-II Authentication Key is never sent over message and a secret RIP-II Authentication Key. This RIP-II
the network in the clear, thus providing protection against the passive Authentication Key is never sent over the network in the clear, thus
attacks now commonplace in the Internet. providing protection against the passive attacks now commonplace in
the Internet.
In this way, protection is afforded against forgery or message In this way, protection is afforded against forgery or message
modification. It is possible to replay a message until the sequence modification. It is possible to replay a message until the sequence
number changes, but the sequence number makes replay in the long term number changes, but the sequence number makes replay in the long term
less of an issue. The mechanism does not afford confidentiality, since less of an issue. The mechanism does not afford confidentiality, since
messages stay in the clear; however, the mechanism is also exportable messages stay in the clear; however, the mechanism is also exportable
from most countries, which test a confidentiality algorithm would fail. from most countries, which test a confidentiality algorithm would fail.
Other relevant rationales for the approach are that MD5 is used in SNMP Other relevant rationales for the approach are that Keyed MD5 is used |
Version 2, and is therefore present in routers already, as is some form in SNMP Version 2, and is therefore present in routers already, as is
of password management. A similar approach has been proposed for some form of password management. A similar approach has recently been |
authentication in IP version 6 (IPv6). standardised for use in IP-layer authentication [7]. |
2. Implementation Approach 2. Implementation Approach
Implementation requires three issues to be addressed: Implementation requires three issues to be addressed:
(1) A changed packet format, (1) A changed packet format,
(2) Authentication procedures, and (2) Authentication procedures, and
(3) Management controls. (3) Management controls.
2.1. RIP-II PDU Format 2.1. RIP-II PDU Format
The basic RIP-II message format provides for an 8 byte header with an The basic RIP-II message format provides for an 8 byte header with an
array of 20 byte records as its data content. When MD5 is used, the array of 20 byte records as its data content. When Keyed MD5 is used, |
same header and content are used, except that the 16 byte the same header and content are used, except that the 16 byte
"authentication key" field is reused to describe a "Keyed Message "authentication key" field is reused to describe a "Keyed Message
Digest" trailer. This consists in five fields: Digest" trailer. This consists in five fields:
(1) The "Authentication Type" is Keyed Message Digest Algorithm, (1) The "Authentication Type" is Keyed Message Digest Algorithm,
indicated by the value 3 (1 and 2 indicate "IP Route" and indicated by the value 3 (1 and 2 indicate "IP Route" and
"Password", respectively). "Password", respectively).
(2) A 16 bit offset from the RIP-II header to the record containing the (2) A 16 bit offset from the RIP-II header to the record containing the
cryptogtaphic digest. This value effectively points to the end of cryptogtaphic digest. This value effectively points to the end of
routing data in the packet.. routing data in the packet..
(3) An unsigned 8-bit field that contains the Key Identifier or Key-ID. (3) An unsigned 8-bit field that contains the Key Identifier or Key-ID.
This identifies the key used to create the Authentication Data for This identifies the key used to create the Authentication Data for
this RIP-II message. A key is associated with an interface. this RIP-II message. In implementations supporting more than one |
authentication algorithm, the Key-ID also indicates the |
authentication algorithm in use for this message. A key is |
associated with an interface. |
(4) An unsigned 8-bit field that contains the length in octets of the (4) An unsigned 8-bit field that contains the length in octets of the
trailing Authentication Data field. The presence of this field trailing Authentication Data field. The presence of this field
permits other algorithms (e.g., SHA) to be substituted for MD5 if permits other algorithms (e.g., Keyed SHA) to be substituted for |
desired. Keyed MD5 if desired. |
(5) An unsigned 32 bit non-decreasing sequence number. (5) An unsigned 32 bit non-decreasing sequence number.
The trailer consists of the Authentication Data, which is the output of The trailer consists of the Authentication Data, which is the output of
the Keyed Message Digest Algorithm. When the Authentication Algorithm the Keyed Message Digest Algorithm. When the Authentication Algorithm
is MD5, the output data is 16 bytes; during digest calculation, this is is Keyed MD5, the output data is 16 bytes; during digest calculation, |
effectively followed by a pad field and a length field as defined by RFC this is effectively followed by a pad field and a length field as
1321. The field is contained in a record reminiscient of other defined by RFC 1321. The field is contained in a record reminiscient
entiries, to be kind to ancient RIP implementations, but the actual of other entiries, to be kind to ancient RIP implementations, but the
length of the digest varies by algorithm. actual length of the digest varies by algorithm.
2.2. Processing Algorithm 2.2. Processing Algorithm
When the authentication type is "Keyed Message Digest", message When the authentication type is "Keyed Message Digest", message
processing is changed in message creation and reception. processing is changed in message creation and reception.
0 1 2 3 3 0 1 2 3 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) | Version (1) | Routing Domain (2) | | Command (1) | Version (1) | Routing Domain (2) |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
skipping to change at page 4, line 30 skipping to change at page 4, line 30
| reserved must be zero | | reserved must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved must be zero | | reserved must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ (RIP-II Packet length-24) bytes Data / / (RIP-II Packet length-24) bytes Data /
| | | |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| 0xFFFF | 0x01 | | 0xFFFF | 0x01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Authentication Data (var. length; 16 bytes when MD5 is used) / / Authentication Data (var. length; 16 bytes with Keyed MD5) / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MD5 algorithm logically appends the following information to the The MD5 algorithm logically appends the following information to the
packet during the MD5 calculation. packet during the MD5 calculation.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad bytes (defined by RFC 1321 when MD5 is used) | | zero or more pad bytes (defined by RFC 1321 when MD5 is used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length MSW | | 64 bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 13 skipping to change at page 5, line 13
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.1. Message Generation 2.2.1. Message Generation
The RIP-II Packet is created as usual, with these exceptions: The RIP-II Packet is created as usual, with these exceptions:
(1) The UDP checksum need not be calculated. If it is not, it MUST be (1) The UDP checksum need not be calculated. If it is not, it MUST be
set to zero. set to zero.
(2) The authentication type field indicates the Keyed Message Digest (2) The authentication type field indicates the Keyed Message Digest
Algorithm (2). Algorithm (3). |
(3) The authentication "password" field is reused to store a packet (3) The authentication "password" field is reused to store a packet
offset to the Authentication Data, a Key Identifier, the offset to the Authentication Data, a Key Identifier, the
Authentication Data Length, and a non-decreasing sequence number. Authentication Data Length, and a non-decreasing sequence number.
The value used in the sequence number is arbitrary, but two suggestions The value used in the sequence number is arbitrary, but two suggestions
are the time of the message's creation or a simple message counter. are the time of the message's creation or a simple message counter.
The RIP-II Authentication Key is selected by the sender based on the The RIP-II Authentication Key is selected by the sender based on the
outgoing interface. Each key has a lifetime associated with it. No key outgoing interface. Each key has a lifetime associated with it. No key
skipping to change at page 5, line 37 skipping to change at page 5, line 37
the key, stored in the sender and receiver along with it, the Key ID the key, stored in the sender and receiver along with it, the Key ID
effectively indicates which authentication algorithm is in use if the effectively indicates which authentication algorithm is in use if the
implementation supports more than one authentication algorithm. implementation supports more than one authentication algorithm.
(1) The RIP-II header's packet length field indicates the standard (1) The RIP-II header's packet length field indicates the standard
RIP-II portion of the packet. RIP-II portion of the packet.
(2) The Authentication Data Offset, Key Identifier, and Authentication (2) The Authentication Data Offset, Key Identifier, and Authentication
Data size fields are filled in appropriately. Data size fields are filled in appropriately.
(3) The RIP-II Authentication Key, which is 16 bytes long when the MD5 (3) The RIP-II Authentication Key, which is 16 bytes long when the
algorithm is used, is now appended to the data. For all Keyed MD5 algorithm is used, is now appended to the data. For all |
algorithms, the RIP-II Authentication Key is never longer than the algorithms, the RIP-II Authentication Key is never longer than the
output of the algorithm in use. output of the algorithm in use.
(4) Trailing pad and length fields are added and the digest calculated (4) Trailing pad and length fields are added and the digest calculated
using the indicated algorithm. When MD5 is the algorithm in use, using the indicated algorithm. When Keyed MD5 is the algorithm in use, |
these are calculated per RFC 1321. these are calculated per RFC 1321.
(5) The digest is written over the RIP-II Authentication Key. When MD5 (5) The digest is written over the RIP-II Authentication Key. When Keyed |
is used, this digest will be 16 bytes long. MD5 is used, this digest will be 16 bytes long.
The trailing pad is not actually transmitted, as it is entirely The trailing pad is not actually transmitted, as it is entirely
predictable from the message length and algorithm in use. predictable from the message length and algorithm in use.
2.2.2. Message Reception 2.2.2. Message Reception
When the message is received, the process is reversed: When the message is received, the process is reversed:
(1) The digest is set aside, (1) The digest is set aside,
(2) The appropriate algorithm and key are determined from the value of (2) The appropriate algorithm and key are determined from the value of
the Key Identifier field, the Key Identifier field,
(3) The RIP-II Authentication Key is written into the appropriate (3) The RIP-II Authentication Key is written into the appropriate
number (16 when MD5 is used) of bytes starting at the offset number (16 when Keyed MD5 is used) of bytes starting at the offset |
indicated, indicated,
(4) Appropriate padding is added as needed, and (4) Appropriate padding is added as needed, and
(5) A new digest calculated using the indicated algorithm. (5) A new digest calculated using the indicated algorithm.
If the calculated digest does not match the received digest, the message If the calculated digest does not match the received digest, the message
is discarded unprocessed. If the neighbor has been heard from recently is discarded unprocessed. If the neighbor has been heard from recently
enough to have viable routes in the route table and the received enough to have viable routes in the route table and the received
sequence number is less than the last one received, the message likewise sequence number is less than the last one received, the message likewise
skipping to change at page 6, line 40 skipping to change at page 6, line 40
be stored by neighbor and zeroed whenever it determines that be stored by neighbor and zeroed whenever it determines that
connectivity to the neighbor has been lost. Acceptable messages are now connectivity to the neighbor has been lost. Acceptable messages are now
truncated to RIP-II message itself and treated normally. truncated to RIP-II message itself and treated normally.
3. Management Procedures 3. Management Procedures
3.1. Key Management Requirements 3.1. Key Management Requirements
It is strongly desirable that a hypothetical security breach in one It is strongly desirable that a hypothetical security breach in one
Internet protocol not automatically compromise other Internet protocols. Internet protocol not automatically compromise other Internet protocols.
The Authentication Key of this specification SHOULD NOT be stored using The Authentication Key of this specification SHOULD NOT be stored using |
protocols or algorithms that have known flaws or fail to afford perfect protocols or algorithms that have known flaws. |
forward secrecy.
Implementations MUST support the storage of more than one key at the Implementations MUST support the storage of more than one key at the
same time, although it is recognized that only one key will normally be same time, although it is recognized that only one key will normally be
active on an interface. They MUST associate a specific lifetime (i.e., active on an interface. They MUST associate a specific lifetime (i.e.,
data/time first valid and data/time no longer valid) and a key date/time first valid and date/time no longer valid) and a key |
identifier with each key, and MUST support manual key distribution identifier with each key, and MUST support manual key distribution
(e.g., the privileged user manually typing in the key, key lifetime, and (e.g., the privileged user manually typing in the key, key lifetime, and
key identifier on the router console). The lifetime may be infinite. key identifier on the router console). The lifetime MAY be infinite.
If more than one algorithm is supported, then the implementation MUST If more than one algorithm is supported, then the implementation MUST
require that the algorithm be specified for each key at the time the require that the algorithm be specified for each key at the time the
other key information is entered. Keys that are out of date MAY be other key information is entered. Keys that are out of date MAY be
deleted at will by the implementation without requiring human deleted at will by the implementation without requiring human
intervention. Manual deletion of active keys SHOULD also be supported. intervention. Manual deletion of active keys SHOULD also be supported.
Note that there are four "times" that are important with respect to a Note that there are four "times" that are important with respect to a
key: key:
+ The time the system starts accepting received packets signed with | + The time the system starts accepting received packets signed with
the key (KeyStartReceive). the key (KeyStartReceive).
+ The time the system starts signing packets with the key | + The time the system starts signing packets with the key
(KeyStartSign). (KeyStartSign).
+ The time the system stops signing packets with the key, which is to | + The time the system stops signing packets with the key, which is to
say, the time it starts signing with the next key (KeyStopSign). say, the time it starts signing with the next key (KeyStopSign).
+ The time the system stops accepting received packets signed with the | + The time the system stops accepting received packets signed with the
key (KeyStopReceive). key (KeyStopReceive).
The times SHOULD be in the order listed, which is to say that none of The times SHOULD be in the order listed, which is to say that none of
these times occurs before the one mentioned before it. There needs to these times occurs before the one mentioned before it. There needs to
be some distance between starts and between stops in order to get a be some distance between starts and between stops in order to get a
seamless transition. Each system sends with whichever key has the most seamless transition. Each system sends with whichever key has the most
recent "start" time, and makes its first attempt at validation of recent "start" time, and makes its first attempt at validation of
incoming traffic with the same key. If this validation fails and | incoming traffic with the same key. If this validation fails and
another (older) key is also active, the system should attempt to | another (older) key is also active, the system should attempt to
validate with any other active keys it may possess. validate with any other active keys it may possess.
Note that the concept of a "key lifetime" does not require a hardware Note that the concept of a "key lifetime" does not require a hardware
time of day clock or the use of NTP, although one or the other is time of day clock or the use of NTP, although one or the other is
advised; it merely requires that the earliest and latest times that the advised; it merely requires that the earliest and latest times that the
key is valid must be programmable in a way the router understands. key is valid must be programmable in a way the router understands.
It is likely that the IETF will define a standard key management It is likely that the IETF will define a standard key management
protocol. It is strongly desirable to use that key management protocol protocol. It is strongly desirable to use that key management protocol
to distribute RIP-II Authentication Keys among communicating RIP-II to distribute RIP-II Authentication Keys among communicating RIP-II
skipping to change at page 9, line 24 skipping to change at page 9, line 24
In the event that the last key associated with an interface expires, it In the event that the last key associated with an interface expires, it
is unacceptable to revert to an unauthenticated condition, and not is unacceptable to revert to an unauthenticated condition, and not
advisable to disrupt routing. Therefore, the router should send a "last advisable to disrupt routing. Therefore, the router should send a "last
authentication key expiration" notification to the network manager and authentication key expiration" notification to the network manager and
treat the key as having an infinite lifetime until the lifetime is treat the key as having an infinite lifetime until the lifetime is
extended, the key is deleted by network management, or a new key is extended, the key is deleted by network management, or a new key is
configured. configured.
4. Conformance Requirements 4. Conformance Requirements
To conform to this specification, an implementation MUST support all of To conform to this specification, an implementation MUST support all
its aspects. The MD5 authentication algorithm defined in RFC-1321 MUST of its aspects. The Keyed MD5 authentication algorithm MUST be |
be implemented by all conforming implementations. A conforming implemented by all conforming implementations. MD5 is defined in |
implementation MAY also support other authentication algorithms such as RFC-1321. A conforming implementation MAY also support other |
NIST's Secure Hash Algorithm (SHA). Manual key distribution as authentication algorithms such as Keyed Secure Hash Algorithm (SHA). |
described above MUST be supported by all conforming implementations. Manual key distribution as described above MUST be supported by all
All implementations MUST support the smooth key rollover described under conforming implementations. All implementations MUST support the
"Key Change Procedures." smooth key rollover described under "Key Change Procedures."
The user documentation provided with the implementation MUST contain The user documentation provided with the implementation MUST contain
clear instructions on how to ensure that smooth key rollover occurs. clear instructions on how to ensure that smooth key rollover occurs.
Implementations SHOULD support a standard key management protocol for Implementations SHOULD support a standard key management protocol for
secure distribution of RIP-II Authentication Keys once such a key secure distribution of RIP-II Authentication Keys once such a key
management protocol is standardized by the IETF. management protocol is standardized by the IETF.
5. Acknowledgments 5. Acknowledgments
skipping to change at page 10, line 27 skipping to change at page 10, line 27
Computer Communications Review, Volume 19, Number 2, pp.32-48, Computer Communications Review, Volume 19, Number 2, pp.32-48,
April 1989. April 1989.
[5] N. Haller, R. Atkinson, "On Internet Authentication", Request for [5] N. Haller, R. Atkinson, "On Internet Authentication", Request for
Comments 1704, DDN Network Information Center, October 1994. Comments 1704, DDN Network Information Center, October 1994.
[6] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB [6] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB
Workshop on Security in the Internet Architecture", Request for Workshop on Security in the Internet Architecture", Request for
Comments 1636, DDN Network Information Center, June 1994. Comments 1636, DDN Network Information Center, June 1994.
[7] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. |
|
[8] R. Atkinson, "IP Encapsulating Security Payload", RFC-1827, |
August 1995. |
7. Security Considerations 7. Security Considerations
This entire memo describes and specifies an authentication mechanism for This entire memo describes and specifies an authentication mechanism for
the RIP-II routing protocol that is believed to be secure against active the RIP-II routing protocol that is believed to be secure against active
and passive attacks. Passive attacks are clearly widespread in the and passive attacks. Passive attacks are clearly widespread in the
Internet at present. Protection against active attacks is also needed Internet at present. Protection against active attacks is also needed
even though such attacks are not currently widespread. even though such attacks are not currently widespread.
Users need to understand that the quality of the security provided by Users need to understand that the quality of the security provided by
this mechanism depends completely on the strength of the implemented this mechanism depends completely on the strength of the implemented
skipping to change at page 11, line 7 skipping to change at page 11, line 7
provided to the users of this mechanism. provided to the users of this mechanism.
Specifically with respect to the use of SNMP, compromise of SNMP Specifically with respect to the use of SNMP, compromise of SNMP
security has the necessary result that the various RIP-II configuration security has the necessary result that the various RIP-II configuration
parameters (e.g. routing table, RIP-II Authentication Key) managable via parameters (e.g. routing table, RIP-II Authentication Key) managable via
SNMP could be compromised as well. Changing Authentication Keys using SNMP could be compromised as well. Changing Authentication Keys using
non-encrypted SNMP is no more secure than sending passwords in the non-encrypted SNMP is no more secure than sending passwords in the
clear. clear.
Confidentiality is not provided by this mechanism. Work is underway Confidentiality is not provided by this mechanism. Recent work in the
within the IETF to specify a standard mechanism for IP-layer encryption. IETF provides a standard mechanism for IP-layer encryption. [8]
That mechanism might be used to provide confidentiality for RIP-II in That mechanism might be used to provide confidentiality for RIP-II in
the future. Protection against traffic analysis is also not provided. the future. Protection against traffic analysis is also not provided.
Mechanisms such as bulk link encryption might be used when protection Mechanisms such as bulk link encryption might be used when protection
against traffic analysis is required. against traffic analysis is required.
The memo is written to address a security consideration in RIP-II The memo is written to address a security consideration in RIP-II
Version 2 that was raised during the IAB's recent security review [6]. Version 2 that was raised during the IAB's recent security review [6].
8. Chairman's Address 8. Chairman's Address
skipping to change at page 11, line 38 skipping to change at page 11, line 38
Fred Baker Fred Baker
Cisco Systems Cisco Systems
519 Lado Drive 519 Lado Drive
Santa Barbara, California 93111 Santa Barbara, California 93111
Phone: (805) 681 0115 Phone: (805) 681 0115
Email: fred@cisco.com Email: fred@cisco.com
Randall Atkinson Randall Atkinson
Information Technology Division Information Technology Division
Naval Research Laboratory Naval Research Laboratory
Washington, DC 20375-5320 Washington, DC 20375-5337 |
Voice: (DSN) 354-8590 Phone: (202) 404-8590 |
Fax: (DSN) 354-7942 Email: atkinson@itd.nrl.navy.mil |
Email: atkinson@itd.nrl.navy.mil
Table of Contents Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
2 Implementation Approach ......................................... 3 2 Implementation Approach ......................................... 3
2.1 RIP-II PDU Format ............................................. 3 2.1 RIP-II PDU Format ............................................. 3
2.2 Processing Algorithm .......................................... 4 2.2 Processing Algorithm .......................................... 4
2.2.1 Message Generation .......................................... 5 2.2.1 Message Generation .......................................... 5
2.2.2 Message Reception ........................................... 6 2.2.2 Message Reception ........................................... 6
3 Management Procedures ........................................... 6 3 Management Procedures ........................................... 6
 End of changes. 28 change blocks. 
60 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/