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
No comments:
Post a Comment