Network Working Group E. Duros Internet-Draft UDcast November 2001 Expires April 2002 Identifying Security Implications in a Link-Layer Tunnelling Mechanism for Unidirectional Links Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Many operators may deploy network infrastructures that use unidirectional links such as broadcast satellite links or digital TV links (...), which are capable of carrying IP traffic. In order to transparently integrate these links in their infrastructure, they may use a link-layer tunnelling mechanism such as defined in [RFC3077]. The purpose of this document is to attempt to identify any potential security implications related to this mechanism in order to help operators set up adequate securing mechanisms. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. Duros [Page 1] Internet Draft Identifying Security Implications in LLTM November 2001 Table of Contents 1 Introduction ................................................ 2 2 Terminology ................................................. 2 3 General Overview ............................................ 3 4 DTCP Protocol ............................................... 5 5 Tunnelling Mechanism ........................................ 6 6 Routing Protocols ........................................... 7 7 Acknowledgments.............................................. 8 1 Introduction A link-layer tunnelling mechanism (LLTM) [RFC3077] has been designed to integrate unidirectional links (see section 2 for terminology) in the Internet. This mechanism emulates full broadcast and bidirectional connectivity to all nodes that are directly connected to a unidirectional link. Please refer to [RFC3077] for a complete description of mechanism. This document identifies security implications that are inherent to LLTMs. We focus on the LLTM security implications that operators should be aware of when deploying a network architecture using this mechanism. However, we do not intend to provide the solution to secure the LLTM. This might be too complex since it depends on many different factors, such as the type of unidirectional link being used, the type of return path between a receiver and feed, etc. However, we should provide sufficient information to operators to set up the right policies to secure the LLTM in their specific network environment. We present in section 3 a general overview of a typical network architecture integrating a unidirectional link. We describe how LLTM operates between a feed and a set of receivers. The following sections describe LLTM security implications which are inherent to this architecture. Section 4 identifies a security hole related to DTCP. Section 5 identifies a security hole related to the tunnelling mechanism between a receiver and a feed. Section 6 identifies security implications related to routing protocols that may be present. 2 Terminology The terminology used in this document is the same as the terminology defined in [RFC3077]: Duros [Page 2] Internet Draft Identifying Security Implications in LLTM November 2001 Unidirectional link (UDL): A one-way transmission link, e.g. a broadcast satellite link. Receiver: A router or a host that has receive-only connectivity to a UDL. Send-only feed: A router that has send-only connectivity to a UDL. Receive-capable feed: A router that has send-and-receive connectivity to a UDL. Feed: A send-only or a receive capable feed. Node: A receiver or a feed. Bidirectional interface: a typical communication interface that can send or receive packets, such as an Ethernet card, a modem, etc. 3 General Overview In this section we describe a general network architecture that integrates a unidirectional link. The feed and the receivers implement the LLTM and we present how LLTM operates in this architecture. The unidirectional link can be either a broadcast satellite link, terrestrial UHF/VHF link (like digital TV links), or any other link with this common characteristic. A send-only feed is connected to the global Internet with a bidirectional interface (e.g. Ethernet). It is also connected to the unidirectional link with a send-only interface. There is no receive- capable feed in the architecture. A set of receivers is connected to the unidirectional link with a receive-only interface. They all have a bidirectional interface (e.g. Ethernet or ppp) connected to the Internet. The receivers can reach the feed bidirectional interface through the Internet. All the nodes connected to the unidirectional link, i.e. the feed and the receivers, implement the LLTM. As a result, every node can send a unicast, a multicast or a broadcast layer-two frame over the unidirectional link. A node can reach any other node as if they were connected to a bidirectional broadcast network. In other words, nodes are connected in a similar way to an Ethernet local area network. Figure 1 depicts this architecture with a single feed and several Duros [Page 3] Internet Draft Identifying Security Implications in LLTM November 2001 receivers: Unidirectional Link ---->------------------------------>------ | | | |fuip |r1u |r2u -------- -------- -------- ---------- | Feed | |Recv 1| |Recv 2|---|subnet A| -------- -------- -------- ---------- |fbip |r1b |r2b | | | | | ---------------------------------------------------- | Internet | ---------------------------------------------------- Figure 1: Typical topology using LLTM fuip is the feed unidirectional IP address as defined in Section 7 of RFC[3077]. Also called the feed tunnel end-point. fbip is the feed bidirectional IP address as defined in Section 7 of RFC[3077]. r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver 2) receive-only interface. r1b (resp. r2b) is the IP address of the 'Receiver 1' (resp. Receiver 2) bidirectional interface connected to the Internet. Subnet A is a local area network connected to recv 2. The feed, which implements [RFC3077], periodically announces its tunnel end-point over the unidirectional link. This provides a means for receivers to dynamically discover the presence of a feed and to send packets to its tunnel end-point. This mechanism is called the dynamic tunnelling configuration protocol and is described in detail in Section 7 of RFC[3077]. Referring to Figure 1, the feed sends DTCP HELLO packets over the unidirectional link. The source IP address of the packet is fuip. The payload of the HELLO packet contains the feed tunnel end-point, i.e. fbip. Receivers listen to the DTCP announcements to detect the presence of the feed. When the feed is detected, a receiver keeps track of the feed tunnel end-point (fbip) that is contained in the HELLO packet. Note that the feed is considered active as long as the receiver Duros [Page 4] Internet Draft Identifying Security Implications in LLTM November 2001 receives its DTCP announcements. Thereafter, the link-layer traffic that cannot be sent physically over the unidirectional link, is encapsulated within GRE packets [RFC2784] and sent to the feed tunnel end-point (fbip). Encapsulated GRE packets sent from a receiver (recv 1 or recv 2) to the feed, are routetd via the Internet. The source IP address of a GRE packet is r1b or r2b, the bidirectional interface IP address of a receiver. The destination IP address of a GRE packet is fbip, the feed tunnel end-point. Upon reception of a GRE packet, the feed decapsulates the packet which reveals the original link-layer frame. The feed processes this frame as if it was received from its send-only interface. Note, the feed may have to forward the received frame over the unidirectional link if the destination MAC address of the frame is: a broadcast or multicast destination, or the unicast MAC address of a receiver. See Section 6.2 of [RFC3077] for the entire details of this process. The LLTM allows a receiver to send a broadcast, a multicast or a unicast packet over the unidirectional link. This functionality is generally mandatory to support dynamic routing over the link. Indeed, a receiver which implements a dynamic routing protocol (e.g. recv 2 which implementing a multicast routing protocol), needs to communicate with neighbour routers connected to the link. This is performed by exchanging multicast or unicast signalling messages over the link among neighbour routers. The following section attempts to identify security implications related to the link-layer tunnelling mechanism in this architecture. 4 DTCP Protocol The DTCP protocol is part of the specification of the LLTM. As explained in [RFC3077]: "The DTCP protocol provides a means for receivers to dynamically discover the presence of feeds and to maintain a list of operational tunnel end-points. Feeds periodically announce their tunnel end-point addresses over the unidirectional link. Receivers listen to these announcements and maintain a list of tunnel end-points." A feed periodically sends HELLO messages containing a list of operational tunnel end-points. Referring to Figure 1, the feed announces a single tunnel end-point, which is fbip. To the LLTM, this information may be considered sensitive because all the receivers send GRE traffic to this specific IP address. Duros [Page 5] Internet Draft Identifying Security Implications in LLTM November 2001 Furthermore, depending on the unidirectional link technology (e.g. a broadcast satellite link), it may be fairly easy for unauthorised receivers to listen to HELLO packets and discover the feed tunnel end-point(s). In these cases, link-layer security mechanisms may be used to prevent unauthorised receivers from obtaining this information. 5 Tunnelling Mechanism The LLTM uses a tunnelling mechanism to relay traffic between a receiver and a feed. A receiver creates a GRE packet for every MAC packet which could not be transmitted over the unidirectional link. This packet is then tunneled to the feed bidirectional IP address. A packet tunneled with a GRE encapsulation has the following format: the delivery header is an IP header whose destination is the tunnel end-point (fbip in Figure 1) and source is the receiver bidirectional IP address (r1b or r2b in Figure 1), followed by a GRE header specifying the link-layer type of the unidirectional link. Figure 2 presents the different levels of encapsulation: ---------------------------------------- IP delivery | destination addr = fbip | header | source addr = r1b or r2b | | IP proto = GRE (47) | ---------------------------------------- GRE header | type = MAC type of the UDL | ---------------------------------------- GRE payload | | | MAC packet | | | ---------------------------------------- Figure 2: Encapsulated packet For scalability issues, the LLTM at the sending side does not maintain any state information with respect to the receiver tunnel end-points. LLTM processes incoming GRE packets regardless of the originator, it makes no distinction among receivers that are authorised or not to tunnel packets. As a result, receivers may gain access to services whereas they are not authorised to. It would be advisable to install some mechanism in order to prevent the feed from processing the unauthorised incoming tunneled packets. The feed operator may know the receiver bidirectional IP addresses from which expects to receive packets. Then, all tunneled packets Duros [Page 6] Internet Draft Identifying Security Implications in LLTM November 2001 whose IP source address is unknown may be simply discarded before being processed by the feed. This can be easily performed by equipment located near the feed, which is on the same path as the tunneled packets. This equipment would filter the packets according to their IP source addresses. However this mechanism is not secure enough against IP spoofing. An Internet host may steal a receiver IP address which is authorised to tunnel packets. The host may tunnel GRE packets to the feed containing the IP source address of the authorised receiver. As a result, the tunneled packets would go through the filtering equipment without being discarded, and then, be processed by the feed. IP spoofing can be countered by authenticating all tunnels. This mechanism is used to provide data origin authentication for IP datagrams and protection against replays. It can take place either in the delivery IP protocol (e.g. [RFC2402]) or in an authentication protocol integrated with the tunnelling mechanism. The authentication mechanism is not specified in this document 6 Routing Protocols This section presents security issues related to routing protocols. Unlike the two previous sections, these are not directly related to the LLTM. However, operators should be aware that when deploying networks with routing protocols, a few security measures should be taken, especially when using the LLTM. Let's consider an operator that provides full bidirectional connectivity to a set of receivers which are routers. These receivers exchange routing information with each other over the unidirectional through the LLTM. Referring to Figure 1, receiver 2 is configured as a router implementing dynamic routing protocols. It exchanges routing information with the feed and other receivers which are also routers. Currently, the operator may also provide network connectivity to receivers which are not allowed to send routing information. This is the case when a receiver is configured as a multi-homed host having several IP interfaces and should not implement a routing protocol. The administrator of such receivers may be tempted to run a unicast or a multicast routing protocol to provide connectivity to a local area network (e.g. subnet A in Figure 1). The administrator would then gain access to extra services offered by the operator. To prevent unauthorised receivers from providing undesirable routing information, routing protocols running on top of the LLTM must use authentication mechanisms when available. As a result, a feed would Duros [Page 7] Internet Draft Identifying Security Implications in LLTM November 2001 only take into account routing messages which are authenticated, non- authenticated messages simply being discarded. 7 Acknowledgments This document is the result of work undertaken by the UDLR working group. I would like to thank, especially, Sir Scott Richardson (UDcast) for his valuable Bristish-style editing comments and the UDteam for the technical inputs. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2784] Farinacci, D., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional Links', RFC 3077, March 2001 Author's address Emmanuel Duros UDcast 2455, route des Dolines Les Taissounieres - BP 355 06906 Sophia-Antipolis Cedex France Phone : +33 4 93 00 16 60 Fax : +33 4 93 00 16 61 Email : Emmanuel.Duros@UDcast.com Duros [Page 8]