Network Working Group Chao-Chun Wang, NEC
Internet Draft
Expiration Date: Aug 1999 Tom Worster, GDC
TCP Encapsulation for GSMP Messages
<draft-wang-gsmp-tcp-encapsulation-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
Abstract
The GSMP charter calls for a draft to propose how to
encapsulate GSMP messages in IP packet <draft-doria-gsmp-
applicability-00.txt>. This memo recommends using TCP as
the transport to carry GSMP message over IP.
Wang et al. Expires Aug 1999 [Page 1]
INTERNET DRAFT TCP Encapsulation for GSMP Messages Feb 1999
1. Introduction
The General Switch Management Protocol (GSMP) Version 2
(RFC 2297) [1] is a general-purpose protocol which controls
an ATM switch. GSMP allows a controller to manage the
connection state of a switch. The switch may communicate
with the controller asynchronously to report events. In
GSMP there is a one-to-one relationship between controller
and switch. However, there is no restriction preventing
either a system from being the controller of more than one
switch or a switch from supporting control sessions with
more than one controller.
GSMP V2 specifies the encapsulation of GSMP messages over
an ATM connection between controller and switch as well as
a direct ethernet encapsulation. The current GSMP
applicability draft [2] and the GSMP working group charter
both suggest that GSMP should extended to support non-ATM
label switches and to have the option to control the switch
remotely. In some applications remote control over ATM is
inappropriate so there is a requirement for an option of
encapsulation of GSMP messages over IP.
Since remote switch control over an IP network is
potentially less reliable and more susceptible to security
attack, it is required that the IP encapsulation mechanism
should provide reliability, flow control and security.
Another rule for the selection of an IP encapsulation is
that it should not affect the GSMP protocol and should not
include any extension. Simply put, we should leave the
protocol work to the GSMP protocol draft.
We consider two possible solutions for the IP
encapsulation. One is to use IP stack only and implements
the necessary support in the GSMP applications. Another one
is to use the TCP/IP stack and have the transport protocol
takes care the additional requirements and the application
can be kept as simple as possible.
The first solution which uses RAW IP support requires that
GSMP client and server applications keep track of the
status of the link and the state of each messages exchange.
The benefits of this approach include a thin and efficient
IP layer and less resource is demanded by the protocol
processing. Even though it does not require an extensive
changes to the protocol to provide the necessary support
for the above requirements and does not significantly
affect the switch application design, it does make the
controller application more complex and thus might hinder
the effort of fast deployment of GSMP.
Wang et al. Expires Aug 1999 [Page 2]
INTERNET DRAFT TCP Encapsulation for GSMP Messages Feb 1999
The other option is to use TCP which is reliable and will
minimise changes to the controller application. Even though
the protocol stack will consume more resource, the cost of
hardware is diminishing while the cost of software is
increasing. A simple solution for the application is more
attractive.
Based on these arguments, this memo proposes to use TCP
(RFC 793)[3] as its transport protocol to encapsulate GSMP
messages over IP. TCP provides reliable delivery of GSMP
messages with both network and end-system flow control. As
for security and authentication, we propose a two-layer
security mechanism. It is recommended that vendor should
support at least one of them. Both mechanisms are taken
from existing IETF security mechanisms.
This memo does not introduce changes to GSMP messages. The
IP encapsulation only provided as a vehicle for GSMP
messages and any changes or extension of the protocol are
not in the scope of this document.
2. Summary of operation
In GSMP, the controller is the master and switch is the
slave. For TCP encapsulations of GSMP messages, the
controller runs the client code and the switch runs the
server code.
Upon initialization, the server is listening on GSMP's
(proposed) well known port number. The controller
establishes a TCP connection with each switch it manages.
Adjacency protocol messages, which are used to synchronise
the controller and switch and maintain handshakes, are sent
by the controller to the switch after the TCP connection is
established. Regular GSMP messages may be sent only after
the adjacency protocol has achieved synchronization.
3. TCP Encapsulation of GSMP packets
GSMP V2 includes an Ethernet encapsulation for which GSMP
message is encapsulated in the Ethernet frame. A four-byte
"Sender Instance" field and a four-byte "Receiver Instance"
field are appended to the non-adjacency GSMP message to
offer extra level of protection against the corruption of
state. There is an assigned Ethertype for GSMP message
which is 0x880C. It is possible that some users might
choose to implemented a GSMP enabled IP network.
This creates the possibility of two type of network, one is
a "GSMP enabled IP network" and the other is a regular IP
Wang et al. Expires Aug 1999 [Page 3]
INTERNET DRAFT TCP Encapsulation for GSMP Messages Feb 1999
network. The Ethertype for GSMP Ethernet encapsulation is
0x880c and Ethertype for IP is 0x0800. A typical
ether_input routine only recognise ETHERTYPE_IP or
ETHERTYPE_ARP and drops the rest ETHERTYPE packets. A GSMP
enabled IP network is a network with protocol stack which
recognises the 0x880c. Whether there is a separate routine
to handle GSMP messages is not our concern. We only state
the possibility. The TCP encapsulation of the GSMP messages
should be able to be transported on either type of network.
In order to assure compatibility with the ethernet
encapsulation, the TCP encapsulation appends two addition
fields, the four-byte "Sender Instance" field and a four-
byte "Receiver Instance" field to all non-adjacency gsmp
messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TCP Header ~
| |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When sending the TCP encapsulated GSMP adjacency messages
via a GSMP enabled IP network, the Ethernet frame should
used the Unicast 48-bit IEEE MAC address of the destination
in the SYN message.
NOTE: Even if this been converted to the Broadcast address,
it should still be possible to deliver the message to the
correct protocol layer based on the destination IP address.
4. Security consideration
To ensure the authenticity and security of GSMP messages
which are transported through an IP network we recommend
use of IETF security measures. We propose a two-layer
securities mechanism standardised by the IETF. The first
layer of security mechanism is applied to network layer
using IP-Sec (RFC 2401) [4]. This option is not described
any further in this memo.
Wang et al. Expires Aug 1999 [Page 4]
INTERNET DRAFT TCP Encapsulation for GSMP Messages Feb 1999
The second layer is simpler mechanism which applies to the
transport layer to protect TCP packet from spoofing which
is based on the authentication mechanism used by BGP4 [5].
This option is described further below.
We recommended that at least one of the above measures
should be adopted to protect the GSMP message.
4.1 TCP security extension
RFC 2385 [5] proposes a TCP extension to enhance security
for BGP4 using an MD5 authentication signature. Since the
extension is not limited to BGP we recommend adopting the
same TCP extension to significantly reduce the danger from
certain security attacks such as spoofing. Following is a
brief summary of this extension.
Every segment sent on a TCP connection is protected by a
16-byte MD5 digest which is produced by applying the MD5
algorithm to the field in TCP header in the following
order:
A. the TCP pseudo-header (in the order: source IP
address, destination IP address, zero-padded
protocol number, and segment length),
B. the TCP header, excluding options, and assuming a
checksum of zero,
C. the TCP segment data (if any),
D. an independently-specified key or password, known to
both TCPs and presumably connection-specific.
A key exchange mechanism is opened for further study. We
recommend the mechanism defined in RFC 2409 "The Internet
Key Exchange (IKE)" [6].
The proposed option has the following format:
Wang et al. Expires Aug 1999 [Page 5]
INTERNET DRAFT TCP Encapsulation for GSMP Messages Feb 1999
+---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+
| |
+---------------------------------------+
| |
+---------------------------------------+
| |
+-------------------+-------------------+
| |
+-------------------+
The proposed TCP extension still satisfies the constraint
set to TCP options fields. The most loaded options which
with 4 bytes MSS, 4 bytes window scale, 12 bytes timestamp,
18 bytes for MD5 digest and 2 bytes for end-of-option-list
just make it 40 bytes.
5. The relationship between controllers and switches
GSMP V2 does not explicitly specify the relationship
between the controller and switch and various different
implementations are possible. Some users might, for various
reasons, choose to design a switch which supports multiple
GSMP control sessions. In the future, GSMP may explicitly
specify a many-to many mapping. Therefore, we recommended
that switch's GSMP TCP server must support concurrent
sessions to the same server port number.
6. GSMP message and message header format
The message and message header format are defined in the
GSMP V2 and unaffected by the IP encapsulation.
7. GSMP Adjacency Protocol
We recommended setting MSG_OOB option, which sets TCP URG
bit, when sending the adjacency protocol message. Since no
GSMP message can be accepted before the switch and switch
controller synchronised with each other, the adjacency
protocol message should be processed with highest priority.
8. Conclusion
This memo proposes to use TCP as the transport to carry
GSMP messages over an IP network. This approach puts
minimum burden on the application and has the transport
Wang et al. Expires Aug 1999 [Page 6]
INTERNET DRAFT TCP Encapsulation for GSMP Messages Feb 1999
protocol layer takes care the issues of reliability and
flow control required by the GSMP messages. The TCP
extension adopted from RFC 2385 and IPSEC from RFC 2401
provides the authentication and security for the GSMP
messages.
References
[1] Newman, P, Edwards, W., Hinden, R., Hoffman, E., Ching
Liaw, F., Lyon, T. and Minshall, G., "Ipsilon's
General Switch Management Protocol Specification,"
Version 2.0, RFC 2297, Mar 1998.
[2] A. Doria, T. Worster, and K. Sundell, "Applicability
of GSMP as an IETF Protocol," Internet Draft, draft-
doria-gsmp-applicability-00, Oct 1998.
[3] J. Postel, "Transmission Control Protocol," RFC 793,
Sep 1981.
[4] S. Kent and R. Atkinson "Security Architecture for the
Internet Protocol," RFC 2401, November 1998.
[5] A. Heffernan, "Protection of BGP Sessions via the TCP
MD5 Signature Option," RFC 2385, August 1998.
[6] D. Harkins, D. Carrel, "The Internet Key Exchange
(IKE)," RFC 2409, November 1998.
Authors Addresses
Chao-Chun Wang,
NEC C&C Research Labs.
110 Rio Robles Dr., M/S SJ100
San Jose, CA95134
Phone: (408)943-3028
Fax: (408)943-3099
ccwang@ccrl.sj.nec.com
Tom Worster
General DataComm, Inc.
199 W Newton St,
Boston, MA 02116 USA
Phone: +1 617 247 2624
tom.worster@gdc.com
Wang et al. Expires Aug 1999 [Page 7]