Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF. We
advise the General Area Director (i.e. the IETF/IESG chair) by providing
more in depth reviews than he could do himself of documents that come up
for final decision in IESG telechat. I was selected as the GenART
member to review this document. Below is my review, which was written
specifically with an eye to the GenART process, but since I believe that
it will be useful to have these comments more widely distributed, others
outside the GenART group are being copied.
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
