Subject: [Ieprep] An alternative concept of IEprep

From: RJ Atkinson <[email-masked]>
Date: Thu, 12 Dec 2002 13:26:02 -0500

Personally, I find the Japanese deployment of IEprep to be very
interesting.  Trying to take their concept and generalise it a bit,
here is an alternative (non-voice) concept for IEprep for discussion.

Ran
[email-masked]

------------------------------------------------------------------------ 
-

OBJECTIVE:
	Provide enhanced ability for emergency workers to communicate
among themselves during an (unplanned) emergency.

OPERATING ENVIRONMENT:
	This service should work from a laptop deployed in the field,
that would be connected via dialup PSTN, wireless, Ethernet, or
whatever other connectivity existed in the field.

	This service should work equally well for an emergency service
worker who happens across an Internet cafe that offers access to
the world wide web.

APPLICATIONS:
	Only standard Internet applications protocols would be used.  The
primary applications would be all be based around HTTP and TLS [1].
The applications would be chosen in part for their ability to operate
robustly in challenging environments -- meaning that the applications
should still be able to work just fine in circumstances of packet loss
on access links, variable latency and jitter, and so forth.  The  
applications
should also all be well-behaved from a congestion avoidance and control
perspective.

	Specific supported applications would include web-based email, both
secure web sites (using TLS and login/password) and non-secure web sites
(e.g. http://news.bbc.co.uk), Internet Relay Chat (IRC), Instant  
Messaging (IM),
and possibly also tailored web-based applications.

	Web-mail could be used for nearly any sort of communications,
including requests, situation reports, and so forth.  For improved
availability, users that would predictably need access during an
emergency (e.g. US FEMA staff, Red Cross, local emergency services)
could obtain an account on a dedicated webmail cluster that is built
in a high-availability and distributed manner.  The URLs, login id,
and password could all be pre-printed on a wallet-sized card, for  
example.

	The secure web sites could be used for uploading/downloading various
kinds of documents (e.g. situation reports, requests for equipment or
other assistance, standard operating procedures, lists of victims,
lists of known survivors, etc.).  There might be  
pre-planned/pre-deployed
IEprep web server clusters (similar to the above webmail cluster  
concept),
in addition to using whatever other servers were suitable in an ad hoc
manner.

DEPLOYMENT CONCEPT:

	While dedicated servers are not required for this concept to work well
and be very useful, dedicated servers could help improve service  
availability
and reduce communications latency.

	A good strategy for the servers would be to build several  
high-availability
server clusters.  High-availability meaning that if a component failed,  
the
system could quickly recover and the non-failed components would  
continue to
work together, though possibility with diminished storage, I/O, or CPU
capabilities.  HA server clusters are widely available COTS products,  
though
they are often not cheap.

	Clusters would be placed in ISP co-location facilities, preferably in  
the
same bunker-style facilities used for the ISP's core routers.  The goal  
would
be to have at least one server cluster inside each large ISP's core.   
Contracts
could be signed with the ISPs to give service restoration to those  
clusters
priority -- and if co-located in the ISP's core router POPs, there is  
high
probability that the ISP could get technical staff on site quickly if  
needed.
Being inside an ISP's core router POP also helps ensure service  
availability,
because the server cluster could easily have redundant connectivity to  
multiple
core routers.

	In addition, the operator of the server clusters would endeavor to get  
the
ISPs to agree that service restoration of links among the contracted  
ISPs
would get preference in the event of a fibre cut (or similar).

	Each server cluster would be configured to automatically remain in sync
with each other server cluster.  So that if one lost any single  
cluster, there
would be a high probability that most of the data on that one cluster  
would
also be replicated on some other cluster.

	Applications would need to be deployed such that login to any cluster
would be approximately equal to logging into any other cluster.  This  
way,
users need only login to the nearest or most reachable cluster.

	Anycast might or might not be useful for addressing the servers.  An
alternative to anycast is to list the URL for each cluster on a  
wallet-sized
card, so that users could try each one in turn from the field.

SECURITY

	These server clusters would be a high-value target.  So they should
probably have high-grade IP encryptors at each cluster to provide secure
connectivity to other clusters.  If operated by a government, one could
imagine using a military-grade IPsec encryptor [2] or a formally  
evaluated
commercial-grade IPsec encryptor.  The server software (OS and  
applications)
should be hardened.  The servers should have a high-availability system
configuration, including redundant hardware and HA-capable OS software.
The web services might well use X.509v3 certificates (or equivalent) to
provide strong authentication of identity.  The web services should use
strong cryptography (e.g. 3DES-CBC + HMAC SHA-1 or better) with their
TLS implementation.  Login database data should be replicated at each
site rather than centralised in order to improve availability of login
services.  Disk systems should be RAID with more capacity than one  
thinks
is needed in the worst case (disk is cheap).  The systems should  
probably
be behind some sort of firewall device.  The servers ought NOT be behind
a NAT because that makes IPsec and other security applications difficult
or impossible to deploy

NOTES:

[1] IETF's Transport-Layer Security (TLS) specification is the primary  
standard
	for security with HTTP.  TLS is derived from SSL 3.0, but contains a  
variety
	of architectural and technical fixes, including more solid security.
[2] For data rates up to 1 Gbps, these either exist GOTS/COTS today or  
are going
	to be available near term.  For data rates up to 10 Gbps, one might  
need
	to wait up to 24 months.  If the speed were critical, one could use  
evaluated
	commercial-grade products on an interim basis.  The real trick is  
having a
	solid key management plan, of course.

------------------------------------------------------------------------ 
------------

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep