One document matched: draft-rfced-info-mercer-00.txt
INTERNET DRAFT EXPIRES JUNE 1999 INTERNET DRAFT
Network Area S. Mercer
Internet Draft Storage Technology Corp.
A. Molitor
Storage Technology Corp.
M. Hurry
Siemens ICN
T. Ngo
Sun Microsystems, Inc.
H.323 Firewall Control Interface (HFCI)
<draft-rfced-info-mercer-00.txt>
Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this document is unlimited.
Introduction
It is becoming clear that next generation telephony networks will be
built on top of IP-based networks, as opposed to the traditional
voice technology. There are several reasons for this, among them
lower cost and greater flexibility.
While there are several Voice on IP (VoIP) solutions, the H.323 [2]
standard from the ITU seems to be a major player. Other solutions
will probably resemble H.323, even if they do not comply with the
standard. This memo proposes an Application Interface to permit
H.323 devices to open 'pinholes' in an otherwise opaque firewall, to
permit the traffic necessary for H.323 through, and nothing else.
Since other VoIP solutions resemble H.323, at least approximately,
the same Application Interface may well be useful for them.
In particular, Real-Time Protocol (RTP), defined in RFC1889 [3], is
likely to be the underlying voice transport for any VoIP solution.
Motivation
There are several reasons why it is difficult to get H.323 packets
through a firewall. See [1]. Among the reasons are:
1. Most of the control information is encoded in ASN.1, which is
a complex encoding scheme and does not end up with fixed byte
Mercer, Molitor, Hurry, Ngo [Page 1]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
offsets for address information.
2. An H.323 call is made of several different simultaneous
connections. Q.931 and H.245 use TCP connections, and for an
audio-only conference, there may be up to 4 different UDP
'connections' made.
3. The addresses and ports numbers are exchanged within the data
stream of the 'next higher' connection. Q.931 uses well-known TCP
port 1720. Within the Q.931 data stream, dynamic TCP ports for
H.245 connections are negotiated. Within the H.245 data stream,
it also has commands that open dynamic UDP 'connections' for RTP
and RTCP.
This makes it particularly difficult for firewalls that perform
network address translation, because they need to modify the
addresses inside these data streams. The firewall not only has to
monitor data streams and disassemble the packets on the control
streams, it must also be able to recompose valid data in the control
streams as is traverses the firewall.
For these reasons, many firewalls either do not support H.323 or all
UDP ports have to be opened on the firewall to allow H.323 packets to
go through, which introduces substantial security risk.
Since the H.323 devices already have the complicated H.323 logic, it
would be beneficial to have a protocol between H.323 devices and
firewalls to permit H.323 devices to temporarily open 'pinholes' in a
firewall to allow H.323 traffic through, and an application
programming interface for H.323 devices to send commands to the
firewall through the protocol.
There are several advantages to this approach:
1. Firewalls do not have to implement the complicated H.323 logic
to detect setup or teardown of communication sessions
2. Better performance on the firewall since it does not incur the
processing overhead to monitor data streams nor does it parse
ASN.1 in H.323 packets.
Scope
This memo is intended to define an interface for communications
between two specific components of an H.323 solution. The details of
implementing and securing the communications channel are outside the
Mercer, Molitor, Hurry, Ngo [Page 2]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
scope of this memo. The nature of the underlying channel may be
wildly different between implementations of H.323 solutions, so no
protocol will fit all architectures.
However, it is the intent of the authors to introduce a follow-up
memo with a protocol suitable for implementing the interface
specified in this memo. While the protocol may not be as widely
applicable as the interface specified in this memo, it will have some
degree of generality. This protocol will, of course, address the
relevant security issues.
We wish to begin by introducing the functionality, and to improve it
through feedback, before proceeding to commit it to a protocol.
For these reasons, no protocol suitable for implementing this
interface is defined herein. Since no protocol is defined, we
present only a sketch of the security requirements for such a
protocol.
Definitions
The word 'Gateway', in an H.323 context, is a device which translates
some non-H.323 communications service (e.g. Plain Old Telephone
Service, H.320, etc.) into H.323.
service word 'Gatekeeper', in an H.323 context, is a device which
contains the call control intelligence to establish and terminate
H.323 compliant communications sessions. Note that a Gateway may, or
may not, include the Gatekeeper functions. If a Gateway does not, it
must rely on a remote Gatekeeper to handle these necessary functions.
The word 'Proxy', in an H.323 context, means a Gateway which
translates from H.323 to H.323. This device is very much like a
proxy firewall, but for H.323 applications. Indeed, it may be
integrated with a traditional proxy firewall for IP applications, and
provide H.323 connectivity through that firewall.
Herein, 'signaling' is used in the telephony sense, to describe
control traffic used to set up a telephone call. For H.323,
signaling is carried out using the Q.931 and H.245 recommendations of
the ITU.
The word 'session' is used to refer to all the connections and state
information associated with a telephone call. This includes TCP
connections used to pass signaling traffic, as well as UDP based
connections passing the actual voice traffic.
Relation with the H.323 standards
Mercer, Molitor, Hurry, Ngo [Page 3]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
Since RTP is a dominant standard for the transport portion of VoIP
solutions, the means to dynamically open and close ports for this
class of UDP traffic on a firewall has to be addressed. The HFCI is
designed as an interface between the H.323 compliant gateway or
gatekeeper and a designated firewall to open and close permissions
for the ephemeral ports negotiated to complete the H.323 session,
including the RTP transport portion. The HFCI provides the gateway
or gatekeeper the ability to manage the firewall, opening specific
TCP permissions for well-known or registered ports, in support of
VoIP services and applications, and opening only the negotiated TCP
and UDP port permissions necessary to allow the H.245 session to
transmit the voice and control traffic, for each call.
General Considerations
The bulk of H.323 negotiation, as well as the voice traffic itself,
is carried over connections between ephemeral ports. Each level of
negotiation will select, more or less at random, ports for the next
level. This makes "firewalling" H.323 very difficult, without being
one of the players in the negotiations. The most reasonable model
seems to be to provide the H.323 Proxy, as simply as possible, with
mechanisms to manage a firewalling device with the pinpoint accuracy
required.
The H.323 signaling traffic is carried over TCP streams, and is not
very latency sensitive. Of course, the end-user would like calls to
be set up in a timely fashion, but certainly the usual application-
space proxy is a suitable model here. However, the voice traffic
itself is carried in small UDP datagrams, passed between ephemeral
ports, and is very latency sensitive. This traffic is ideally suited
for management by a packet filtering device. Luckily, the H.323
Proxy model (see [1]) permits the voice traffic to pass in parallel
to the signaling traffic. Thus, signaling traffic may be firewalled
by a proxy firewall of the usual architecture, while the voice
traffic passes through a high-speed, low-latency packet filter. In
order to be effective, this packet filtering device must be under the
control of the Proxy.
For convenience, we assume that the packet filtering may also be
filtering the signaling traffic (though, of course, it need not).
This memo outlines an interface suitable for an H.323 Gateway or
Gatekeeper to control a filtering device, to provide the precise
controls needed to manage the several layers of signaling, and the
voice traffic itself. This permits the use of H.323 over public IP
networks, with the smallest possible risk exposure.
Control Interface
Mercer, Molitor, Hurry, Ngo [Page 4]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
This memo proposes a simple set of methods, suitable for
implementation as a functional interface, or through RPC or RPC-like
mechanisms. The goal is to define the exact functionality required
to manage a filtering device, for controlling H.323 traffic.
The protocol definition is given as a set of procedures with
arguments and results, in the style of RFC1094, the specification for
NFS.
Init
returnCode = Init()
This initializes the implementation of the API, and may or may not do
anything important. It exists as a placeholder, to permit an
implementation the opportunity to set up any internal data
structures.
This should be invoked only once.
FirewallInit
returnCode = FirewallInit(
firewallIpAddress,
firewallType,
userId,
authenticationType,
authenticationData,
subDeviceId,
h323GatewayAddress,
h323GatewayPort,
returnedFirewallId)
This initializes an abstract "control channel" to a filtering device.
Any initialization required to access the filtering device (key
exchange, connect socket, etc.) may be performed by the underlying
implementation at this point.
This may be invoked as many times as necessary to establish control
connections to specific filtering devices, and sub-devices within
them.
firewallIpAddress
The administrative IP address of the filtering device. If the
filtering device is internal, or otherwise implicitly addressed, the
Mercer, Molitor, Hurry, Ngo [Page 5]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
parameter may be ignored.
firewallIpAddress is either a 32 bit IPv4 address or a 128 bit IPv6
address.
firewallType
An appropriate member of an enumeration identifying the filtering
device type. This may be used by the underlying implementation to
support multiple filtering device types.
firewallType is an unsigned 32 bit integer.
Currently defined firewallType values include:
FIREWALL_TYPE_NETSENTRY 0xa1880001
userId, authenticationType, authenticationData
In the event that the filtering device requires some login procedure,
these arguments are intended to provide material to perform that
login. Some or all of them may be ignored by an underlying
implementation. For the purposes of this memo, these are abstract,
opaque, data, agreed upon by the application and the underlying
implementation.
The userId is a numeric identifier, intended (naturally) to identify
which user profile to login as. The authenticationType is an
appropriate member of an enumeration, which determines the structure
of the authenticationData. The authenticationData is the actual
material used to authenticate. For example, the authenticationType
might specify "MD5", or "Password"; in the former case, the
authentication data would probably contain a 128 bit secret, in the
latter, a secret text string.
userId is an unsigned 32 bit integer.
authenticationType is an unsigned 32 bit integer.
Currently defined authenticationType values include:
AUTH_TYPE_NONE 1
AUTH_TYPE_MD5 2
AUTH_TYPE_PASSWORD 3
AUTH_TYPE_SHA1 4
authenticationData is the address of a data structure appropriate for
the authentication type.
subDeviceId
A numeric identifier specifying which abstract filtering device
Mercer, Molitor, Hurry, Ngo [Page 6]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
within the larger device specified by the firewallIpAddress, with
which we intend to communicate. A given implementation may ignore
this, if the filtering device in question has no notion of sub-
devices.
subDeviceId is an unsigned 32 bit integer.
h323GatewayAddress, h323GatewayPort
These specify the IP address and TCP port number of the H.323 Gateway
device to which Q.931 connections are to be made as the initial
component of call setup. This is usually the well-known port 1720,
and is the only fixed port in the entire H.323 call-setup scheme.
h323GatewayAddress is either a 32 bit IPv4 address or a 128 bit IPv6
address.
h323GatewayPort is an unsigned 16 bit integer.
returnedFirewallId
This is an opaque numeric identifier returned by the underlying
implementation, which is used by the application to uniquely identify
the desired filtering device in subsequent API calls.
returnedFirewallId is an address for an unsigned 32 bit integer.
FirewallShutdown
returnCode = FirewallShutdown(
firewallId)
This method performs the inverse of the FirewallInit method, and
tears down any underlying state implementing the control channel.
This may include closing a socket, invalidating key material, or
possibly nothing at all, depending on the underlying implementation.
firewallId
This is the opaque numeric identifier returned by the FirewallInit
method.
firewallId is an unsigned 32 bit integer.
OpenPermission
returnCode = OpenPermission(
Mercer, Molitor, Hurry, Ngo [Page 7]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
firewallId,
ipAddress1,
port1,
ipAddress2,
port2,
protocol,
sessionId,
returnedPermissionId)
This opens a single "pinhole" in the firewall implemented by the
filtering device. It may allow a single TCP connection to proceed
for some H.323 control traffic, or it may open a pair of adjacent UDP
ports, to permit voice traffic between a pair of endpoints to pass.
The permission opened is tagged with a session identifier, which
uniquely identifies (within the scope of the underlying
implementation) the "phone call" that the permission is for.
firewallId
This is the opaque numeric identifier returned by the FirewallInit
method.
firewallId is an unsigned 32 bit integer
ipAddress1, port1, ipAddress2, port2.
These are the IP addresses and port numbers of the two endpoints of
communication, for which permission for communication should be
opened. This may be a set of addresses and ports for a specific stage
of H.323 signaling, or for the actual voice traffic.
If the protocol (see below) specifies that this is a UDP connection,
the port numbers are constrained to be even numbered, and the actual
connection permissions will apply to the specified port numbers, as
well as the next port numbers in sequence. This is because the UDP
traffic passed by an H.323 call actually uses two adjacent UDP port
pairs, which are always evenly aligned. See RFC1889 on RTP [3], for
the details.
Thus, if the protocol specified is UDP, and (for example) port1 is
1764 and port2 is 20562, then UDP traffic would be permitted between
the two specified IP addresses, and ports 1764,1765 on ipAddress1,
and ports 20562,20563 on ipAddress2.
ipAddress1 and ipAddress2 are either 32 bit IPv4 addresses or 128 bit
IPv6 addresses.
Mercer, Molitor, Hurry, Ngo [Page 8]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
port1 and port2 are unsigned 16 bit integers.
protocol
One of an enumeration specifying either TCP or UDP. This determines
whether the port numbers are TCP port numbers (for signaling traffic)
or UDP port numbers (for data traffic).
protocol is an unsigned 8 bit integer.
Currently defined protocol values include:
TCP 6
UDP 17
sessionId
This is an identifier passed to the underlying implementation which
uniquely identifies the "phone call" to which this permission is to
belong. It may also be unused, if the calling application has no
need to bundle permissions together into a session. This identifier
may be used with the CloseSession method (described below) to revoke
all permissions that have been granted for a single phone call
session.
sessionId is an unsigned 32 bit integer.
returnedPermissionId
This is an opaque numeric identifier returned by the underlying
implementation, which uniquely identifies the permission opened by
this invocation. This identifier may be used with the
ClosePermission method (described below) to revoke this specific
permission.
returnedPermissionId is an address for an unsigned 32 bit integer.
ClosePermission
returnCode = ClosePermission(
firewallId,
permissionId)
This performs the inverse operation of the OpenPermission method.
firewallId
This is the opaque numeric identifier returned by the FirewallInit
method.
Mercer, Molitor, Hurry, Ngo [Page 9]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
firewallId is an unsigned 32 bit integer
permissionId
This is the opaque numeric identifier returned by the OpenPermission
method, which uniquely identifies the permission to be closed down.
permissionId is an unsigned 32 bit integer.
CloseSession
returnCode = CloseSession(
firewallId,
sessionId)
This performs a ClosePermission operation for all the permissions
with a specified session identifier. This effectively closes all the
(possibly several) "pinholes" opened up for a given "phone call"
session.
firewallId
This is the opaque numeric identifier returned by the FirewallInit
method.
firewallId is an unsigned 32 bit integer
sessionId
This is the session identifier provided by the calling application to
one or more OpenPermission invocations, which identifies the bundle
of permissions making up the phone call session.
sessionId is an unsigned 32 bit integer.
Return Codes
Return codes for all procedures are unsigned 32 bit integers.
General Codes
SUCCESS 0xa1881017
Indicates that the method invocation was successful.
Bad Parameter Codes
Each of these codes indicates that the indicated parameter of the
Mercer, Molitor, Hurry, Ngo [Page 10]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
method invocation was, in some way, 'bad'. If multiple parameters
are bad, the underlying implementation may return any appropriate bad
parameter code.
BAD_ADDRESS1 0xa1881002
BAD_ADDRESS2 0xa1881003
BAD_AUTH_DATA 0xa1881004
BAD_AUTH_TYPE 0xa1881005
BAD_DEVICE_ID 0xa1881006
BAD_FIREWALL_ADDRESS 0xa1881007
BAD_FIREWALL_ID 0xa1881008
BAD_FIREWALL_TYPE 0xa1881009
BAD_GATEWAY_ADDRESS 0xa188100a
BAD_GATEWAY_PORT 0xa188100b
BAD_PERMISSION_ID 0xa188100c
BAD_PORT1 0xa188100d
BAD_PORT2 0xa188100e
BAD_PROTOCOL 0xa188100f
BAD_SESSION_ID 0xa1881010
BAD_USER_ID 0xa1881011
Incorrect State Codes
NOT_INITIALIZED 0xa1881015
This indicates that some method was invoked which must be preceded by
a suitable invocation of an initialization method. Normally, this
indicates that the Init method was not invoked.
ALREADY_INITIALIZED 0xa1881001
This may be returned by an invocation of Init or FirewallInit, to
indicate that a suitable invocation has already be performed.
Mercer, Molitor, Hurry, Ngo [Page 11]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
If this is returned, the internal state of the underlying
implementation should be unchanged by the method invocation.
Internal Errors
COMMUNICATION_ERROR 0xa1881012
If the filtering device is remotely addressed in some fashion, and
communications with it fail (possibly because of incorrect
authentication data), this code should be returned.
MEMORY_ALLOCATION_ERROR 0xa1881013
Returned when a memory exhaustion condition has been encountered.
MEMORY_CORRUPTION_ERROR 0xa1881014
Returned when a memory corruption problem has been detected. The
underlying implementation should use structure tagging, especially if
it is a library to be linked against an H.323 Gateway or Proxy
application. This may indicate that the surrounding application has
some problem.
PROVISIONING_ERROR 0xa1881016
A generic error returned if some problem managing the filtering
device was encountered.
HFCI Usage
General Description
The HFCI implements this set of commands to facilitate the
administrative communication flow between the gateway and firewall.
Each command is invoked by the gateway or gatekeeper to control the
firewall.
Init
FirewallInit
OpenPermission
ClosePermission
CloseSession
FirewallShutdown
The first two commands are invoked to initiate the control
communication and create permissions for an initial set of well-known
or registered ports. OpenPermission is used to grant permissions on
specific ports to support the H.323 connections. The next two
Mercer, Molitor, Hurry, Ngo [Page 12]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
commands revoke individual permissions or the set of all permissions
granted for a specific H.323 session. The final command revokes all
permissions granted and terminates communication with the firewall.
To simplify the explanation, the term "gateway" will be used below
instead of the terms "gateway or gatekeeper".
Initialization
Prior to initialization, the firewall must be configured with a
userId and proper authentication information to grant appropriate
administrative access for the gateway. When the gateway is placed in
service, the gateway will initialize the HFCI with the Init command,
and will then initiate the control communication with the firewall by
invoking the HFCI FirewallInit command. The firewall will use the
provided userId and authentication information to verify that the
gateway has authorization to manage the firewall. During the
initialization process, the firewall will be instructed to grant
permissions for an initial set of well-known or registered ports to
permit initial Q.931 connections destined for the gateway.
Opening Ports
With the control communication established and the firewall and
gateway ready for service, the gateway may use the HFCI to tell the
firewall to open permissions for specific TCP ports to allow various
application communications to be established with the gateway. This
is accomplished by invoking the OpenPermission command, possibly
several times.
When an H.323 session is established, the gateway will use the HFCI
OpenPermission command to tell the firewall to grant permissions for
specific TCP and UDP ports to support the voice and control traffic.
The permissions opened for each session are marked with a unique
session identifier, provided by the gateway, to facilitate revoking
those permissions when the session is terminated.
Closing Ports
After the gateway receives an acknowledgment that a specific session
is terminated, the gateway uses the HFCI CloseSession and/or
ClosePermission commands to tell the firewall to revoke the TCP and
UDP permissions that were granted for that session.
Call Setup Flow Scenario
To accurately describe the way the HFCI will be used, a possible call
flow between two gateways with HFCI implemented, separated by a
Mercer, Molitor, Hurry, Ngo [Page 13]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
firewall, is described. When implemented in a network, each gateway
would be protected behind a firewall. A single firewall is used here
to simplify the concept.
This diagram is meant to exhibit the behavior of the HFCI with
respect to typical Q.931 and H.245 messages required to setup and
establish an H.323 compliant session. For clarity purposes, Gateway
A is considered external to the firewall and not protected by it.
Gateway B is considered internal to and protected by the firewall.
Gateway B is authorized to use the HFCI to manage the firewall.
Gateway A (External) Firewall Gateway B (Internal)
1. Q.931 TCP port 1720 --> (fixed pinhole) --> Setup
2. <-- (fixed pinhole) <-- Call Proceeding
3. <-- (fixed pinhole) <-- Alerting
4. <-- HFCI Open TCP
port for H.245
"pinhole A"
5. <-- (pinhole A) <-- Gateway B Connect
(H.245)
6. H.245 Messages <--> (pinhole A) <--> H.245 Messages
7. Open RTP Channel --> (pinhole A) -->
8. <-- HFCI Open UDP
ports for RTP
"pinhole B"
9. <-- (pinhole A) <-- Open RTP channel ACK
10. <-- (pinhole A) <-- Open RTCP Channel
11. Open RTCP Channel
ACK --> (pinhole A) -->
12. RTP/RTCP Messages <--> (pinhole B) <--> RTP/RTCP Messages
Call Disconnect Flow Scenario
This diagram is meant to exhibit the behavior of the HFCI with
Mercer, Molitor, Hurry, Ngo [Page 14]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
respect to typical H.225 and H.245 messages required to terminate an
H.323 compliant session. For clarity purposes, Gateway A is
considered external to the firewall and not protected by it. Gateway
B is considered internal to and protected by the firewall. Gateway B
is authorized to use the HFCI to manage the firewall.
Gateway A (External) Firewall Gateway B (Internal)
1. Disconnect --> (pinhole A) -->
2. <-- (pinhole A) <-- Disconnect ACK
3. Close RTP/RTCP
ports --> (pinhole A) -->
4. <-- HFCI, close pinhole B
5. <-- (pinhole A) <-- Close ports ACK
6. <-- HFCI, close pinhole A
Security Considerations
The goal of this memo is to lay out procedures for securing the call
setup and call traffic components of the H.323 protocol. The meta-
issue of securing the management traffic implementing this is outside
the scope of this document. However, it is useful to sketch some
minimum requirements.
Minimum Control Channel Security Requirements
If the control channel resides entirely inside a Gatekeeper device,
there are no particular security requirements. The HFCI may be a
purely functional interface to a built-in packet filtering device,
for example. At this point, security must be focused on protecting
the Gatekeeper device (which, of course, must always be well
protected).
If the packet filtering component resides on a private network with
the gatekeeper function, some security is required. At a minimum,
strong authentication, and the usual suite of security properties
(replay prevention, session-hijack-proofing and so on) are required.
The fact that the underlying transactions open access through the
firewall require some degree of protection, even in the context of a
Mercer, Molitor, Hurry, Ngo [Page 15]
Internet Draft H.323 Firewall Control Interface (HFCI) Nov 1998
private network.
If the packet filtering device is connected to the Gatekeeper
function through an open network, strong authentication as indicated
above, together with strong encryption, is indicated.
References
[1] Chouinard, D., Richardson, J., Khare, M., "H.323 and Firewalls",
Intel Corporation Whitepaper, November 1997.
[2] ITU-T Recommendation H.323, "Visual Telephone Systems and Equipment
for Local Area Networks Which Provide A Non-Guaranteed Quality of
Service"
[3] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson., "RTP: A
Transport Protocol for Real-Time Applications", RFC1889, January
1996.
Authors' Addresses
Andrew Molitor
Storage Technology Corp. MS 602
7625 Boone Ave. N
Brooklyn Park, MN, 55428
Steve Mercer
Storage Technology Corp. MS 030
7600 Boone Ave. N
Brooklyn Park, MN, 55428
Maurice Hurry
Siemens Information and Communication Networks Inc.
900 Broken Sound Pkwy.
Boca Raton, FL 33487
Teodora Ngo
Sun Microsystems, Inc.
901 San Antonio Road, MS: MTV21-237
Palo Alto, CA 94303
INTERNET DRAFT EXPIRES JUNE 1999 INTERNET DRAFT
| PAFTECH AB 2003-2026 | 2026-04-23 15:53:35 |