RIPv2 Cryptographic Authentication
RFC 4822

Note: This ballot was opened for revision 06 and is now closed.

(Scott Hollenbeck) Discuss

Discuss (2005-11-23 for -)
The abstract says: "This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC-2082".  Is this document supposed to update or obsolete RFC 2082?  The text doesn't say for sure, and there's no reference.

Section 2.1 (and elsewhere): "8 byte header with an array of 20 byte records".  "octet" would be better than "byte" if 8-bit values are being described.

(Bert Wijnen) (was No Objection) Discuss

Discuss (2005-12-02 for -)
Main point of my DISCUSS (sorry for being late, but I did
verbally say so during IESG telechat on Dec 1st):

It's perfectly reasonable to say "use a key management protocol
to managage keys, not SNMPv3"  but it is less reasonable to 
demand that there be no way to read e.g. authentication type
via SNMPv3.

Thanks to MIB Doctors Dan Romascanu and Mike HEard for review
and help formulating the issue and details:

Section 5.2 starts off with:

  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 is problematic. Beyond the judgment value about different
security methods that we 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 OPS area recommendations,
boilerplates, etc. (Ran Atkinson was somehwat involved in that 
several years back).

Further it states:

  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, but we would add a reference to the document that
needs to be modified. Mike has looked at RFC 1724 and believes
that that is the document in question.  The offending object is
rip2IfConfAuthType.  It needs to have a new enum value added to
accomodate the new auth type specified in
draft-rja-ripv2-auth-03.txt.  In addition, the compliance statement
does not have a MIN-ACCESS for this read-create object;  at a
minimum, a new compliance statement should be written that allows
this object to be implemented as read-only.

rip2IfConfAuthKey is the object with the key, and it also lacks a
MIN-ACCESS clause.  Since this object always returns ''H when read,
it is reasonable for its MIN-ACCESS to be not-accessible.  (It would
also be OK to deprecate or obsolete the object, I think.)

It would also be useful to mention what means of configuration
are acceptable if SNMPv3 is not good enough. 

The next piece of text is:

       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'. (addresses the original 
comment that I had put in yesterday, dec 1st).
Comment (2005-12-01 for -)
No email
send info
Security Considerations, section 5.2, last para states

  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.

There is no "INFORM object". 
I think what is meant he is an object that has a MAX ACCESS that
at least allows acces level of "accessible-for-notify".

Further comments from AAA_doctor Jari Arkko 

>  o draft-rja-ripv2-auth-03.txt
>    RIPv2 Cryptographic Authentication (Proposed Standard) - 1 of 1 
>    Token: Russ Housley
>
I reviewed this spec. Overall, its good, I have no substantive
comments. A couple of editorial issues in case you have an
opportunity to revise the spec:

- Section 5.4 talks about "recent work in the IETF" and then
  points to references from -95. Maybe this part needs an
  update :-)

- Informational references include pointers to the original
  IPsec RFCs. I would suggest replacing these RFCs with
  the newest that are available.

- I would have expected to see SHA-256 et al be mentioned
  earlier on. They may be related to SHA-1 but FIPS-180-2
  considers them separate algorithms, and for pure ease
  of finding documents, I think the abstract should mention
  all the algorithms.

--Jari

(Alex Zinin) Discuss

Discuss (2005-12-01 for -)
This document is subject to provisions of 1264, even though it is not coming
from the RTG area. Can we have the implementation status for it?

> 2.1.  RIPv2 PDU Format

Please add an illustration showing lengths of the fields and their
arrangement in the RIPv2 message.

>       KEY-IDENTIFIER (KEY-ID)
>          The unsigned 8-bit KEY-ID value is used to identify the RIPv2
>       Security Association in use for this packet.  The receiver uses
>       the combination of the interface the packet was receive upon and
>       this value to uniquely identify the appropriate Security
>       Association.  The sender selects which RIPv2 Security Association
>       to use based on the outbound interface for this RIPv2 packet and
>       then places the correct KEY-ID value into that packet.

What if the sender has multiple active SAs on an interface.

>       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.

Please say that this is the outbound sequence number

>       START TIME
>            This is a local representation of the day and time that
>       this Security Association first becomes valid.
> 
>       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.

Are these activation times for sending or for inbound message validation,
or both?

>  When creating the RIPv2 Packet, the follow process is followed:
> 
>       (1)  The packet length field of the RIPv2 header indicates the
>            size of the main body of the RIPv2 packet.
> 
>       (2)  An appropriate RIPv2 Security Association is selected for
>            use with this packet.

How is it selected?

> The Authentication Data Offset,
>            Key Identifier, and Authentication Data size fields are
>            filled in appropriately.

> 2.3.2.  Message Reception
> 
> 
>   When the message is received, the process is reversed:
> 
>   (1)  The received Authentication Data is set aside and stored
>        for later use,
> 
>   (2)  The appropriate RIPv2 Security Association is determined
>        from the value of the Key Identifier field and the interface
>        the packet was received on.

Nowhere in the algorithm is the SA's start/stop times are checked.

>   (6) If the neighbor has been heard from recently enough to have viable
>       routes in the local routing table, and the received sequence number
>       is less than the last sequence number received, then the message
>       MUST be discarded unprocessed.  If the received sequence number
>       is less than the last sequence number received, that fact SHOULD
>       be logged as a security event.  This logged 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 an out of order RIPv2 Sequence
>       Number was received.
> 
>       When connectivity to the neighbor has been lost, the receiver
>       SHOULD be ready to accept either:
>            - a message with a sequence number of zero.
>            - a message with a higher sequence number than
>              the last received sequence number.

You need to say somewhere earlier in the text, that neighbor-specific state
needs to be maintained. Simple RIP implementations (without demand-circuit
extensions) do not normally maintain it, and get away with keeping soft
state for routes only.


>   NOTA BENE:
>        A router that has forgotten its current sequence number but
>   remembers its Security Association MUST send its first packet with a
>   sequence number of zero.  This leaves a small opening for a replay
>   attack.

Actually, it's not at all small. If I recorded RIP packets from the
router's previous incarnation, I can play them back all day long and
it doesn't matter if the rebooted router managed to send its update
first.

> 3.2.  Key Management Requirements
> 
...
>           An operator MAY configure the Security Association lifetime
>   to infinite, which means that the session is never rekeyed. 

Normally, we use 2119 language to specify implementation requirements. This
one is a prose statement about what an operator can do. "may" instead?

> 4.  Conformance Requirements
...
>   The user documentation provided with the implementation MUST contain
>   clear instructions on how to configure the implementation such that
>   smooth key rollover occurs successfully.

Checking vendor's documentation is not part of IETF's process. Please
remove.

>   Implementations SHOULD support a standard key management protocol
>   for secure distribution of RIPv2 Authentication Keys once such a
>   key management protocol is standardized by the IETF.

This makes conformance to this document dependant on future IETF
developments, without making it clear which protocol(s) will be required
for interoperability. Please remove.

> 5.  Security Considerations

>   This entire memo describes and specifies an authentication mechanism
>   for the RIPv2 routing protocol that is believed to be secure against
>   passive attacks.  Passive attacks are clearly widespread in the
>   Internet at present.[HA94]

It has never been clear to me what the author means by "passive attacks" in
routing. In this particular document, if he means this mechanism prevents
passive eavesdropping, then this is not true, as no confidentiality if
provided. If he means passively recorded packets cannot be used later to
mount an active attack, this isn't true either, as the sequence space isn't
guaranteed to be preserved across reboots. In any case, saying "is believed
to be secure against passive attacks" seems inappropriate.

> 5.2 Security Considerations for Network Management
...
> 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.
> 
>        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).

I'm skeptical about this part. An individual submission, telling what the
IETF should do in future...

(Russ Housley) Yes

Comment (2005-11-30 for -)
No email
send info
Comments from Jari Arkko:

I reviewed this spec. Overall, its good, I have no substantive
comments. A couple of editorial issues in case you have an
opportunity to revise the spec:

- Section 5.4 talks about "recent work in the IETF" and then
 points to references from -95. Maybe this part needs an
 update :-)

- Informational references include pointers to the original
 IPsec RFCs. I would suggest replacing these RFCs with
 the newest that are available.

- I would have expected to see SHA-256 et al be mentioned
 earlier on. They may be related to SHA-1 but FIPS-180-2
 considers them separate algorithms, and for pure ease
 of finding documents, I think the abstract should mention
 all the algorithms.

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2006-10-20)
No email
send info
When posting the -06 version, the Secretariat noticed that the
boilerplate is unconventional. Since it seems to contain the
right words in unusual places, I told them to post it anyway,
but in general I believe we should ask authors to follow the
guidelines carefully.

(Margaret Cullen) No Objection

(Lisa Dusseault) (was Discuss) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2006-08-02)
No email
send info
Moving the remaining items from my DISCUSS into a COMMENT, as the DISCUSS-worthy things have been addressed or have Magnus holding a DISCUSS on them.

Section 2.1: Do different keys have unique IDs? Can a key have multiple IDs?

Section 2.2: "This information doesn't need to be sent in each packet, so it is never sent in the clear-text over the wire." I don't follow this logic: "not every packet" implies "never cleartext"?

Section 2.2 and Section 2.3.2 step 6:Only when the sequence number decreases are packets not processed. Are RIPv2 messages idempotent? Otherwise I don't see how this protects against immediate replays.

Section 2.3.1: "UDP checksum SHOULD be calculated but MAY be set to zero." If all the crypto hashes are stronger, shouldn't the SHOULD and the MAY be reversed?

Nit: There is some confusion throughout the draft with regards to RFC2119 language.

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) (was Discuss, Yes) No Objection

Comment (2005-11-29)
No email
send info
I think the advice in section 3 and the strong recommendation that
keys be used for short periods of time is good advice.  However I
think it is hugely impractical to implement.  I think we should not
give advice that we believe cannot reasonably be implemented because
doing so lessens the effect of advice we do give.

(Cullen Jennings) No Objection

Comment (2006-04-06 for -)
No email
send info
I hope the many comments others have provided get incorporated into next version of draft. One trivial NIT, in section 2.5, I suspect "repeat B times" was meant to be 8.

(David Kessens) No Objection

(Allison Mankin) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund (was Discuss) No Objection

Comment (2006-04-24)
No email
send info
nd of Section 2.1:
  XXX (add packet diagram here)
  
  Missing figure. And I think the figure could really help. 
  
Section 3.1 is missing.