Can I put in my two-penny worth on this debate?
I am putting some glosses on the mailing from John Coulthard (JC) who
was responding to points made by Ewan Davis (ED). I am sorry of the
result looks confusing!!
> From: John Coulthard <[log in to unmask]>
> I will try to pick up each of the points made by Ewan Davis ED
>
>
> ED: I don't understand your comments on network pricing, can you translate
> the management speak?
>
> J : I mean that the cost of networking must be looked at as a whole. Here
> is a real example. An organisation did not want to join NHSnet, it was too
> expensive, it also paid 40,000UKP for databases in its Library to access the
> same data on NHSnet would cost 14,500UKP The cost of the NHSnet connection
> was 20,000 UKP a total of 34,500 UKP. They then used the difference to
> purchase a Firewall.
This is a pretty bogus piece of economics. It mixes together two
quite separate activities (the provision of network services, and the
provision of access to a service reachable by a network) and their
costs. There is absolutely no reason at all to tie these together,
unless of course you want to restrict access to a valuable
non-network service to those who are connected to a restricted
membership network. Can we please all agree that the function of a
network is to provide connectivity, and that to seek, by regulation,
to embed in this network service the provision of other quite
separate services will inevitably distort the argument.
>
> Summary NHSnet was cost effective. Using the Internet would not have been
> possible the databases were not available.
That is thoroughly putting things inside out. The databases were
not available via the Internet because a POLICY decision to that
effect had been made. I can think of no good TECHNICAL reason why
connection via the Internet should not be provided; of course there
may well be good reasons for restricting access, but this is done by
well known techniques (passwords etc) which are totally independent
of the route via which connection is established.
>
> I use this example because it is real and it shows now the business case
> works.
No it doesn't. It shows how policy decisions as to the means of
accessing a service can be misused.
> ED: The simple question is why aren't NHSNet tariffs competitive vs other
> ISPs many of whom provide the sort of additional services the NHS requires
> as part of their offering to the corporate Intranet market. Either NHSNet is
> over engineered, overpriced or both.
>
> J: Because it is faster, more reliable will still be here in 10 years
> never mind 10 months. See the Economist article of a couple of months ago
> about the survival rate of ISPs.
The slowest part of a network like NHSNet, which of necessity must
provide large numbers (about 10,000 I would guess) of local loops to
serve relatively small numbers of users at the end of each loop
(typically about 10 or fewer active users at any one time I would
guess) is always likely to be these local loops. (JANET is lucky
here; the number of connections to sites is small, in the order of a
few hundreds, and the individual sites are each large, in the order
of a thousand active users at an average University). These local
loops are also likely to be the noisiest, and the least reliable, not
least because they will often represent a single point of failure.
All other aspects are likely to be insignificant, at least until the
traffic densities on the NHSNet backbone go up by a very substantial
factor.
Bear in mind too that networks, especially large wide aarea ones, are
always "Grandpa's Axes"; during their life they will have three new
heads and four new handles, but will always be referred to as
Grandpa's Axe. (I suspect that the only original bits of JANET that
are now in use are the desks in the offices; certainly all the lines
and switches have been replaced at least four times to my knowledge)
>
> ED You comments about attachments are technically correct but in practical
> terms are rubbish. I routinely send attachments of 100's of k to a few meg
> and long ago gave up splitting them in to smaller segments because nearly
> all ISPs handle them as a single item without problems.
>
> JC: Well you asked, it is all about Body Part 14 and 15 of the X.400
> message. X.400 does not handle proprietary attachments that well, it
> will do, it does things like guaranteed delivery and read receipt that smtp
> does not do. These are the features that make X.400 what it is. However,
> there is an ongoing "flamewar"! about SMTP and X.400 No need to add to it
> here. Smtp is good for some things and X.400 is good for others. I
> prefer to think of X.400 as the Registered Post of Email.
I have sympathy with John here! There is little doubt in my mind
that X.400 is technically superior to SMTP. There is however the
nasty issue of the effectiveness and reliability of the
IMPLEMENTATIONS of the two protocols, and it is here that the
troubles arise. It has always been the case that the large market
for Internet based products, and in general terms higher grade of
implementation effort that has gone into their reaalisation has meant
that the Internet based system arrives earlier, is more effective,
better supported, and all round just plain better, than the products
based on CCITT standards. It is a shame, as the CCITT design is
often at least as good, but there it is.
>
> ED: There a lots of simple firewalls. Have a look at www.davecentral.com for
> a long list.
>
> JC: I will have a look.
>
> AD: Firewalls become complex when you need to apply complex policies with
> large numbers of users such as firewall between a corporate Intranet and the
> Internet which will provide differential access through the firewall for
> different users or classes of user and allow access to services from the
> outside with complex IP filtering. Such firewalls are expensive and need
> highly skilled personnel to maintain them.
>
> JC: I agree, will a PCG be complex organisation? 200 plus employees
> 100,000 patients?
I don't want to get sucked into the PCG war, but I see a serious
issue here. My view is that a firewall needs to protect a 'small'
group; by small I mean
1 small enough so that all the people associated with the group know
all the others
2 small enough so that all the people (and equipment) working in the
group can be housed in a single building, or a part of a larger
building, around which there can be physical control of access.
(Instances mught be a GP clinic, or a hospital department)
Such a small group can then be relied on to provide considerable
physical control of access to terminals and workstations, reducing
the risk of access by an unauthorised intruder who enters the
premises. The group can share unencrypted data. The presence of a
firewall may help to reduce the risk of access by an unauthorised
intruder who gains network access. Of course, the data, or more
accurately the applications running on the systems, within the small
group, should provide password control of access. Since physical
access to servers is restricted, the risks of tampering with the
servers is reduced. Any personal or clinical data which is to be
sent across the wider area network (ie NHSNet in our context) should
be encrypted.
In this view of things, many of the firewall systems will be serving
only a small number of users, typically say 30 persons, of whom 10
would be active at any one time. Such a firewall is going to be
inexpensive, and easy to maintain. The firewall should NOT be seen
as providing security, but only as a contributor. The real security
resides in the appliccations running within each small group, and in
encryption when data is in transit between groups.
Mike Wells
***************************************************
* M. Wells *
* 9 Hall Close *
* Bramhope *
* Leeds LS16 9JQ *
***************************************************
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
