idnits 2.17.1 draft-tschofenig-nsis-natfw-security-problems-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 951. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 935. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 941. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 957), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 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.) ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 12, 2004) is 7227 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) == Unused Reference: 'RFC2119' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nsis-qos-nslp' is defined on line 856, but no explicit reference was found in the text -- No information found for draft-draft-ietf-nsis-ntlp - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.draft-ietf-nsis-ntlp' == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. 'I-D.ietf-nsis-nslp-natfw') == Outdated reference: A later version (-02) exists of draft-aoun-nsis-nslp-natfw-migration-01 == Outdated reference: A later version (-03) exists of draft-iab-model-01 == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-07 == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-12 == Outdated reference: A later version (-11) exists of draft-ietf-kink-kink-05 == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-05 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-01 == Outdated reference: A later version (-14) exists of draft-ietf-sip-connect-reuse-01 == Outdated reference: A later version (-01) exists of draft-manyfolks-signaling-protocol-mobility-00 == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-04 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NSIS H. Tschofenig 2 Internet-Draft Siemens 3 Expires: January 10, 2005 July 12, 2004 5 Path-coupled NAT/Firewall Signaling Security Problems 6 draft-tschofenig-nsis-natfw-security-problems-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 10, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This draft raises some of the open issues in dealing with 40 path-coupled NAT/Firewall signaling and tries to raise awareness of 41 the security issues beyond the NSIS working group. These issues need 42 to be addressed in order to proceed with the security architecture 43 for NAT/Firewall signaling. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. High-level Protocol Overview . . . . . . . . . . . . . . . . . 6 49 2.1 GIMPS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 2.2 NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 9 51 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 12 52 3.1 Security for NAT vs. Firewall Traversal . . . . . . . . . 12 53 3.2 Which Security Protection at Which Layer? . . . . . . . . 13 54 3.3 Different Requirements for Different Parts of the 55 Network . . . . . . . . . . . . . . . . . . . . . . . . . 13 56 3.4 Mobility, Sender Invariance, and Authorization Problems . 14 57 3.5 Dependencies among QoS, NAT, and Firewall Signaling . . . 15 58 3.6 End-to-end security . . . . . . . . . . . . . . . . . . . 16 59 3.7 Asymmetry of Security Protocols . . . . . . . . . . . . . 18 60 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 62 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 65 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 66 8.2 Informative References . . . . . . . . . . . . . . . . . . . 24 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26 68 Intellectual Property and Copyright Statements . . . . . . . . 27 70 1. Introduction 72 The NSIS working group is currently working on three protocols: a 73 lower-layer transport mechanism (NTLP) and two signaling applications 74 (NSLPs). The first signaling application deals with QoS signaling 75 and the other one with NAT/Firewall signaling. The lower-layer 76 transport only carries application-specific payloads between a number 77 of NSIS aware nodes along the path in the forward and the backward 78 direction. 80 The work on path-coupled QoS signaling is the result of efforts on 81 RSVP. The work on path-coupled NAT/Firewall signaling has its origin 82 in the Midcom working group where NAT and Firewall signaling has to 83 cope with network topology problems. The TIST [refs.tist] proposal 84 led to a BOF and the work was moved to the NSIS working group. The 85 approach taken by the Midcom working group assumes that the NAT/ 86 Firewall is known when the signaling protocol starts and that it can 87 be addressed by the entity controlling the midddlebox. A strong 88 trust relationship between the middlebox and the entity controlling 89 the middlebox is assumed. In more complex topologies with multiple 90 NATs and Firewalls the order of these devices need to be considered 91 with respect to the data flow traversing them. Additionally, the 92 entity controlling these devices need to know which device will be 93 hit by which data flow. This often requires some knowledge of the 94 topology. 96 The NSIS approach is different in the sense that this knowledge about 97 the topology is moved to a discovery mechanism, and it becomes the 98 responsibility of the end host to start signaling. 100 This document is organized as follows: Section 1 describes what 101 problem the NAT/Firewall NSLP is going to solve. Section 2 presents 102 a basic protocol model and a high-level description of the messages 103 transmitted, as suggested in [I-D.iab-model]. Section 3 lists 104 challenges and open issues. 106 The approach of path-coupled signaling has some implications: 108 o First, some application logic needs to be added to the end host to 109 control the creation of the NAT binding or Firewall pinholing on a 110 per-flow basis. NSIS allows a proxy in the network to be used to 111 perform this operation on behalf of the end host, but some 112 additional security considerations need to be taken into account. 113 o Due to the soft-state principle it is necessary to refresh the 114 state continual. Otherwise, the established state would be 115 deleted. 116 o Path-coupled signaling for each direction is required to deal with 117 routing asymmetry. 119 o Changes to the routing path (e.g., due to mobility) require 120 periodic re-discovery. The refresh partially addresses this 121 issue, but the effect on the communication in the NAT/Firewall 122 signaling case is more devastating, since data cannot flow to one 123 of the end hosts if packet filters are not established at 124 Firewalls along the path. 125 o The impression exists that Firewalls and NATs are commonly used 126 today and in a way that requires path-coupled signaling. With 127 NATs, a number of protocols deal with creating NAT bindings. but 128 mostly without incorporating security mechanisms between the 129 signaling end points and the NAT(s). With Firewalls the situation 130 is quite different, since deployment heavily depends on the 131 scenario and on the environment. Furthermore, with increasing 132 end-to-end encryption and with protocols heavily overloading HTTP 133 and SIP, it is difficult to estimate the future of traditional, 134 packet-filter-based firewalls (and also for stateful packet 135 filtering firewalls). 137 Security considerations for NAT and Firewall traversal need to be 138 treated separately. 140 In the past, mainly two approaches have been used for establishing 141 NAT bindings: 143 These NAT bindings are typically used to allow data traffic from 144 the outside to be forwarded to a specific host on the inside. 145 Dynamic NAT creation can be categorized into one of the following 146 three categories: 147 * Implicit creation by outbound-initiated communications whereby 148 the translated address and port is selected from a configured 149 address and port pool. 150 * Explicit creation by the Application Layer Gateway(ALG) either 151 via an API call if the NAT and the ALG are co-located or 152 otherwise via a separate protocol. 153 * Separate signaling protocols that requests the creation of a 154 NAT binding 156 An alternative classification is by the trigger for the creation of a 157 NAT binding. In many cases an outbound data packet itself is used to 158 cause the allocation of a NAT binding. Alternatively, a signaling 159 protocol can be used to accomplish the same goal by directly 160 addressing the NAT itself. The Midcom and the NSIS working groups 161 are trying to develop protocols of the latter category. 163 There is little doubt that a user needs to have sufficient rights (or 164 be authorized) to create packet filters at a Firewall. The Midcom 165 working group addressed this aspect in a convenient way, since trust 166 between the middlebox and the entity controlling the middlebox is 167 assumed. In most scenarios these two entities belong to the same 168 administrative domain. Another common 'firewall' uses cryptographic 169 data protection with IPsec. Protocols for establishing IPsec 170 security associations already exists with IKE [RFC2409], KINK 171 [I-D.ietf-kink-kink] and IKEv2 [I-D.ietf-ipsec-ikev2], and hence 172 there is little motivation to focus on these cases. 174 2. High-level Protocol Overview 176 NSIS decided to use a two-layer architecture with one lower-layer 177 transport (NTLP) and multiple upper-layer application signaling 178 protocols (NSLPs). The NTLP itself is meaningless if it is not used 179 in conjunction with an upper-layer NSLP. An upper layer protocol, 180 such as the NAT/Firewall NSLP, cannot work without the lower layer. 181 The layering provides a functional split and has to ensure that 182 future applications can be easily integrated without modifying other 183 parts of the protocol. 185 This two-layer architecture is explained and the relationship between 186 the GIMPS and the NTLP is described in [I-D.ietf-nsis-fw]. For this 187 document the difference between the GIMPS and the NTLP is not too 188 important. 190 This section addresses the protocol functionality of the NAT/Firewall 191 NSLP and also the NTLP, since the former depends on the latter. 193 2.1 GIMPS 195 GIMPS (see [I-D.draft-ietf-nsis-ntlp]) establishes installed NTLP 196 "routing" state, which allows signaling messages to be routed 197 backwards along the same path. This is not possible without 198 installed state (or similar mechanisms such as record route) due to 199 routing asymmetry. This state is different from application-specific 200 state (such as QoS reservations). 202 GIMPS provides two ways to send signaling messages: 204 o The first is an RSVP-like signaling style with end-to-end 205 addressed messages. The end-to-end addressed message contains the 206 source and the destination IP addresses of the data flow. The 207 messages are intercepted along the path by NSIS nodes interested 208 in these messages (by using Router Alert Options). The GIMPS 209 specification refers to this as the Datagram mode (D-mode). 210 o The second mode (called Connection mode or C-mode) is used when 211 NSIS nodes are directly addressed. This mode assumes that the 212 discovery procedure has already finished (or the address of the 213 receiving node is known via other means) and information about the 214 node is already available. 216 From the previous description it might be apparent that an important 217 part of the NTLP is its discovery mechanism. Without knowing the 218 next NSIS aware node discovery (either implicit or explicit) is 219 necessary. Providing security for a discovery message is difficult, 220 particularly if standard security protocols should be used. 221 Combining discovery with signaling message delivery is, from a 222 signaling point of view, faster, but security protection is a lot 223 harder. Currently, the GIMPS specification says that D-Mode does not 224 provide security protection. TLS and IPsec are suggested for C-Mode 225 message protection. 227 Figure 1 shows the explicit discovery mechanism. Because it is 228 assumed that an NSIS node is unaware of the topology, it is difficult 229 to protect the discovery procedure against all threats. For example, 230 the querying node might not be able to tell whether a responding node 231 is truly the next NSIS node along the path. Furthermore, the 232 querying node might not know the identity of the responding node and 233 hence authentication cannot provide a sufficient guarantee that this 234 node is an authorized NSIS node. Hence, some authorization mechanism 235 has to exist in the routing infrastructure and in the entire system 236 to ensure that nodes along the path act according to their prescribed 237 roles. Such mechanisms might not exist in ad hoc networks. 238 Unauthorized entities located along the path are able to harm NSIS 239 signaling and some NSIS applications, such as NAT/Firewall NSLP and 240 QoS NSLP. 242 As an example, an adversary along the path not authorized to 243 participate in NSIS signaling observes the NSIS signaling messages 244 and the subsequent data traffic. The adversary is able to learn 245 which IP traffic is allowed to pass the firewall and might learn 246 which QoS treatment a given flow will receive. 248 +----------+ +----------+ 249 | Querying | |Responding| 250 | Node | | Node | 251 +----------+ +----------+ 253 GIMPS-query 254 ----------------------> 255 (Query Cookie) 257 GIMPS-response 258 <---------------------- 259 (Query Cookie, 260 Responder Cookie) 262 Final handshake 263 ----------------------> 264 (Responder Cookie) 266 Figure 1: GIMPS discovery mechanism 268 The discovery mechanism shown in Figure 1 only presents the 269 high-level details. It allows the querying node to learn the IP 270 address of the responding node. Additional functionality, such as 271 discovering NSIS-unaware NATs between these two nodes is under 272 discussion. 274 The usage of two cookies is somewhat unusual and requires 275 explanation. The responder cookie is used to prevent denial of 276 service attacks in the classical sense as used by other protocols, 277 such as SCTP or IKE. The query cookie has to ensure that an 278 adversary does not redirect the discovery message to another NSIS 279 node. This is guaranteed by providing a cookie by the querying node 280 and by returning the same cookie in the response. This mechanism 281 prevents off-path adversaries from flooding the querying node with 282 GIMPS-responses. The querying node uses this cookie to match a 283 request with a pending response. Furthermore, transmitting the query 284 cookie from the responding node to the querying node after a security 285 association is established between the two ensures that the responder 286 has actually participated in the discovery exchange (i.e., the 287 discovery procedure is bound to the subsequent exchange). 289 Once the next NSIS node is known, a messaging association can be 290 established between these two nodes using C-mode. The same procedure 291 is repeated again and again for the C-Mode until the last GIMPS node 292 is reached. Note that the NSIS signaling does not necessarily need 293 to terminate at the data flow receiver. The data flow receiver might 294 not be NSIS capable, and some other node along the path (e.g., the 295 access router) might act on his behalf. 297 The GIMPS protocol itself is only executed between NSIS peers, and 298 they also implement the signaling application. There are no GIMPS 299 nodes along the path that do not contain an upper layer signaling 300 application. This is, both an architectural principle and a 301 technical protocol design simplification. As with other protocols, 302 such as Diameter, security mechanisms at the "lower-layer" prevent 303 certain attacks at both layers between two NSIS nodes and allow 304 standard channel security mechanisms to be used. 306 2.2 NAT/Firewall NSLP 308 Currently, the NAT/Firewall NSLP description (see 309 [I-D.ietf-nsis-nslp-natfw]) mostly analyses the different problems 310 and challenges, describes trust relationships and motivates the 311 different scenarios where the protocol is used. 313 Unlike other protocols, little information is actually carried in the 314 NSLP beyond the information carried at the NTLP: information about a 315 created NAT binding, as well as lifetime and signaling information 316 (such as protocol headers and error messages). Information about the 317 flow identifier and the session identifier is carried in the NTLP. 318 Currently no additional security payloads at the NSLP layer are 319 specified. 321 The most valuable part of these information elements is the flow 322 identifier (in most cases a 5-tuple but in some cases not completely 323 known to the sender and/or the receiver at the time of transmitting a 324 message). As an example, a data sender might indicate which source 325 port, protocol type and source IP address has to be used, but it 326 cannot know the public IP address, of the NAT binding yet since it is 327 up to the protocol execution to establish and learn this NAT binding. 329 It is useful to distinguish between two signaling modes: 331 The first mode (CREATE) is the traditional way of creating a NAT 332 binding by sending a message from the data sender along the path 333 to the data receiver. Figure 2 shows a message exchange for this 334 signaling mode. 336 The second mode (RESERVE) is used when a data receiver is behind a 337 NAT and wants to establish a NAT binding to allow incoming data 338 traffic. Figure 3 shows this mode. It was necessary to introduce 339 this mode, because path-coupled signaling in the traditional sense 340 is not immediately applicable. 342 Private Address Public Address 343 +----------+ Space +----------+ Space +----------+ 344 | Data | | NAT | | Data | 345 | Sender | | | | Receiver | 346 +----------+ +----------+ +----------+ 347 | | | 348 | Create | Create | 349 |----------------------------->+--------------------------->| 350 | | | 351 | Succeeded/Error | Succeeded/Error | 352 |<-----------------------------+<---------------------------| 353 | | | 354 ============================================================> 355 Direction of data traffic 357 Figure 2: CREATE Mode 359 With the CREATE mode shown in Figure 2 the data sender (which happens 360 to be the NSIS initiator in this case) sends a message to request a 361 NAT binding to be created. The message is targeted to the data 362 receiver (or even to any node in the Internet), which returns a 363 success or failure message. The data sender learns about the new NAT 364 binding, as a consequence. 366 Public Internet Private Address 367 +----------+ +----------+ Space +----------+ 368 | Data | | NAT | | Data | 369 | Sender | | | | Receiver | 370 +----------+ +----------+ +----------+ 371 | | | 372 | | Reserve Reserve | 373 | |<---------------------------| 374 | | | 375 | | Return ext addr/Error | 376 | |--------------------------->| 377 | | | 378 ============================================================> 379 Direction of data traffic 381 Figure 3: RESERVE Mode 383 With the RESERVE mode shown in Figure 3 the data receiver behind a 384 NAT creates a NAT binding. This allows data traffic from a node on 385 the Internet to be received. Please note that the RESERVE message is 386 sent in the opposite direction of the data traffic. The RESERVE mode 387 is, in some sense, not path-coupled, since the data receiver starts 388 signaling but, on the other hand, the data sender will send the data 389 traffic to the IP address (and port) allocated at the NAT. 391 It should be noted that in [I-D.ietf-nsis-fw] the RESERVE mode 392 currently requires an additional CREATE message from the data sender 393 to the NAT to activate the binding. This issue is still in 394 discussion. 396 3. Challenges 398 This section highlights some of the challenges discovered. Further 399 details can be found in NAT/Firewall NSlP [I-D.ietf-nsis-nslp-natfw]. 401 3.1 Security for NAT vs. Firewall Traversal 403 As we tried to motivate in Section 1, the creation of NAT bindings is 404 security sensitive but not to the same degree as firewall traversal. 405 Existing proposals for NAT traversal typically do not use a signaling 406 protocol. Instead regular data traffic from the internal to the 407 external network is used. This is also true for IPv4/IPv6 transition 408 mechanisms in case of automatic tunneling. A typical threat against 409 a NAT device is flooding by an adversary that allocates a large 410 number of NAT bindings. If the dynamically allocated NAT bindings 411 are selected from a limited pool of available bindings (in particular 412 if a NAT instead of a NAPT is used) then this might be a real threat. 413 For a NAPT this threat does not seem to be dangerous enough to 414 require special purpose signaling protocols. As a minor note, STUN 415 [RFC3489] and TURN [I-D.rosenberg-midcom-turn] are signaling 416 protocols, but they do not provide additional security for the NAT 417 device when allocating NAT bindings. 419 If security should be provided for creating NAT bindings, then 420 authentication might be useful in cases of misuse (e.g., allocation 421 of too many NAT bindings). More interesting is, however, 422 authorization. In most networks today every node is automatically 423 authorized to create NAT bindings. To support mobility it is 424 possible either to allocate a new NAT binding (approach used today) 425 or to update the state. Updating a NAT binding is security 426 sensitive, since an adversary can modify an existing NAT binding in 427 order to redirect traffic to a third-party victim, to the adversary 428 itself, or even to a black hole. Flooding a third-party entity might 429 be particularly dangerous if the data sender is streaming a large 430 amount of data (possibly over a wireless interface). 432 Since a NAT binding has a life-time, it is necessary to refresh it 433 continually. This mechanism provides a self-healing property, since 434 a new data packet (or a new signaling message) causes either the 435 creation of a new binding or the refresh of the old one. 437 In contrast, firewall pinholing is more security sensitive. Creating 438 or deleting packet filters might easily violate the security policy 439 of a network and might allow an adversary to mount a number of 440 attacks. Only authorized entities are typically allowed to modify 441 packet filters. This requires proper authorization. Authentication 442 will also most like be required, since typically the authenticated 443 identity is used for computing the authorization decision. As 444 described in Figure 5, this might lead to problems with path-coupled 445 signaling. 447 3.2 Which Security Protection at Which Layer? 449 An obvious question is which security mechanisms should be provided 450 at which layers. The choice impacts the performance and deployment. 451 The working group is currently in the stage of investigating the 452 threats, trust relationships, and security properties of the two 453 NSLPs to evaluate the impact on the NTLP. 455 Figure 4 shows the different layers. Providing security protection 456 at both layers between the neighboring entities is not valuable if no 457 additional functionality is provided. Note that if the protection is 458 provided between different entities (non-neighboring NSIS nodes) then 459 such protection is justified. Recent developments in Diameter with 460 regard to CMS [I-D.ietf-aaa-diameter-cms-sec] have shown that there 461 is a tendency not to use additional upper-layer security mechanisms 462 if lower-layer security mechanisms are provided, even if the security 463 properties are different. The same can also be observed in other 464 protocols, such as SIP or even in RSVP where the preferred choice is 465 the Integrity Object and not the mechanisms provided with the 466 Identity Objects. Public-key-based authentication, for example, 467 offered with the Identity Object is not used. 469 +------+ +------+ 470 | NE | | NE | 471 |+----+| |+----+| 472 ||NSLP|| NSLP Security ||NSLP|| 473 || 1 || - - - - - - - - - - - - - || 1 || 474 |+----+| |+----+| 475 | || | | || | 476 |+----+| NTLP Security |+----+| 477 ====||NTLP||============================||NTLP||==== 478 |+----+| |+----+| 479 +------+ +------+ 481 Figure 4: Security at Different Layers 483 3.3 Different Requirements for Different Parts of the Network 485 Since NSIS protocols are executed in an end-to-end fashion with some 486 (and possibly many) NSIS nodes along the path, it is important to 487 consider a large number of usage environments. These environments 488 might impose different requirements on the security protection. At a 489 high level, we can distinguish between intra-domain communication 490 (communication within an administrative domain), inter-domain 491 communication (communication between administrative domains) and 492 finally the communication with the end hosts and the attached 493 network. NSIS, unlike RSVP, does not necessarily need to be executed 494 between the true data sender and data receiver. It is possible to 495 use NSIS within a single administrative domain only. The impact on 496 security of using NSIS in such diverse environments is that different 497 security protocols, not just one, need to be supported. Some 498 architectures use Kerberos, others rely on special authentication and 499 key exchange protocols, and again others rely on public-key-based 500 mechanisms. 502 It is highly desirable to provide some flexibility for the 503 authentication and key exchange protocol. 505 For some NSLPs, such as a quality of service signaling protocol, it 506 is desireable to execute the authorization procedure at an entity 507 where the user is known (typically its home network). This typically 508 implies that the authentication and key exchange protocol is also 509 terminated at the same entity. 511 3.4 Mobility, Sender Invariance, and Authorization Problems 513 The NAT/Firewall NSLP establishes state at possibly several entities 514 between the NSIS initiator and the NSIS responder. Providing 515 authentication of the signaling initiator to each individual node 516 along the path might be possible but not particularly useful, since 517 the initiator is most likely unknown to some middlebox along the 518 path. Hence, authentication per se does not solve the security 519 problem. 521 If authentication is only provided to some entities along the path 522 (most likely to the neighboring NSIS nodes), then information about 523 the initiator of the session is known to some NSIS nodes (except for 524 the session identifier, which does not change along the path and over 525 the lifetime of a session). Now, with the introduction of mobility 526 it might be possible that intermediate NSIS nodes need some assurance 527 that a particular sender is the owner of a session. No other entity 528 should be allowed to modify state since this would allow certain 529 attacks. In some respect this issue is similar to the authorization 530 property in Mobile IP where the mobility binding needs to be 531 protected against unauthorized modifications. 533 It seems that the property of "sender Invariance" is required in this 534 case: "A party is assured that the source of the communication has 535 remained the same as the one that started the communication, although 536 the actual identity of the source is not important to the recipient." 537 The interactions among security, mobility, session ownership, and 538 authorization are subject to ongoing discussions in 539 [I-D.manyfolks-signaling-protocol-mobility]. 541 3.5 Dependencies among QoS, NAT, and Firewall Signaling 543 Routing asymmetry has to be considered for firewalls but is not 544 applicable to NAT-only signaling. In the presence of NATs, we are 545 always sure that the forward path and the backward path are same with 546 regard to the NAT boxes, since the NAT forces the IP packets to flow 547 through these devices. But, in the presence of firewalls, the 548 forward and the backward routes may be different. A solution needs 549 to focus on the more difficult case where the routes are different. 550 In the forward direction some rules are established in the traversed 551 firewalls. In the reverse direction, if a different route is taken, 552 the packets might be blocked by some other firewall. 554 It is important to study the relationship between NSIS signaling and 555 other application protocols (such as SIP) and also between different 556 NSIS signaling applications themselves. Different NATs and firewalls 557 can be found along the path, and the worst case needs to be assumed. 558 As we argue in NAT-FW [I-D.ietf-nsis-nslp-natfw], it is always 559 possible with mobility that an end host finds itself located behind a 560 NAT. Before NSIS can start, the NSIS initiator needs to know the 561 destination IP address, since this is an integral part of 562 path-coupled signaling. This might, however, already assume some 563 application layer signaling exchange. The IP address information 564 exchanged during this exchange might, however, be wrong due to the 565 presence of a NAT. In some scenarios (e.g., receiver behind a NAT) 566 NSIS signaling might need to start beforehand. With NSIS QoS 567 signaling it is also necessary to avoid breaking this type of 568 signaling application. The NSIS NAT/Firewall NSLP does not aim to 569 learn topology information but rather to create NAT bindings and 570 firewall pinholes and to make information about the NAT binding 571 available to the end host. In a short memo on NAT handling in NSIS 572 (see [nat-memo]) we argue that it is necessary to incorporate a 573 mechanisms for learning the presence of NSIS unaware nodes into the 574 GIMPS discovery procedure. Additionally, it is necessary to modify 575 the flow identifier of the QoS signaling message at the corresponding 576 NAT device along the path to reflect the address change. An NSIS 577 initiator should not need to know where this address translation 578 takes place; this would require topology information. Providing the 579 necessary flow identifier modification in addition to the 580 installation of a QoS reservation would be useful. 582 One question is therefore how much NAT handling needs to be 583 incorporated into the NTLP and into every NSLP to support proper 584 signaling behavior. If NAT handling is added to the QoS signaling, 585 then it automatically inherits the authorization applied to QoS 586 signaling. Should this procedure be extended to Firewall signaling? 587 Does the right to make a QoS reservation imply the right to traverse 588 the firewall? 590 3.6 End-to-end security 592 Securing the communication between neighboring NAT/FW NSLPs with a 593 chain of trust is a convenient assumption that allows simplified 594 signaling message processing. However, it might not always be 595 applicable, especially between two arbitrary networks. We assume 596 that NATs and firewalls are typically located in the access networks 597 and are typically not found in the core network. Hence, two 598 observations follow: 600 o The two access networks (and the firewalls/NATs in these networks) 601 do not trust each other or they might not even know of each other. 602 o The end host might have a trust relationship with the local access 603 network that allows it to create firewall pinholes. However, it 604 cannot be assumed that the end host of one network is able to 605 create packet filters at another network. In the example of 606 Figure 5 Host A is not authorized to create pinholes at Middlebox 607 2. A trust relationship exists only between Host B and Middlebox 608 2. This scenario represents a scenario in which two employees of 609 two companies want to communicate through their corporate network 610 firewalls. Company B trusts it own employees but not employees of 611 company A. 613 In [I-D.ietf-nsis-nslp-natfw] we describe three possible approaches 614 to tackle this problem. None of these three approaches is without 615 drawbacks. We have chosen the one approach that assumes the 616 signaling message is sent end-to-end and each end host contributes 617 its part to the authorization decision. Furthermore, we have to 618 assume that the NSIS signaling message is allowed to bypass the 619 firewall (without installing a packet filter at this stage of the 620 protocol) to reach the other end host. 622 Based on Figure 5 the authorization steps can be described as 623 follows: Host A starts with the NSIS signaling message exchange and 624 has to authenticate itself to Middlebox 1. Middlebox 1 authorizes 625 Host A to create a pinhole based on the existing trust relationship. 626 Then the signaling message is forwarded along the path and 627 intercepted by Middlebox 2. No trust relationship between 628 Middleboxes 1 and 2 or between Host A and Middlebox 2 exists. Hence, 629 Middlebox 2 does not authorize the pinhole creation. For more 630 restrictive firewalls an error message is returned to Host A, but in 631 our scenario the NSIS signaling message is forwarded to Host B ( the 632 final destination of the signaling message exchange). Host B 633 verifies that the signaling message is provided from a trusted 634 device, might already expect an incoming message based on some 635 application layer signaling exchange with Host A, and returns a 636 response message. Middlebox 2 authorizes Host B's request for 637 pinhole creation due to the existing trust relationship. The message 638 travels back to Host A, which receives a positive confirmation that 639 the signaling message exchange is successful. Host A can start 640 transmitting data packets. 642 Please note that if Middlebox 2 is actually a NAT (instead of a 643 firewall) then the scenario for a receiver behind a NAT is 644 applicable, which allows Host B to perform signaling locally without 645 the above-described complications. This is one of the other 646 solutions described in [I-D.ietf-nsis-nslp-natfw]. 648 +---------------------+ +-----------------------+ 649 | Network A | Internet | Network B | 650 | +---------+ +---------+ | 651 | +---->+ Middle- +<------------>+ Middle- +<----+ | 652 | | ...>| box 1 | | box 2 |<....| | 653 | | . +---------+ +---------+ .| | 654 | | . | | .| | 655 | | . | | .| | 656 | | . | | .| | 657 | v v | | vv | 658 | +--+-+-+ | | +--+---+ | 659 | | Host | | | | Host | | 660 | | A | | | | B | | 661 | +------+ | | +------+ | 662 +---------------------+ +-----------------------+ 663 -----: NSIS Communication 664 .....: Trust Relationship 666 Figure 5: Authorization Problems 668 Without a proper binding of the NSIS to application signaling , Host 669 B might suddenly receive an NSIS signaling message that indicates a 670 firewall pinhole has to be created. Host B does not know which end 671 host requested this NAT binding nor for which reason. Hence it might 672 be reasonable to think about providing end-to-end security (via a 673 binding between NSIS signaling and the application signaling) as an 674 option to provide the receiving node stronger guarantees about the 675 entity requesting certain actions. It has to be noted that other 676 NSIS signaling scenarios in which intermediate nodes start (or 677 terminate) NSIS signaling on behalf of the end hosts might be much 678 more difficult to deploy along with end-to-end security. 680 The main questions raised by this section are whether the described 681 observations are correct and whether it seems possible to make the 682 assumption that an NSIS signaling message be allowed to traverse the 683 packet filter firewall. Furthermore, it needs to be studied whether 684 end-to-end security provides better properties. 686 It is worth noting that the observation such a need of this 687 application layer signaling to NSIS signaling binding is raised in 688 [I-D.aoun-nsis-nslp-natfw-migration]. 690 3.7 Asymmetry of Security Protocols 692 Some security protocols operate asymmetrically, which leads to 693 unpleasant consequences for the NSIS protocol suite. The Transport 694 Layer Security protocol (TLS) [RFC2246], IKEv2 695 [I-D.ietf-ipsec-ikev2], and also custom security protocols (such as 696 those provided with RSVP Identity Representation and, for example, 697 Kerberos [RFC3182]). NAT/Firewall NSLP signaling messages travel 698 along a path between the NSIS initiator and the NSIS responder 699 containing a number of entities that act in different roles. Due to 700 the routing asymmetry it is necessary to start signaling from both 701 end hosts (one signaling exchange for each data flow direction). In 702 IKEv2 the security properties of the initiator and the responder are 703 different with respect to denial of service protection and support 704 for the Extensible Authentication Protocol (EAP) 705 [I-D.ietf-eap-rfc2284bis]. This is also the case if an end host 706 wants run TLS with unilateral authentication (NSIS entity in the 707 network to the end host) with upper layer client-side authentication. 708 This type of exchange might be typical for QoS signaling, since 709 authorization has to be executed at entities other than those 710 executing the security protocol. From a deployment point of view it 711 is simpler to have public key based authentication of the network to 712 the user than to support a client-side PKI. Such a client-side PKI 713 is, however, necessary when the roles are reversed. Figure 6 shows 714 this problem graphically. Unfortunately, TLS cannot reverse its 715 roles and cannot reuse the session cache for the reverse direction. 716 This problem was also observed in the context of SIP, where 717 [I-D.ietf-sip-connect-reuse] provides a solution to reuse an 718 established TCP or TLS connection that was established based on a SIP 719 REGISTER before a SIP INVITE (or similar message) is used. NSIS, 720 however, has no provision to support separate 'registration' and a 721 'end-to-end' signaling message exchanges due to the path-coupled 722 property. 724 +---------------------+ +-----------------------+ 725 | Network A | Internet | Network B | 726 | +---------+ +---------+ | 727 | +---->+ NSIS +------------->+ NSIS +-----+ | 728 | | | Entity | | Entity | | | 729 | | | B | | C | | | 730 | | +---------+ +---------+ | | 731 | | | | | | 732 | | | | | | 733 | | | | v | 734 | +--+---+ | | +--+---+ | 735 | | NSIS | | | | NSIS | | 736 +--+Entity+-----------+ +------------+Entity+---+ 737 | A | TLS server TLS client| D | 738 +--+---+ +--+---+ 739 ^ | 740 | v 741 +-----+-------+ +-----+-------+ 742 | NSIS | TLS TLS | NSIS | 743 | Initiator X | client server | Responder Y | 744 +-------------+ +-------------+ 746 Figure 6: Problems with Asymmetric Protocols 748 4. Conclusion 750 This section summarizes and reiterates a few questions addressed in 751 this document: 753 o Is it useful to separate the security aspects for NAT and firewall 754 signaling? 755 o To what extend is end-to-end security important? 756 o How can specific authorization problems be addressed? 757 o What can be done with regard to the properties of asymmetric 758 security protocols? 759 o Are the proposals in [I-D.tschofenig-nsis-sid] adequate to address 760 the sender-invariance property for mobility scenarios? This 761 document, for example describes how to reuse concepts like 762 hash-chains and the Purpose-Built Key mechanism 763 [I-D.bradner-pbk-frame] to provide a mobility solution without a 764 global PKI. 766 5. Security Considerations 768 This entire document addresses security issues of path-coupled NAT/ 769 Firewall signaling. The main intention is to solicit feedback and 770 comments from the community at an early stage of the protocol 771 development. 773 6. Contributors 775 The author would like to thank Richard Graveman for his detailed 776 review. 778 7. Acknowledgements 780 The author would like to thank Cedric Aoun, Marcus Brunner, Srinath 781 Thiruvengadam, Martin Stiemerling and Miquel Martin for their time to 782 discuss many NAT/Firewall related issues. 784 8. References 786 8.1 Normative References 788 [I-D.draft-ietf-nsis-ntlp] 789 Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 790 Messaging Protocol for Signaling", 791 draft-draft-ietf-nsis-ntlp-00 (work in progress), October 792 2003, . 794 [I-D.ietf-nsis-nslp-natfw] 795 Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, 796 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 797 draft-ietf-nsis-nslp-natfw-02 (work in progress), May 798 2004, . 800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 801 Requirement Levels", March 1997. 803 [draft-tschofenig-nsis-sid] 804 Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. 805 and X. Fu, "Security Implications of the Session 806 Identifier", June 2003. 808 8.2 Informative References 810 [I-D.aoun-nsis-nslp-natfw-migration] 811 Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H. 812 Tschofenig, "NAT/Firewall NSLP Migration Considerations", 813 draft-aoun-nsis-nslp-natfw-migration-01 (work in 814 progress), February 2004, 815 . 817 [I-D.bradner-pbk-frame] 818 Bradner, S., Mankin, A. and J. Schiller, "A Framework for 819 Purpose-Built Keys (PBK)", draft-bradner-pbk-frame-06 820 (work in progress), June 2003, 821 . 823 [I-D.iab-model] 824 Rescorla, E., "Writing Protocol Models", 825 draft-iab-model-01 (work in progress), May 2004, 826 . 828 [I-D.ietf-aaa-diameter-cms-sec] 829 Calhoun, P., Farrell, S. and W. Bulley, "Diameter CMS 830 Security Application", draft-ietf-aaa-diameter-cms-sec-04 831 (work in progress), March 2002, 832 . 834 [I-D.ietf-eap-rfc2284bis] 835 Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H. 836 Levkowetz, "Extensible Authentication Protocol (EAP)", 837 draft-ietf-eap-rfc2284bis-07 (work in progress), December 838 2003. 840 [I-D.ietf-ipsec-ikev2] 841 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 842 draft-ietf-ipsec-ikev2-12 (work in progress), January 843 2004, . 845 [I-D.ietf-kink-kink] 846 Thomas, M. and J. Vilhuber, "Kerberized Internet 847 Negotiation of Keys (KINK)", draft-ietf-kink-kink-05 (work 848 in progress), January 2003, 849 . 851 [I-D.ietf-nsis-fw] 852 Hancock, R., "Next Steps in Signaling: Framework", 853 draft-ietf-nsis-fw-05 (work in progress), October 2003, 854 . 856 [I-D.ietf-nsis-qos-nslp] 857 Bosch, S., "NSLP for Quality-of-Service signaling", 858 draft-ietf-nsis-qos-nslp-01 (work in progress), October 859 2003, . 861 [I-D.ietf-sip-connect-reuse] 862 Mahy, R., "Connection Reuse in the Session Initiation 863 Protocol (SIP)", draft-ietf-sip-connect-reuse-01 (work in 864 progress), February 2004, 865 . 867 [I-D.manyfolks-signaling-protocol-mobility] 868 Bless, R., "Mobility and Internet Signaling Protocols", 869 draft-manyfolks-signaling-protocol-mobility-00 (work in 870 progress), January 2004, 871 . 873 [I-D.rosenberg-midcom-turn] 874 Rosenberg, J., "Traversal Using Relay NAT (TURN)", 875 draft-rosenberg-midcom-turn-04 (work in progress), 876 February 2004, . 878 [I-D.tschofenig-nsis-sid] 879 Tschofenig, H., "Security Implications of the Session 880 Identifier", draft-tschofenig-nsis-sid-00 (work in 881 progress), June 2003, 882 . 884 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 885 RFC 2246, January 1999, . 887 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 888 (IKE)", RFC 2409, November 1998, . 890 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 891 Herzog, S. and R. Hess, "Identity Representation for 892 RSVP", RFC 3182, October 2001, . 894 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, 895 "STUN - Simple Traversal of User Datagram Protocol (UDP) 896 Through Network Address Translators (NATs)", RFC 3489, 897 March 2003, . 899 [nat-memo] 900 Tschofenig, H., "Memo about NSIS NAT Handling, available 901 at: http://www.tschofenig.com/drafts/NSIS-NAT-Handling.txt 902 (Feb. 2004)", February 2004, . 904 [refs.tist] 905 Shore, M., "The TIST (Topology-Insensitive Service 906 Traversal) Protocol", DRAFT draft-shore-tist-prot-00.txt, 907 May 2002. 909 Author's Address 911 Hannes Tschofenig 912 Siemens 913 Otto-Hahn-Ring 6 914 Munich, Bayern 81739 915 Germany 917 EMail: Hannes.Tschofenig@siemens.com 919 Intellectual Property Statement 921 The IETF takes no position regarding the validity or scope of any 922 Intellectual Property Rights or other rights that might be claimed to 923 pertain to the implementation or use of the technology described in 924 this document or the extent to which any license under such rights 925 might or might not be available; nor does it represent that it has 926 made any independent effort to identify any such rights. Information 927 on the procedures with respect to rights in RFC documents can be 928 found in BCP 78 and BCP 79. 930 Copies of IPR disclosures made to the IETF Secretariat and any 931 assurances of licenses to be made available, or the result of an 932 attempt made to obtain a general license or permission for the use of 933 such proprietary rights by implementers or users of this 934 specification can be obtained from the IETF on-line IPR repository at 935 http://www.ietf.org/ipr. 937 The IETF invites any interested party to bring to its attention any 938 copyrights, patents or patent applications, or other proprietary 939 rights that may cover technology that may be required to implement 940 this standard. Please address the information to the IETF at 941 ietf-ipr@ietf.org. 943 Disclaimer of Validity 945 This document and the information contained herein are provided on an 946 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 947 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 948 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 949 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 950 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 951 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 953 Copyright Statement 955 Copyright (C) The Internet Society (2004). This document is subject 956 to the rights, licenses and restrictions contained in BCP 78, and 957 except as set forth therein, the authors retain all their rights. 959 Acknowledgment 961 Funding for the RFC Editor function is currently provided by the 962 Internet Society.