idnits 2.17.00 (12 Aug 2021) /tmp/idnits31939/draft-tschofenig-nsis-casp-midcom-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages 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 28 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 721: '...ations are used: MAY (O), MUST NOT (--...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1272 has weird spacing: '...aversal with ...' == Line 1362 has weird spacing: '...gnaling only ...' -- 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 (23 October 2002) is 7150 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) -- Missing reference section? '1' on line 1700 looks like a reference -- Missing reference section? '2' on line 1704 looks like a reference -- Missing reference section? '3' on line 1708 looks like a reference -- Missing reference section? '4' on line 1712 looks like a reference -- Missing reference section? '5' on line 1715 looks like a reference -- Missing reference section? '6' on line 1719 looks like a reference -- Missing reference section? '7' on line 1722 looks like a reference -- Missing reference section? '8' on line 1726 looks like a reference -- Missing reference section? 'Response' on line 1036 looks like a reference -- Missing reference section? '20' on line 1651 looks like a reference -- Missing reference section? '9' on line 1729 looks like a reference -- Missing reference section? '10' on line 1733 looks like a reference -- Missing reference section? '11' on line 1737 looks like a reference -- Missing reference section? '12' on line 1741 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft H. Tschofenig, H. Schulzrinne 4 Siemens/Columbia U. 5 draft-tschofenig-nsis-casp-midcom-00.txt 6 23 October 2002 7 Expires: January 2003 9 A Firewall/NAT Traversal Client for CASP 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as 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 material 23 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 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes a CASP client protocol that allows nodes to 34 signal information to firewalls mainly in an in-path fashion. 35 The protocol furthermore allows the signaling initiator to establish 36 and/or learn a NAT binding. This information can then be used 37 within other protocols such as SIP. 39 1 Introduction 41 CASP-Midcom is a client protocol for the Cross-Application Signaling 42 Protocol (CASP) [1]. It is one of a family of CASP client protocols and 43 allows the signaling of firewall information along the data path (in- 44 path) in a topology independent manner. CASP-Midcom aims to address 45 issues raised in the MIDCOM working group [2] and uses ideas for in-path 46 signaling using RSVP as described in [3] and in [4]. CASP-Midcom aims to 47 provide a long-term solution to the MIDCOM problem with the following 48 properties: 50 Routing of Signaling Messages: CASP with its scout discovery 51 mechanisms allows signaling messages to follow the path of the 52 data traffic towards a destination. This assumes that standard 53 routing is used. CASP, however, operates independent of the 54 underlying routing mechanism. Route changes can be detected by 55 the scout protocol and signaling message transmission is 56 adopted accordingly. Other mechanisms for detecting route 57 changes can also be used such as routing protocols. 59 Security Protection: Creating holes into a firewall is a sensitive 60 task that requires trust and an appropriate security 61 protection of the signaling messages in order to be 62 successful. Trust assumptions between the participating 63 entities thereby determine whether the task of installing 64 packet filters at a firewall is possible at all. CASP-Midcom 65 thereby reuses the security mechanisms introduced by CASP. 66 Still some additional security mechanisms described in this 67 document have to be used to provide secure protocol operation. 69 Sender/Receiver Initiated: CASP signaling can be executed in 70 sender- and receiver initiated mode. Establishment of firewall 71 packet filter information is usually done in a asymmetric 72 manner e.g. establishment of unidirectional Traffic Selectors 73 at firewalls. 75 Flexibility in Message Delivery: Signaling messages can be 76 triggered by any node along the path. In most cases, however, 77 it is the responsibility of the signaling message initiator 78 (typically the end host) to provide the necessary information 79 which policy rules to install. CASP messages might terminate 80 at any CASP peer along the path. Hence it is not necessary to 81 forward the messages to the final destination. The decision 82 whether to furthermore forward the signaling message toward 83 the destination can be caused by the initiator (by including 84 CASP specific information) or the decision could also be 85 forced for example by a non CASP-aware firewall. Such a device 86 might not forward CASP message. Another example is an 87 authorization failure generated because of lacking trust (and 88 proper credentials by the signaling initator). 90 Error Resilience: CASP was designed based on the soft-state 91 principle to allow orphan states to time-out automatically. 93 End Host Topology Unawareness: Routing signaling messages along the 94 data path allows CASP aware nodes to reflect topology 95 information into the processing of CASP signaling messages. 96 Processing of Traffic Selectors is an example where local 97 topology and protocol information need to be available to 98 ensure proper behavior. Traffic Selector handling is already 99 defined in CASP [1]. Defining them at the CASP M-Layer is 100 necessary since this object is used by more than one client 101 layer protocol. The Traffic Selector used in CASP-QoS [5] 102 messages might be also require modification by a NAT along the 103 path. Mid-path modification of the Traffic Selector allows 104 the end host to be topology unaware. If topology information 105 needs to be incorporated into the signaling message processing 106 then it should be done at the locations where the 107 corresponding information is easily available (for example at 108 the individual CASP-Midcom aware nodes along the path). 110 2 Definitions 112 Trust Relationship: The term trust relationship and the 113 subcategories is used at various places in this document. 114 Since its meaning might confuse some readers a short 115 description is given in this section. CASP is a protocol for 116 establishing state information within a possibly large number 117 of network elements. Unlike to typical end-to-end 118 communication protocols there is more than one mean to 119 establish trust: end-to-end, end-to-middle, between 120 neighboring peers and between non-neighboring peers. Figure 1 121 describes these options graphically: 123 The existence of a security association (statically or 124 dynamically created) requires some degree of trust. However, 125 it does not necessarily lead to the necessary degree of trust 126 to allow certain operations to be executed (authorization). 127 Hence in this case the term trust is not equal to the 128 existence of a security association. With the creation of 129 policy rules at firewalls additional trust might be required 130 in addition to a chain-of-trust where only neighboring peers 131 trust each other. The principle of chain-of-trust is a 132 frequently used concept in the area of QoS signaling 133 protocols. In Section 2 of [6] the concept is described in 134 **************************************** 135 * * 136 * * 137 +----+-----+ +----------+ +----+-----+ 138 +-----+ Firewall +-------+ Firewall +--------+ Firewall +-----+ 139 | | 1 | | 2 | | 3 | | 140 | +----------+ +----+-----+ +----------+ | 141 | ~ | 142 | ~ | 143 | ~ | 144 | ~ | 145 | ~ | 146 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 147 | ~ | 148 | ~ | 149 +--+--++ +--+---+ 150 | Host +//////////////////////////////////////////////////////+ Host | 151 | A | | B | 152 +------+ +------+ 154 Legend: 155 -----: Peer-to-Peer Trust Relationship 156 /////: End-to-End Trust Relationship 157 *****: Middle-to-Middle Trust Relationship 158 ~~~~~: End-to-Middle Trust Relationship 160 Figure 1: Possible Trust Relationships 162 more detail. 164 Policy Rule: The term policy rule is used as defined in [7]. Other 165 frequently used terms are packet filters, filter rules or 166 firewall rules. In addition to the Traffic Selector attributes 167 an action has to be specified. Since it was agreed not to 168 allow deny rules there are only two possible actions: allow 169 without logging and allow with logging. Per-default no 170 logging is defined - the Traffic Selector attribute is used 171 without any modification. If logging is desired then it has to 172 be specified as described in Section 8. As stated in [7] it 173 was agreed not to specify a deny action for policy rule. 174 Hence there is no such deny action defined in this document. 176 Policy Groups: The term policy group is not used in this document 177 since its meaning is partially captured by the Traffic 178 Selector functionality introduced in CASP. CASP allows various 179 Traffic Selector attributes (even lists and ranges of certain 180 attributes) to be specified. In case of in-path discovery only 181 one IP destination address can be specified inside the Traffic 182 Selector in the generic case since it is used routing (and 183 hence also used by the scout in-path discovery protocol). For 184 off-path signaling this rule must not hold. 186 Lifetime of Policy Rules: It is worth mentioning that the lifetime 187 specified for policy rules is equal to the established state 188 at the C-layer. For the lifetime the following rule applies: 189 lifetime(C-Layer) less-or-equal lifetime(M-Layer) less-or- 190 equal lifetime(T-Layer). Since the Transport-Layer (T-Layer) 191 is shared by many M-Layer session its lifetime is not 192 explicitly specified. The lifetime of the T-Layer might depend 193 on the local policy but usually it is removed as soon as all 194 M-Layer states expired. 196 Traffic Selector (TS): The term Traffic Selector refers to 197 attributes describing subsets of a data traffic for which a 198 specific behavior should be assigned. In case of firewall 199 traversal the term Traffic Selector refers to policy rules (or 200 policy groups in case that it is more generalized). The term 201 flow identifier is also often used in the area of QoS 202 signaling protocols. For a NAT traversal a Traffic Selector 203 refers to the NAT binding. 205 There is furthermore a one-to-one relationship between a M- 206 layer and a C-layer (state defined in this document including 207 policy rules and other parameters) state. If a particular M- 208 layer state is removed then also the corresponding C-layer 209 state has to be removed. The identification of the both states 210 (M-layer and C-layer) is done based on the 128-bit session 211 identifier. 213 3 Trust Relationships 215 It is unusual to start a protocol description with trust relationships 216 to explain the basic protocol behavior. A protocol for firewall 217 traversal is somewhat different since trust relationships are very 218 important for the protocol design and for its internal mechanisms. It is 219 worth noting that NAT traversal does not cause problems to the same 220 degree. 222 3.1 Peer-to-Peer Trust Relationship 224 The following scenarios can be considered as the simplest since peer-to- 225 peer trust relationship exist between the participating entities. These 226 trust relationships are either pre-existing or can be dynamically 227 established (for example between Host A and the local middlebox i.e. 228 Middlebox 1 within Network A) as part of the execution of a security 229 protocol. Authentication and authorization of the request to the 230 middlebox device is thereby required for successful protocol completion. 231 Important in this context is the trust relationship between the two 232 networks (i.e. between Middlebox 1 and Middlebox 2). In this scenario it 233 is assumed that no firewall is present within the core network. In case 234 that Middlebox requires authentication of the Host A (or from the user 235 located at Host A) then an "Authentication Required" RESPONSE message 236 with an error code is returned to the initiator. In case of a sender- 237 initiated signaling message transmitted by Host A the requested filter 238 entries at the first middlebox are already installed when the request at 239 the subsequent middlebox fails. 241 Since end hosts usually do not have (and should not have) topology 242 information of the networks along the path it is not possible to 243 transmit Traffic Selectors for both directions (if data traffic later 244 flows in both directions). Hence it is required that both nodes 245 transmit separate signaling messages for each direction containing 246 separate Traffic Selectors for each traffic flow (if the data traffic is 247 later sent in both directions). These signaling messages are transmitted 248 by the end hosts and they do not need to travel along the same path. 249 Therefore the signaling message in both directions do not necessarily 250 install state at the same firewall. 252 Policy rules installation is based on the information transmitted with 253 the Traffic Selector object. Traffic Selectors can change mid-path (for 254 example when passing a NAT) and are allowed to change mid-session (for 255 example because of mobility). For those cases where the information 256 transported within a Traffic Selector object cannot be interpreted an 257 error message is returned indicating the inadequate information. Traffic 258 Selector processing failures are possible when for example a Virtual 259 Private Network Identifier such as (Extended) Tunnel ID is transmitted 260 to an IP firewall. 262 3.2 Intra-domain Trust Relationship 264 In larger corporations often more than one firewall is used to protect 265 different departments. In many cases the entire enterprise is 266 controlled by a security department which gives instructions to the 267 department administrators. In such a scenario a peer-to-peer trust- 268 relationship might be prevalent. Sometimes, however, it might be 269 necessary to preserve authentication and authorization information 270 within the network. In this case an interaction between the individual 271 middleboxes and a central entity (for example a policy decision point - 272 PDP) might be required. Each middlebox can either communicate with the 273 +--------------------------+ +--------------------------+ 274 | | | | 275 | Network A | | Network B | 276 | | | | 277 | +---------+ +---------+ | 278 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 279 | | | box 1 | Trust | box 2 | | | 280 | | +---------+ Relationship +---------+ | | 281 | | | | | | 282 | | | | | | 283 | | | | | | 284 | | Trust | | Trust | | 285 | | Relationship | | Relationship | | 286 | | | | | | 287 | | | | | | 288 | | | | | | 289 | +--+---+ | | +--+---+ | 290 | | Host | | | | Host | | 291 | | A | | | | B | | 292 | +------+ | | +------+ | 293 +--------------------------+ +--------------------------+ 295 Figure 2: Peer-to-Peer Trust Relationship 297 PDP or the PDP issues an authorization token which allows the 298 middleboxes to react independently. Figure 3 refers to this structure. 299 To avoid complex protocol interactions individual middleboxes within an 300 administrative domain should make use of their trust relationship 301 instead of challenging the signaling message originator. 303 3.3 Required End-to-Middle Trust Relationship 305 In some scenarios a simple peer-to-peer trust relationship between 306 participating nodes is not sufficient. Network B might require some 307 proof of identity of the signaling message originator. If such a proof 308 is not included in the signaling message arriving at Middlebox 2 then a 309 RESPONSE message with an error code "Authentication Required" is 310 returned. However, in many cases the user initiating the signaling 311 message exchange is already aware of such a constraint and received 312 credentials before the message exchange was started. These credentials 313 might be based either on symmetric (shared secret) or based on 314 asymmetric (public key) cryptography. In order to avoid a 315 challenge/response type of message exchange and to reuse the CASP 316 +---------------------------------------------------------------+ 317 | | 318 | Network A | 319 | | 320 | | 321 | +---------+ +---------+ 322 | +----///--------+ Middle- +------///------++ Middle- +--- 323 | | | box 2 | | box 2 | 324 | | +----+----+ +----+----+ 325 | | | | | 326 | +----+----+ | | | 327 | | Middle- +--------+ +---------+ | | 328 | | box 1 | | | | | 329 | +----+----+ | | | | 330 | | | | | | 331 | - | | | | 332 | - | +----+-----+ | | 333 | | | | Policy | | | 334 | +--+---+ +-----------+ Decision +----------+ | 335 | | Host | | Point | | 336 | | A | +----------+ | 337 | +------+ | 338 +---------------------------------------------------------------+ 340 Figure 3: Intra-domain Trust Relationship 342 security mechanisms the initiating node (Host A in this case) already 343 includes a CMS object to the outgoing signaling message. The CMS object 344 contains the identity of the signaling initiator, the identity of the 345 network, the destination address of Host B, a timestamp for replay 346 protection and possibly some other application specific information like 347 an application identifier. CMS allows to use both symmetric and 348 asymmetric credentials. 350 Figure 4 shows the slightly more complex trust relationships in this 351 scenario. 353 3.4 Missing Network-to-Network Trust Relationship 355 Peer-to-peer trust relationship as shown in Figure 2 is a very 356 convenient assumption that allows simplified signaling message 357 processing. However, it is obvious that such an assumption does not 358 always hold. Especially the trust relationship between two arbitrary 359 +--------------------------+ +--------------------------+ 360 | | | | 361 | Network A | | Network B | 362 | | | | 363 | | Trust | | 364 | | Relationship | | 365 | +---------+ +---------+ | 366 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 367 | | | box 1 | +-------+ box 2 | | | 368 | | +---------+ | +---------+ | | 369 | | | | | | | 370 | |Trust | | | | | 371 | |Relationship | | | | | 372 | | | | | Trust | | 373 | | | | | Relationship| | 374 | | | | | | | 375 | | | | | | | 376 | | | | | | | 377 | | | | | | | 378 | +--+---+ | | | +--+---+ | 379 | | Host +----///----+------+ | | Host | | 380 | | A | |Trust | | B | | 381 | +------+ |Relationship | +------+ | 382 +--------------------------+ +--------------------------+ 384 Figure 4: End-to-Middle Trust Relationship 386 non-adjacent access networks is likely non-existent because of the large 387 number of networks and the unwillingness of administrators to have other 388 network operators to create holes in their firewalls. Hence in the 389 following scenario we assume a somewhat different message processing and 390 show three possible approaches. None of these three approaches is 391 without drawbacks or constraining assumptions. 393 We identified three possible approaches of tackling the problem 394 described in Figure 5. 396 Receiver-Initiated Signaling The first approach makes use of 397 receiver-based signaling message exchange. If Host A sends a 398 signaling message toward the destination to Middlebox 1 the 399 message can be properly protected. Middlebox 1 establishes 400 some state information and expects a incoming message 401 initiated by Host B. Signaling message protection between the 403 +--------------------------+ +--------------------------+ 404 | | | | 405 | Network A | | Network B | 406 | | | | 407 | +---------+ Missing +---------+ | 408 | +-///-+ Middle- | Trust | Middle- +-///-+ | 409 | | | box 1 | Relation- | box 2 | | | 410 | | +---------+ ship +---------+ | | 411 | | | | | | 412 | | | | | | 413 | | | | | | 414 | | Trust | | Trust | | 415 | | Relationship | | Relationship | | 416 | | | | | | 417 | | | | | | 418 | | | | | | 419 | +--+---+ | | +--+---+ | 420 | | Host | | | | Host | | 421 | | A | | | | B | | 422 | +------+ | | +------+ | 423 +--------------------------+ +--------------------------+ 425 Figure 5: Missing Network-to-Network Trust Relationship 427 two networks is difficult. The missing trust relationship does 428 not necessarily mean that no security association 429 establishment is possible. The lacking trust "only" disallows 430 Middlebox 1 to create packet filters at Middlebox 2. If the 431 CASP message itself is allowed to pass the firewall then it 432 finally reaches Host B. Host B should not experience any 433 difficulties to install filters at the local firewall 434 (Middlebox 2). The message is then forwarded to Middlebox 1 435 which already waits for the incoming signaling message. 436 Because it is possible to associate existing state information 437 at Middlebox 1 with the incoming message packet filters are 438 installed and the message is finally forwarded to Host A. 439 Authorization for packet filter installation in Network A has 440 to be provided by Host A and for Network B has to be provided 441 by Host B when returning the response message. Traffic 442 Selectors are installed for data traffic from Host A to Host 443 B. The same procedure has to be applied again to signal 444 information for the other direction (Host B to Host A). 446 The following behavior has to be assumed in order for this 447 approach to be applicable: 449 - CASP signaling messages must be allowed to pass firewalls 450 along the path. Blocking CASP messages at firewalls 451 disallows the receiver of the signaling message to return a 452 signaling message. 454 - The PATH message is assumed to be stateful. 456 This approach suffers from the following drawbacks: 458 - If CASP signaling messages are not allowed to bypass a 459 firewall then no policy rules are create at any node along 460 the path. 462 - Receiver-Initiated signaling has the advantage that the 463 receiver has to accept the creation of the policy rule in 464 his own network to trigger the creation locally. This seems 465 to simplify security processing. If a NAT is present then 466 still a RESPONSE message is required to inform the data 467 message sender about the NAT-binding (i.e. the IP addresses 468 and port information seen by a data traffic receiver). 470 Access Network-Only Signaling Message Exchange The next approach is 471 based on signaling Traffic Selector information by both hosts 472 into the local access network only. CASP allows to specify 473 such a behavior by indicating the signaling endpoint with the 474 help of scoping ( for example with domain name). If packet 475 filters for both directions have to be installed then 476 signaling messages have to make reservations up- and 477 downstream along the data path. Similar to proposals in the 478 area of QoS signaling some problems are likely to occur. One 479 such problem is that downstream reservations in general does 480 not work due to the policy of routing protocols and the 481 asymmetric routes. The problem of triggering downstream 482 reservations is for example described in [8]. Another problem 483 for example is the placement of a firewall or NAT along the 484 path other than in the access network. This would prevent a 485 successful data exchange. 487 The following behavior has to be assumed in order for this 488 approach to be applicable: 490 - Triggering a signaling message downstream must be possible. 491 Thereby the correct firewall should be affected where later 492 data traffic enters the domain. 494 - No other firewalls or NATs are present along the path other 495 than in the access network. 497 This approach suffers from the following drawbacks: 499 - To signal policy rules only within the access network (by 500 both end-points) has a number of disadvantage and challenges 501 as described in various source including [8]. The complex 502 message processing caused by this approach stronly argues 503 against it although it might sound simple (and even might be 504 simple in restricted environments). Section 9 also addressed 505 message flows for this case. Although its usage is possible 506 with CASP we strongly discourage its usage. 508 - Some circumstances can lead to ineffective policy rules. 510 Authorization Tokens The last approach is based on some exchanged 511 authorization tokens which are created by an authorized entity 512 (such as the PDP) in each access network. Both hosts need to 513 exchange these tokens with some protocols such as SIP or HTTP 514 which is more likely to allowed to bypass the firewall. Later 515 when the CASP-Midcom signaling messages are exchanged the 516 token is included. Host A would then include the received 517 token for Network B. When the signaling message arrives at 518 Middlebox 2 then the token is verified by the token-creating 519 entity. To avoid reusing of the token a timestamp has to be 520 included. Adding IP address information about Host A would 521 create difficulties in relationship with NATs. Information 522 about Host B might be possible to include in order to limit 523 attacks where a token is lost and reused to a different host 524 for a different purpose. The goal is to restrict the token. 525 Which information can be safely included inside the token 526 might also be implementation specified since it only has to be 527 verified locally. Some further investigation is required. 529 The following behavior has to be assumed in order for this 530 approach to be applicable: 532 - The exchange of authorization tokens between end-systems 533 must be possible. These protocols must be allowed to pass 534 the firewalls. 536 - An end-system must be able to request such an authorization 537 token at some entity in the local network. 539 This approach suffers from the following drawback: 541 - An additional protocol is required for an end host to 542 request an authorization token from an entity in the local 543 network as depicted in Section 9. Note that CASP could be 544 extended to provide this functionality but currently it does 545 not. 547 3.5 Off-Path Signaling 549 The separation of message delivery and next-hop discovery for the CASP 550 protocol allows it to support in-path and off-path signaling easily with 551 the same protocol. Throughout this document in-path signaling was 552 assumed (the Scout protocol is used per-default for next peer discovery) 553 but off-path signaling might be required in some scenarios where a 554 third-party entity wants to signal some policy rules to a firewall. This 555 mechanism has disadvantages in larger networks with multiple firewalls 556 since topology information is required in order not to install policy 557 rules at the wrong device. 559 4 Assumptions 561 Based on the above-described trust relationships the following protocol 562 assumptions have to be made. 564 ú Middleboxes along the path are CASP-aware. If a middlebox is not 565 CASP-aware then protocol functionality can not be fully 566 guaranteed. The CASP-Midcom protocol can operate with 567 limitations if a CASP-unaware firewall blocks all CASP signaling 568 traffic. To support CASP-unaware NATs along the path some 569 information needs to be added to a CASP-Midcom message to allow 570 the signaling message receiving entity to verify that the source 571 ip address (and port numbers) have changed. Currently no such 572 object is included in this version of the document. 574 ú The end host should not be required to know the topology of the 575 networks along the path or some other network internal issues. 576 Therefore it is not possible to make an assumption about routing 577 and hence we have to assume asymmetric routes. As a consequence 578 end hosts include unidirectional Traffic Selectors only. Within a 579 administrative domain where more information is available this 580 assumption might not hold and the establishment of bi-directional 581 Traffic Selectors could be possible. 583 5 NAT Involvement 585 Two issues need to be addressed when NATs are present along the path. 586 Since the end host should not a-priori knowledge about the location, 587 number and types of NATs along the path their presence has to be 588 assumed. 590 First the CASP signaling messages must be able to traverse a non-CASP 591 aware NAT box without major problems. Since CASP uses transport 592 protocols such as TCP or SCTP a NAT is able to maintain a binding. Note 593 that non-CASP aware NATs prevent the successful installation of packet 594 filters at subsequent CASP-aware firewalls. In case that the NAT is 595 CASP-aware problems only occur if source port numbers are fixed. So far 596 CASP does not require fixed source port numbers to be used. 598 The second issue addresses data packets for which a NAT binding needs to 599 be requested. When an end host starts to transmit scout packets to 600 discover the presence of firewalls/NATs along the path it is willing to 601 subsequently transmit data packets with a given Traffic Selector. 602 Subsequently such a firewall/nat/firewall scenario is described to 603 explain the basic protocol interaction and the usefulness allowing 604 Traffic Selectors to change mid-path (i.e. along the path). Mid-session 605 changes of Traffic Selectors happen in mobility cases (for example if 606 the end host obtains a new care-of address). 608 In Figure 6 a hosts (Host A) wants to enable transmit data traffic from 609 source IP address 192.168.1.5 to a given destination IP address (not 610 shown in the Figure 6) at port 666 (both udp and tcp). Therefore Host A 611 transmits a CASP-Midcom message to Firewall 1 (after discovering that 612 this firewall is along the data path) to create the corresponding packet 613 filters. Note that the traffic selector is unidirectional. This scenario 614 shows a sender-initiated scenario. Firewall 1 installs two policy rules 615 (one for udp and the other one for tcp) after successful authentication 616 and authorization. After forwarding to the next middlebox (a NAT in this 617 case) a NAT binding has to be created for the given traffic selectors. 618 The externally visible Traffic Selector (IP address changed to 619 139.23.203.30 and port number=7000) is then forwarded to the next 620 firewall (Firewall 2). Firewall 2 again creates policy rules after 621 authentication and authorization. Then the message is forwarded towards 622 the destination. 624 After the signaling messages reaches its target (the destination IP 625 address) or until no further firewall can be reached (for example 626 because the message is rejected at a non CASP-aware firewall) a RESPONSE 627 message is returned (if requested by the signaling message initiator). A 628 RESPONSE message would contain a Status object which includes 629 information about the applied Traffic Selector and whether the message 630 reached its target or not. In case of NATs along the path the Traffic 631 Selector information is then included in protocols like SIP to 632 communicate on which protocol/port data will be sent. 634 Section 9 additionally addresses some message flows with NAT 635 involvement. 637 +---------------------------------------------------------------+ 638 | | 639 | Network A | 640 | | 641 | TS=(192.168.1.5; TS=(139.23.203.30; | 642 | tcp+udp;666) tcp+udp;7000) | 643 | +---------+ +----------+ 644 | +----///------->+ NAT +------///----->+ Firewall +--> 645 | | | 1 | | 2 | 646 | | +---------+ +----------+ 647 | | | 648 | +----+-----+ | 649 | | Firewall | | 650 | | 1 | | 651 | +----+-----+ | 652 | ^ | 653 | - TS=(192.168.1.5; | 654 | - tcp+udp;666) | 655 | | | 656 | +--+---+ | 657 | | Host | | 658 | | A | | 659 | +------+ | 660 +---------------------------------------------------------------+ 662 Figure 6: NAT Involvement 664 6 Operation 666 CASP-Midcom defines the following message types: 668 Path: A PATH message allows a receiver-initiated reservation 669 approach. This message does not cause packet filters to be 670 installed although all objects are present. This message is 671 then used as a trigger to cause a CREATE to be returned. The 672 PATH message transmitting entity includes the objects which 673 are later used (if not modified) by the sender of the CREATE 674 message. 676 Create: A CREATE message allows to establish or update state at one 677 or more firewall(s). Verification is necessary to ensure that 678 policy rule creation is allowed by the requesting entity and 679 that no other local security policy is violated. In case a 680 security policy is violated or the creation of the policy 681 rule(s) is not permitted, a RESPONSE message with a "Security 682 Policy Violated" error code is returned. If the CREATE message 683 is used without a previous PATH message then it represents a 684 typical sender-initiated reservation. 686 Release: A RELEASE message is used to delete installed state at a 687 firewall/NAT explicitly without waiting for a soft-state 688 timeout. This message can only delete previously installed 689 state. Referring to previously installed state can easily be 690 done using the session identifier. 692 Response: A RESPONSE message is either sent to acknowledge a 693 previous message or to indicate an error. In case of an 694 acknowledgement it is required that the signaling message 695 initiator requests the transmission of a response message. 696 Therefore the Next object is set to the Response message. No 697 state information is modified by processing and forwarding an 698 acknowledgement. If an error has to be returned then the 699 error code inside the RESPONSE message allows to specify more 700 detailed error information. Such an error code might for 701 example indicate missing user specific credentials, a missing 702 authorization token or a security policy violation. Detailed 703 error codes have to be defined in future versions of this 704 document. 706 Query: A QUERY message triggers a RESPONSE message to return 707 installed state information. The main purpose of this message 708 is to provide diagnostic facilities. An initiator must only be 709 able to query owned state information. Otherwise the entire 710 set of policy rules of a firewall could be retrieved which 711 causes security concerns. An adversary would have a simple 712 mechanism to retrieve a lot of useful information for 713 subsequent attacks. 715 Trigger: Some sort of trigger message is required to support access 716 network signaling message exchanges as described in Section 9 717 and in Section 3.4. (TBD: This usefulness of this message or 718 other technical alternatives require some investigation.) 720 The following table shows the basic message behavior whereby the 721 following abbreviations are used: MAY (O), MUST NOT (--), MUST (M) or NA 722 (not applicable)) 724 The operations specify which message might indicate information to 725 trigger which other message in response by the other end. Some messages 726 (such as an error message) are created automatically without previous 727 indication. 729 Msg/Next Msg Path Create Release Response Query Trigger 730 ----------------------------------------------------------------- 731 Path NA M -- O -- -- 732 Create O O -- O -- -- 733 Release -- -- O? O M -- 734 Response -- -- -- NA -- -- 735 Query -- -- -- M NA -- 736 Trigger O O O? -- -- NA 738 Note that the "Must" entries in the table above indicate only the 739 default behavior. For example: A PATH message must be followed by a 740 CREATE message. However, in case of an error a RESPONSE message (with an 741 error code) will be returned. 743 The following issues still require some investigations: 745 - To enable a bi-directional reservation the sender of a CREATE 746 message has to indicate either another CREATE message in the Next 747 object or a PATH message. It is questionable whether a sender- 748 initiated signaling message should follow a receiver-initiated? 750 - Is it useful to allow a RESPONSE or a RELEASE message to follow a 751 RELEASE message? 753 7 Typical Policy Rule Attributes 755 Traffic Selectors used in CASP are used to install policy rules in 756 firewalls. This paragraph describes some typically used attributes. 757 Other attributes such as flow labels might be used but are considered as 758 an exception. We believe that a granularity at transport layer protocol 759 state-level (syn, syn/ack, ack, etc.) is not required. 761 - Source/destination IPv4 and IPv6 addresses 763 - Port numbers (possibly including ranges and a list of port 764 numbers) 766 - Transport protocol (for example TCP, UDP) 768 - SPI (for IPSec protected data traffic) 770 - Identifiers for AH and ESP (Protocol numbers, next headers 771 fields) 773 A NAT object returned to the signaling message initiator contains the 774 same attribute types. The NAT object is included as a payload in the 775 Status object. A signaling message originator may also use the NAT 776 object to request a particular NAT binding to take place. The same 777 object is used for this purpose. 779 There are only two actions defined for a policy rule: "allow / no 780 logging" (default) and "allow / logging". The first action does not 781 require additional objects to be included other than the Traffic 782 Selector. This is the default action. If a "allow / logging" action has 783 to be specified then the Logging Action object defined in 8 has to be 784 included. This action creates log entries whenever the rule was 785 triggered. End hosts are usually not allowed to specify this behavior 786 because it could be used for a denial of service attack to cause log 787 files to grow quickly and without bounds. 789 Note that a single Traffic Selector might also specify a range or ports. 790 Furthermore it is also possible to specify more than one Traffic 791 Selector object within a single signaling message. 793 8 Objects 795 The following objects are used by the CASP-Midcom client protocol: 797 8.1 Logging Action 799 This object indicates which Traffic Selector(s) want to have logging 800 specified. Note that end host are usually not allowed to specify this 801 behavior for in-path signaling. It might, however, be requested within the 802 network or in case of off-path signaling. (TBD: Some investigation is 803 required to evaluate whether this action is really required.) 805 8.2 ApplicationID 807 This object contains an identifier to provide more information about the 808 data for which the policy rule is installed. Application-level firewalls 809 and firewalls with stateful inspection are able to use this information. 810 Providing a wrong application identifier for a given data traffic would 811 then cause a processing failure. Such a behavior is more secure than a 812 traditional packet filter firewall. Note that encrypted end-to-end 813 traffic might reduce this advantage to some degree. A local 814 security policy might indicate that this information is required before 815 creating policy rules. A missing ApplicationID object would then cause a 816 "Application ID require" RESPONSE message with an error code is 817 returned. 819 8.3 Next 821 The Next object indicates the next request that the signaling message 822 receiver should generate if the incoming message was successfully 823 processed. Section 6 shows possible combinations of messages. For 824 example, a CREATE message might contain a Next object which is set to 825 CREATE causing another create message to be returned. Such a message 826 flow would represent a bi-directional reservation. A frequently used 827 object is the response object providing indications about a previously 828 submitted message. 830 8.4 Authorization Token 832 This object is used as described in Figure 5 of Section 3.4. More 833 description will be added in the near future (see Section 11). 835 8.5 CMS Credential Object 837 This object allows user specific cryptographic credentials to be 838 transmitted some CASP peers (or networks) along the path. Figure 4 839 describes a scenario where such an object is required. Attributes 840 included in this object are also briefly mentioned in Section 3.3. 842 8.6 Time 844 This object indicates that filters should be installed somewhere in the 845 near future. This might be required in the context of in-advance QoS 846 reservation for a conferencing scenario. If this object is not present, 847 the current time is used. 849 8.7 Version 851 The version indication is used to quickly determine whether any of the 852 object has changed (for example Traffic Selector), without having to do 853 a bit-by-bit comparison. The Version object might be useful for messages 854 which refresh established state information only. Uniqueness of the 855 Version object is only required for a session. Whenever state 856 information has to be modified then a new value has to be placed in the 857 Version object. A high-resolution timestamp is typically used for this 858 purpose. 860 8.8 Status 862 The Status object is used to deliver status information inside the 863 RESPONSE message. This object might return error notifications or 864 information about installed Traffic Selectors (e.g. NAT-Object). 865 Delivering Traffic Selector information is helpful for application that 866 need to deliver IP address, protocol type and port information to the 867 initiator in case of NATs along the path. One such protocol is SIP. 869 9 Basic Protocol Behavior 870 The following message flows try to show the basic protocol behavior and 871 possible combinations regarding sender- and receiver-initiated messages 872 flows, uni-directional/bi-directional Traffic Selectors, different trust 873 assumptions and NAT and/or Firewall traversal. The subsequently shown 874 figures do not include message flows for next-peer discovery (for 875 example using the Scout protocol). 877 9.1 Receiver-Initiated Message Flow with Firewalls 879 The following message flow shows the protocol behavior in case of a 880 receiver-initiated signaling message exchange with two administrative 881 domains (Network A and B) and two firewalls located at the borders. For 882 the message flow a peer-to-peer trust relationship is assumed. 883 Cryptographic credentials which support end-to-middle authentication 884 (Host A-to-FW 2) can be included by Host A into the PATH message. The 885 usage of receiver-initiation has the advantage that Host B has to assist 886 in policy rule installation at Firewall B. 888 In Figure 7 the sender indicates which policy rule to install by adding 889 this information to the Traffic Selector. Host A uses the IP address 890 139.23.203.23 and the destination IP address (Host B) is 17.12.23.5. 891 Note that the transport protocol is not mentioned since it is not 892 helpful. The first firewall (FW 1) installs the indicated policy rule 893 (Traffic Selector with actional "allow / without logging"). The message 894 is forwarded to the next CASP aware node (FW 2). Because of the peer-to- 895 peer trust assumption FW 2 trusts FW1 for the correctness of the 896 provided parameters. The identity of the signaling message originator 897 might be included in the signaling messages addressed toward the other 898 end host. Policy rules are installed at both firewalls. When the 899 signaling message reaches Host B then a CREATE message is returned in 900 response and included the same Traffic Selector (unmodified). Note that 901 the Traffic Selector is always directional (especially for the CREATE 902 message in response to a PATH message this is applicable). The CREATE 903 message installs the policy rules at the two firewalls. The CREATE 904 message finally reaches Host A who can immediately start to transmit 905 data traffic towards Host B. 907 The following issues arise with the description of the message flow of 908 Figure 7: 910 - Should Traffic Selector information included in the PATH and 911 CREATE message. Traffic Selector information in the PATH message 912 could be temporarily stored at middleboxes (in this firewalls). 913 The CREATE message would then only refer to existing state 914 information. 916 +------------------------------+ +-----------------------------+ 917 | +------+ +------+ | | +------+ +--------+ | 918 | |Host A| Network | FW 1 | | | | FW 2 | Network | Host B | | 919 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 920 +-+--+-------------------+-----+ +----+-----------------+----+-+ 921 |Path(TS= | | | 922 |(src=139.23.203.23, | | | 923 | dst=17.12.23.5, | | | 924 | sport=5000, | | | 925 | dport=600) | | | 926 |--------------------->| | | 927 | |Path(TS= | | 928 | |(src=139.23.203.23,| | 929 | | dst=17.12.23.5, | | 930 | | sport=5000, | | 931 | | dport=600) | | 932 | |------------------>| | 933 | | |Path(TS= | 934 | | |(src=139.23.203.23, | 935 | | | dst=17.12.23.5, | 936 | | | sport=5000, | 937 | | | dport=600) | 938 | | |--------------------->| 939 | | |Create(TS= | 940 | | |(src=139.23.203.23, | 941 | | | dst=17.12.23.5, | 942 | | | sport=5000, | 943 | | | dport=600) | 944 | | |<---------------------| 945 | |Create(TS= | | 946 | |(src=139.23.203.23,| | 947 | | dst=17.12.23.5, | | 948 | | sport=5000, | | 949 | | dport=600) | | 950 | |<------------------| | 951 |Create(TS= | | | 952 |(src=139.23.203.23, | | | 953 | dst=17.12.23.5, | | | 954 | sport=5000, | | | 955 | dport=600) | | | 956 |<---------------------| | | 957 | Data Traffic (unidirectional) | 958 |================================================================>| 960 Figure 7: Receiver-Initiated Message Flow with Firewalls 961 - It does not seem to be useful to have a stateless version of the 962 PATH message. Do we want to support such a stateless version? 964 - If the Path message fails then no policy rules are installed. The 965 signaling message flow has to be restart. 967 Figure 7 does not contain NATs, micro-/macro-mobility specific message 968 flows or any form of tunneling. Hence no Traffic Selector modification 969 mid-path is necessary. Such a Traffic Selector modification would be 970 required otherwise. Entities which are aware of micro-/macro-mobility 971 protocols (for example a MAP or a home agent) are no middleboxes in the 972 traditional sense. Since they have an impact on the Traffic Selector and 973 on the data traffic it would be necessary to treat them as artificial 974 middlebox to properly address flow identifications along the path. If no 975 such treatment takes place then the wrong policy rules are installed at 976 firewalls with the consequence that the entire protocol interaction is 977 useless. In this description we assume that Traffic Selector attributes 978 are based on information used for routing (i.e. IP addresses). 980 9.2 Sender-Initiated Message Flow with Firewalls 982 The following message flow shows the protocol behavior in case of a 983 sender-initiated signaling message exchange with two administrative 984 domains (Network A and B) and two firewalls (FW 1 and FW 2). No NAT and 985 other devices requiring modifications to the Traffic Selector are used. 986 This message flow also assumes a peer-to-peer trust relationship. 987 Cryptographic credentials which support end-to-middle authentication 988 (Host A-to-FW 2) can be included by Host A into the CREATE message. 990 The message flow in Figure 8 is similar to Figure 7. The CREATE message 991 contains the Traffic Selector and immediately (after authentication, 992 authorization and verification) causes the installation of policy rules. 993 The signaling message sender might request a RESPONSE message. In case 994 of NATs along the path such a RESPONSE message is very useful to return 995 NAT binding information. 997 This scenario does not require Traffic Selector modification along the 998 path. No NAT binding is returned with the optional RESPONSE message. 1000 The following issue arises with the description of the message flow of 1001 Figure 8: 1003 - If a verification error is caused during the CREATE message 1004 processing then some firewalls might have installed policy rules 1005 whereas others have never seen the signaling message. A RESPONSE 1006 message indicating an error could leave installed state in place 1007 or cause already established state to be removed automatically. 1009 +------------------------------+ +-----------------------------+ 1010 | +------+ +------+ | | +------+ +--------+ | 1011 | |Host A| Network | FW 1 | | | | FW 2 | Network | Host B | | 1012 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1013 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1014 |Create(TS= | | | 1015 |(src=139.23.203.23, | | | 1016 | dst=17.12.23.5, | | | 1017 | sport=5000, | | | 1018 | dport=600) | | | 1019 |--------------------->| | | 1020 | |Create(TS= | | 1021 | |(src=139.23.203.23,| | 1022 | | dst=17.12.23.5, | | 1023 | | sport=5000, | | 1024 | | dport=600) | | 1025 | |------------------>| | 1026 | | |Create(TS= | 1027 | | |(src=139.23.203.23, | 1028 | | | dst=17.12.23.5, | 1029 | | | sport=5000, | 1030 | | | dport=600) | 1031 | | |--------------------->| 1032 | | | [Response] | 1033 | | |<---------------------| 1034 | | [Response] | | 1035 | |<------------------| | 1036 | [Response] | | | 1037 |<---------------------| | | 1038 | Data Traffic (unidirectional) | 1039 |================================================================>| 1041 Figure 8: Sender-Initiated Message Flow with Firewalls 1043 9.3 Receiver-Initiated Message Flow with a Firewall and a NAT 1045 The message flow in Figure 9 introduces a NAT box (NAT 1) along the path 1046 between Host A and Host B additional to a firewall at Network B. Note 1047 that NAT 1 might additionally have firewall functionality which would 1048 require to install policy rules in addition to to obtain a NAT binding. 1049 The message flow assumes that Host A with source IP address 10.1.0.5 1050 wants to transmit data traffic at source port 1200 (for example UDP / 1051 not shown in this example) to destination address 17.12.23.5 at 1052 destination port number 600. Host A does not requires a particular NAT 1053 binding. Instead the provided NAT binding is provided as a NAT-Object in 1054 response. If Host A would like to request a particular NAT binding then 1055 the NAT-Object has to be included in the initial PATH message. 1057 As soon as the signaling message reaches NAT 1 a NAT binding is 1058 requested and the result of this request is placed into the Traffic 1059 selector field (i.e. src ip address is changed from 10.1.0.5 to 1060 139.23.203.30 and the sport is rewritten from 1200 to 5000). When the 1061 signaling messages is successfully processed by FW 2 and forwarded to 1062 Host B a CREATE message with the indicated Traffic Selector is returned. 1063 A copy of the received Traffic Selector is placed into the NAT-Object. 1064 By returning the NAT-Object information Host A is able to learn which IP 1065 address and port information is seen by Host B. This IP address and port 1066 information would then included in for example a SDP of a SIP message. 1067 The CREATE message is routed backwards toward Host A (since the path is 1068 pinned down). 1070 The exchange of end-to-end messages after a successful signaling message 1071 exchange might be required to exchange parameters about the subsequent 1072 data traffic. Finally Host A starts to transmit data packets to Host B. 1074 9.4 Sender-Initiated Message Flow with a Firewall and a NAT 1076 Figure 10 shows a sender-initiated signaling message flow whereby FW 2 1077 in Network B initially rejects the signaling message due to an 1078 authentication/authorization failure. The returned RESPONSE message 1079 includes among the error code, information about the entity creating the 1080 error (in this case FW2@NetworkB) and optionally a challenge value. The 1081 challenge value allows Host A to either provide a freshness guarantee 1082 based on the challenge value and/or based on a timestamp. The usage of 1083 CMS allows Host A and Network B to use symmetric and asymmetric 1084 credentials for authentication. In any case a Credential object is 1085 attached to the CREATE signaling message. The Credential object 1086 securely binds a timestamp or a sequence number (to prevent replay 1087 attacks), identities, lifetime and possibly Traffic Selector information 1088 to the cryptographic credentials. Note that the RESPONSE message might 1089 return a NAT-Object if requested. 1091 Host A retransmits a new signaling message. After verification of the 1092 request and the credentials FW 2 forwards the message to Host B. As in 1093 previous examples Host B returns a RESPONSE message with a NAT-Object 1094 back to Host A. 1096 The message flow shows the following protocol features: 1098 +------------------------------+ +-----------------------------+ 1099 | +------+ +------+ | | +------+ +--------+ | 1100 | |Host A| Network | NAT 1| | | | FW 2| Network | Host B | | 1101 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1102 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1103 |Path(TS= | | | 1104 |(src=10.1.0.5, | | | 1105 | dst=17.12.23.5, | | | 1106 | sport=1200, |Path(TS= | | 1107 | dport=600) |(src=139.23.203.23,| | 1108 |--------------------->| dst=17.12.23.5, | | 1109 | | sport=5000, |Path(TS= | 1110 | | dport=600) |(src=139.23.203.23, | 1111 | |------------------>| dst=17.12.23.5, | 1112 | | | sport=5000, | 1113 | | | dport=600) | 1114 | | |--------------------->| 1115 | | | | 1116 | | |Create(TS= | 1117 | | |(src=139.23.203.23, | 1118 | |Create(TS= | dst=17.12.23.5, | 1119 | |(src=139.23.203.23,| sport=5000, | 1120 | | dst=17.12.23.5, | dport=600); | 1121 |Create(TS= | sport=5000, | NAT-Object= | 1122 |(src=10.1.0.5, | dport=600); |(src=139.23.203.23, | 1123 | dst=17.12.23.5, | NAT-Object= | dst=17.12.23.5, | 1124 | sport=1200, |(src=139.23.203.23,| sport=5000, | 1125 | dport=600); | dst=17.12.23.5, | dport=600)) | 1126 | NAT-Object= | sport=5000, |<---------------------| 1127 |(src=139.23.203.23, | dport=600)) | | 1128 | dst=17.12.23.5, |<------------------| | 1129 | sport=5000, | | | 1130 | dport=600)) | | | 1131 |<---------------------| | | 1132 | | | | 1133 | For example: SIP Signaling | 1134 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 1135 | | | | 1136 | Data Traffic (unidirectional) | 1137 |================================================================>| 1139 Figure 9: Receiver-Initiated Message Flow with a Firewall and a NAT 1141 - End-to-Middle Authentication by including a CMS object 1143 +------------------------------+ +-----------------------------+ 1144 | +------+ +------+ | | +------+ +--------+ | 1145 | |Host A| Network | NAT 1| | | | FW 2| Network | Host B | | 1146 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1147 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1148 |Create(TS= | | | 1149 |(src=10.1.0.5, |Create(TS= | | 1150 | dst=17.12.23.5, |(src=139.23.203.23,| | 1151 | sport=1200, | dst=17.12.23.5, | | 1152 | dport=600) | sport=5000, | | 1153 |--------------------->| dport=600) | | 1154 | |------------------>| | 1155 | |Response(ErrorCode=| | 1156 |Response(ErrorCode= |"Auth. Required", | | 1157 |"Auth. Required", | FW2@NetworkB, | | 1158 | FW2@NetworkB, | challenge=0x7a..8,| | 1159 | challenge=0x7a..8, |<------------------| | 1160 |<---------------------| | | 1161 |Create(TS= | | | 1162 |(src=10.1.0.5, | | | 1163 | dst=17.12.23.5, |Create(TS= | | 1164 | sport=1200, |(src=139.23.203.23,| | 1165 | dport=600) | dst=17.12.23.5, |Create(TS= | 1166 | Credentials(...)) | sport=5000, |(src=10.1.0.5, | 1167 |--------------------->| dport=600) | dst=17.12.23.5, | 1168 | | Credentials(...)) | sport=1200, | 1169 | |------------------>| dport=600) | 1170 | | |--------------------->| 1171 | | | Response( | 1172 | | Response( | NAT-Object(...)) | 1173 | Response( | NAT-Object(...)) |<---------------------| 1174 | NAT-Object(...)) |<------------------| | 1175 |<---------------------| | | 1176 | | SIP Signaling | | 1177 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 1178 | | | | 1179 | Data Traffic (unidirectional) | 1180 |================================================================>| 1182 Figure 10: Sender-Initiated Message Flow with a Firewall and a NAT 1184 (Credential object) to the signaling message after the 1185 authentication/authorization failure. If the Credential object is 1186 included into the first CREATE signaling message then no such 1187 error message is returned. However, in that case replay protection 1188 can only be based on timestamps (loosely synchronized clocks). 1190 - A NAT-Object is included in the RESPONSE message to let the 1191 signaling message initiator to return the public IP address. 1193 - The RESPONSE message indicating an error could also return a NAT- 1194 Object to provide initial information to the 1196 - The same protocol operations can be used without NATs (only 1197 firewalls). 1199 9.5 Sender-Initiated NAT/Firewall Traversal with Authorization Token 1201 The next scenario is slightly more complicated in the sense that 1202 authorization information for Network B is provided by Host B. Host B 1203 first request an authorization token from an entity in the local network 1204 by some means. This token is then communicated to Host A using an end- 1205 to-end protocol such as SIP or HTTP. This token then provides the 1206 necessary trust for Network B to allow the CREATE message to install 1207 policy rules at FW 2. Note that this message flow is different compared 1208 to the scenario described in Figure 10. In this case no pre-established 1209 cryptographic credentials between Host A and Network B are present 1210 before the protocol is used between Host A and Host B. 1212 The sender-initiated message flow is similar to the above-described 1213 flows with the only exception that the Authorization Token is included. 1214 The token is removed at FW 2 after successful verification. 1216 9.6 Sender-Initiated Firewall Signaling only at the Access Network 1218 Sometimes people argue that the signaling message exchange should be 1219 done locally at the network access only because per-flow signaling 1220 messages are not processed in the core network. Instead of sending the 1221 signaling messages from one access network to the other whereby the 1222 signaling messages are transparent in the core each host transmits 1223 signaling messages independently in its own network. Although the 1224 concept sounds very simple at the first glance it turns out to be very 1225 complex in the generic case. Most difficulties appear because of the 1226 asymmetric routing architecture. Establishing policy rules in the uplink 1227 direction is fairly simple and requires only a mechanism which allows 1228 some sort of scoping (i.e. signaling messages have to terminate 1229 somewhere in the access network) without actually indicating the end- 1230 point. Casp provides means for scoping and local access network 1231 signaling. The installation of policy rules on the downlink 1232 direction is complicated because some topology information inside the 1233 network must be known in order to avoid policy rule creation at the 1234 +------------------------------+ +-----------------------------+ 1235 | +------+ +------+ | | +------+ +--------+ | 1236 | |Host A| Network | NAT 1| | | | FW 2| Network | Host B | | 1237 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1238 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1239 | | | Authorization | 1240 | | | Token | 1241 | | | Request | 1242 | | |<---------------------| 1243 | | | Authorization | 1244 | | End-to-End | Token | 1245 | | Communication | Response | 1246 | | (Authorization |--------------------->| 1247 | | Token) | | 1248 |<----------------------------------------------------------------| 1249 |Create(TS= | | | 1250 |(src=10.1.0.5, | | | 1251 | dst=17.12.23.5, |Create(TS= | | 1252 | sport=1200, |(src=139.23.203.23,| | 1253 | dport=600); Token) | dst=17.12.23.5, |Create(TS= | 1254 |--------------------->| sport=5000, |(src=10.1.0.5, | 1255 | | dport=600); Token)| dst=17.12.23.5, | 1256 | |------------------>| sport=1200, | 1257 | | | dport=600) | 1258 | | |--------------------->| 1259 | | | Response( | 1260 | | | NAT-Object(...)) | 1261 | | Response( |<---------------------| 1262 | | NAT-Object(...)) | | 1263 | Response( |<------------------| | 1264 | NAT-Object(...)) | | | 1265 |<---------------------| | | 1266 | | SIP Signaling | | 1267 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 1268 | | | | 1269 | Data Traffic (unidirectional) | 1270 |================================================================>| 1272 Figure 11: Sender-Initiated NAT/Firewall Traversal with Authorization 1273 Token 1275 wrong devices. Hence there is a built-in risk to cause the protocol to 1276 fail (i.e. to install policy rules at the wrong location). 1278 For the message flow described in Figure 12 we assume the following 1279 protocol behavior: 1281 - Host A and Host B initiate a bi-directional Traffic Selector 1282 establishment with a scope restricted to the local access network 1283 only. Without some sort of bi-directional signaling message 1284 exchange a sort of TRIGGER message is required to initiate a 1285 downlink Traffic Selection establishment. 1287 - Based on the characteristics of signaling message exchanges local 1288 at both access networks assumptions about the topology must be 1289 made (or some topology information must be known). 1291 - In this simplified message flow no NAT device is present. 1293 - Host A has a-priori knowledge about the Traffic Selector for the 1294 inbound traffic (i.e. src=17.12.23.5 and sport=601). 1296 With the initial CREATE message Host A already supplies Traffic Selector 1297 information for the bi-directional reservation (i.e. the CREATE message 1298 by Host A is followed by another CREATE message from FW 1). To kept the 1299 CREATE signaling message within the local access network scoping is 1300 used. Indicating a particular IP address might also be possible but 1301 often the endpoint is unknown to the end host. As a result of successful 1302 processing a CREATE message is returned in response with the already 1303 provided Traffic Selector. 1305 Optionally an end-to-end message communication might follow to transmit 1306 Traffic Selector information from Host A to Host B. In most cases some 1307 communication is, however, required. Similar as in Network A a CREATE 1308 message is initiated by the end host with the Next object set to another 1309 CREATE message. 1311 Finally if everything was successful data can be exchanged in both 1312 directions on port 5001<-601 and a 5000->600. 1314 9.7 Sender-Initiated NAT and Firewall Traversal within the Access 1315 Network 1317 The message flow described in Figure 13 extends the description in 1318 Figure 12 by using a uni-directional signaling exchange. As a 1319 consequence of this extension a TRIGGER message is required to cause a 1320 downlink signaling message to be sent within Network B. In order to 1321 avoid this message Network B could intercept the end-to-end message 1322 exchange to trigger a signaling message to Host B. However, this 1323 approach might suffer from the problem to be able to read and evaluate 1324 end-to-end signaling messages. 1326 +------------------------------+ +-----------------------------+ 1327 | +------+ +------+ | | +------+ +--------+ | 1328 | |Host A| Network | FW 1 | | | | FW 2 | Network | Host B | | 1329 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1330 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1331 |Create(TS=(src=139.23.205.5, | | 1332 | dst=17.12.23.5, sport=5000, dport=600); | | 1333 | Next=Create(TS=(src=17.12.23.5, | | 1334 | dst=139.23.205.5,sport=601,dport=5001)); | | 1335 | Scope=NetworkA) | | | 1336 |--------------------->| | | 1337 |Create(TS= | | | 1338 |(src=17.12.23.5, | | | 1339 | dst=139.23.205.5, | | | 1340 | sport=601, | | | 1341 | dport=5001)) | | | 1342 |<---------------------| | | 1343 | | End-to-End | | 1344 | | Communication | | 1345 | | (TS) - Optional | | 1346 |<--------------------------------------------------------------->| 1347 | |Create(TS=(src=17.12.23.5, | 1348 | | dst=139.23.205.5, sport=601, dport=5001);| 1349 | | Next=Create(TS=(src=139.23.205.5, | 1350 | | dst=17.12.23.5, sport=5000, dport=600)); | 1351 | | Scope=NetworkB) | | 1352 | | |<---------------------| 1353 | | |Create(TS= | 1354 | | |(src=139.23.205.5, | 1355 | | | dst=17.12.23.5, | 1356 | | | sport=5000, | 1357 | | | dport=600)) | 1358 | | |--------------------->| 1359 | Data Traffic (bi-directional) | 1360 |<===============================================================>| 1362 Figure 12: Sender-Initiated Firewall Signaling only at the Access 1363 Network 1365 Additionally a NAT device is used in Network A which requires Host A to 1366 request a NAT binding and the corresponding NAT-Object which is then 1367 communicated to Host B. Using the Traffic Selector information inside 1368 the NAT-Object Host B learns the public IP address and port information 1369 of the data traffic transmitted by Host A. 1371 The access network signaling message exchange requires some topology 1372 information as explained in previous figures. The TRIGGER message must 1373 cause a downlink signaling message to be initiated by a network device 1374 which where the data traffic of Host A is sent through. 1376 A even more difficult example would address a topology where each 1377 network is equipped with a NAT. The same is true for Traffic Selector 1378 installation for data traffic flowing in both directions with one or two 1379 NATs. 1381 10 Security Considerations 1383 Installing packet filters to one or more firewalls is a security 1384 sensitive process. Security protection of signaling messages is 1385 necessary in order to defeat a number of threats. This section gives a 1386 brief discussion of possible threats and addresses their corresponding 1387 countermeasures. 1389 10.1 Threats 1391 Denial of Service: Denial of service attacks can be launched by 1392 modifying messages used during the discovery process. A client 1393 could then be forced to contact a "wrong" firewall which is 1394 outside the data path. Furthermore it is possible to flood a 1395 firewall with bogus request and thereby cause massive state 1396 and computational resources to be allocated as part of the key 1397 exchange process. Furthermore an adversary can modify the 1398 Traffic Selector of a request to cause a large number of 1399 packet filters to be allocated. An adversary might also remove 1400 administrator installed packet filters which are not related 1401 to previous packet filter installations by users. 1403 Man-in-the-Middle: MITM attacks are possible during the discovery 1404 process where the entity of a firewall is discovered. In this 1405 case the user might be convinced to communicate with a 1406 firewall which is not the case. Many of these attacks are 1407 related to the discovery mechanism and therefore also 1408 described in [1]. Further threats which are not specific to 1409 the scout mechanism but also related to the next-hop discovery 1410 mechanism require further investigation (such as SLP, DHCP, 1411 DNS, etc.). The authors of some of these configuration 1412 mechanisms have already identified potential vulnerabilities 1413 and provide the corresponding security protection. 1415 Eavesdropping: An eavesdropper might be able to learn some 1416 installed packet filters by listening to the signaling message 1417 communication between a client and a firewall. Furthermore it 1419 +------------------------------+ +-----------------------------+ 1420 | +------+ +------+ | | +------+ +--------+ | 1421 | |Host A| Network | NAT 1| | | | FW 2 | Network | Host B | | 1422 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1423 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1424 |Create(TS= | | | 1425 |(src=192.168.1.5, | | | 1426 | dst=17.12.23.5, | | | 1427 | sport=5000, | | | 1428 | dport=600); | | | 1429 | Scope=NetworkA) | | | 1430 |--------------------->| | | 1431 |Response( | | | 1432 |NAT-Object= | | | 1433 |(src=139.23.203.30, | | | 1434 | dst=17.12.23.5, | | | 1435 | sport=8000, | | | 1436 | dport=600)) | End-to-End | | 1437 |<---------------------| Communication | | 1438 | | (NAT-Object) | | 1439 |<--------------------------------------------------------------->| 1440 | | |Trigger(TS= | 1441 | | |(src=139.23.205.30, | 1442 | | | dst=17.12.23.5, | 1443 | | | sport=8000, | 1444 | | | dport=600); | 1445 | | | Scope=NetworkB) | 1446 | | |<---------------------| 1447 | | |Create(TS= | 1448 | | |(src=139.23.205.30, | 1449 | | | dst=17.12.23.5, | 1450 | | | sport=8000, | 1451 | | | dport=600)) | 1452 | | |--------------------->| 1453 | Data Traffic (uni-directional) | 1454 |================================================================>| 1456 Figure 13: Sender-Initiated NAT and Firewall Traversal within the Access 1457 Network 1459 might be possible to learn an authorization token exchanged 1460 between the two entities or between entities along the path. 1461 Since the session identifier is used to uniquely identify 1462 state establish along entities along the path an adversary 1463 might reuse this identifier to refer to existing state 1464 information. 1466 Integrity Violation: By modifying a request message an adversary 1467 can delete installed firewall filters, install filters using a 1468 different authorization identity or to create filters with a 1469 large lifetime. 1471 Masquerading: An adversary might gain information by querying 1472 installed packet filters at a firewall by masquerading the 1473 identify or a real user. This might be used for subsequent 1474 attacks. 1476 Rogue Firewall: An adversary at a compromised firewall might 1477 exploit an existing trust relationship to install or remove 1478 filters at other firewalls. Furthermore it is possible to 1479 return a NAT object with wrong information causing subsequent 1480 data traffic to be send to an arbitrary location. 1482 Unauthorized Access: A regular user might install firewall filters 1483 although he is not allowed because of missing authorization. 1484 Administrators are usually very concerned about installing 1485 packet filters from users access from an external network. 1487 Replay Attacks: An adversary might eavesdrop CASP-Midcom signaling 1488 messages and use them later for a replay attack. Furthermore 1489 an adversary might be able to collect authorization tokens and 1490 reuse them in a different context or later in time to open 1491 holes into a firewall. 1493 Privacy Violation: Adversaries can learn about the identities 1494 participating in the message exchange by eavesdropping 1495 information exchanged between the two end-systems. Especially 1496 authorization tokens exchanged between end-systems outside the 1497 CASP protocol (as explained in Section 3.4) represent a 1498 vulnerability. 1500 10.2 Countermeasures 1502 To prevent the above-listed attacks a number of countermeasures are 1503 taken: 1505 Denial of Service: To limit denial of service attacks a number of 1506 countermeasure were taken. First the scout protocol (and other 1507 configuration mechanisms) experience some protection to 1508 prevent basic attacks. Furthermore it is necessary to mutually 1509 authenticate and authorize both peers after establishing a 1510 transport layer connection as described in [1]. Since the 1511 authentication and key exchange protocol requires state and 1512 computational resources it has to be resistant against denial 1513 of service attacks. When transmitting CASP-Midcom specific 1514 information protection of the requests itself is necessary to 1515 prevent an adversary from object modification which otherwise 1516 would cause unpredictable behavior. 1518 Man-in-the-Middle: MITM attacks during the discovery phase are 1519 prevented by secure configuration mechanisms. The scout 1520 protocol experiences limited security protection by its 1521 nature. An authentication and authorization step is 1522 required after learning the identity of the next CASP peer. 1523 MITM adversaries will experience difficulties launching a 1524 successful attack after transport layer connection 1525 establishment because of the signaling message protection. 1527 Eavesdropping: Eavesdropping of signaling messages is prevented by 1528 using either IPSec ESP (without NULL encryption) or by using 1529 TLS (with encryption cipher-suites). It is therefore not 1530 possible to learn authorization tokens, session identifiers or 1531 other firewall packet filter specific information that might 1532 be useful for an adversary eavesdropping on for example a 1533 wireless link. With the suggested security protection 1534 eavesdropping is therefore only possible at CASP-Midcom aware 1535 nodes participating in the signaling message exchange. This 1536 is, however, intentional and required for the operation of the 1537 protocol. 1539 Integrity Violation: Modifying the content of signaling packets is 1540 prevented by either IPSec or TLS. Exchanged information 1541 thereby experiences both confidentiality as well as integrity 1542 protection. The usage of integrity protection with IPSec ESP 1543 is strongly recommended. 1545 Masquerading: Spoofing an identity to be able to delete or query 1546 installed packet filter information is prevented by data 1547 origin authentication of transmitted signaling messages. For 1548 the establishment of the required security associations mutual 1549 authentication is assumed. 1551 Rogue CASP-Midcom Node: Firewalls are security sensitive network 1552 devices. An adversary can use a compromised firewall in a 1553 number of ways. To prevent a compromised firewall to harm 1554 other firewalls trust might be limited and strong verification 1555 of request might be required. In case of missing peer-to-peer 1556 trust relationships more sophisticated protocol handling (as 1557 described in 3.3 and 3.4) is necessary. Such a handling makes 1558 it more difficult for an adversary to perform a successful 1559 attack. Note that any malicious CASP-Midcom (or CASP node in 1560 general) can impact the security of other entities (not just 1561 firewalls). 1563 Unauthorized Access: Differentiation of access rights between 1564 various users and user-groups is common. The same type of 1565 authorization mechanisms based on access control lists can be 1566 applied. If authorization tokens are used then additionally a 1567 locally known user must be able to request such a token. For 1568 the trust relationship described in 3.3 one administrative 1569 domain must have a pre-established security association. The 1570 establishment of such this security association is usually 1571 bound to some access control rights. 1573 Privacy Violation: Encryption of information about user identities 1574 contained in authorization token prevents an adversary from 1575 obtaining user specific information. Currently only a keyed 1576 message digest function (HMAC) is provided to protect the 1577 authorization token content against modification. Either a 1578 custom mechanisms for encrypting some token parts or CMS 1579 encryption could be used to provide the necessary protection. 1580 Further investigation is required. 1582 To summarize: CASP relies on the security mechanisms described in [1]. 1583 Securing the messaging layer in a CASP-peer to CASP-peer fashion is 1584 provided either by IPsec or by TLS. Non peer-to-peer protection of 1585 client layer objects is provided by CMS which allows CASP-Midcom objects 1586 defined in this document to be encapsulated and protected by CMS. 1588 11 Open Issues 1590 - The format of the objects need more work. 1592 - The structure of the authorization token needs more 1593 investigation. There is also a question about a custom token 1594 format or a CMS object. Both have advantages and disadvantages. 1596 - Terminology needs to be aligned with the Midcom Requirements and 1597 Framework drafts. Issues (such as groups of policy rules) 1598 discussed in these documents have to be mapped against the issues 1599 in this draft. 1601 - Traffic Selector attributes need some work to avoid the complex 1602 verification in case of overlapping rules. It must not be 1603 possible to prevent an administrator-created deny policy rule to 1604 become ineffective by an added allow policy rule with an 1605 overlapping port range. Hence it might be necessary to have an 1606 additional verification step to prevent these type of problems. 1608 12 Acknowledgements 1610 We would like to thank (in alphabetical order) Steffen Fries, Xiaoming, 1611 Fu, Joerg Ottensmayer and Martin Reinhardt for their comments to this 1612 draft. 1614 A Object Format Details 1616 For concreteness, we describe a strawman packet format below. 1618 All CASP messages are composed of one or more TLV (type-length-value) 1619 objects. Within each object, elements are aligned on multiples of their 1620 size, to speed processing. All objects have lengths of a multiple of 32 1621 bits. The length field in the object indicates the number of 32-bit 1622 words. 1624 We describe messages and objects as pseudo-C structures. Elements are 1625 enumerated in transmission order. We use the data types uint8, uint16, 1626 uint32, uint64, uint128 to identify unsigned integers with 8, 16, 32, 64 1627 or 128 bits, respectively. 1629 Definitions for IPv4 and IPv6 address for the usage with Traffic 1630 Selectors are already provided in [1]. 1632 IPSec ESP and AH SPIs is four bytes in length. 1634 typedef struct uint32 SPI; 1636 Using a custom authorization token format might be more lightweight. 1637 (TBD: Authorization tokens can either be defined as CMS objects or as a 1638 objects with a custom structure. Using CMS object would simplify its 1639 definition and would allow a more generic usage. CMS objects are 1640 larger in size than custom build tokens. Some investigation is required 1641 to find the optional usage.) 1643 The following fields could be included in such a token: 1645 typedef struct { 1646 uint32 ID; 1647 Identity token_creator, token_requestor, token_user; 1648 Identity src_addr, dst_addr; 1649 NTP_TIMESTAMP timestamp; 1650 uint8 AlgorithmID; 1651 uint8 HMAC[20]; 1652 ...Object describing the authorized TS.... 1653 } AuthToken; 1655 An authorization token is identified by a 32-bit number. The src_addr 1656 and the dst_addr attribute might contains an IPv4, IPv6 address or a 1657 FQDN. The Identity can either be a generic Unicode and ASCII ID, a FQDN 1658 or a URI. Unicode Identifiers (Unicode_ID), ASCII Identifiers and FQDNs 1659 are defined in [9]. The Uniform Resource Identifiers (URI) is defined 1660 in [10]. 1662 Since a NAT may change the source address it is possible to specify a 1663 FQDN, URI or an ASCII/Unicode ID or to omit the field. The 1664 token_creator specifies the identity of the entity which was responsible 1665 for the creation of the token. Information about this entity is 1666 necessary to route the token to the same entity for verification. 1667 Information about the entity requesting the token might be required. 1668 Finally the user identity obtained from authentication might be 1669 included. Especially if authentication to a firewall in the middle of 1670 the CASP-chain is required then this information provides additional 1671 authorization information. 1673 For cryptographic protection of the authorization token a keyed message 1674 digest HMAC [11] is used whereby the used algorithm (MD5, SHA-1) is 1675 indicated in the AlgorithmID field. The secret key necessary for the 1676 HMAC computation needs to be locally known only since verification is 1677 done at the token creator. The format of the NTP timestamp is defined 1678 in [12]. Finally the object contains information about the authorized 1679 Traffic Selector. Since a NAT might change some of this information its 1680 usefulness is questionable. 1682 B Authors' Addresses 1684 Henning Schulzrinne 1685 Dept. of Computer Science 1686 Columbia University 1687 1214 Amsterdam Avenue 1688 New York, NY 10027 1689 USA 1690 EMail: schulzrinne@cs.columbia.edu 1692 Hannes Tschofenig 1693 Siemens AG 1694 Otto-Hahn-Ring 6 1695 81739 Munich 1696 Germany 1697 EMail: Hannes.Tschofenig@siemens.com 1698 C Bibliography 1700 [1] H. Schulzrinne, H. Tschofenig, X. Fu, J. Eisl, and R. Hancock, "Casp 1701 - cross-application signaling protocol," Internet Draft, Internet 1702 Engineering Task Force, Sept. 2002. Work in progress. 1704 [2] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan, 1705 "Middlebox communication architecture and framework," Internet Draft, 1706 Internet Engineering Task Force, Mar. 2002. Work in progress. 1708 [3] M. Shore, "The TIST (topology-insensitive service traversal) 1709 protocol," Internet Draft, Internet Engineering Task Force, May 2002. 1710 Work in progress. 1712 [4] M. Shore, "Towards a network-friendlier midcom," Internet Draft, 1713 Internet Engineering Task Force, June 2002. Work in progress. 1715 [5] H. Schulzrinne, H. Tschofenig, X. Fu, and J. Eisl, "A quality-of- 1716 service resource allocation client for casp," Internet Draft, Internet 1717 Engineering Task Force, Sept. 2002. Work in progress. 1719 [6] H. Tschofenig, "RSVP security properties," Internet Draft, Internet 1720 Engineering Task Force, June 2002. Work in progress. 1722 [7] T. Taylor, "Semantics which the MIDCOM protocol must support," 1723 Internet Draft, Internet Engineering Task Force, June 2002. Work in 1724 progress. 1726 [8] J. Manner et al. , "Localized RSVP," Internet Draft, Internet 1727 Engineering Task Force, May 2002. Work in progress. 1729 [9] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, and 1730 R. Hess, "Identity representation for RSVP," RFC 3182, Internet 1731 Engineering Task Force, Oct. 2001. 1733 [10] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 1734 identifiers (URI): generic syntax," RFC 2396, Internet Engineering Task 1735 Force, Aug. 1998. 1737 [11] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: keyed-hashing for 1738 message authentication," RFC 2104, Internet Engineering Task Force, Feb. 1739 1997. 1741 [12] D. L. Mills, "Network time protocol (version 3) specification, 1742 implementation," RFC 1305, Internet Engineering Task Force, Mar. 1992. 1744 Table of Contents 1746 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1747 2 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1748 3 Trust Relationships . . . . . . . . . . . . . . . . . . . 5 1749 3.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . . . 5 1750 3.2 Intra-domain Trust Relationship . . . . . . . . . . . . . 6 1751 3.3 Required End-to-Middle Trust Relationship . . . . . . . . 7 1752 3.4 Missing Network-to-Network Trust Relationship . . . . . . 8 1753 3.5 Off-Path Signaling . . . . . . . . . . . . . . . . . . . 13 1754 4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 13 1755 5 NAT Involvement . . . . . . . . . . . . . . . . . . . . . 13 1756 6 Operation . . . . . . . . . . . . . . . . . . . . . . . . 15 1757 7 Typical Policy Rule Attributes . . . . . . . . . . . . . 17 1758 8 Objects . . . . . . . . . . . . . . . . . . . . . . . . . 18 1759 8.1 Logging Action . . . . . . . . . . . . . . . . . . . . . 18 1760 8.2 ApplicationID . . . . . . . . . . . . . . . . . . . . . . 18 1761 8.3 Next . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1762 8.4 Authorization Token . . . . . . . . . . . . . . . . . . . 19 1763 8.5 CMS Credential Object . . . . . . . . . . . . . . . . . . 19 1764 8.6 Time . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1765 8.7 Version . . . . . . . . . . . . . . . . . . . . . . . . . 19 1766 8.8 Status . . . . . . . . . . . . . . . . . . . . . . . . . 19 1767 9 Basic Protocol Behavior . . . . . . . . . . . . . . . . . 19 1768 9.1 Receiver-Initiated Message Flow with Firewalls . . . . . 20 1769 9.2 Sender-Initiated Message Flow with Firewalls . . . . . . 22 1770 9.3 Receiver-Initiated Message Flow with a Firewall and a 1771 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1772 9.4 Sender-Initiated Message Flow with a Firewall and a 1773 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1774 9.5 Sender-Initiated NAT/Firewall Traversal with 1775 Authorization Token . . . . . . . . . . . . . . . . . . . . . . . . 27 1776 9.6 Sender-Initiated Firewall Signaling only at the 1777 Access Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1778 9.7 Sender-Initiated NAT and Firewall Traversal within 1779 the Access Network . . . . . . . . . . . . . . . . . . . . . . . . . 29 1780 10 Security Considerations . . . . . . . . . . . . . . . . . 31 1781 10.1 Threats . . . . . . . . . . . . . . . . . . . . . . . . . 31 1782 10.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . 33 1783 11 Open Issues . . . . . . . . . . . . . . . . . . . . . . . 35 1784 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . 36 1785 A Object Format Details . . . . . . . . . . . . . . . . . . 36 1786 B Authors' Addresses . . . . . . . . . . . . . . . . . . . 37 1787 C Bibliography . . . . . . . . . . . . . . . . . . . . . . 38