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

RE: INITIAL-CONTACT issues




I agree that tcp specs do not specify keepalive mechanism.
However they discuss the issue in detail (RFC 1122), the
need for it, the reason why it should not be part of TCP...
I was trying to show that the problem of state-cleanup due
to crashed hosts was already faced by TCP implementors.

I am implementing 'COMMIT' and 'INITIAL-CONTACT' etc,
and the question I keep having is.
'Is there any reason why IKE is not implemented on
top of TCP?'
The architecture seems to allow it - most of the 
implemenations using IKE also have a tcp stack
(atleast the one's I have seen).
Any reason why TCP was not considered as a choice
(atleast a SHOULD support) for carrying IKE traffic?

  Thanks,
-- sankar ramamoorthi --

-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Monday, May 03, 1999 12:52 PM
To: Sankar Ramamoorthi
Cc: ipsec@lists.tislabs.com
Subject: RE: INITIAL-CONTACT issues


Sankar,

The TCP spec does not contain a "keepalive" mechanism (at least the one I
remember did not); keepalive is a feature added by some implementations.
TCP specifies timers for killing off connections, e.g., in terms of no ack
for transmitted data, which is one way to deal with the situation where one
end of the connection has crashed. Also, since TCP is implemented in end
systems, an application may intervene to terminate a connection, e.g.,
because a user decides to give up.  IPsec, when implemented in a host, and
integrated with a socket interface, can use the same set of inputs for
terminating an SA if the SA is dedicated to a TCP connection.

IPsec has a harder job, in the case of an SG, because there is no direct
tie to a socket interface.  That's where SA management, in terms of
cleanup, becomes hard.

Steve


Follow-Ups: