[ih] "The First Router" on Jeopardy

[Tony Li]

Then take a look at https://rpki-monitor.antd.nist.gov/ and see that we’re actually making pretty steady progress on 
getting RPKI deployed.

Tony


> On Nov 26, 2021, at 8:11 PM, Brian E Carpenter via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> If you want to be even more concerned, see the article about securing BGP
> at page 19 of:
> https://ipj.dreamhosters.com/wp-content/uploads/2021/10/243-ipj.pdf
> 
> Regards
>   Brian
> 
> On 27-Nov-21 16:48, Jack Haverty via Internet-history wrote:
>> I just ran across a contemporary article on the current use of BGP in
>> the operational Internet:
>> https://krebsonsecurity.com/2021/11/the-internet-is-held-together-with-spit-baling-wire/
>> Fascinating, to me at least, since I lost track of how BGP was being
>> used back in the 80s when we created it as an interim technique. Honest,
>> I didn't see this article before I sent my historical offering below.
>> Looks like "baling wire" is still in the Internet operators' toolbox,
>> after 40 years.
>> Jack Haverty
>> On 11/25/21 12:16 PM, Jack Haverty via Internet-history wrote:
>>> On 11/24/21 5:47 PM, Guy Almes via Internet-history wrote:
>>>> First, by 1987, when both the ARPAnet and the proto-NSFnet backbone
>>>> were both operational, networks that connected to both had to decide
>>>> which to use, and that led to interesting routing decisions. Problems
>>>> encountered then led, for example, to creation of BGP.
>>> 
>>> FYI, for The Historians, I offer a little of the earlier history, all
>>> from the 1980-1983 timeframe.
>>> 
>>> At the ICCB (before it was renamed IAB) meetings, there was a list
>>> kept on the whiteboard of "things that need to get figured out". One
>>> of the items on that list was "Routing", which included issues like
>>> "Type Of Service", "Shortest Path First", and "Policy Routing" -- all
>>> part of the "How should routing behave in the future Internet?"
>>> topic.  There were two concrete motivators for these issues.
>>> 
>>> The Internet had started to evolve from its "fuzzy peach" stage, where
>>> essentially the ARPANET was the peach surrounded by a fuzzy layer of
>>> LANs, into a richer topology where there were actually choices to be
>>> made.
>>> 
>>> First, SATNET had linked the US and Europe for a while, but Bob Kahn
>>> initiated the addition of a transatlantic path using the public X.25
>>> service.   The interconnect was called a "VAN Gateway" (VAN stood for
>>> Value Added Network but I never did understand what that really
>>> meant).   The VAN gateway essentially added an interface option to the
>>> existing gateways, allowing them to connect to the public X.25
>>> networks, and use them as a "circuit" (albeit virtual) between
>>> gateways.  In effect, the entire X.25 public network system was made
>>> an available component of the Internet; it became just another network
>>> that could be used within the overall Internet.
>>> 
>>> The "dial up" nature of the X.25 service also introduced the
>>> possibility of dynamic configuration of the Internet topology -- e.g.,
>>> adding or deleting circuits between pairs of gateways as a situation
>>> warranted, simply by using the dialup infrastructure of the public
>>> X.27/X.75 system.  We called that something like "Dynamic Adaptive
>>> Topology", but I don't recall ever actually trying to use that
>>> capability except on the single US<->EU path in parallel with SATNET.
>>> 
>>> This "VAN" capability was used to create a topology where there were
>>> two ways IP datagrams could cross the Atlantic.   Bringing economics
>>> into the picture, the SATNET path was funded by ARPA, to be used only
>>> for ARPA-approved projects.   The X.25 path was funded by whoever
>>> opened the circuit first (which we, as ARPA contractors, silently
>>> engineered to be usually the European side; seemed like the right
>>> thing to do).   This issue appeared on the ICCB's to-do list 
> as
>>> "Policy Based Routing".
>>> 
>>> Pending the "real" solution, I don't recall exactly how the gateways
>>> back then made the choice of path for each packet; my vague
>>> recollection is that it had something to do with destination addresses
>>> - i.e., a host might have two distinct IP addresses, one for use via
>>> SATNET and the other for use via X.25.   And a single physical net
>>> would be assigned two network numbers (no shortage then), one for use
>>> via X.25 and the other for use via SATNET. IIRC, that's how the UCL
>>> network in London was configured.  The early Internet had to sometimes
>>> use patching plaster and baling wire to keep it going as the research
>>> sought the right way for the future.
>>> 
>>> Second, the Wideband Net, a satellite-based network spanning the US,
>>> was made part of the Internet topology by gateways between it and the
>>> ARPANET.   There were then multiple network paths across the 
> US.   But
>>> the gateways' routing metric of "hops" would never cause any datagrams
>>> to be sent over the Wideband Net.   Since the Wideband Net was only
>>> interconnected by gateways to ARPANET nodes, any route that used the
>>> Wideband Net would necessarily be 2 hops longer than a direct path
>>> across the ARPANET.   The routing mechanisms would never make such a
>>> choice.    This issue was captured on the ICCB's list as "Expressway
>>> Routing", a reference to the need for car drivers to make a decision
>>> to head toward the nearest freeway entrance, rather than taking a
>>> direct route toward their destination, in order to get to their
>>> destination faster.
>>> 
>>> I don't recall how people experimented with the Wideband Net, i.e.,
>>> how they got datagrams to actually flow over it.   Perhaps that was a
>>> use of the "Source Routing" mechanisms in the IP headers.   Maybe
>>> someone else remembers....
>>> 
>>> We didn't know how to best address these situations, but of course
>>> there were a lot of ideas.  In addition, the existing Internet lacked
>>> some basic mechanisms that seemed to be necessary.  In particular, the
>>> use of "hops" to determine which path was the shortest was woefully
>>> inadequate.   A "hop" through a Satellite net might be expected to
>>> take much longer than a hop through a terrestrial net, simply due to
>>> Physics.   But a hop through the ARPANET traversing many IMPs, when
>>> the net was congested, might actually take longer than a satellite
>>> transit.  A time-based metric was not feasible in the gateways without
>>> some means of accurately measuring time, at a precision of
>>> milliseconds, in the routers scattered across the continents.
>>> 
>>> Dave Mills was on the ICCB, and he took on this quest with unbridled
>>> energy and determination.   NTP was the result - an impressive piece
>>> of engineering.   Using NTP, computers (e.g., routers, gateways,
>>> hosts, servers, whatever you call them) can maintain highly
>>> synchronized clocks, and measure actual transit times of IP datagrams
>>> for use in calculating "shortest path". Everyone can thank Dave and
>>> his crew that your computers know what time it is today.
>>> 
>>> The Time mechanisms would be helpful, but much more was needed to
>>> handle "Policy Based" and "Expressway" routing situations.  Lots of
>>> people had ideas and wanted them put into the "core gateways" that BBN
>>> operated.   But doing that kind of experimentation and also keeping
>>> the Internet core reliably running 24x7 was a struggle.
>>> 
>>> I was also on the ICCB at the time, and I recruited Dr. Eric Rosen
>>> back at BBN to help think about it.   He and I had numerous day-long
>>> sessions with a whiteboard.  The result was EGP - the Exterior Gateway
>>> Protocol.   If you read Eric's now ancient RFC defining EGP, 
> you'll
>>> see that it was not intended as a routing protocol.   Rather 
> it was
>>> more of a "firewall" mechanism that would allow the Internet to be
>>> carved up into pieces, each of which was implemented and operated at
>>> arm's length from the others but could interoperate to present a
>>> single Internet to the end users.
>>> 
>>> The intent was that such a mechanism would make it possible for some
>>> collection of gateways (e.g., the "core gateways" of the Internet at
>>> that time) to be operated as a reliable service, while also enabling
>>> lots of other collections of gateways to be used as guinea pigs for
>>> all sorts of experiments to try out various ideas that had come up.
>>> Each such collection was called an "Autonomous System" of gateways
>>> using some particular technical mechanisms and under some single
>>> operator's control.   EGP was a mechanism to permit reliable
>>> operational services to coexist in the Internet with research and
>>> experimentation.
>>> 
>>> When the ideas had been tried, and the traditional "rough consensus"
>>> emerged to identify the best system design, the new algorithms,
>>> mechanisms, protocols, and anything else needed, would be instantiated
>>> in a new Autonomous System, which would then grow as the new system
>>> was deployed - much as the ARPANET has served as the nursery for the
>>> fledgling Internet, with all IMPs disappearing over time as they were
>>> replaced by routers directly connected with wires.
>>> 
>>> That's where my direct involvement in the "research" stopped, as I
>>> went more into deploying and operating network stuff, from about
>>> mid-1983 on.   Perhaps someone else can fill in more gaps in 
> the History.
>>> 
>>> Enjoy,
>>> Jack Haverty
>>> 
>>> 
>>> 
>>> 
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history