RE: Pls check: draft-rja-ripv2-auth-03.txt (Proposed Standard)

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

Searching for the string 'SNMP':

2) In the event that the last RIPv2 Security Association of an
    interface expires, it is unacceptable to revert to an
    unauthenticated condition, and not advisable to disrupt routing.
    Therefore, the router MUST send a "last RIPv2 Security Association
    expiration" notification to the network manager (e.g. via SYSLOG,
    SNMP, and/or other means) 

This looks OK 

 Also, the use of SNMP, even SNMPv3 with cryptographic
  authentication and cryptographic confidentiality enabled,
  to read or write RIPv2 Security Associations, or any component
  of the security association (for example the cryptographic key),
  is NOT RECOMMENDED.  This practice would create a potential for a
  cascading vulnerability, whereby a compromise in the SNMP security
  implementation would necessarily lead to a compromise not only
  of the local routing table (which could be accessed via SNMP)
  but also of all other routers that receive RIPv2 packets
  (directly or indirectly) from the compromised router.  Similarly,
  the use of other protocols (e.g. RADIUS, Diameter) to configure
  the security association is also NOT RECOMMENDED.  Instead, a key
  management protocol approved by the IETF should always be used
  for automated configuration of RIPv2 Security Associations.
  Recent IRTF and IETF work into multicast key manaagement appears
  promising in this regard.

This looks problematic to me. Beyond the judgment value about different
security methods that I would leave to the security experts to judge
about, defining SNMPv3 as NOT RECOMMENDED, even for read operations
seems extreme and not in synch with the area recommendations,
boilerplates, etc. 

  Also, the use of SNMP to configure which form of RIPv2
  authentication is in use is also NOT RECOMMENDED because of a
  similar cascading failure issue.  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.

This seems OK to me, but I would add a reference to the document that
needs to be modified. It would also be useful to mention what means of
configuration are acceptable. 

       Further, for similar reasons, any future revisions to the
  RIPv2 Management Information Base (MIB) SHOULD deprecate or omit any
  MIB objects that would permit reading or writing any RIPv2 Security
  Association, or any RIPv2 Security Association component (for example
  the cryptographic key).

Again, too extreme, when it comes to read operations.

      Also, it is RECOMMENDED that any future revisions to the RIPv2
  Management Information Base (MIB) consider adding MIB objects to hold
  information about any RIPv2 security events that might have occurred
  and MIB objects that could be used to read the set of security events
  that have been logged by the RIPv2 subsystem.  Each security event
  mentioned in this document is also RECOMMENDED for inclusion in future
  versions of RIPv2 SNMP MIB as an INFORM object.

The intent seems OK to me, the terminology is wrong. Instead of '
inclusion in future versions of RIPv2 SNMP MIB as an INFORM object' it
should say 'inclusion of appropriate notifications and MIB objects in
future versions of the RIPv2 MIB module'. 

Regards,

Dan



 
 

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of Wijnen, Bert (Bert)
> Sent: Thursday, December 01, 2005 8:18 PM
> To: Mreview (E-mail)
> Subject: Pls check: draft-rja-ripv2-auth-03.txt (Proposed Standard) 
> 
> This was on this weeks IESG agenda.
> It has some statements about SNMP that I doubt we can agree with.
> 
> The doc as some otehr discusses, I think we can add our 
> concern. I had not yet done so (yet) cause I only saw it in 
> the last minute. 
> 
> The risk is that otehr people n the security community will 
> pick up on this.
> 
> Bert
> 
>