[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