Comprehensive Enterprise Fleet...

Comprehensive Enterprise Fleet Management

An Overview of Remote Communication Gate S Pro

(RCG-S Pro) for @Remote Enterprise Pro with the

@Remote Connector Option

Detailed information on capabilities

and functionality of RCG-S Pro with

the @Remote Connector Option

[A companion @Remote Enterprise Pro On-Site

white paper is also available.]

Produced by the Global Technology Support Section

Ricoh Company, Ltd.

May 2010

1.0 Overview

1.1 Today’s Customer Environment

1.2 @Remote and IT

1.3 Advantages of RCG-S Pro with the @Remote Connector Option for Network-Connected Printing Devices

1.4 RCG-S Pro OnSite and @Remote Connector Option Specifications

2.0 System Structure Of RCG-S Pro With @Remote Connector Option

3.0 Communication Methods and Information Security

3.1 HTTPS Communication Between RCG-S Pro and Connected Devices

3.2 SNMP Communication Between RCG-S Pro and Connected Devices

3.3 Communication Between RCG-S Pro and the Center Communication Server

3.4 Device Connection Check

3.5 Updating Firmware

3.6 AutoDiscovery

4.0 Appendix

4.1 Device Information

4.2 @Remote Protocols and Open Ports

4.3 Cryptographic Algorithms of HTTPS

4.4 Network Traffic and Communication Timing

5.0 Frequently Asked Questions

The content of this document, and the appearance, features and specifications of Ricoh products and services are subject to change from time to time without notice. While care has been taken to ensure the accuracy of this information, Ricohmakes no representation or warranties about the accuracy, completeness or adequacy of the information contained herein,and shall not be liable for any errors or omissions in these materials. Your actual results will vary depending upon your useof the products and services, and the conditions and factors affecting performance. THERE ARE NO GUARANTEES THATYOU WILL ACHIEVE RESULTS SIMILAR TO OURS. The only warranties for Ricoh products and services are as set forth in theexpress warranty statements accompanying them. Nothing herein shall be construed as constituting an additional warranty.Ricoh does not provide legal, tax, accounting or auditing advice, or represent or warrant that our products orservices will GUARANTEE OR ENSURE COMPLIANCE WITH ANY LAW, REGULATION OR SIMILAR REQUIREMENT. Customeris responsible for making the final selection of products, solutions and technical architectures, and for ensuring its owncompliance with various laws such as the Gramm-Leach-Bliley Act, the Sarbanes-Oxley Act and the Health InsurancePortability and Accountability Act (HIPAA).

Table of Contents

1.1 Today’s Customer Environment

Although potential for growth has never been larger, this is a challenging time for companies

everywhere. Worldwide opportunities mean global competition, and businesses that want to stay

ahead face complex tasks. Not the least of which is how to cut costs while staying abreast with the

relentless pace of changing technology.

Business is under ever-growing pressure to improve the quality and decrease the turnaround time

of their products and services. Much of the success or failure of a business depends directly on the

quality of the equipment and services at its disposal. In a large business environment especially,

administration of the print fleet is becoming more and more important. Weak maintenance and lack

of intelligent system management can negate the advantages of quality equipment and staff.

Add to this the fact that the IT manager’s workload is increasingly complex, as administration duties

and IT development expand. Pressure to get the maximum from networked print devices has never

been greater. Control over devices is an elemental factor of network efficiency, since this is key to

TCO (Total Cost of Ownership – the sum of three costs: start up, control/administration, and operation).

Also, as competition intensifies, business system costs have grown in significance and are now a

major management priority.

The challenge for IT is to reduce time lost on equipment maintenance, configuring, servicing,

supplying and monitoring. It is to relieve dependencies on users for reports on device population,

utilization trending status or malfunctions. Reports that unfailingly come after the problem has

occurred and understandably often lack the technical detail necessary for a prompt assessment

and solution.

To counter precisely these obstacles, an ideal remote servicing system would be capable

of the following:

• Detecting problems before users will become aware of them — to tackle firmware and reboot

remotely, with minimal user intervention.

• Identifying and pre-diagnosing potential breakdowns or shortages. Technicians could then be

dispatched, fully equipped with the necessary parts.

• Monitoring device population, trending performance and making whatever modifications necessary

to optimize productivity and efficiency.

• Watching over toner consumption, and enabling re-order before toner runs out.

• Providing TCO-relevant data to the administrator.

• Establishing an automated, usage-based meter submission and billing system to streamline

running costs.

1

Overview

Section 1.0

2

Section 1.0

1.2 @Remote and IT

@Remote is designed to be capable of exactly these functions. Its purpose is to provide five related

enhancements to your fleet of networked printing devices:

1. IT equipment maintenance capabilities, including status, critical service event notification, toner

alert notification and supply ordering and delivering.

2. IT equipment productivity improvement, by maximizing device utilization and aligning the right

devices with applications.

3. IT cost reduction, including initial outlay for equipment, maintenance and operation costs such

as monitoring device monthly volumes.

4. IT usability to the networked print population at the fleet or device level.

5. Green Reporting to determine whether the networked print fleet meets environmental and

cost-saving expectations.

The solution is the Ricoh Remote Communication Gate S Pro (also known as RCG-S Pro or @Remote

Enterprise Pro) with the @Remote Connector Option.

To limit the downtime of each kind of networked device (multifunction products, laser printers), it is of

growing necessity that IT deploys systems and tools to help manage these devices. RCG-S Pro with the

@Remote Connector Option provides for this, allowing users to benefit from improved business productivity,

automation of select maintenance processes and the reduced costs associated with these activities.

Utilizing RCG-S Pro with the @Remote Connector Option, IT administrators can map, monitor and

configure devices, as well as automate service alerts, toner alerts, meter collection and submission and

perform remote firmware upgrades. This option also provides secure, Web-based access to fleet reports.

Green Reports provide a view to select environmental aspects of print activity —

such as paper and energy usage — for Ricoh managed devices.

3

Section 1.0

1.3 Advantages of RCG-S Pro with the @Remote Connector Option for Network-Connected Printing Devices

There are four broad features of RCG-S Pro with the @Remote Connector Option that make it

particularly advantageous for users:

1. Reduced Device Downtime via automated email notification of critical service events to the

service provider through an Internet connection. Users can print or copy with little worry about

incomplete jobs or being delayed due to maintenance and repairs. And the organization is freed

from time-consuming manual device monitoring and expenses associated with downtime. The

solution can also perform remote firmware upgrades or, if necessary, alert dispatch personnel.

2. Automated Meter Collection and Submission so that users no longer have to manually collect

and report meter figures. This means production efficiency can be measured directly, meter figures

confirmed and TCO-relevant data obtained and acted upon. In the past, the traditional meter

collection procedure involved:

1. The service provider requests the user to check the meter(s).

2. The user checks the device’s meter.

3. The user reports the meter figure by postcard, telephone or online.

4. The service provider sends an invoice for actual usage.

Section 1.0

4

With RCG-S Pro and the @Remote Connector Option, workload is dramatically reduced and efficiency

is greatly increased.

1. RCG-S Pro collects and submits the meter information to the service provider

automatically. Human touch is eliminated.

2. The service provider sends an invoice for actual usage.

3. Receive Alerts when Toner Nears End automatically when toner levels are at near end or

depleted. Formerly, the process was:

1. Device runs out of toner. User calls the service provider.

2. The service provider requests toner delivery from the delivery center.

3. The delivery center delivers the toner to the user.

With RCG-S Pro, the @Remote Connector Option and a qualified service provider, the user no

longer has to worry about devices running out of toner. The device can alert the service provider

when 10% of toner is remaining. Depending on the capabilities of the service provider, even more

automation is available.

4. Device Monitoring by RCG-S Pro to gather information on device/fleet population, utilization,

operational status and trending. In many cases, IT managers have to utilize each vendor’s management

software to monitor devices and prevent potential issues. RCG-S Pro not only automatically

monitors Ricoh devices but also those of other providers to keep track of device/fleet population.

AtRemote.net device monitoring reports offer a variety of print fleet views

including vendor population by units and prints.

Monthly trending reports from AtRemote.net show page volumes by vendor with

drill down detail to an individual device.

5

Section 1.0

1.4 RCG-S Pro OnSite and @Remote Connector Option Specifications

@Remote Enterprise Pro (RCG-S Pro) OnSite

OnSite Dedicated Server

6

Section 1.0

SNMP Trap Real-Time

Database SQL Express 2005

Grouping Manual

Batch Configuration Yes

Counters Detailed (for most Ricoh devices); Total Print Counter for third-party networked devices

Device Mapping Yes, with user-supplied .jpg file

Hardware CPU: Pentium 4 2.8GHz Hyper-Threading support or better recommended

Memory: 1 GB or more minimum; 2 GB or more recommended whenmanaging 1,000+ devices or when using the optional @Remote Connector

Free disk space: OS recommended space + 10 GB

Server must utilize an intelligent UPS (Uninterruptible Power Source).

The server running the @Remote Connector should not be powered down without completing the normal Windows Server operating systemshutdown procedure.

Operating Systems Windows Server 2003 Standard Edition/Enterprise Edition SP2 or later; Windows Server 2003 R2 Standard Edition/Enterprise Edition SP2 orlater; Windows Server 2008 Standard Edition/Enterprise Edition (only 32 bitOS is supported)

Browser Microsoft Internet Explorer 6 (SP1), 7 with Java Script

Screen Resolution 1024 x 768 or more

Network TCP/IP must be installed and configured correctly (only IPv4 is supported);100Mbps or more network speed is recommended; Internet connection isrequired to use the RFU and @Remote functions

Virtual Server VMware Infrastructure 3 Standard Edition

Database SQL Server 2005 Express Edition SP2 or later; .NET Framework 2.0 must be installed before installing SQL Server 2005; .NET Framework 2.0is not included in the server installer; Please download it using WindowsUpdate or from Microsoft’s Web site

Web Server Apache 2.0.48; Apache is included in the server installer

IIS 6.0 or later; IIS is not included with the server installer; install IIS before installing the server

Flash Player Adobe Flash Player 9.0 or later

Section 1.0

7

OnSite Client

Printer and Multi-function Device Requirements

@Remote Connector Options

Hardware CPU: Pentium 500MHz recommended

Memory: 128 MB recommended

Operating Systems Windows 2000 Professional/Server/Advanced Server SP4 or later; Windows XP Home/Professional SP2 or later; Windows Server 2003 Standard Edition/Enterprise Edition SP2 or later; Windows 2003 R2 Standard Edition/Enterprise Edition SP2 or later; Windows VistaUltimate/Enterprise/Business/Home Premium/Home Basic; Windows Server 2008 Standard Edition/Enterprise Edition SP2 or later

Supported Browser Microsoft Internet Explorer 6 (SP1), 7

Screen Resolution 1024 x 768 recommended

Flash Player Adobe Flash Player 9.0 or later

Network Protocol TCP/IP

Standard MIB Printer MIB (RFC 1759); MIB-II (RFC 1213); Host Resource MIB (RFC 2790)

Interfaces 10/100MB Ethernet (802.x.x compatible); Wireless LAN devices (802.x.x compatible); IP over 1394

Toner Alerts

Service Alerts

Automated Meter Submission

Remote Firmware Upgrade

Access to Fleet Reports (for most Ricoh devices)

Communicate to atremote.net

RCG-S Pro with the @Remote Connector Option is an interactive system, allowing data to flow

between two main components:

1. The RCG-S Pro software installed on a server at the customer’s location. This server acts as a relay

unit through which all networked devices (MFPs, printers, copiers) communicate.

2. The Center Communication Server, a Ricoh facility where the RCG-S Pro data is received and

hosted.

Note that communication to and from the RCG-S Pro server to the Center is limited only to @Remote

technology systems. No other system will communicate with the RCG-S Pro server. Also, no system,

including the Center Communication Server, can initiate communication to the RCG-S Pro server.

The RCG-S Pro server always initiates outbound communication.

8

System Structure of RCG-S Pro with the @Remote Connector Option

Section 2.0

9

Communication Methods and Information Security

Section 3.0

RCG-S Pro utilizes two communication methods to communicate between devices and the Center

Communication Server – HTTPS (Hyper Text Transfer Protocol Security) and SNMP (Simple Network

Management Protocol).

It is also important to note that communication between the RCG-S Pro server and the devices is

available in two modes: Monitored or Managed. In Monitored mode the RCG-S Pro server provides

AutoDiscovery, automates meter collection/submission and allows access to the atremote.net secure

fleet reporting Web portal for discovered devices. Managed mode includes the same capabilities as

Monitored mode plus automated alerts for critical service events, automated toner alerts, remote

firmware upgrades and “Green Reports” via the atremote.net Web portal for managed, network-

connected Ricoh devices.

3.1 HTTPS Communication Between RCG-S Pro and Connected Devices

HTTPS communication takes two forms:

I. Access from devices to the RCG-S Pro server via HTTPS PKI (Public Key Infrastructure). For example,

a service emergency alert such as device failure or low toner/toner out.

1. When there is a device alarm, the device initiates authentication in real time via electronic

certificate with RCG-S Pro.

2. Devices send device failure call information to RCG-S Pro by HTTPS Post Request.

3. The RCG-S Pro confirms receipt of device failure call information by sending back the

result via HTTPS Response.

II. Access from the RCG-S Pro server to device via HTTPS PKI. For example, meter counter information

and service information (device settings, historical data, etc.)

1. When the RCG-S Pro is initiating, authentication via electronic certificate takes place

between RCG-S Pro and the devices.

2. The RCG-S Pro sends the obtain counter information request to devices using HTTPS

Post Request.

3. Devices confirm receipt of the counter information request by sending back the meter

information via HTTPS Response.

HTTPS-related information for connected Ricoh-compatible devices includes:

1. RCG-S Pro to device communication (and vice versa) is in Secure Socket Layer (SSL) format.

2. Data is encrypted. RCG-S Pro supports cipher RC4-MD5 128 bits. However, if the device supports

only a DES 56 bits key, the encryption level will be reduced to a DES 56 bits key. This key is created

and changed for every session.

3. Both RCG-S Pro and the devices have RSA 512 bit certificates for @Remote and use security

authentication checks.

4. For each communication, a mutual authentication procedure is completed before the data is sent.

The RCG-S Pro server recognizes and communicates only with devices that have a printer MIB

(Management Information Base). Also, print devices connected to print servers or client PCs

are not discovered.

10

Section 3.0

11

Section 3.0

3.2 SNMP Communication Between RCG-S Pro and Connected Devices

Utilizing SNMP communication, device MIB information is obtained by periodic polling from the

RCG-S Pro server to the device. For example, meter counter information and a service emergency

alert such as device failure or lower toner/toner out. The default setting for polling is 10 minutes.

1. Devices obtain counter information request OIDs from the RCG-S Pro via SNMP Request.

2. Devices send back their counter information via SNMP Response.

3.3 Communication Between RCG-S Pro and the Center Communication Server

Only one type of communication method is used between the RCG-S Pro server and the service

provider’s Center Communication Server – an HTTPS Internet connection. As with HTTPS

communication between the RCG-S Pro server and connected devices, HTTPS communication

between the RCG-S Pro server and Center Communication Server utilizes encrypted data in an SSL

format. Both servers perform security authentication checks. Before communicating, a mutual

verification procedure is completed before the data is sent. Also, because communication can only be

initiated from the RCG-S Pro server to the Center Communication Server, it is not necessary to open

an additional port for HTTPS reception from outside the customer’s firewall. HTTPS communication

utilizes Port 443 (See Appendix 4.2).

HTTPS communication is initiated from the RCG-S Pro server to the Center Communication Server for

two reasons:

I. Critical Service Alerts such as device failure or low toner/toner out.

1. RCG-S Pro initiates communication.

2. Mutual authentication via electronic certificate takes place between RCG-S Pro and the

Center Communication Server.

3. The RCG-S Pro sends device failure call information to the Center Communication Server

via HTTPS Post Request.

4. The Center Communication Server confirms receipt of device failure call information by

sending back the result via HTTPS Response.

Note: Normally, polling between the RCG-S Pro server and Center Communication Server is performed

once an hour. However, when the Center Communication Server receives specific call information

(such as a device service call), the polling interval is changed to once a minute. After the Center

Communication Server receives a Service Call Reset, the polling interval is reset to once an hour.

12

Section 3.0

13

Section 3.0

II. Meter Counter Collection




3. The RCG-S Pro sends polling information to the Center Communication Server via

HTTPS Post Request.

4. The Center Communication Server confirms receipt of polling information by sending

back the result to the RCG-S Pro via HTTPS Response along with further counter

information request commands.

5. The RCG-S Pro, when the counter information request commands in the HTTPS Response

are processed, responds to the Center Communication Server after initializing mutual

electronic certificate authentication.

6. The RCG-S Pro send its response to meter information back to the Center

Communication Server via HTTPS Post Request.

7. The Center Communication Server confirms receipt of response by sending back the

result via HTTPS Response.

3.4 Device Connection Check

Between RCG-S Pro and devices via HTTPS:

1. Mutual authentication takes place between RCG-S Pro and the device.

2. An ID2 request is sent from RCG-S Pro to the device via HTTPS Post Request.

3. The device sends back ID2 information to RCG-S Pro via HTTPS Response.

Between RCG-S Pro and devices via SNMP:

1. RCG-S Pro performs serial number information request OIDs via SNMP Request. (Ricoh

devices provide serial number information. Third-party devices provide a MAC address.)

2. Devices send back serial number information via SNMP Response.

14

Section 3.0

15

Section 3.0

3.5 Updating Firmware

RCG-S Pro with the @Remote Connector Option has the ability to update device firmware for Ricoh

managed devices via HTTPS broadband Internet connection. In order to do so the following

equipment is utilized:

• The Center Communication Server, which manages communication between RCG-S Pro and

devices, obtains the required firmware version, and completes updates on the requested

implementation date.*

• The RCG-S Pro Server to acquire firmware data from the Ricoh Global Server and transfer the data

to the target device.

• The Ricoh Global Server to warehouse the firmware versions.

• The device for the firmware update.

* Firmware updates can be implemented at any specified time, such as after working hours. One or multiple firmware versions can beupgraded or downgraded in a scheduled session.

The request to update device firmware process is as follows:

Steps 1 & 2 RCG-S Pro initiates communication to the Center Communication Server to request any

device firmware updates. The Center Communication Server responds to the RCG-S Pro server for a

list of target devices requesting firmware updates and the date of the scheduled update.




3. The RCG-S Pro sends polling to the Center Communication Server via HTTPS Post Request.

4. The Center Communication Server confirms receipt of polling by sending back the

request to update firmware information via HTTPS Response.

5. The RCG-S Pro sends a response to the request to update firmware to the Center

Communication Server via HTTPS Post Request.

6. The Center Communication Server sends an HTTPS Response.

Note: Communication between RCG-S Pro and the Center Communication Server is initiated only by

the RCG-S Pro.

Step 3 When the date of the scheduled update is reached, RCG-S Pro acquires the firmware data

from the Ricoh Global Server via the Center Communication Server.




16

Section 3.0

17

Section 3.0

3. RCG-S Pro sends a request for firmware information to the Ricoh Global Server via HTTPS

Get Request.

4. The Ricoh Global Server confirms receipt of request for firmware data by sending back

the result to the RCG-S Pro via HTTPS Response along with further firmware data request

commands.

Note: It is not necessary to open a port for HTTPS reception from outside the customer’s firewall

because the Center Communication Server is not initiating communication through the customer

firewall.

Steps 4 & 5 For access from RCG-S Pro to devices, RCG-S Pro sets up the device ID and password

via FTP login. A connection is made when the ID and password are correct. Updated firmware is then

sent to the device via FTP and a response is sent if the firmware data was received. The device also

sends a boot notification to the RCG-S Pro server to automatically reboot after the firmware update.

1. Send ID and password via FTP login.

2. Connection is made when ID and password are correct.

3. Send firmware data to the device via FTP.

4. Receive response if firmware data was received via FTP.

5. When there is a device alarm, the device initiates authentication via electronic certificate

with RCG-S Pro.

6. Devices send boot notification information to RCG-S Pro by HTTPS Post Request.

7. RCG-S Pro confirms receipt of boot notification information by sending back the result via

HTTPS Response.

Step 6 RCG-S Pro sends the results of the firmware update to the Center Communication Server.




3. The RCG-S Pro sends notification of the results of updating the firmware version of the

device to the Center Communication Server via HTTPS Post Request.

4. The Center Communication Server confirms receipt of response to the notification of the

results of updating the firmware version of the device by sending back the result to the

RCG-S Pro via HTTPS Response.

3.6 AutoDiscovery

With AutoDiscovery, the RCG-S Pro can automatically discover network-connected devices and —

with the @Remote Connector Option — encrypt and send information (e.g. Printer MIB, meter data)

to the Center Communication Server via a secure HTTPS connection. RCG-S Pro collects device

information from devices which are specified by identifying selected network segments in the

Discovery Settings menu of the user interface for RCG-S Pro.

The following intervals can be set for RCG-S Pro AutoDiscovery:

Execution interval Set value Note

Once per day Time: 0:00–23:59 Example: 13:00

Once per week Day: Sunday–Saturday Example: 12:00, SundayTime: 0:00–23:59

Once per month Day of month: 1–28th Example: 9:00, the 20thTime: 0:00–23:59

Note: The factory default setting is “Not Used.” If the device is without electrical power or is not

connected to the network, no device information will be obtained.

18

Section 3.0

19

Section 3.0

Traffic utilization with the RCG-S Pro server is also negligible.

*Data size is doubled when using SSL communication.

SNMPThe AutoDiscovery process between the RCG-S Pro server and device is shown below. Device MIB

information is obtained from periodic RCG-S Pro to device polling.

1. Devices obtain counter information request OIDs from RCG-S Pro via SNMP Request.

2. Devices send back their counter and device information via SNMP Response.

Traffic Size & Communication Timing via SMNP for Meter Data

Between Device & RCG-S Pro Approx 4 KB or less per device traffic size

User set communication timing

Between RCG-S Pro & CenterCommunication Server

Approx. 4 KB or less per message traffic size*

Approx. 8 KB after the device data is captured

HTTPSThe following diagram depicts the procedure to securely transmit stored device data on the RCG-S Pro

server to the Center Communication Server. The device information acquired via SNMP is stored with

RCG-S Pro temporarily and then notified collectively by the following procedures for every ten devices.




3. RCG-S Pro sends polling information to the Center Communication Server via

HTTPS Post Request.

4. The Center Communication Server confirms receipt of polling information by sending

back the result to the RCG-S Pro via HTTPS Response along with further counter

information request commands.

5. RCG-S Pro, when the counter information request commands in the HTTPS Response are

processed, responds to the Center Communication Server after initializing mutual

electronic certificate authentication.

6. RCG-S Pro sends its response to counter information back to the Center Communication

Server via HTTPS Post Request.

7. The Center Communications Server confirms receipt by sending back the result

via HTTPS Response.

AutoDiscovery Network Security

20

Section 3.0

Security Concern HTTPS

Security Threat? Reason

Attack from outside of customer’s network NO No HTTPS server at customer location.Communication can only be initiated byRCG-S Pro from behind the customerfirewall.

Customer data security including:

• Unauthorized access

• Malicious data interference

• Illicit network monitoring

NO All data is transmitted in SSL protocolonly after both ends verify each other’sidentity and only to the address specifiedat setup. The data itself is also encrypted(cipher RC4-MD5 128 bits).

21

Appendix 4.1 – Device Information

Information obtained during the AutoDiscovery process:

• Select meter counters

• Controller/NIC version

• Model and vendor name

• MAC/Serial number

• IP address

Appendix

Section 4.0

Advantages Information Obtained Device Details

Reduces downtime

Alert Device failure call (jam, cover open, etc.)

Firmware Controller/NIC version

Automated counterchecking

Counter Total/copier, fax, printer/black & white, color counter

Toner alert Toner low, Staples out Toner end/near end

Device monitoring Device information Model name, vendor name, IP address, etc.

Appendix 4.2 – @Remote Protocols and Open Ports

RCG-S Pro Port Usage and Communication Methodologies

*User Datagram Protocol

Open Ports and Communication Methodologies

22

Section 4.0

No. Occasion Communication Direction Port. No. Protocol Type

1 RCG-S Pro is connecting todevice by FTP.

RCG-S Pro = > Device 20 FTP TCP

2 RCG-S Pro is sending firmwareinformation.

RCG-S Pro = > Device 21 FTP TCP

3 RCG-S Pro is capturing MIBinformation from device.

RCG-S Pro = > Device 161 SNMP UDP*

4 RCG-S Pro is sending notificationto Center Communication Server via HTTPS.

RCG-S Pro = > CenterCommunication Server

9443 HTTPS TCP

Device is sending notificationsuch as emergency call.

Device = > RCG-S Pro

CE/Service Technician isoperating RCG-S Pro via laptop.

CE’s Laptop = > RCG-S Pro

RCG-S Pro is requestingfirmware information.

RCG-S Pro = > CenterCommunication Server

5 RCG-S Pro is capturing deviceinformation.

RCG-S Pro = > Device 7443 HTTPS TCP

6 RCG-S Pro tries to communicatewith device for the first time.

RCG-S Pro = > Device 7444 HTTPS TCP

No. CommunicationType Communication Direction Port. No. Protocol Type

1 Device is sending notificationsuch as Emergency Call.

Device = > RCG-S Pro 9443 HTTPS TCP

CE/Service Technician operatesRCG-S Pro via laptop.

CE’s Laptop = > RCG-S Pro

Appendix 4.3 – Cryptographic Algorithms of HTTPS

Figure 1 below shows SSL negotiation with mutual authentication, client authentication and server

authentication. Steps are detailed on the following page.

Figure 1: SSL Handshake Change Cipher Protocol

23

Section 4.0

REMOTE COMMUNICATION GATE (CLIENT)

Client private key Certificate: RSA-512

Client public key Certificate: RSA-512

CA public key Certificate: RSA-512

Server private key Certificate: RSA-512

Server public key Certificate: RSA-512

CA public key Certificate: RSA-512

COMMUNICATION SERVER (SERVER)

(1) SSL version, Seed (random number),Supported cipher suite

(2) SSL version, Seed (random number), Session ID, Cipher used in the conversation

(4) Client Certificate Request

(5) Server Certificate Verify

(7) Pre master secret (Random number) generation

(9) Sign to data using client private key

(11) Session Key generation Cipher RC4-MD5 128 bits (RCG-S Pro V3.34 or later) with two seeds and pre master secret

(12) Client Certificate Verify Session Key generation Cipher RC4-MD5 128 bits (RCG-S Pro V3.34 or later)

(14) Finished/Session Start

(3) Server Certificate

(8) Pre-master secret

(6) Client Certificate

(10) Data with signature

(13) Finished

(1) The first step in the process is for the client to send the server a “Client Hello” message. This hello

message contains the SSL version and the cipher suites the client can talk and seed of random

number. The client sends its maximum key length details at this time.

(2) The server returns the hello message with one of its own in which it nominates the version of SSL

and the ciphers and key lengths to be used in the conversation, chosen from those offered in the

client hello.

(3) The server sends its digital certificate to the client for inspection.

(4) The server sends a client certificate request after sending its own certificate.

(5) The client verifies the server certificate.

(6) The client sends its certificate.

(7) The client generates a pre master secret and encrypts it using the server's public key.

(8) The client sends a pre master secret to the server.

(9) The client signs to data using client secret key.

(10) The client sends a “certificate verify message” in which it encrypts a known piece of plaintext

using its private key. The server uses the client certificate to decrypt, therefore ascertaining the

client has the private key.

(11) The client generates a session key with two seeds and pre master secret.

(12) The server verifies the client certificate. The server decrypts pre master secret using server private

key, and generates a session key.

(13) The client now sends a “Finished” message using the new key to determine if the server is able

to decrypt the message and the negotiation was successful.

(14) The server sends its own “Finished” encrypted message using the key. If the client can read this

message then the negotiation is successfully completed.

RCG-S Pro and the Center Communication Server have a 512 bit certificate. Therefore an RSA 512

bits cipher suite is used. For RCG-S Pro Ver. 3.34 and later an RC4-MD5 128 bits cipher is used for

encryption. When HTTPS method is selected, the session key (i.e. the encryption key for HTTPS) is

created each and every time.

Section 4.0

24

Appendix 4.4 – Network Traffic and Communication Timing

25

Section 4.0

Traffic Size & Communication Timing(By Device Type & Purpose)

Between Device & RCG-S Pro

Between RCG-S Pro &Center Communication

Server

SNMP Communication Meter Date Server Traffic Size Approx 4 KB or less perdevice before encryption

Approx 80 KB or less permessage (depending onthe # of devices)

CommunicationTiming

Every 24 hours polling asdefault

Daily/weekly/monthly (On the meter reading due date)/18:00-10:00local time

Failure Supply Call Traffic Size Approx 4 KB per device Approx 8 KB per device

CommunicationTiming

Every 10 minutes pollingas default

Real-time (right afterFailure Call/Supply Call is captured)

Device Connection Checkwhen Disconnected

Traffic Size Approx 1 KB perdisconnected device

CommunicationTiming

Search for thedisconnected device every 12 hours

HTTPS CommunicationDevice

Meter Data Traffic Size Approx 160 KB per device Approx 1.5 MB or less permessage (depending onthe # of devices)

CommunicationTiming

Every 24 hours polling as default

Daily at random times

Service Call/Supply Call Traffic Size Approx 100 KB per device Approx 10 KB per device

CommunicationTiming

Real-time Real-time

Firmware Update Traffic Size Avg. 6 MB (Max 16 MBper firmware)

Avg. 6 MB (Max. 16 MBper firmware)

CommunicationTiming

Specified date and time Specified date and time

Device Connection Checkwhen Disconnected

Traffic Size Approx 1 KB perdisconnected device

CommunicationTiming

Search for thedisconnected device every 12 hours

Note: Although RCG-S Pro executes a connection check and collects device information from

monitored devices, only data from managed devices is sent to the Center Communication Server.

26

Frequently Asked Questions

Section 5.0

Q1. Should the RCG-S Pro be installed in a special location?

A. The RCG-S Pro does not require any specific location. Install it where you would IT servers.

Q2. How are RCG-S Pro settings protected?

A. Access is user name and password protected.

Q3. Should power to the RCG-S Pro normally be left on? What about power to devices?

A. Leave the server powered on, so the RCG-S Pro can collect device data at the times specified

during setup. Also, because it should remain connected, the RCG-S Pro is a server PC. Make

sure main power switches on devices are on (a device’s status cannot be read if its main

power is switched off).

Q4. How can I turn off the RCG-S Pro?

A. 1. Double-click “C:Program Files RMWSDMEX tool atremote_stop_manual.bat” to stop the

@Remote service in the server PC.

2. Confirm by Services in Server Manager that the @Remote service (DH AtRemoteService)

is stopped.

3. Shut down Windows by the normal procedure.

4. Unplug or turn off the power switch.

Q5. How can I turn on the RCG-S Pro?

A. 1. Plug in or turn on the server’s power switch.

2. Start up Windows by the normal procedure.

Note: Wait for about 30 seconds after Windows starts up, because you must wait until

RCG-S Pro is started and in standby.

3. Double-click “C: Program Files RMWSDMEX tool atremote_start_auto.bat” to start the

@Remote service in the server PC.

4. Confirm by Services in Server Manager that the @Remote service (DH AtRemoteService) is

started.

Q6. Is data that is sent out over the Internet secure?

A. Yes, because it is transmitted in SSL protocol after both ends verify each other’s identity, and

only to the address specified at setup. Also, for further security, the data itself is encrypted

between the device, RCG-S Pro and the Center Communication Server (encryption level is at

cipher RC4-MD5 128 bits).

• Communication between RCG-S Pro and the Center Communication Server uses the form

initiated by RCG-S Pro.

• Communication is never initiated from the Center Communication Server.

27

Section 5.0

Q7. What kind of data is received from the Center Communication Server?

A. When the Center Communication Server requires device information it sends a request

(status sense) for it.

Q8. Can any @Remote system communicate into the RCG-S Pro?

A. Initiated communication is from RCG-S Pro: To go through the firewall, the Center

Communication Server must send necessary information in reply to the signals sent

regularly from the RCG-S Pro (frequency specified at setup).*

* Communication is not initiated by the Center Communication Server.

Q9. Can viruses enter the user network when communicating over the Internet?

A. No, because communication occurs only within the limits of RCG-S Pro and the Center

Communication Server. Also, the data is sent in SSL protocol after mutual authentication

(virus checks are carried out before sending).

Q10. How many devices can RCG-S Pro monitor and manage?

A. Up to 5,000 managed devices can be registered to the Center Communication Server.

For AutoDiscovery, RCG-S Pro can monitor and manage a total of 5,000 devices per instance,

including those devices registered to the Center Communication Server.

Q11. What about traffic size on the user network and its communication timing?

A. Traffic size and its communication timing will differ depending on the communication data

type. Please refer to Appendix 4.4 for the detailed traffic size and its communication timing.

Q12. Is there any chance of obtaining the customer's server or client PC’s information via RCG-S Pro?

A. No. Information on the customer's server or client PC is never obtained via RCG-S Pro.

Q13. Does RCG-S Pro support a Token Ring environment?

A. No, it does not.

Ricoh Americas Corporation, Five Dedrick Place, West Caldwell, NJ 07006 © 2010 Ricoh® and the Ricoh logo are registered trademarks of Ricoh Company Ltd. All other trademarks are the property of their respective owners.

Comprehensive Enterprise Fleet...

Documents

Transcript of Comprehensive Enterprise Fleet...