Security hole in RIP-2

Gary Scott Malkin <gmalkin@xylogics.com> Thu, 04 February 1993 15:27 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04404; 4 Feb 93 10:27 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04400; 4 Feb 93 10:27 EST
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa10233; 4 Feb 93 10:27 EST
Received: by atlas.xylogics.com id AB20452 (5.65c/UK-2.1-930202); Thu, 4 Feb 1993 10:26:15 -0500
Received: by atlas.xylogics.com id AA14005 (5.65c/UK-2.1-930202); Thu, 4 Feb 1993 10:26:12 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Gary Scott Malkin <gmalkin@xylogics.com>
Date: Thu, 04 Feb 1993 10:26:12 -0500
Message-Id: <14005.199302041526@atlas.xylogics.com>
To: ietf-rip@xylogics.com
Subject: Security hole in RIP-2

There is a potential security hole in the RIP-2 authentication caused
by the backwards compatibility rules.  If you're running sending RIP-2
packets and accepting either version, there is no problem with the
periodic responses because they never leave you network so nobody can
snoop them to find the password.  This means that nobody from outside
your network can inject bogus routing packets because a RIP-2 router
would discard the unauthenticated response.  However, somebody from
outside could send a RIP-1 query to one of the routers sending RIP-2
responses.  The router would not authenticate the RIP-1 packet and
would then deliver the password in the response.

There are two solutions.  Ideally, the router has to be smart enough to
answer a RIP-1 query with a RIP-1 response, which may not be easy for
some implementations.  Otherwise, the documentation must clearly state
that authentication is only secure when the routers are configured to
accept only RIP-2 packets, so that the RIP-1 query would be discarded.

----------------------------------------------------------------------
Gary Malkin            "Felis Catus, is your taxonomic nomenclature an
(617) 272-8140         `exothermic quadruped, carnivorous by nature'?"