Re: [tcpm] TCP-AO: Text for New_Key Process

Gregory M. Lebovitz wrote:
> Folks,
> resend...
> 
> Neither I nor Joe have received ANY feedback on this New_Key process. 
> Can people pls do a quick review and reply to me, Joe, and list with 
> comments? Joe is trying to get a next version out.
> 
> Many thanks,
> Gregory.
> 
> At 01:18 AM 12/19/2008, Gregory M. Lebovitz wrote:
>> Hey Joe, and all.
>> Below is pasted my first crack at the text for the New_Key Process. 
>> All input welcome.
>> Gregory
>>
>> ==New_Key Process:
>>
>> [Suggest you place text about new_key at the end of section 6 in -02]
>>
>> One big difference between TCP-AO and TCP MD5 is that TCP-AO allows 
>> for the change of a TSAD entry -- and thus the corresponding change of 
>> a conn_key -- during a connection, without having to drop the 
>> connection. This allows for an HMAC algorithm or TSAD_key change 
>> without a connection loss. This behavior is very beneficial for the 
>> optimal operation of applications with long lived connections, such as 
>> BGP. The process of moving from one key to another is called "New_Key".
>>

 From the beginning I have been uncomfortable with the abuse of an 
"option" being used to reliably transport something that is not truly
an option.

But as Joe pointed out during a prior round, a simple digest is derived
from the payload. So it is not truly separate payload.

But the "new key process" strikes me as going farther than that. It is
trying to shoe-horn in a second data stream onto one TCP connection.
There are already two ways to do this:

+ At the transport layer with a transport protocol designed to support
   multiple streams, specifically SCTP.
+ Above the transport layer, such as is done with SSH tunneling.

Either of those methods work, so I do not see the justification for
doing major havoc to some of the normal working assumptions with TCP.
Deliberately sending frames that have a substantial chance of being
dropped is just plain wrong.

In fact, I am fairly sure that some of the techniques proposed would
be diagnosed by a current Intrustion Detection System as an attack.

To justify that level of a change there should be something wrong with
the Transport protocol itself, not just an application that doesn't
want to change anything.

Let the current TCP-MD5 applications figure out their own solution on
how to do out-of-band signaling. Using a null encryption and SSH 
wrappers strikes me as one very viable solution that could preserve
existing code. But just find a solution *above* the TCP stack, and
avoid "minor" modifications to TCP that require stacks to do things
that previously would have been an attack.

-- 
Caitlin Bestler
cait@asomi.com - http://www.asomi.com/CaitlinBestlerResume.html
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm