W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: keepalives again

From: Balint Nagy Endre <bne@bne.ind.eunet.hu>
Date: Thu, 26 Oct 1995 02:17:08 +0100 (MET)
To: Beth Frank <efrank@ncsa.uiuc.edu>
Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <238.bne@bne.ind.eunet.hu>
> > The MAC/TCP problem mentioned by Beth Frank reopens the question (for me),
> > but not knowing the details we can't go forward.
> > -- 3 days later: according to Roy's suggestion: what is the real difference
> > between the TCP abort and TCP close on MAC?
> > The problem seems not being http specific. How this problem is solved in other 
> > TCP/IP based protocols/applications? Discussing this with MAC developers may 
> > help. Who knows the MAC guys?
> The MAC Mosaic guys are going to run some tests to determine exactly what
> does happen on close vs. abort.  Their off the cuff guess is that abort
> doesn't send a close connection message, and the server only finds out
> the connection is broken when it trys to read from the socket next.
Hmm. If a TCP party does not send close packet, the other end will timeout
(in read) if some timeout exists in the protocol or hung undefinitely long.
If it tries to send something, then gets a 'connection reset by peer' error.
BTW I mean MAC guys at MAC. If there is a general problem, then
a) they will say, where are the patches
b) they will say: we are working on the problem, and later give some patches
c) none of the above. If this is the case, then we should make workarounds.
> > For the second half of the problematics (the state/context ascpects) we have
> > different domain. Contexts/states can be keept indepently from TCP connections.
> > (Authentication contexts are a special case, however they can be keept using a 
> > more complex technique. Persistent TCP connections help here a lot, but still
> > don't solve the problem completely.)
> We've been warned repeatedly by our security guru that persistent TCP connections
> can by hijacked by unauthorized users without much difficulty, so there are different
> constraints on an authentication session than on an open (insecure?) session.
But this is more complicate than to fool the WWW basic authentication.
An open TCP connection isn't less secure than the basic authentication scheme,
and hijacking needs access of the backbone. (I mean breaking in into
the ISPs network.)

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
Received on Wednesday, 25 October 1995 18:44:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC