Towards Non-Repudiation in Network Routing - Specifically RIPv2

Presently, I'm a student at DeVry University Online (DVUO). Personally, I've found it exceedingly difficult to retain so much of sense of goodwill across discussions in undirected forums. Within the discretely bounded discussion forums of the online classes at DVUO, however, moreover that every discussion forum in the class is directed about one or more single, discrete topics, it's rather easier to retain a simple sense of focus, there -- and none to any ad hominem regard, candidly, whether positively or otherwise. It's none so difficult for me to "Keep my heart in it," then, in those bounded, focused discussion forums. Of course, if there's any goodwill quotient, it stays bounded to those forums, inasmuch.

One of the topics we are discussing, in one of DVUO's networking courses, is the topic: The Routing Information Protocol (RIP) and its specific editions. That being clearly a part of "Existing work," on the Internet, certainly there could not be any concern as if with regards to "Intellectual property," in my presenting my present view about the topic, here.

The Routing Information Protocol (RIP) -- whether in the RIP protocol version RIPv1 or RIPv2 for IPv4 networks, or RIPng on an IPv6 network -- broadly, RIP is a family of network protocols, each similarly applied in dynamic routing configurations. An RIP protocol would be applied namely for broadcasting of routing information in router neighbor updates on a dynamically routed IPv4 or IPv6 network. Dynamic routing may be contrasted to  static routing -- the latter, as in which a static network address and netmask would be used for determining a "next hop" for routing of a network packet, in a static routing table configuration, not requiring further updates from other routers on the network.

The Routing Information Protocol protocol may be useful in a "network backbone" network, namely in a configuration in which  a router would be able to select one of multiple alternate routes for a "next hop" in packet routing.

RIPv1, specifically, might be useful if a network's routers would not support RIPv2. In a brief feature comparison, RIPv2 would offer some advantages over RIPv1 -- including, the addition of an authentication data field, as an extension available for the RIPv2 message format.[1]

Essentially, RIPv2 message authentication, as a feature, is available as an extension on the baseline RIPv2 message format. An RIPv2 protocol implementation should be able to function with or without the RIPv2 message authentication feature.[2]

Functionally, an RIPv2 authenticated message frame would consist of a two-byte authentication type code -- e.g simple password as type 2 -- and a 16 byte authentication data field. Of course, in simple password RIPv2 message authentication, there would be the disadvantage of the password being encoded in plain text within the 16 byte field.[2]  Preferably, RIPv2 MD-5 authentication would be used instead, for authenticated RIPv2 messaging. Though that would not ensure a complete non-repudiability -- such as with regards to non-repudiation and the Kerberos authentication framework[3] -- but the MD-5 approach would at least serve to ensure that when the password would be encoded into the authentication data field, it would be encoded using an MD5 checksum of the password text.[4]

RIPv2 message authentication may serve in a role in message authentication for routing updates. However the simple password-in-a-packet model would not in itself support non-repudiation -- i.e it would not be proofed against "Man in the middle" exploits of the routing table updates. In a short summary: If an RIPv2 authenticated message is sent "in the clear" -- that is, without any manner of a secure handshake and tunneling such as with SSL -- then if the RIPv2 authenticated message would be intercepted, the message password in the authentication data field, hypothetically, could be duplicated by an exploiting network device, that allowing that device then to spoof the actual router. Perhaps it might therefore seem redundant as a feature, if not potentially counterproductive to network functionality, but it is available as a feature for RIPv2 and extending protocols.

I wonder, then, are there ways to limit the possible "Man in the middle exploit potential," in that?

The first idea I that would like to denote, at that, would be to inquire of whether a Kerberos KDC may be applied in parallel with RIPv2 message authentication? Can RIPv2 message authentication be extended for integration with Kerberos? If that could be effective, for securing a network's routing updates in a manner of non-repudiation? 

Focusing, then, on the 16 byte authentication data field in an authenticating RIPv2 message, could that 16 bytes be applied in some sort of a manner integrating with Kerberos tickets? Would that be possible in RIPv2 broadcast updates? Or is it simply an inapplicable idea?


Secondly, I wonder if RIPv2 could be applied onto an SSL transport? Perhaps that would be altogether simpler than to try to "Work it together with Kerberos," so to speak?



Either way, I'm sure it would seem nonconventional, to a popular point of view that one would so much as question "Existing knowledge." Personally, I'm none so much a populist about technology.  I know only so much as I know. Personally, I believe that there must be a way to prevent that RIPv2 packets could be spoofed on a network -- in a manner none so colloquial as to prevent "Router poisoning," though perhaps that single phrase might serve to describe the possible seriousness of the concern.

If, more broadly then, the concern would be of "Router poisoning" it would need a more complex problem analysis than my brief synopsis, here. In short, a "Spoofed route" might be problematic only if there was an exploited router for the "Spoofed route" to direct traffic to, in a network -- nothing so trivial, and nothing whatsoever good for a digital network. Perhaps it would be simply too complex of a "Threat surface," too much to merit further analysis, in this short view.

Works consulted:

[1] Ahamed, Afazuddin. CCNA Prep: Why Choose RIPv2 over RIPv1? Intense School. 2013
[2] Malkin, G. RIP Version 2, Carrying Additional Information. IETF. 1994
[3] Neuman, B. Clifford and Theodore Ts'o. Kerberos: An Authentication Service for Computer Networks. IEEE Communications Magazine. 1994
[4] Baker, F. and R. Atkinson. RIP-2 MD5 Authentication. IETF. 1997

I C SPACE LIGHTS....

 ED. NOTE: I'd cut and pasted this from my own response, tonight, in an online forum.

Considering the OSI seven layer model: There may be some applications possible for existing fiber optic "layer 1" technologies, therein using  a sort of "different" optical media, though, namely in real "Outer space," moreover in a context of the emerging privatization of "Outer space," as around such as Richard Branson's Virgin Galactic and SpaceShip Two, the latter's "home spaceport" being located near Las Cruces, New Mexico.

Observing the web site of the NASA LLCD  project, specifically, NASA has begun to develop technologies such that may be suitable for high-throughput communication between satellites, using a digital encoding on optical signals, in real "outer space." Of course, there would also be some complex satellite positioning algorithms being required, in the same -- the network being absent of an effective "cable" between each of the respective light-signal endpoints -- that the system appears to function in a manner broadly analogous to a hypothetical system of a flashlight (or rather, a laser) and a lens, each in a digital circuit, moreover absent of intervening "air".

If the optical networking technologies used in the LLCD project might be -- in some ways -- analogous to conventional fiber optic media, then, and if the same technologies may be suitably miniaturized, perhaps such a possibility could be recognized commercially, and applied towards further production of that technology. Of course, it might not be viable for a "mass market," but it might be useful for application in further development of some emerging technologies -- such as, ostensibly, towards asteroid mining at orbital lagrange points above low earth orbit. No doubt, such systems as could be used in a by-in-large automated orbital asteroid mining system, those systems could function without continuous optical networking, but certainly it would not be a bad thing if a constant optical network was available as among the respective "mining satellites", and wherever the main "mining control people" would be, whether in orbit or (ostensibly with a repeater between the optical network and a radio network) on the ground.

Conceivably, if it may be possible to build the further OSI layers on top of that optical media, then -- perhaps, as in implementing an existing TCP/IP stack effectively onto such networking media, as could be approached in using Cisco's IOS and its QNX RTOS baseline, or an RTOS Linux implementation -- then, it might even be possible to implement CORBA in real "outer space". Of course, it would also need a suitably resilient digital electronics platform, for such a networking system to function continuously, in orbit.

Maybe one day, there could be CIsco routers in real "outer space."