[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPsec and TCP



I also ran into the same problem (which started this thread).
When exactly do you think keying should start?  If you defer
until the user initiates a connection but before TCP starts,
you must obtain control somewhere in the application layer.

In a stack that I control, this issue was worked around
by intercepting requests at the socket layer, determining
if keying is required, and only letting TCP take control
once the keying material is available.  I also tried some
other solutions that provided similar results (such as 
deferring TCP's timeout starting point) but they required 
more modifications to the stack and did not work any
better (from a user's perspective).

For stacks I do not control which is the case most of the time
I have tried pre-calculating keys which I am sure sounds like a terrible
solution to most people.  I have also tried spoofing the stack
regarding TCP connection setup and handling the actual TCP connection
setup and keying myself which seems to work OK but is complex.  
I am interested to hear whay others have done.  I think this may
be an important problem to overcome in implementations since
the side effects will be apparent to users.

Derek

At 06:05 PM 12/20/96 -0500, Hilarie Orman wrote:
>I think the processing order is just wrong.  Keying should be done before
>sending TCP data, i.e. the event that triggers keying must happen before
>invoking TCP or very early in the TCP open processing.
>
>Hilarie
>
>
>


Follow-Ups: