Draft: draft-rja-ripv2-auth-02.txt Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Tuesday 10/18/2005 3:15 PM CST LC Date: 10/18/2005 Summary: this document is almost ready for publication as Proposed Standard. There are no show-stoppers, but there are some places where the text was not clear to me, that the editors may wish to look at before publication. My notes follow. Thanks, Spencer Dawkins In section 2.2, I was somewhat lost reading this text - I'm not sure I understand what "abnormal operation" might be? In normal operation, a RIPv2 Security Association is never used outside its lifetime. Also in section 2.3, this text appears: SEQUENCE NUMBER This is an unsigned 32-bit number. For a given KEY-ID value, this number MUST NOT decrease. In normal operation, the operator should rekey the RIPv2 session prior to reaching the maximum value. The initial value used in the sequence number is arbitrary. There is text in section 2.3.2 NOTA BENE that discusses "a small opening for a reply attack" based on zero sequence numbers - could the 2.3 SEQUENCE NUMBER description point to the NOTA BENE? Also in section 2.3, this text appears: STOP TIME This is a local representation of the day and time that this Security Association becomes invalid (i.e. when it expires). It is permitted, but not recommended, for an operator to configure this to be "never expire". The "never expire" value is not recommended operational practice because it reduces security as compared with periodic rekeying. This seems slightly out-of-phase with Section 3.2, which says The configured Security Association lifetime MAY be infinite; however, periodic rekeying is strongly encouraged. What I THINK the text is saying is, 'An operator MAY configure this to be "never expire", but should perform periodical re-keying no matter what STOP TIME is configured as'. In section 2.3.1, this text appears: (3) Algorithm-dependent processing occurs now, either for the "Keyed-MD5" algorithm xor the "HMAC-SHA1" algorithm family. See the respective sub-sections (below) for details of this "xor" is both cute and accurate, but it sure looked like a typo to me... In section 2.3.2, this text appears: (5) If the calculated authentication data result does not match the received Authentication Data field, then: (a) the message MUST be discarded without being processed, and (b) a security event SHOULD be logged by the RIPv2 subsystem of the receiving system. That security event SHOULD indicate at least the day/time that the bad packet was received, the Source IP Address of the received RIPv2 packet, the Key-ID field value, and the fact that RIPv2 Authentication failed upon receipt of the packet. I'd like to see the routing interface listed as well, which seems closer to the last paragraph of section 5.1, which says: This log item MUST include at least note that the RIPv2 Authentication Key expired, the RIP routing protocol instance(s) affected, the routing interfaces affected, the Key-ID that is affected, and the current date/time. Also in section 2.3.2, this text appears: (6) If the neighbor has been heard from recently enough to have viable routes in the route table, I wasn't quite sure what "viable" meant (is this just "routes in the routing table"?) In section 2.5, I was really confused by this text. Because the RIPv2 packet is only hashed once, the overhead of double hashing is negligible. I THINK I know what you're saying, but I'm guessing - maybe something like "two hashing operations are performed, but since each RIPv2 packet is only processed once, the overhead of double hashing is negligible"? In Section 5.2, the following text appears: Any future revision of the RIPv2 Management Information Base (MIB) should deprecate or omit any MIB objects that would permit modification of the RIPv2 Authentication mode (e.g. none, cleartext password, RIPv2 Cryptographic Authentication) in use. and then, a paragraph or two later: Also, any future revisions to the RIPv2 Management Information Base (MIB) SHOULD deprecate or omit any MIB objects that would permit SNMP to be used to modify whether the RIPv2 instance uses cryptographic authentication, cleartext password authentication, or no authentication. It seemed to me that this was very close to being duplicated text (maybe not, but I wanted to ask). In Section 5.3, s/these incorrect /these are incorrect/ In the Informative References section, I wondered if these should be pointing to the 2401-ish series, since the 1820-ish RFCs are listed as obsoleted (which should current readers be looking at, to understand THIS document?) [Atk95a] Atkinson, R., "Security Architecture for the Internet Protocol", RFC-1825, August 1995. [Atk95b] Atkinson, R., "IP Authentication Header", RFC-1826, August 1995. [Atk95c] Atkinson, R., "IP Encapsulating Security Payload", RFC-1827, August 1995.