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

IPv4, IPv6, CORBA, and also: Device Filtering on IP Networks

The following is an item that I'd written for an online class, today. The topic for the forum was namely a matter focused about subnetwork addressing, in classless (i.e CIDR) and classful IPv4 addressing.

In writing my response for the forum item, I've arrived at a couple of possible thesis topics, including

• IPv4 addressing considered limiting for CORBA application networks
• MAC addresses not considered sufficient for network device authentication

My response was as follows. For convenience, I'm just going to cut and paste my own response to the forum item, here.

As an obvious "Note to self," here shared in a sense, I think that it would behoove me to continue to study the IPv6 implementation on Linux.

Separately, there's the matter of MAC filtering, MAC spoofing, and alternately VPN architectures.

Ed note: Blogger's HTML editor has "Some issues" in regards to how it applies Cascading Stylesheets. I've had to process this HTML by hand, so that it will be legible to the reader. Of course, I used Emacs, for the quick markup change, in this item

Functionally, a subnet mask is a bitmask for the sequence of consecutive bits of an IPv4 address, with "all ones" for the bits that represent thenetwork address portion of the IPv4 address [ TCP/IP Guide Reference 1 ,  Reference 2 ]

Whether in CIDR addressing or classful addressing, subnetting revolves, functionally, around the application of a subnet mask. 
In classful addressing, for address classes A through C, the classful IPv4 address' subnet masks is calculated at, each, a full byte boundary in the IPv4 address.  [ TCP/IP Guide, Reference 3] Class A addressees have a subnet mask of 8 bits (one byte) in length, class B subnet masks are 16 bits in length, and class C address, 24 bits in length, with the remaining bits being avaialble for host addressing and subnetting on a single network.

In CIDR, a subnet mask may be defined at any any effective bit length less than 32  [TCP/IP Guide Reference 2].

For example, on a network using CIDR addressing, when the assigned IPv4 netmask for the network is 28 bits in length, 4 bits are then available for addresses for hosts and subnet gateways, on the network. That equates to 2^4 total addresses, namely 16.


If one may introduce a sidebar with regards to network address translation, as in an interest of informing the discussion with regards to IPv4 addressing:

Individual subnets of a network, if using network address translation, may use any of the IPv4 address ranges reserved for private IPv4 networks [ RFC1918 ] for addresses on any single, local subnet. In a network architecture using network address translation, the number of available host addresses, across all subnets -- rather, the number of "client" host addresses would be effectively infinite, i.e not a number

Network address translation introduces a corresponding concern, as with regards to availability of network services on a subnet M, for such servcies as must be available to hosts on any subnet not being a subnet of M. That may be addressed, effectively, with port fin orwarding at the network gateway and/or firewall on subnet M, wherein each individual network service that must be available on "Not M" must be assigned to a single port "P" on the network gateway for the "M" network itself. The packet filtering framework on M must then configured to forward packets delivered to port "P" of the network gateway, to forward those packets specifically any single port P' (P prime, may or may not be equal to P) on a host A on subnet M, such that host would be providing the required network service, on port "P prime". Of course, the packet filtering framework must also be configured correspondingly for network address translation, such that packets sent from A, in response to packets sent to A:P will be appropriately forwarded back to the requesting network peer, on its corresponding client socket port.

Candidly, on a further sidebar: A CORBA application architecture might not scale as well on an IPv4 network using network address translation, not as well as on an IPv6 network not using network address translation. (Considering that I've an interest in developing CORBA network services for consumer applications, and clearly this matter of IP address availability would pertain to CORBA service implementation, then I hope that it may be an apropos topic to continue about, briefly, here). In short, if a CORBA ORB on a network not M must access a CORBA ORB on a network M, and the gateway for M is using network address translation, then the number of ORBs that the ORB on not M may connect to is effectively limited to the number of available network ports on the network gateway for M. Moreover, in this situation, the configuration for network port forwarding on M may be decisively non-trivial. So, for a network of CORBA services, IPv6 network addressing would be preferred.


Continuing on that example, the network gateway for subnet M may be implemented with a Linux host, in which instance, Linux kernel netfiltermodules and the iptables command may be used for configuring the effective port forwarding schema for a subnet [ NAT HOWTO for Linux 2.4 and later kernel versions]. Citing personal experience, a Linux host with at least two network interfaces would be sufficient -- one network interface, dedicated to the "upstream" network, and the second network interface, connected to a switch on the Local Area Network or LAN.

Personally, I've not had any direct experience with server rack configurations. It's my assumption that there may be "Rack units" available for using Linux as a network gateway and firewall provider. I'm familiar with Linux networking, not really familiar with Windows NT networking. Though Linux  might seem to have a more "Bare bones" user interface, primarily at the shell commands used for configuring such as a netfilter system, but I think it's easier to understand the expected results of configuration changes, using Linux shell commands, rather than some GUIs, candidly.

Of course, firewall configuration would be a tangential topic, overall. I'm at least familiar with so much of Linux firewall configuration as may be applied for network address translation.

Tangentially, a network firewall on a network gateway may also be applied for MAC-based peer filtering -- essentially, as to block unauthorized PCs from transmitting packets to services on the firewall, and to block unauthorized PCs from transmitting packets through the firewall -- in a sort of rudimentary "authorized network interfaces" configuration, such that can be implemented with bare-bones shell scripting, in Linux, or with further GUI configuration in a broader application design. Of course, it is possible to "spoof" a MAC address. So, I write "authorized network interfaces," rather than "Authorized devices," as it is possible,  though it would not be ideal, for a single MAC address to be assigned to two or more  network interfaces, possibly each on two or more separate network devices.  Certainly, there are broader network security frameworks available for network peer authorization -- as may be applied within a single network architecture -- including X.509 certificates such as used in a VPN framework such as  strongSwan