Part of my job is to work on the design of new products. Do the overall architecture and some product management. To be good at this, I have to listen to our customers, partners and consultants. Therefore I like to be involved in consulting, especially for larger and complicated installations, so I can stay close to the needs and demands of the customers.

In this role, I am often confronted with the same basic problem: how do we have to lay out our network landscape (firewalls, networks, servers and appliances) to ensure a reliable and secure operation, even if we have to communicate with external partners.

In this post I want specifically talk about ISDN connections to your partners, because they are not very common and many firewall admins or security officers try to approach the problem with common IP network knowledge, which is often not the best way to solve this. Let me apologize in advance: this covers a broad topic and will be quite technical, I haven’t explained all the backgrounds, it requires good understanding of networking, and some XI knowledge.

ISDN Communication

First of all, let’s have a look why and how you would want to communicate with ISDN.  This is an easy one, using traditional EDI communication protocols (Point-to-Point, like OFTP or Mailbox based, like X.400 P7) is good in industries, where you can reach all your major suppliers and customers. For example in German retail the X.400 based mailbox service of the German Telekom (Telebox) is heavily used. In the Automotive industry you can reach all the OEMs and suppliers over OFTP. It is so successful, that all major banks in Germany also accept communication with OFTP (the Odette File Transfer Protocol). Of course, those protocols are older than the Internet Boom. The reason why they are still used is the ease of set up, and the comparable low risk of those connections. (You can set up a new partner within minutes of configuration. If you try to do this with inter-company VPN connections you may need to occupy network staff on both sides for days and the security officers will call you anything you can imagine.

So, we assume you have a customer, which suggests you to do an ISDN based data interchange connection, and you decide to exchange XML Documents or EDI data formats (EDIFACT or ANSI X.12). In both cases you need a technical Adapter for the SAP Exchange Infrastructure (XI) to speak the traditional EDI protocol. SAP offers a J2EE based Adapter Engine. From SEEBURGER you get the OFTP or  P7 Adapters, which are basically JCA standard based connectors to communication protocols.

ISDN Hardware

Because those adapters must be completely integrated into the adapter engine, and because the certification of the adapters requires vendors to support all platforms (on which XI is supported) there is a problem: how to access the ISDN hardware from within Java?

Well, in the non-java world there is a programming standard called CAPI, it is the Common ISDN API. Most of the hardware vendors who offer ISDN cards provide this dynamic library. However ISDN cards and the CAPI are not provided on all hardware architectures, and it is generally not a good idea to connect a mission critical server to a landline. So SEEBURGER has a wrapper to access the native shared libraries, but our preferred solution is the use of a TCP based network protocol called Virtual or Remote CAPI, which can access ISDN devices (router appliance, Line Servers) over the network. We have implemented this network protocol in pure Java (using simple Sockets). This allows separation of the ISDN Hardware and the server, it also allows to connect multiple servers to multiple routers. That way you can achieve redundancy: Software can switch the phone lines without line jacking. Since there is no native code executed in the Java VM no general protection fault can harm the operation of the adapter engine, and no buffer overflow can be exploited by intruders.

Generally we use Funkwerk Router (Bintec X- family) as the telemetric solution, which supports single BRI ISDN connections up to multiple PRI (60 channels). There is also PC Software which can turn a PC with ISDN cards into a Line Server. Current Software based PBX Systems (VoIP) sometimes also offer this functionality. We don’t recommend to use Cisco’s SoHo Line of routers, they don’t provide all the needed features.

Landscape

So how does the landscape look like? Well, first of all you have your backend networks. You most likely know your setup better then me (after all I am not a BASIS guy).

The XI Installation uses NetWeaver ABAP and J2EE parts on at least one central server called the integration server. IS is then connected to the backend systems for doing A2A (application integration with XML message routing). Most likely the adapters of the IS will connect to the backend systems through a saprouter. The IS is critical for internal operations, it must be separated from the applications which handle the remote communication. This is mainly to minimize the impact of a security problem. However since the B2B adapters are implemented in Java, you are quite safe anyway: no nasty buffer overflows in this code. But nobody is perfect, so rather be safe than sorry: place a filter between IS and the Adapter Engine(s) used to host the B2B adapters. Usually this engine is placed on a network segment like DMZ or secure server network.

Ok, so finally we need to talk about the placement of the ISDN router(s). Actually router is a pretty misleading word here. Those boxes can do classical routing (IP over dial up connections by PPP), but this functionality is not used by the Remote CAPI client. So you don’t have to fear malicious IP packets coming from that device to your network. The data stream from possibly un-trusted external endpoints is terminated directly in the adapter code. The adapter thinks it is directly talking to the ISDN card and handling the public network signals and data streams. Since this connection is transparent it basically means that the Adapter Engine and the ISDN appliance are exposed to the same risk, therefore can be placed in one network segment. However it is no problem to place a filter between both (for example if this is general company policy and you are not able to get a exception even if there is no gain from this separation). The filter also makes sense, if you use the appliance for real routing in addition to the EDI usage. The Adapter Engine will connect on a single TCP port to the appliance (username/password protected). Unfortunately you won’t find a Firewall which can intercept that traffic, so you have to use a generic TCP forwarding.

Content Security

A short note on content security: malicious data from your partners will be detected by the XML mapper of XI or by the EDI format converters of SEEBURGER. So there is really no need to run a malware scanner on that data. In fact: installing an on-access scanner on a production system is a big no-no IMHO. (Beware: if a file is rejected, because it is not valid syntax this data can contain malware, but system administrators are expected to delete it, it won’t be executed automatically, so it is harmless)

Wrap Up

  • Use dedicated Adapter Engines for those technical Adapters involved with external communication
  • Offload ISDN Hardware to an appliance
  • Firewall between Adapter Engine and Integration Server
  • Optionally Firewall between ISDN appliance and Adapter Engine
  • Firewall to Internet is  not used in this scenario

For futher reading I strongly recommend you check out the SAP Security Guides on XI and NetWeaver from the Service Marketplace, as well as the SEEBURGER Adapters Master Installation Guide (from the Adapter CDs).

This has become a long post, sorry folks. (I warned you). Please let me know if this was too hardcore. Look out for the next post, it will be based on this one, and discuss the additional considerations for IP based Inter-Company communication (AS2, ebXML MS, RNIF or Web Services).

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Dries Guth
    Hi Bernd,

    very nice to read your blog on this solution. Your analysis about the different positions of the ISDN hardware, the adapter engine and the integration in different parts of a system landscape without the need of a firrewall is very nice.

    Some technical questions on the socket connection to the RCAPI Router: How did you handle the aspect that you can know over a tcp/ip java socket if the Router is still alive? How could you guarantee with the adapter inside the adapter engine, that the router is still running?

    Another question is, how did you handle muliple calls on one router? Is it even possible that the router can distiguish between different ncoming calls and send it to different connected sockets, connected on the router?

    Hope to stay in contect with you, it is nice to here, what your favours are and to háve everytinme an ear on the customers wishes and needs in the technical sector.

    Best regards

    (0) 
    1. Bernd Eckenfels Post author
      I am not too deep into the implementation, so I might be wrong 🙂

      Besides the usual TCP keepalive protocol the Remote CAPI protocol is kind of record oriented. You can send nop-capi commands to the router (“version request”).

      The socket will be teared down if the connection (or router) does not deliver an answer. The adapter is doing that check with one or multiple telematic servers.

      The complete ISDN signalling data (MSN, Call user data, service type, caller id, etc) is transmitted as a incoming call record to the listening application (actually to multiple listening applications). The application can then screen that call record and issue a “answer call” command – or not.  This way you can configure the adapter to accept some calls, but not others. typically you dont answer voice calls for example).

      However, the application is also requied to log into the router, and you can actually maintain a list of MSN endpoints associated with users. So you can have a production and test isdn number, the router listens to both and routes the rings only to applications conencted as the specific user. (i might be wrong on the later, you have to check the router handbooks)

      # Hope to stay in contect with you, it is nice to # here, what your favours are and to háve
      # everytinme an ear on the customers wishes
      # and needs in the technical sector.

      You can also mail me offlist, I am curious what product or service your company is offering… rcapi servers?

      (0) 
  2. Bernd Eckenfels Post author
    I am not too deep into the implementation, so I might be wrong 🙂

    Besides the usual TCP keepalive protocol the Remote CAPI protocol is kind of record oriented. You can send nop-capi commands to the router (“version request”).

    The socket will be teared down if the connection (or router) does not deliver an answer. The adapter is doing that check with one or multiple telematic servers.

    The complete ISDN signalling data (MSN, Call user data, service type, caller id, etc) is transmitted as a incoming call record to the listening application (actually to multiple listening applications). The application can then screen that call record and issue a “answer call” command – or not.  This way you can configure the adapter to accept some calls, but not others. typically you dont answer voice calls for example).

    However, the application is also requied to log into the router, and you can actually maintain a list of MSN endpoints associated with users. So you can have a production and test isdn number, the router listens to both and routes the rings only to applications conencted as the specific user. (i might be wrong on the later, you have to check the router handbooks)

    # Hope to stay in contect with you, it is nice to # here, what your favours are and to háve
    # everytinme an ear on the customers wishes
    # and needs in the technical sector.

    You can also mail me offlist, I am curious what product or service your company is offering… rcapi servers?

    (0) 

Leave a Reply