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

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 20 Oct 2006 21:39:33 -0500

And, as the latest note in the continuing saga, I had reviewed version 03, 
was happy, and am still happy with 06.

I do note that the discussion of KINK and MSEC in 5.6 seems to duplicate the 
longer discussion in 5.3, but what it says in each place seems reasonable 
enough - I'm just not sure why the second paragraph in 5.3 doesn't appear in 
5.6, probably replacing the text that's there now.

But this isn't what Gen-ART guys look for on their third trip through a 
specification. "Ready for publication as Proposed Standard".

Thanks,

Spencer

> 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 

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