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

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 24 Nov 2005 23:59:11 -0600

Just a quick note for the upcoming telechat agenda - I had reviewed version 
02 of this document and traded e-mail with Ran, and my comments are 
addressed in version 03.

I would say "ready for publication as Proposed Standard".

Thanks,

Spencer

> 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 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art