[e2e] Pre-auth wrapper for setup of e2e apps
John Kristoff
jtk at aharp.is-net.depaul.edu
Tue Jan 14 22:01:40 PST 2003
Apologies in advance if I'm completely ignorant of past research/work
on this sort of thing or if I'm just being silly. Pointers welcome.
I'm thinking of a service model that uses a callback model for
TCP-like applications.
So for example, rather than clients talking directly and immediately
to a server application, there is an initial service request to a
simple, generic and well known wrapper on the server. The job of
the wrapper service is to simply authenticate, validate and 'call
back' the clients. The authentication and validation could be
sophisticated or nothing more than a TCP-like 3-way handshake.
In the initial exchange between a client and the server's wrapper,
the application and callback info are agreed upon. If successful,
the client listens passively for a callback from the server (and
only the server with agreed upon parameters).
I'm imagining something like this (half baked and simplified):
initial client initial server
-------------- --------------
service request ---> wrapper
receipt <--- validate, callfrom cookie
ack ---> prepare callback
set timer
listen:callfrom <--- ephemeral src ip/port
ack --->
session established, data transfer
This does not seem deployable with today's lack of e2e-ness in much
of the deployed IP internetworks and well entrenched method for doing
things. However...
Would this be likely to increase or lessen security (or both at the
same time)? How dumb of an idea is it that single, well known
pre-session wrapper be used for all TCP-like application setups?
Are there advantages to this prescreening of applications (and
ports/protocols)? Does this have good or bad DoS properties?
Is this robust or not?
Would this do anything for maintaining e2e-ness in a future
internetwork architecture?
What else am I missing that makes this sort of thing good or bad?
John
More information about the end2end-interest
mailing list