I think that you are invoking a very old argument regarding BGP. That
is, that a TCP connection failure should not be interpreted as a path
failure and, therefore, should not cause routes to be withdrawn.
You may or may not be right regarding this issue. However, the point is
moot. For better or worse, that decision was made years ago and BGP
became the infrastructure upon which interdomain routing is based. This
isn't about to change any time soon.
Given that BGP is what it is, we would do well to enhance TCP to support
its current requirements.
Joe Touch wrote:
> Andrew Lange wrote:
>>What we do have to design protocols around is user requirements. We
>>also have to design protocols with maximum flexibility and robustness.
>>End users will use the protocols in ways we haven't predicted to meet
>>requirements we don't yet know about. All TCP EXT AUTH does is provide
>>a way to authenticate TCP sessions. It is radically more simple and
>>easier to do this at the TCP layer than to implement something slightly
>>different across a variety of higher-level routing protocols.
> Those modifications are already underway or implemented in the primary
> protocol of interest (BGP). These modifications reflect (IMO) an error
> in protocol design: TCP connectivity was never intended to reflect path
> viability for routing. Interpreting TCP disconnects as a path failure -
> which is the only reason to flush the associated routes - is thus an
> error which it is appropriate to correct.
> If that's not sufficient, it would be very useful to understand why
> IPsec isn't more than sufficient to solve the user protocol requirements
> If there are needs beyond the protocol level - e.g., anything involving
> disgruntled employees fits in here - then it'd be useful to understand
> why a protocol solution is necessary.
>>On Jun 12, 2006, at 1:49 PM, Joe Touch wrote:
>>>Caitlin Bestler wrote:
>>>>Andrew Lange wrote:
>>>>>The main reason for the TCP extended auth proposal is the
>>>>>ability to rollover keys without taking the session down.
>>>>>Adding additional, more secure algorithms is a secondary goal.
>>>>>A key attack vector our customers are concerned about is the
>>>>>disgruntled employee let go or other compromise of the key list.
>>>>>They need to be able to change the keys without interrupting
>>>>>the session and causing routing to suffer. Without this, a
>>>>>new mechanism is not particularly useful.
>>>>Something about "disgruntled employee" sounds distinctly
>>>>application domain to me.
>>>Yeah - and one would hope that wouldn't be frequent enough to design
>>>protocols around either ;-)
> tcpm mailing list
tcpm mailing list