Subject: [Gen-art] Gen-ART Review of draft-rja-ripv2-auth-02.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 18 Oct 2005 15:14:37 -0500

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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art