RE: EDI over http?

["Carl Hage" <carl@xxxxxxxxx>]

> From:          Peter Rawlinson <PeterR@xxxxxxxxxxxxx>

> I think the use of IP connection could run into some difficulties.  I
> can't immediately see the benefit in using a new port, when HTTP is a
> well established medium for 'dropping off' information over 80.  Company
> firewall policy will be far more 'agreeable' over the established port
> 80, rather than a 'proprietary' standard which adopts IP connection over
> another designated port.  Additional testing would have to be conducted
> to confirm prevention of malicious acts using this port.

I think the opposite might be true. An EDI system should really be 
separated from the more general purpose HTTP systems, and using a 
separate machine and separate port (the number doesn't matter) for 
firewall filtering provides the best security.

There is nothing magic about port 80-- it's simply a parameter in a 
firewall-router. Company policy should be in securing access, and if 
separating a port for important financial transactions improves 
security, they would prefer to do that.

You don't need to test some other port running plain (secured) 
X12/EDIFACT packets, other than of course testing the X12/EDIFACT 
message processing. This wouldn't be a proprietary standard-- just 
elimination of unneeded overhead, and the potential security or other 
problems associated with the overhead processing. Instead of being 
able to break an HTTP server and CGI gateway software, an attacker 
could only break the X12/EDIFACT processor, which could be done as 
well via CGI gateway.

Actially, HTTP servers and CGI processing in particular, are common 
sources of security problems, since they are quite complex. Every now 
and then problems are fixed in HTTP servers, and many people running 
default distributions (e.g. NCSA) ran CGI programs that allowed 
remote access. Famous hacks like the CIA site were due to HTTP 
server breakins.

Email is more secure in general than HTTP, and most security problems 
are related to the notoriously complex sendmail program. 
Sendmail does message translation and forwarding-- not needed 
for EDI use.

I would see a firewall as having port 80 access (incoming, plus 
outgoing proxy) to an HTTP server, plus a separate port to a separate 
isolated machine for EDI use. The EDI system is separately isolated 
from the corporate LAN/Intranet, including the HTTP server and
independent of the Internet firewall (though could be done by the 
same router). Basically you want a separate secured "room" with only 
one small "hole" to pass EDI application level interchanges. A 
separate machine or another "hole" would be used for general EDI 
support via SMTP (AS1). Everybody is isolated from this system, 
including others in the corporation. (Inside jobs are >10X more 
common than outside hacks.) I see a HTTP/CGI interface using the same 
real-time EDI exchange as a means to link HTTP services with a 
secured transaction processing system.

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

> From:          Dave Darnell <dave_d@xxxxxxxxxxxxx>

> But what about PPTP (Point to Point Tunneling Protocol) or IPSec
> where you could have multiple secure IP connections?

PPTP, IPSec, and SSL all provide a somewhat transparent layer of 
security over basic IP messaging. Either a private secured net (e.g. 
within a computer room), or one (or more) of these security layers 
allows the direct real-time application-application linkage provided 
by IP. These aren't incompatible, and one can be used in lieu of 
another. From the application programming point of view, these are 
all basically just IP, with some minor differences in initializing 
library subroutine calls.

However, with all these, some provision should be made for sending 
digital signatures or exchanged data (for general data-- not 
protocol/message specific), for purposes of non-repudiation. A simple 
extension can be made to SSL, and I'm not sure of the others.

I think an advantage of SSL over IPSec or PPTP is that SSL is a layer 
on top of regular IP and can be intergrated with an application 
program sold to third parties. IPSec or PPTP have thier advantages 
(mostly for other uses than TP-TP erchange), but are more integrated 
with the guts of IP and/or routers. You can use PPTP, of course, but 
it's main use is subnetwork-subnetwork linkage rather than 
application-application, which is the only thing SSL provides.

-----

> From:          Rik Drummond <drummond@xxxxxxxxxx>
> Good points....Ya know,  this establishes the secure process to
> process connection, but does not establish the protocol for the
> exchange of the data objects. Would we not have to establish a new
> protocol or use something like smtp, esmtp, http, or ftp inside of
these?

X12 and EDIFACT already have almost everything needed for messaging, 
e.g. a header, some data, and a terminator. A new data protocol isn't 
needed, but an administrative/procedural protocol needs to be defined 
to know when to drop the connection and for acknowledgement.

Of course, if you define some port for EDI, you can't just send any 
general "data objects"-- it must be for something specific, e.g. 
limited to X12 and/or EDIFACT interchanges. Someone could define some 
new future protocol, in which case that might need a separate port or 
wrapper that defines the data objects. But new future protocols don't 
exist yet, and we don't need any overhead for the protocols we do 
have, like X12 or EDIFACT, which are fairly complete. (I think HL7 
has it's own IP level messaging included in the standard.)

This, of course, only applies to TPs with IP connectivity, and a 
protocol like AS1 is needed for general store-and-forward, gateway 
systems, and off-line or part-time processing.

To use plain X12, for example, there could be an agreement for 
exchanges over IP (with security layer of some sort):

  - TP listens for connections on IP port XXX.
  - Sender initiates connection and writes the X12 interchange to
    the socket.
  - Sender waits and reads an interchange as a reply. If no reply is
    received within a timeout period, assume a failure, drop and 
    retry.
  - Recipient accepts a connection, and reads the X12 interchange 
    data.
  - Recipient responds with an interchange containing a 997 
    Functional ACK, and optionally another transaction, e.g. a
    PO Reply, in response to the interchange.
  - Sender reads the reply interchange, and checks the transactions.
  - If the reply contains only a 997, the sender drops the 
    connection.
  - If the reply read by the Sender contains a non-997 transaction,
    the role of Sender-Recipient reverses, and processing continues
    as described above, where the original Sender must respond with
    a 997 and optional additional message in the "conversation".

Here, 997's are used in lieu of transport protocol ACKs or SMTP MDN 
receipts. The ACK goes all the way into the EDI translator, and 
provides EDI (X12) specific info on the interchange status. Here we 
require 997s in all cases. If necessary, an EDI-IP server could 
generate dummmy success 997's if an EDI translator didn't generate an 
error 997.

Other EDI protocols, including any new real-time conversational EDI, 
need to include some sort of ACK and definition of the type of reply 
required.

Defining the length or end of data in a transfer protocol isn't 
needed, since these are already part of the X12/EDIFACT interchange.

The protocol defined above might also be used with a SMTP or HTTP 
gateway machine, which passes the interchanges to a secured 
transaction processing system between the SMTP messaging system or 
WWW end-user GUI. The EDI system uses raw X12 over IP on machines 
isolated from the net servers which handle transport layers, email 
exchanges, MDN reciept generation, etc., or provides user-level 
human-machine transactions, e.g. via plain ASCII email or WWW.

BTW, there is a separate issue on establishing a TP relationship, 
e.g. how can a new customer just start a transaction without having 
lawyers on both sides spend a week faxing documents back and forth.
This goes beyond a transport protocol, though, and gets into some 
limitations with X12/EDIFACT. I suppose regular WWW might be good for 
manually setting up a TP relationship, and a CGI script could return 
a customer ID that can be used in X12/EDIFACT exchanges. 
Unfortunately X12 can't use the unique internet email IDs as 
TP identifiers due to length limitations.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@xxxxxxxxx> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086