Internet Draft 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. 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]