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
<draft-ietf-udlr-security-00.txt>
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]
