[ih] Exterior Gateway Protocol

[Jack Haverty]

Tony,

Thanks for the update.  From my end-user's perspective, the net seems to
work amazingly well.  Especially now, with half the planet seeming to be
Zooming all the time, I'm astonished that it still works at all.  But of
course we users don't see the army of people inside the net, frantically
playing whack-a-mole to keep it running with all the things that go on.

Back circa 1980, the potential problem of attacks was well known, and
there were research projects working on it in various government
activities.  Little of that appeared in the public Internet, but there
are traces from projects like TACACS and the Military Message
Experiment.   I think there were two reasons for that: it wasn't
considered a problem for an experimental collegial network, and
appropriate hardware wasn't available either.  

Most of those efforts were focused on the traditional usage model of a
human at a terminal using the network to access a remote computer.  
That could be addressed by access control (TACACS) implemented with
appropriate crypto mechanisms.   "End-to-end" was the buzzword of the day.

There was a larger problem identified, which I used to call the
"end-middle" problem.  Basically this recognizes that even in carrying a
single TCP connection, there are many other important traffic flows in
the net which also need protection in order for that TCP connection to
function.

The way to analyze this was to look at every field, of every header, of
every protocol, that had to work properly to assure that the users' TCP
connection involved would also work.  Each piece of information in each
such field had a source that generated it, and one or more "consumers"
that received and acted upon it.  Unless those communications were also
appropriately secured (one or more of authenticated, secret, authorized,
etc.), the viability of the users' TCP traffic was at risk.

So, for example, ICMP messages that originated at a gateway, and were
sent to a host, or vice-versa, should be appropriately secured.  They
are one example of an end-middle information flow.   Same with GGP
messages, although perhaps they'd be called "middle-middle".  Fields in
the IP header had similar characteristics, e.g., the addresses, TOS,
TTL, et al that were intended to convey "commands" to the gateways along
the path.  They are also an end-middle flow.

So, with in-band signalling there was recognition of the need to secure
the signalling as well as the user traffic.  But implementation could
wait for the next release.   Sigh.

Much of the discussions at the time never made it into RFCs.  Most work
was much more informal, carried out in email, or innumerable meetings,
or even at the hotel bar or chinese restaurant late into the evening.  
Sadly that's a now a real problem for historians.   Of course, I can
only recall the particular discussions where I was involved, so a
complete history would need to get many more perspectives.

/Jack

On 9/4/20 3:13 PM, tony.li at tony.li wrote:
>
> Jack,
>
>
>> I haven't followed all of the subsequent routing ideas and
>> implementations, but I assume they continue to use "in-band" designs. 
>> So if you can read this message, the answer to that experimental
>> question is apparently "Yes, it works!”
>
>
> Yes, it works. Sorta.
>
> In-band signaling was fine when we had a cooperative community.  Once
> the Internet hit the mainstream,
> it has been seriously problematic. DoS attacks to all control
> protocols are the daily norm. Forgery of control traffic is
> trivial and easy. We’ve had to put hardware in place to help alleviate
> some of these symptoms.
>
> ICMP is frequently used for DoS attacks, so most folks block it. This
> renders PMTUD ineffective.
>
> Net net: the decision to go to in-band signaling needed to be coupled
> with a decision to secure signaling,
> either by crypto or by piggybacking it on the transport protocol
> itself (with crypto there too). 
> And again, an overall security architecture is sorely missing.
>
> Regards,
> Tony
>