comprehensive enterprise fleet...
TRANSCRIPT
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
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 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.
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 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.
1. RCG-S Pro initiates communication.
2. Mutual authentication via electronic certificate takes place between RCG-S Pro and 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.
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 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.
1. RCG-S Pro initiates communication.
2. Mutual authentication via electronic certificate takes place between RCG-S Pro and the
Center Communication Server.
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.