idnits 2.17.1 draft-ietf-udlr-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2119], [RFC3077]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2002) is 8045 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3077' on line 177 ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Duros 3 Internet-Draft UDcast 4 November 2001 5 Expires April 2002 7 Identifying Security Implications in 8 a Link-Layer Tunnelling Mechanism for Unidirectional Links 10 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 Many operators may deploy network infrastructures that use 36 unidirectional links such as broadcast satellite links or digital TV 37 links (...), which are capable of carrying IP traffic. In order to 38 transparently integrate these links in their infrastructure, they may 39 use a link-layer tunnelling mechanism such as defined in [RFC3077]. 40 The purpose of this document is to attempt to identify any potential 41 security implications related to this mechanism in order to help 42 operators set up adequate securing mechanisms. 44 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 45 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 46 document, are to be interpreted as described in [RFC2119]. 48 Table of Contents 50 1 Introduction ................................................ 2 51 2 Terminology ................................................. 2 52 3 General Overview ............................................ 3 53 4 DTCP Protocol ............................................... 5 54 5 Tunnelling Mechanism ........................................ 6 55 6 Routing Protocols ........................................... 7 56 7 Acknowledgments.............................................. 8 58 1 Introduction 60 A link-layer tunnelling mechanism (LLTM) [RFC3077] has been designed 61 to integrate unidirectional links (see section 2 for terminology) in 62 the Internet. This mechanism emulates full broadcast and 63 bidirectional connectivity to all nodes that are directly connected 64 to a unidirectional link. Please refer to [RFC3077] for a complete 65 description of mechanism. 67 This document identifies security implications that are inherent to 68 LLTMs. We focus on the LLTM security implications that operators 69 should be aware of when deploying a network architecture using this 70 mechanism. However, we do not intend to provide the solution to 71 secure the LLTM. This might be too complex since it depends on many 72 different factors, such as the type of unidirectional link being 73 used, the type of return path between a receiver and feed, etc. 74 However, we should provide sufficient information to operators to set 75 up the right policies to secure the LLTM in their specific network 76 environment. 78 We present in section 3 a general overview of a typical network 79 architecture integrating a unidirectional link. We describe how LLTM 80 operates between a feed and a set of receivers. The following 81 sections describe LLTM security implications which are inherent to 82 this architecture. 84 Section 4 identifies a security hole related to DTCP. Section 5 85 identifies a security hole related to the tunnelling mechanism 86 between a receiver and a feed. Section 6 identifies security 87 implications related to routing protocols that may be present. 89 2 Terminology 91 The terminology used in this document is the same as the terminology 92 defined in [RFC3077]: 94 Unidirectional link (UDL): A one-way transmission link, e.g. a 95 broadcast satellite link. 97 Receiver: A router or a host that has receive-only connectivity to a 98 UDL. 100 Send-only feed: A router that has send-only connectivity to a UDL. 102 Receive-capable feed: A router that has send-and-receive connectivity 103 to a UDL. 105 Feed: A send-only or a receive capable feed. 107 Node: A receiver or a feed. 109 Bidirectional interface: a typical communication interface that can 110 send or receive packets, such as an Ethernet card, a modem, etc. 112 3 General Overview 114 In this section we describe a general network architecture that 115 integrates a unidirectional link. The feed and the receivers 116 implement the LLTM and we present how LLTM operates in this 117 architecture. 119 The unidirectional link can be either a broadcast satellite link, 120 terrestrial UHF/VHF link (like digital TV links), or any other link 121 with this common characteristic. 123 A send-only feed is connected to the global Internet with a 124 bidirectional interface (e.g. Ethernet). It is also connected to the 125 unidirectional link with a send-only interface. There is no receive- 126 capable feed in the architecture. 128 A set of receivers is connected to the unidirectional link with a 129 receive-only interface. They all have a bidirectional interface (e.g. 130 Ethernet or ppp) connected to the Internet. The receivers can reach 131 the feed bidirectional interface through the Internet. 133 All the nodes connected to the unidirectional link, i.e. the feed and 134 the receivers, implement the LLTM. As a result, every node can send a 135 unicast, a multicast or a broadcast layer-two frame over the 136 unidirectional link. A node can reach any other node as if they were 137 connected to a bidirectional broadcast network. In other words, nodes 138 are connected in a similar way to an Ethernet local area network. 140 Figure 1 depicts this architecture with a single feed and several 141 receivers: 143 Unidirectional Link 145 ---->------------------------------>------ 146 | | | 147 |fuip |r1u |r2u 148 -------- -------- -------- ---------- 149 | Feed | |Recv 1| |Recv 2|---|subnet A| 150 -------- -------- -------- ---------- 151 |fbip |r1b |r2b | 152 | | | | 153 ---------------------------------------------------- 154 | Internet | 155 ---------------------------------------------------- 156 Figure 1: Typical topology using LLTM 158 fuip is the feed unidirectional IP address as defined in Section 7 of 159 RFC[3077]. Also called the feed tunnel end-point. 161 fbip is the feed bidirectional IP address as defined in Section 7 of 162 RFC[3077]. 164 r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver 165 2) receive-only interface. 167 r1b (resp. r2b) is the IP address of the 'Receiver 1' (resp. Receiver 168 2) bidirectional interface connected to the Internet. 170 Subnet A is a local area network connected to recv 2. 172 The feed, which implements [RFC3077], periodically announces its 173 tunnel end-point over the unidirectional link. This provides a means 174 for receivers to dynamically discover the presence of a feed and to 175 send packets to its tunnel end-point. This mechanism is called the 176 dynamic tunnelling configuration protocol and is described in detail 177 in Section 7 of RFC[3077]. 179 Referring to Figure 1, the feed sends DTCP HELLO packets over the 180 unidirectional link. The source IP address of the packet is fuip. The 181 payload of the HELLO packet contains the feed tunnel end-point, i.e. 182 fbip. 184 Receivers listen to the DTCP announcements to detect the presence of 185 the feed. When the feed is detected, a receiver keeps track of the 186 feed tunnel end-point (fbip) that is contained in the HELLO packet. 187 Note that the feed is considered active as long as the receiver 188 receives its DTCP announcements. Thereafter, the link-layer traffic 189 that cannot be sent physically over the unidirectional link, is 190 encapsulated within GRE packets [RFC2784] and sent to the feed tunnel 191 end-point (fbip). 193 Encapsulated GRE packets sent from a receiver (recv 1 or recv 2) to 194 the feed, are routetd via the Internet. The source IP address of a 195 GRE packet is r1b or r2b, the bidirectional interface IP address of a 196 receiver. The destination IP address of a GRE packet is fbip, the 197 feed tunnel end-point. 199 Upon reception of a GRE packet, the feed decapsulates the packet 200 which reveals the original link-layer frame. The feed processes this 201 frame as if it was received from its send-only interface. Note, the 202 feed may have to forward the received frame over the unidirectional 203 link if the destination MAC address of the frame is: a broadcast or 204 multicast destination, or the unicast MAC address of a receiver. See 205 Section 6.2 of [RFC3077] for the entire details of this process. 207 The LLTM allows a receiver to send a broadcast, a multicast or a 208 unicast packet over the unidirectional link. This functionality is 209 generally mandatory to support dynamic routing over the link. Indeed, 210 a receiver which implements a dynamic routing protocol (e.g. recv 2 211 which implementing a multicast routing protocol), needs to 212 communicate with neighbour routers connected to the link. This is 213 performed by exchanging multicast or unicast signalling messages over 214 the link among neighbour routers. 216 The following section attempts to identify security implications 217 related to the link-layer tunnelling mechanism in this architecture. 219 4 DTCP Protocol 221 The DTCP protocol is part of the specification of the LLTM. As 222 explained in [RFC3077]: "The DTCP protocol provides a means for 223 receivers to dynamically discover the presence of feeds and to 224 maintain a list of operational tunnel end-points. Feeds periodically 225 announce their tunnel end-point addresses over the unidirectional 226 link. Receivers listen to these announcements and maintain a list of 227 tunnel end-points." 229 A feed periodically sends HELLO messages containing a list of 230 operational tunnel end-points. Referring to Figure 1, the feed 231 announces a single tunnel end-point, which is fbip. To the LLTM, this 232 information may be considered sensitive because all the receivers 233 send GRE traffic to this specific IP address. 235 Furthermore, depending on the unidirectional link technology (e.g. a 236 broadcast satellite link), it may be fairly easy for unauthorised 237 receivers to listen to HELLO packets and discover the feed tunnel 238 end-point(s). In these cases, link-layer security mechanisms may be 239 used to prevent unauthorised receivers from obtaining this 240 information. 242 5 Tunnelling Mechanism 244 The LLTM uses a tunnelling mechanism to relay traffic between a 245 receiver and a feed. A receiver creates a GRE packet for every MAC 246 packet which could not be transmitted over the unidirectional link. 247 This packet is then tunneled to the feed bidirectional IP address. 249 A packet tunneled with a GRE encapsulation has the following format: 250 the delivery header is an IP header whose destination is the tunnel 251 end-point (fbip in Figure 1) and source is the receiver bidirectional 252 IP address (r1b or r2b in Figure 1), followed by a GRE header 253 specifying the link-layer type of the unidirectional link. Figure 2 254 presents the different levels of encapsulation: 256 ---------------------------------------- 257 IP delivery | destination addr = fbip | 258 header | source addr = r1b or r2b | 259 | IP proto = GRE (47) | 260 ---------------------------------------- 261 GRE header | type = MAC type of the UDL | 262 ---------------------------------------- 263 GRE payload | | 264 | MAC packet | 265 | | 266 ---------------------------------------- 268 Figure 2: Encapsulated packet 270 For scalability issues, the LLTM at the sending side does not 271 maintain any state information with respect to the receiver tunnel 272 end-points. LLTM processes incoming GRE packets regardless of the 273 originator, it makes no distinction among receivers that are 274 authorised or not to tunnel packets. As a result, receivers may gain 275 access to services whereas they are not authorised to. 277 It would be advisable to install some mechanism in order to prevent 278 the feed from processing the unauthorised incoming tunneled packets. 279 The feed operator may know the receiver bidirectional IP addresses 280 from which expects to receive packets. Then, all tunneled packets 281 whose IP source address is unknown may be simply discarded before 282 being processed by the feed. This can be easily performed by 283 equipment located near the feed, which is on the same path as the 284 tunneled packets. This equipment would filter the packets according 285 to their IP source addresses. 287 However this mechanism is not secure enough against IP spoofing. An 288 Internet host may steal a receiver IP address which is authorised to 289 tunnel packets. The host may tunnel GRE packets to the feed 290 containing the IP source address of the authorised receiver. As a 291 result, the tunneled packets would go through the filtering equipment 292 without being discarded, and then, be processed by the feed. 294 IP spoofing can be countered by authenticating all tunnels. This 295 mechanism is used to provide data origin authentication for IP 296 datagrams and protection against replays. It can take place either in 297 the delivery IP protocol (e.g. [RFC2402]) or in an authentication 298 protocol integrated with the tunnelling mechanism. The authentication 299 mechanism is not specified in this document 301 6 Routing Protocols 303 This section presents security issues related to routing protocols. 304 Unlike the two previous sections, these are not directly related to 305 the LLTM. However, operators should be aware that when deploying 306 networks with routing protocols, a few security measures should be 307 taken, especially when using the LLTM. 309 Let's consider an operator that provides full bidirectional 310 connectivity to a set of receivers which are routers. These receivers 311 exchange routing information with each other over the unidirectional 312 through the LLTM. Referring to Figure 1, receiver 2 is configured as 313 a router implementing dynamic routing protocols. It exchanges routing 314 information with the feed and other receivers which are also routers. 316 Currently, the operator may also provide network connectivity to 317 receivers which are not allowed to send routing information. This is 318 the case when a receiver is configured as a multi-homed host having 319 several IP interfaces and should not implement a routing protocol. 320 The administrator of such receivers may be tempted to run a unicast 321 or a multicast routing protocol to provide connectivity to a local 322 area network (e.g. subnet A in Figure 1). The administrator would 323 then gain access to extra services offered by the operator. 325 To prevent unauthorised receivers from providing undesirable routing 326 information, routing protocols running on top of the LLTM must use 327 authentication mechanisms when available. As a result, a feed would 328 only take into account routing messages which are authenticated, non- 329 authenticated messages simply being discarded. 331 7 Acknowledgments 333 This document is the result of work undertaken by the UDLR working 334 group. 336 I would like to thank, especially, Sir Scott Richardson (UDcast) for 337 his valuable Bristish-style editing comments and the UDteam for the 338 technical inputs. 340 References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 346 2402, November 1998. 348 [RFC2784] Farinacci, D., Hanks, S., Meyer, D. and P. Traina, "Generic 349 Routing Encapsulation (GRE)", RFC 2784, March 2000. 351 [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. 352 Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional 353 Links', RFC 3077, March 2001 355 Author's address 357 Emmanuel Duros 358 UDcast 359 2455, route des Dolines 360 Les Taissounieres - BP 355 361 06906 Sophia-Antipolis Cedex 362 France 363 Phone : +33 4 93 00 16 60 364 Fax : +33 4 93 00 16 61 365 Email : Emmanuel.Duros@UDcast.com