Browse Prior Art Database

Wake-Up Event Management for Power Managed Servers

IP.com Disclosure Number: IPCOM000124003D
Original Publication Date: 1999-Sep-01
Included in the Prior Art Database: 2005-Apr-05
Document File: 3 page(s) / 164K

Publishing Venue

IBM

Related People

Callender, R: AUTHOR

Abstract

It is well known that the best security method to prevent unauthorized access to a server during off-hours is to "turn it off." The problem with this simplistic solution is that it denies access to authorized off-hours workers.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 50% of the total text.

Wake-Up Event Management for Power Managed Servers

   It is well known that the best security method to prevent
unauthorized access to a server during off-hours is to "turn it
off." The problem with this simplistic solution is that it denies
access to authorized off-hours workers.

   Most SHV servers are now required to support some form of
Power Management (PM), usually following either the APM or ACPI
specification.  Power-Managed servers (for example branch-office
servers connected to a corporate network) will enter a hibernation
state, essentially a power-off condition, when they have not been
accessed for some inactivity period or the administrator forced the
server into hibernation.

   A PM-enabled server can be "awaken"  by several methods,
but primarily via a Wake-on-LAN (WOL) network adapter or modems.  The
WOL network adapters filter the network packets looking for packets
addressed to the server.  If one is received then the WOL network
adapter will generate a wake-up event.  For modems, the
ring-indicator will generate a wake-up event.  In either case, the
server then can respond to the packet that caused the wake-up event.
Subsequent network activity from the remote user will keep the server
from returning to a hibernation state.  Currently any unchallenged
user can wake-up a server equipped with WOL network adapter or
modem.  A malicious user may attempt to probe the reactivated server
for weaknesses in its security; for example, a port-scan search for
unsecured services.

   Again, it would appear the "turn it off"  would be the
safest policy.  However, the "turn it off"  policy denies legitimate
user from accessing the servers.  What is needed is an external
"Wake-Up Manager"  which establish control and policy over when a
server can be awoken.  What's needed is a solution that enables PM
wake-up events on the server under some off-server policy management.
In other words, the server would remain hibernating until the
creditability of an access-requesting user can be verified.  Only
then should the server be allowed to transition out of hibernation
and serve the user.

   The "Wake Up Gate"  solution

   The "Wake-Up Gate Manager" solution consists of three
major components: A "Wake-up Gate" network service, an Service
Processor with "Wake-Up Gate" control software, and the "Wake-Up
Gate" hardware controller.  Each of these components will be
described below, followed by a systematic flow description.

   The "Wake-Up Gate"  Network Service

   This service is provided via standard RPC-based
client-server service methodologies.  This service has three major
functions.
  1.  Validating user requests to enable wake-up events on
      the target server.  This could be through some standard
      security package such as Kerberos.  Logging of request
      and responses would also be made.
  2.  Exchange "Wake-up Gate"  control messages with the
      target server's Service...