[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   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.

   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

   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

   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

   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


                    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

   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.

   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

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

   I would like to thank, especially, Sir Scott Richardson (UDcast) for
   his valuable Bristish-style editing comments and the UDteam for the
   technical inputs.


   [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
   2455, route des Dolines
   Les Taissounieres - BP 355
   06906 Sophia-Antipolis Cedex
   Phone : +33 4 93 00 16 60
   Fax   : +33 4 93 00 16 61
   Email : Emmanuel.Duros@UDcast.com

Duros                                                           [Page 8]