[ih] Exterior Gateway Protocol

[Guy Almes]

Tony, Joe, et al.,
   In addition, and again trying to keep a historical emphasis, the 
original BGP design was for Border Routers that were typically one hop 
from each other.

   But note that the use of TCP, while viewed as mildly heretical at the 
time, brought many advantages.
   For example, experience with EGPv2 made clear that BGP would need to 
support incremental updates, and TCP sessions helped with that.
   Again, as the number of network numbers / prefixes grew rapidly, TCP 
supported very large (especially) initial route messages.
   Again, there were contemporary (e.g., Van Jacobson's early work) and 
ongoing improvements to the performance, stability, and security of TCP, 
and those strengthened BGP without the need for BGP-specific efforts.

   So I think, especially in hindsight, a very good move,
	-- Guy

On 9/4/20 11:29 AM, tony.li at tony.li wrote:
>>> Most of the symptoms that you cite are all a result of the lack of a workable security architecture. A problem that pervades the entire stack, even to this day.
>>
>> Were it not for the TCP-to-BGPpath correlation, BGP security could be completely supported elsewhere, e.g., by signing the individual routes. Even if there were a deployable solution to those signatures, TCP connection vulnerability still requires MD5, AO, or IPsec — or an override in the config to NOT correlate TCP sustainability with path viability.
> 
> 
> Sorry, but that’s provably incorrect.  As we’ve seen with other protocols the transport mechanism must be secured as well, not just the contents. We have authentication in OSPF hellos and IS-IS IIHs for this reason.
> 
> Tony
>