|
|
Ron Bonica wrote:
> Joe,
>
> 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.
It is already changing, if it hasn't already - the relevant IDs are
cited in my draft.
> Given that BGP is what it is, we would do well to enhance TCP to support
> its current requirements.
Sorry, but that's nonsensical; you're asserting:
- BGP is as it is; we can't change it
- TCP needs to be modified
I hope you can see why - if anything - the converse will always occur
first. BGP isn't the only user of TCP.
Joe
>
> Ron
>
> Joe Touch wrote:
>> Andrew Lange wrote:
>>
>>> Joe, Caitlin,
>>>
>>> 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
>> here.
>>
>> 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.
>>
>> Joe
>>
>>
>>
>>> On Jun 12, 2006, at 1:49 PM, Joe Touch wrote:
>>>
>>>
>>>> Caitlin Bestler wrote:
>>>>
>>>>> Andrew Lange wrote:
>>>>>
>>>>>> Hi Joe,
>>>>>>
>>>>>> 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 ;-)
>>>>
>>>> Joe
>>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@xxxxxxxx
>> https://www1.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/tcpm
|
|