HP3000-L Archives

December 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"HOFMEISTER,JAMES (HP-USA,ex1)" <[log in to unmask]>
Reply To:
HOFMEISTER,JAMES (HP-USA,ex1)
Date:
Fri, 22 Dec 2000 22:01:54 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (61 lines)
Hello Folks,

Re: TCP/IP Networking And RF Connections

---------------------------------------------------------Mark writes--
That is exactly correct. This is the right and proper place to put the
security process: at the transport layer. Security should be a process
that is completely invisible to everything above it [the various
protocols (HTTP, FTP, Telnet, etc.), and even higher yet, the
application programs]. This is the simple and elegant solution.
----------------------------------------------------------------------

I almost 100% agree... If you check out the WEB servers, the list of
different authentication solutions is long... and to implement this
in each of the 3000 network services including the Internet Services
(Those found in the INETDCNF other than FTP & Telnet), the ARPA
Services (FTP and Telnet) and the NS Services (VT, RFA, RDBA, DSCOPY)
would be a huge amount of work.   If you only implement a few of the
more widely used solutions, then no matter which ones you select you
have left some one out.  It is apparent to me the best solution is at
the IP Transport layer where encryption can be performed without the
knowledge nor requiring any code change to any of the above services
(as long as their code does not reach below the services level
interacting directly with IP).

Almost 100% agree ???  Well security is always a 2 edged sword, the
best way to secure data is to power down the disk and an stick it in
a vault (it is 99.9 % secure and 0.1% accessible).  By adding
security at the IP level we increase the security of the data
significantly and decrease the accessibility of the data in some
cases.

The specific example that comes to mind is the goal is to prevent the
data to be viewed by hackers who are tracing the line/link and this
goal will be addressed by this solution until a point in time where
the hackers are able to plug in the IP level encryption routine into
their tool.  I assume it is not our goal to prevent HP or others to
trouble shoot network failures and the problem now is that tools
similar to that used by hackers are used by network engineers to
investigate network and services level problems. The IP level security
implementation would render LAN Protocol analyzers and System Link
trace as useless for capturing any data above IP.  All TCP and UDP
headers would be encrypted and unreadable by the existing linktrace
tools.  All Service level headers FTP, Telnet, VT, RFA, NFT, etc.
would be encrypted and unreadable by existing link trace tools.  It
would be necessary to write and improve the existing tools which would
interface at the level above the IP encryption to support the ability
to trouble shoot network failures.

Even with the noted difficulty of investigation of network failures,
the IP level encryption is the way to go.  The functionality
outweighs the cost, we just have to keep in mind that additional tools
are necessary to support this implementation.

Regards,

James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.

ATOM RSS1 RSS2