idnits 2.17.1 draft-tschofenig-nsis-casp-midcom-01.txt: -(545): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(756): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(961): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(967): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(970): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1160): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1295): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1672): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 26 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 41 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 42 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 27 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 3 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 727: '...ations are used: MAY (O), MUST NOT (--...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1267 has weird spacing: '...aversal with ...' == Line 1355 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 (3 March 2003) is 7723 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 1792 looks like a reference -- Missing reference section? '2' on line 1796 looks like a reference -- Missing reference section? '3' on line 1800 looks like a reference -- Missing reference section? '4' on line 1804 looks like a reference -- Missing reference section? '5' on line 1807 looks like a reference -- Missing reference section? '6' on line 1811 looks like a reference -- Missing reference section? '7' on line 1815 looks like a reference -- Missing reference section? '8' on line 1819 looks like a reference -- Missing reference section? '9' on line 1823 looks like a reference -- Missing reference section? 'Response' on line 1033 looks like a reference -- Missing reference section? '10' on line 1826 looks like a reference -- Missing reference section? '11' on line 1830 looks like a reference -- Missing reference section? '12' on line 1834 looks like a reference -- Missing reference section? '20' on line 1738 looks like a reference -- Missing reference section? '13' on line 1838 looks like a reference -- Missing reference section? '14' on line 1842 looks like a reference -- Missing reference section? '15' on line 1846 looks like a reference -- Missing reference section? '16' on line 1850 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 20 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, C. Aoun 4 Siemens/Columbia U./Nortel Networks 5 draft-tschofenig-nsis-casp-midcom-01.txt 6 3 March 2003 7 Expires: September 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 both in an in-path and off-path fashion. 35 The protocol furthermore allows to establish a NAT binding and to 36 provide the signaling initiator with the NAT information. This is 37 information can then be used within other protocols such as SIP. 39 1 Introduction 41 CASP-NATFW 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 and NAT information along the data path 44 (in-path) in a topology independent manner. CASP-NATFW aims to address 45 issues raised and not solved within the MIDCOM working group [2] and 46 uses ideas for in-path signaling using RSVP as described in [3] and in 47 [4]. 49 2 Definitions 51 Terms in context with trust relationships are described in [5]. 53 The following terms are used in this document: 55 Policy Rule: The term policy rule is used as defined in [6]. A 56 policy rule consists of two components: a packet filter and an 57 action to be performed on packets matching the packet filter 58 expression. This document uses two actions for a policy rule: 59 allow without logging and allow with logging. Per-default no 60 logging is used. If logging is desired then it has to be 61 specified as described in Section 9. As stated in [6] it was 62 agreed not to specify a deny action for policy rule. Hence 63 there is no such deny action defined in this document. 65 In the context of NAT, as defined in [7], basic NAT, NAPT and 66 twice NAT could be applied to packet flows matching the packet 67 filter. 69 Policy Groups: The term policy group is not used in this document 70 since its meaning is partially captured by the packet filter. 71 A packet filter allows various attributes (even lists and 72 ranges of certain attributes) to be specified. In case of in- 73 path signaling only one particular destination IP address 74 (which is available in the CASP NTLP payload) can be 75 specified. More fine grain packet filters have to be specified 76 in the CASP NSLP payload (in this case CASP-NATFW). For off- 77 path signaling this rule must not hold. 79 Lifetime of Policy Rules: An NSLP is allowed to specify the 80 lifetime for policy rule. The lifetime corresponds to the 81 refresh interval. If no lifetime or refresh interval is 82 selected then a default value is used. 84 Packet filter (PF): The term packet filter refers to attributes 85 describing subsets of the data traffic for which a specific 86 behavior should be provided. The term flow identifier is also 87 often used in the area of QoS signaling protocols. For NAT 88 traversal a packet filter (or flow identifier) refers to a NAT 89 binding. 91 The terms in-path (off-path) signaling can be used inter-changable with 92 path-coupled (path-decoupled) signaling. 94 3 General Limits of In-Path Firewall Signaling 96 At the beginning of this document it is worth stating that the problem 97 of firewall signaling is addressed by a number of working groups. This 98 section provides a brief overview of some of the recent activities and 99 describes the general limits of in-path firewall signaling. 101 The following working groups or activities at the IETF have a 102 relationship to policy rule installation and firewall communication in 103 general: 105 To address a single device at the borders of the access networks (i.e. 106 the first IP device) is covered by the PANA working group to implement 107 the controlled/uncontrolled network access procedures. Thereby 108 authentication of a user or a device with the help of EAP is required to 109 create policy rules at the first IP device. This subsequently allows the 110 end host to forward packets to the Internet or to access services within 111 the local domain. 113 The MIDCOM working group also aims to install policy rules at firewalls. 114 However, their approach seems to be focused on off-path signaling. 115 Additionally of interest are activities related to Endpoint Firewall 116 Controll, RSIP and Socks. 118 To provide a generic solution to install state at a possibly large 119 number of firewalls along the path some trust must be placed on devices 120 along the path. If no such trust is available which might be likely the 121 case in an adhoc network scenario as shown in Figure 1 then firewall 122 signaling is doomed to fail. 124 An adhoc networks consists of a number of nodes between the end host 125 (Node A) and the ISP to which Node A wants to get access. Although Node 126 A uses an authentication and key exchange protocol to create a policy 127 rule at the firewall 1 it is still possible for an untrusted node (in 128 this case Node 3) to inject data traffic which will pass Firewall 1 129 since the data traffic is unauthenticated. To prevent this type of 130 threat protocols developed in the IPSEC or the IPSRA working group, 131 which establish a security association to protect the data traffic, can 132 be used. 134 To summarize: In many cases in-path policy rule installation might 135 provide enough security protection to prevent unauthorized nodes from 136 gaining access to network resources. However, due to the absence of per- 137 packet authentication man-in-the-middle attacks of malicious nodes along 138 the path cannot be prevented by installed policy rules. 140 +------------------------------------------+ +--------// 141 | Adhoc | | ISP 142 | Network | | 143 | regular data | | 144 | traffic by +---------+ | | 145 | node A |Malicious| | +-+--------+ 146 | +-------------->+ Node +-----+///-->+ Firewall +-// 147 | ^ | 3 |===========>| 1 | 148 | | +---------+ injected +-+--------+ 149 | | data traffic | 150 | | | | 151 | | | | 152 | +---+-----+ +---------+ | | 153 | + Node | | Node | | | 154 | | 1 | | 2 | | | 155 | +---------+ +---------+ | | 156 | ^ | +--------// 157 | | | 158 +----------+-------------------------------+ 159 | 160 +--+---+ 161 | Node | 162 | A | 163 +------+ 165 Figure 1: General Limits of In-Path Firewall Signaling 167 4 Trust Relationships 169 It is unusual to start a protocol description with trust relationships 170 to explain the basic protocol behavior. A protocol for firewall 171 traversal is somewhat different since trust relationships are very 172 important for the protocol design and NAT traversal does not cause 173 problems to the same degree. for its internal mechanisms. 175 4.1 Peer-to-Peer Trust Relationship 177 The following scenarios can be considered as the simplest since peer-to- 178 peer trust relationship exist between the participating entities. These 179 trust relationships are either direct or indirect and help to establish 180 security associations dynamically (for example between Host A and the 181 local middlebox i.e. Middlebox 1 within Network A) with the help of an 182 authentication and key exchange protocol. Authentication and 183 authorization of the request to the middlebox device is thereby required 184 for successful protocol completion. Important in this context is the 185 trust relationship between the two networks (i.e. between Middlebox 1 186 and Middlebox 2). In this scenario it is assumed that no firewall is 187 present within the core network. In case that Middlebox requires 188 authentication of the Host A (or from the user located at Host A) then 189 an "Authentication Required" RESPONSE message with an error code is 190 returned to the initiator. In case of a sender-initiated signaling 191 message transmitted by Host A the requested filter entries at the first 192 middlebox are already installed when the request at the subsequent 193 middlebox fails. 195 Since end hosts usually do not have (and should not have) topology 196 information of the networks along the path it is not possible to 197 transmit policy rules for both directions (if data traffic later flows 198 in both directions). Hence it is required that both nodes transmit 199 separate signaling messages for each direction containing separate 200 policy rules for each traffic flow (if the data traffic is later sent in 201 both directions). These signaling messages are transmitted by the end 202 hosts and they do not need to travel along the same path because of 203 asymmetric routes (see [8]. Therefore the signaling message which is 204 triggered from the two end hosts in each direction do not necessarily 205 need to install state at the same firewall. 207 Policy rule installation is based on the information transmitted with 208 the flow identifier object at the CASP NTLP layer and at the packet 209 filter object at the NATFW NSLP layer. The content of both objects might 210 change mid-path (for example when passing a NAT) and is allowed to 211 change mid-session (for example because of mobility). For those cases 212 where the information carried within a packet filter object cannot be 213 interpreted an error message is returned indicating the inadequate 214 information. Packet filter processing failures are possible when for 215 example a Virtual Private Network Identifier such as (Extended) Tunnel 216 ID is transmitted to an IP firewall or when a firewall is unable to 217 install a packet filter with the indicated granularity. 219 4.2 Intra-domain Trust Relationship 220 +--------------------------+ +--------------------------+ 221 | | | | 222 | Network A | | Network B | 223 | | | | 224 | +---------+ +---------+ | 225 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 226 | | | box 1 | Trust | box 2 | | | 227 | | +---------+ Relationship +---------+ | | 228 | | | | | | 229 | | | | | | 230 | | | | | | 231 | | Trust | | Trust | | 232 | | Relationship | | Relationship | | 233 | | | | | | 234 | | | | | | 235 | | | | | | 236 | +--+---+ | | +--+---+ | 237 | | Host | | | | Host | | 238 | | A | | | | B | | 239 | +------+ | | +------+ | 240 +--------------------------+ +--------------------------+ 242 Figure 2: Peer-to-Peer Trust Relationship 244 In larger corporations often more than one firewall is used to protect 245 different departments. In many cases the entire enterprise is 246 controlled by a security department which gives instructions to the 247 department administrators. In such a scenario a peer-to-peer trust- 248 relationship might be prevalent. Sometimes however it might be 249 necessary to preserve authentication and authorization information 250 within the network. In this case an interaction between the individual 251 middleboxes and a central entity (for example a policy decision point - 252 PDP) might be required. Otherwise it is possible to communicate the 253 authorization decision made at one firewall to another firewall within 254 the same trust domain. Each middlebox can either communicate with the 255 PDP or the PDP issues an authorization token which allows the 256 middleboxes to react independently. Figure 3 refers to this structure. 257 To avoid complex protocol interactions individual middleboxes within an 258 administrative domain should make use of their trust relationship 259 instead of requesting authentication and authorization of the signaling 260 initiator again. This provides both a performance improvement without a 261 security disadvantage since a single administrative domain can be seen 262 as a single entity. 264 +---------------------------------------------------------------+ 265 | | 266 | Network A | 267 | | 268 | | 269 | +---------+ +---------+ 270 | +----///--------+ Middle- +------///------++ Middle- +--- 271 | | | box 2 | | box 2 | 272 | | +----+----+ +----+----+ 273 | | | | | 274 | +----+----+ | | | 275 | | Middle- +--------+ +---------+ | | 276 | | box 1 | | | | | 277 | +----+----+ | | | | 278 | | | | | | 279 | - | | | | 280 | - | +----+-----+ | | 281 | | | | Policy | | | 282 | +--+---+ +-----------+ Decision +----------+ | 283 | | Host | | Point | | 284 | | A | +----------+ | 285 | +------+ | 286 +---------------------------------------------------------------+ 288 Figure 3: Intra-domain Trust Relationship 290 4.3 Required End-to-Middle Trust Relationship 292 In some scenarios a simple peer-to-peer trust relationship between 293 participating nodes is not sufficient. Network B might require some 294 authentication of the signaling message initiator. If authentication and 295 authorization information is not attached to the initial signaling 296 message then the signaling message arriving at Middlebox 2 would cause a 297 RESPONSE message with an error code "Authentication Required" is 298 returned. However, in many cases the user initiating the signaling 299 message exchange is already aware of such a constraint and received 300 credentials before the message exchange was started. These credentials 301 might be based either on symmetric (shared secret) or based on 302 asymmetric (public key) cryptography. In order to avoid a 303 challenge/response type of message exchange the initiating node (Host A 304 in our scenario) already includes a CMS object to the outgoing signaling 305 message. The CMS object contains the identity of the signaling 306 initiator, the identity of the destination network, the destination 307 address of Host B, a timestamp for replay protection and possibly some 308 other application specific information like an application identifier. 309 CMS allows to use both symmetric and asymmetric credentials. 311 Figure 4 shows the slightly more complex trust relationships in this 312 scenario. 314 +--------------------------+ +--------------------------+ 315 | | | | 316 | Network A | | Network B | 317 | | | | 318 | | Trust | | 319 | | Relationship | | 320 | +---------+ +---------+ | 321 | +-///-+ Middle- +---///////----+ Middle- +-///-+ | 322 | | | box 1 | +-------+ box 2 | | | 323 | | +---------+ | +---------+ | | 324 | | | | | | | 325 | |Trust | | | | | 326 | |Relationship | | | | | 327 | | | | | Trust | | 328 | | | | | Relationship| | 329 | | | | | | | 330 | | | | | | | 331 | | | | | | | 332 | | | | | | | 333 | +--+---+ | | | +--+---+ | 334 | | Host +----///----+------+ | | Host | | 335 | | A | |Trust | | B | | 336 | +------+ |Relationship | +------+ | 337 +--------------------------+ +--------------------------+ 339 Figure 4: End-to-Middle Trust Relationship 341 4.4 Missing Network-to-Network Trust Relationship 343 Peer-to-peer trust relationship as shown in Figure 2 is a very 344 convenient assumption that allows simplified signaling message 345 processing. However it is obvious that such an assumption does not 346 always hold. Especially the trust relationship between two arbitrary 347 non-adjacent access networks is likely non-existent because of the large 348 number of networks and the unwillingness of administrators to have other 349 network operators to create holes in their firewalls without proper 350 authorization. Hence in the following scenario we assume a somewhat 351 different message processing and show three possible approaches to 352 tackle the problem. None of these three approaches is without drawbacks 353 or constraining assumptions. 355 +--------------------------+ +--------------------------+ 356 | | | | 357 | Network A | | Network B | 358 | | | | 359 | +---------+ Missing +---------+ | 360 | +-///-+ Middle- | Trust | Middle- +-///-+ | 361 | | | box 1 | Relation- | box 2 | | | 362 | | +---------+ ship +---------+ | | 363 | | | | | | 364 | | | | | | 365 | | | | | | 366 | | Trust | | Trust | | 367 | | Relationship | | Relationship | | 368 | | | | | | 369 | | | | | | 370 | | | | | | 371 | +--+---+ | | +--+---+ | 372 | | Host | | | | Host | | 373 | | A | | | | B | | 374 | +------+ | | +------+ | 375 +--------------------------+ +--------------------------+ 377 Figure 5: Missing Network-to-Network Trust Relationship 379 We identified three possible approaches of tackling the problem 380 described in Figure 5. 382 Receiver-Initiated Signaling: The first approach makes use of 383 receiver-based signaling message exchange. If Host A sends a 384 signaling message toward the destination to Middlebox 1 the 385 message can be properly protected. Middlebox 1 establishes 386 some state information and expects an incoming message 387 initiated by Host B. Signaling message protection between the 388 two networks is difficult. A missing trust relationship does 389 not necessarily mean that no security association 390 establishment is possible. The lacking trust "only" disallows 391 Middlebox 1 to create packet filters at Middlebox 2. Hence, 392 this missing trust is an authorization problem rather than a 393 security association establishment problem. If the CASP 394 message itself is allowed to pass the firewall then it finally 395 reaches Host B. Host B should not experience any difficulties 396 to install filters at the local firewall (Middlebox 2). The 397 message is then forwarded to Middlebox 1 which already waits 398 for the incoming signaling message. Because it is possible to 399 associate existing state information at Middlebox 1 with the 400 incoming message packet filters are installed and the message 401 is finally forwarded to Host A. Authorization for packet 402 filter installation in Network A has to be provided by Host A 403 and for Network B has to be provided by Host B when returning 404 the response message. packet filters are installed for data 405 traffic from Host A to Host B. The same procedure has to be 406 applied again to signal information for the other direction 407 (Host B to Host A). 409 The following behavior has to be assumed in order for this 410 approach to be applicable: 412 - Signaling messages must be allowed to pass firewalls along 413 the path. No authorization for packet filter installation is 414 required at this stage. Blocking signaling messages at 415 firewalls disallows the receiver of the signaling message to 416 return a signaling message. 418 - The signaling message initiated by the NI will require state 419 installation on all the NFs in the path (if a RSVP PATH 420 message semantic is assumed). CASP NTLP, however, also 421 allows a stateless signaling message routing. 423 This approach suffers from the following drawbacks: 425 - If the CASP signaling messages (in this case the "PATH" 426 message) is not allowed to bypass a firewall then no policy 427 rules are created at any node along the path. 429 - Receiver-initiated signaling has the advantage that the 430 receiver has to accept the creation of the policy rule in 431 his own network to trigger the creation locally. This seems 432 to simplify security processing. If a NAT is present then 433 still a RESPONSE message is required to inform the data 434 message sender about the NAT-binding (i.e. the IP addresses 435 and port information seen by a data traffic receiver). 437 Access Network-Only Signaling Message Exchange The next approach is 438 based on signaling packet filter information by both hosts 439 into the local access network only. CASP allows to specify 440 such a behavior by indicating the signaling endpoint with the 441 help of scoping ( for example with domain name or a "local 442 network only" flag). Scoping means that the signaling message 443 although addressed to a particular destination IP address 444 terminates somewhere along the path. If packet filters for 445 both directions have to be installed then the signaling 446 messages have to make packet filter installations up- and 447 downstream along the data path. Similar to proposals in the 448 area of QoS signaling some problems are likely to occur. One 449 such problem is that downstream signaling in general causes 450 problems because of asymmetric routes. In particular it is 451 difficult to determine the firewall where the downstream data 452 traffic will enter a network. The problem of triggering 453 downstream reservations is for example described in [9]. 454 Another problem for example is the placement of a firewall or 455 NAT along the path other than in the access network. This 456 would prevent a successful data exchange. 458 The following behavior has to be assumed in order for this 459 approach to be applicable: 461 - It must be possible to trigger a signaling message exchange 462 for a downstream signaling message exchange at the firewall 463 where the data traffic enters the network. 465 - No other firewalls or NATs are present along the path other 466 than in the access network. 468 This approach suffers from the following drawbacks: 470 - To signal policy rules only within the access network (by 471 both end-points) has a number of disadvantage and challenges 472 (see for example [9]). The complex message processing caused 473 by this approach strongly argues against it although it 474 might sound simple (and even might be simple in restricted 475 environments). Section 10 addresses message flows for this 476 case. Although its usage is possible with CASP we strongly 477 discourage its usage. 479 - Some circumstances can lead to ineffective policy rules. 481 Authorization Tokens: The last approach is based on some exchanged 482 authorization tokens which are created by an authorized entity 483 (such as the PDP) in each access network. Both hosts need to 484 exchange these tokens with some protocols such as SIP or HTTP 485 which is more likely allowed to bypass the firewall. Host A 486 would then include the received authorization token to the 487 signaling message for Network B. When the signaling message 488 arrives at Middlebox 2 then the token is verified by the 489 token-creating entity. In order to prevent parties from 490 reusing the token timestamps (e.g. token creation, token 491 lifetime, etc.) have to be included. Adding IP address 492 information about Host A would create difficulties in 493 relationship with NATs. 495 Information about Host B might be possible to include in order 496 to limit attacks where a token is lost and reused by a 497 different host for a different purpose. The goal is to 498 restrict the usage of the token for a specific session. The 499 content of the token only needs to be verified by the 500 originator of the token since it only has to be verified 501 locally. Since authorization needs to be linked to the 502 authorized actions which have to be performed on the packets 503 matching the packet filter, the token may include the 504 associated action or a reference to it. 506 The following behavior has to be assumed in order for this 507 approach to be applicable: 509 - The exchange of authorization tokens between end-systems 510 must be possible. These protocols must be allowed to pass 511 the firewalls. 513 - An end-system must be able to request such an authorization 514 token at some entity in the local network. 516 - The hosts need to have each other's addresses, which is 517 complicated to have if there are NATs deployed on the path 518 (especially with double NAT). 520 This approach suffers from the following drawback: 522 - An additional protocol is required for an end host to 523 request an authorization token from an entity in the local 524 network as depicted in Section 10. Note that CASP could be 525 extended to provide this functionality but currently it does 526 not. 528 4.5 Off-Path Signaling 530 The separation between signaling message delivery and discovery within 531 at the CASP NTLP protocol allows it to support in-path and off-path 532 signaling easily with the same protocol. Throughout this document in- 533 path signaling was assumed (the Scout protocol is used per-default for 534 next peer discovery) but off-path signaling might be desired in some 535 scenarios where a third-party entity wants to signal some policy rules 536 to a firewall and NATs. This mechanism has disadvantages in larger 537 networks with multiple firewalls since topology information is required 538 in order to install policy rules on the traversed firewalls and NATs. 540 5 Assumptions 542 Based on the above-described trust relationships the following protocol 543 assumptions have to be made. 545 � Middleboxes along the path are CASP-aware. If a middlebox is not 546 CASP-aware then protocol functionality cannot be fully guaranteed 547 (especially if the middlebox cannot be controlled with the help 548 of some protocol at all). The CASP-NATFW NSLP protocol can 549 operate with limitations if a CASP-unaware firewall blocks all 550 CASP signaling traffic. To support CASP-unaware NATs along the 551 path some information needs to be added to a CASP-NATFW message 552 to allow the signaling message receiving entity to verify that 553 the source ip address (and port numbers) have changed. Currently 554 no such object is included in this version of the document. 556 � The end host should not be required to know the topology of the 557 networks along the path or some other network internal issues. 558 Therefore it is not possible to make an assumption about routing 559 and hence we have to assume asymmetric routes. As a consequence 560 end hosts include unidirectional packet filters only. Within a 561 administrative domain where more information is available this 562 assumption might not hold and the establishment of bi-directional 563 packet filters could be possible. 565 6 NAT Involvement 567 Two issues need to be addressed when NATs are present along the path. 568 Since the end host should not a-priori knowledge about the location, 569 number and types of NATs along the path their presence has to be 570 assumed. 572 First, the CASP signaling messages itself must be able to traverse a 573 non-CASP aware NAT box without major problems. A NAT binding of a non- 574 CASP aware NAT can be established and maintained much easier with TCP 575 than with UDP. CASP recommends the usage of transport protocols such as 576 TCP or SCTP In case that the NAT is CASP-aware problems only occur if 577 source port numbers are fixed. CASP does not require fixed source port 578 numbers to be used. 580 The second issue addresses data packets for which a NAT binding needs to 581 be requested. When an end host starts to transmit scout packets to 582 discover the presence of firewalls and NATs along the path it is willing 583 to subsequently transmit data packets which match the packet filter. 584 Subsequently such a firewall-NAT-firewall scenario is described to 585 explain the basic protocol interaction and the usefulness for allowing 586 packet filters to change mid-path (i.e. along the path). Mid-session 587 changes of packet filters happen in mobility cases (for example if the 588 end host obtains a new care-of address). 590 +---------------------------------------------------------------+ 591 | | 592 | Network A | 593 | | 594 | PF=(192.168.1.5; PF=(139.23.203.30; | 595 | tcp+udp;666) tcp+udp;7000) | 596 | +---------+ +----------+ 597 | +----///------->+ NAT +------///----->+ Firewall +--> 598 | | | 1 | | 2 | 599 | | +---------+ +----------+ 600 | | | 601 | +----+-----+ | 602 | | Firewall | | 603 | | 1 | | 604 | +----+-----+ | 605 | ^ | 606 | - PF=(192.168.1.5; | 607 | - tcp+udp;666) | 608 | | | 609 | +--+---+ | 610 | | Host | | 611 | | A | | 612 | +------+ | 613 +---------------------------------------------------------------+ 615 Figure 6: NAT Involvement 617 In Figure 6 a hosts (Host A) wants to enable transmit data traffic from 618 source IP address 192.168.1.5 to a given destination IP address (not 619 shown in the Figure 6) at port 666 (both udp and tcp). Therefore Host A 620 transmits a CASP-NATFW message to Firewall 1 (after discovering that 621 this firewall is the next CASP supporting node along the data path) to 622 create the corresponding packet filters. Note that the traffic selector 623 is unidirectional. This scenario shows a sender-initiated scenario. 624 Firewall 1 installs two policy rules (one for udp and the other one for 625 tcp) after successful authentication and authorization. After forwarding 626 to the next middlebox (a NAT in this case) a NAT binding has to be 627 created for the given traffic selectors. The externally visible packet 628 filter (IP address changed to 139.23.203.30 and port number=7000) is 629 then forwarded to the next firewall (Firewall 2). Firewall 2 again 630 creates policy rules after authentication and authorization. Then the 631 signaling message is forwarded towards the destination. 633 After the signaling messages reaches the destination IP address or until 634 no further firewall can be reached (for example because the message is 635 rejected at a non CASP-aware firewall) a RESPONSE message is returned 636 (if requested by the signaling message initiator). A RESPONSE message 637 would contain a Status object which includes information about the 638 applied packet filter and whether the message reached its target or not. 639 In case of NATs along the path the packet filter information is then 640 included in protocols like SIP to communicate on which protocol/port 641 data will be sent. 643 In case no RESPONSE message is sent back, the CASP-NATFW aware NFs on 644 the path will return a RESPONSE message with an unsuccessful end to end 645 message delivery error when an associated timer to the existing 646 installed state (relevant to the reception of the CREATE message) 647 expires. The CASP-NATFW NI will receive only one RESPONSE message it 648 may receive more than one in particular cases. It is up to the NI to 649 decide if it has to proceed with the application or not. Every CASP- 650 NATFW on the path will need to filter out the associated RESPONSE, 651 messages to the same original CREATE message, sent by the CASP-NATFW NFs 652 on the upstream. In case a RESPONSE message provides a different filter 653 within the installed policy rule attribute, the RESPONSE message will be 654 forwarded on the downstream towards the CASP-NATFW aware NI. 656 Section 10 additionally addresses some message flows with NAT 657 involvement. 659 7 Operation 661 CASP-NATFW defines the following message types: 663 Path: A PATH message allows a receiver-initiated reservation 664 approach. This message does not cause packet filters to be 665 installed although all objects are present. This message is 666 then used as a trigger to cause a CREATE to be returned. The 667 PATH message transmitting entity includes the objects which 668 are later used (if not modified) by the sender of the CREATE 669 message. The PATH message allows receiver-initiated signaling 670 to be supported. 672 Create: A CREATE message allows to establish or update NSLP state 673 (i.e. policy rules) at one or more firewall(s) along the path. 674 Verification is necessary to ensure that policy rule creation 675 is allowed by the requesting entity and that no other local 676 security policy is violated. In case a security policy is 677 violated or the creation of the policy rule(s) is not 678 permitted, a RESPONSE message with a "Security Policy 679 Violated" error code is returned. If the CREATE message is 680 used without a previous PATH message then it represents a 681 typical sender-initiated reservation. 683 Release: A RELEASE message is used to delete installed NSLP state 684 at a firewall and to release a NAT binding without waiting for 685 a soft-state timeout. This message can only delete previously 686 installed state. Referring to previously installed state can 687 easily be done using the session identifier. Only authorized 688 parties are allowed to delete installed state, this includes 689 the creator of the state or other parties trusted by the state 690 creator (useful for fail over of the state creator). 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, discussed in Section 9, is set to 697 the Response message. No state information is modified by 698 processing and forwarding an acknowledgement. If an error has 699 to be returned then the error code inside the RESPONSE message 700 allows to specify more detailed error information. Such an 701 error code might for example indicate missing user specific 702 credentials, a missing authorization token or a security 703 policy violation. Detailed error codes have to be defined in 704 future versions of this 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: The TRIGGER message is an asynchronous event notification 716 sent by a CASP-NATFW aware node. Unlike the CREATE message it 717 does not create or modify NSLP state at nodes between the 718 initiator and the target of the TRIGGER. As a difference to 719 the PATH message also no NTLP routing state is created at 720 nodes between the initator and the target of the TRIGGER. Some 721 sort of trigger message is required to support access network 722 signaling message exchanges as described in Section 10 and in 723 Section 4.4. (TBD: This usefulness of this message or other 724 technical alternatives require some investigation.) 726 The following table shows the basic message behavior whereby the 727 following abbreviations are used: MAY (O), MUST NOT (--), MUST (M) or NA 728 (Not Applicable)) 730 The operations specify which message might indicate information to 731 trigger which other message in response by the other end. Some messages 732 (such as an error message) are created automatically without previous 733 indication. 735 Msg/Next Msg Path Create Release Response Query Trigger 736 ----------------------------------------------------------------- 737 Path NA M -- O -- -- 738 Create O O -- O -- -- 739 Release -- -- O? O M -- 740 Response -- -- -- NA -- -- 741 Query -- -- -- M NA -- 742 Trigger O O O? -- -- NA 744 Note that the "Must" entries in the table above indicate only the 745 default behavior. For example: A PATH message must be followed by a 746 CREATE message. However in case of an error a RESPONSE message (with an 747 error code) will be returned. 749 The following issues still require some investigations: 751 � To enable a bi-directional reservation the sender of a CREATE 752 message has to indicate either another CREATE message in the Next 753 object or a PATH message. It is questionable whether a sender- 754 initiated signaling message should follow a receiver-initiated? 756 � Is it useful to allow a RESPONSE or a RELEASE message to follow a 757 RELEASE message? 759 8 Typical Policy Rule Attributes 761 This paragraph describes some typically used attributes. Other 762 attributes such as flow labels might be used but are considered as an 763 exception of the packet filter. We believe that a granularity at 764 transport layer protocol state-level (syn, syn/ack, ack, etc.) is not 765 required for in-path signaling. 767 � Source/destination IPv4 and IPv6 addresses 769 � Port numbers (possibly including ranges and a list of port 770 numbers) 772 � Transport protocol (for example TCP, UDP) 774 � SPI (for IPSec protected data traffic) 776 � Identifiers for AH and ESP (Protocol numbers, next headers 777 fields) 779 A NAT object returned to the signaling message initiator contains the 780 same attribute types. The NAT object is included as a payload in the 781 Status object. A signaling message originator may also use the NAT 782 object to request a particular NAT binding to take place. The same 783 object is used for this purpose. 785 There are only two actions defined for a policy rule: "allow / no 786 logging" (default) and "allow / logging". The first action does not 787 require additional objects to be included other than the packet filter. 788 This is the default action. If a "allow / logging" action has to be 789 specified then the Logging Action object, defined in 9, has to be 790 included. This action creates log entries whenever the rule was 791 triggered. End hosts are usually not allowed to specify this behavior 792 because it could be used for a denial of service attack to cause log 793 files to grow quickly and without bounds. 795 Note that a single packet filter might also specify a range or ports. 796 Furthermore it is also possible to specify more than one policy rule 797 within a single signaling message (e.g. for off-path signaling). This 798 issue, however, requires further investigation. 800 9 Objects 802 The following objects are used by the CASP-NATFW client protocol: 804 9.1 Logging Action 806 This object indicates which packet filter(s) want to have logging 807 specified. Note that end host are usually not allowed to specify this 808 behavior for in-path signaling. It might however be requested within the 809 network or in case of off-path signaling. (TBD: Some investigation is 810 required to evaluate whether this action is really required.) 812 9.2 ApplicationID 814 This object contains an identifier to provide more information about the 815 data for which the policy rule is installed. Application-level firewalls 816 and firewalls with stateful inspection are able to use this information. 817 Providing a wrong application identifier for a given data traffic would 818 then cause a processing failure. Such a behavior is more secure than a 819 traditional packet filter firewall. Note however that encrypted end-to- 820 end traffic might reduce this advantage to some degree. A local 821 security policy might indicate that this information is required before 822 creating policy rules. A missing ApplicationID object would then cause a 823 "Application ID require" RESPONSE message with an error code is 824 returned. 826 9.3 Next 828 The Next object indicates the next request that the signaling message 829 receiver should generate if the incoming message was successfully 830 processed. Section 7 shows possible combinations of messages. For 831 example, a CREATE message might contain a Next object which is set to 832 CREATE causing another create message to be returned. Such a message 833 flow would represent a bi-directional reservation. A frequently used 834 object is the response object providing indications about a previously 835 submitted message. 837 9.4 Authorization Token 839 This object is used as described in Figure 5 of Section 4.4. More 840 description will be added in the near future (see Section 13). 842 9.5 CMS Credential Object 844 This object allows user specific cryptographic credentials to be 845 transmitted to specific CASP peers (or networks) along the path. Figure 846 4 describes a scenario where such an object is required. Attributes 847 included in this object are also briefly mentioned in Section 4.3. 849 9.6 Time 851 This object indicates that filters should be installed somewhere in the 852 near future. This might be required in the context of in-advance QoS 853 reservation for a conferencing scenario. If this object is not present, 854 the current time is used. 856 9.7 Age 858 The Age object is used to quickly determine whether any of the NSLP 859 object has changed (for example packet filter), to avoid a bit-by-bit 860 comparison. The Age object might be useful for messages which refresh 861 established state information only. Uniqueness of the Age object is only 862 required only within a session. Whenever state information has to be 863 modified then a new value has to be placed in the Age object. A high- 864 resolution timestamp is typically used for this purpose. 866 9.8 Status 867 The Status object is used to deliver status information inside the 868 RESPONSE message. This object might return error notifications or 869 information about installed packet filters (e.g. NAT-Object). Delivering 870 packet filter information is helpful for application (such as SIP, H323, 871 MEGACO, MGCP etc. ) that need to deliver IP address, protocol type and 872 port information to the initiator in case of NATs along the path. 874 10 Basic Protocol Behavior 876 The following message flows try to show the basic protocol behavior and 877 possible combinations regarding sender- and receiver-initiated messages 878 flows, uni-directional or bi-directional packet filters, different trust 879 assumptions and NAT and/or firewall traversal. The subsequently shown 880 figures do not include message flows for next-peer discovery (for 881 example using the Scout protocol). 883 10.1 Receiver-Initiated Message Flow with Firewalls 885 The following message flow shows the protocol behavior in case of a 886 receiver-initiated signaling message exchange with two administrative 887 domains (Network A and B) and two firewalls located at the borders. For 888 the message flow a peer-to-peer trust relationship is assumed. 889 Cryptographic credentials which support end-to-middle authentication 890 (Host A-to-FW 2) can be included by Host A into the PATH message. The 891 usage of receiver-initiation has the advantage that Host B has to assist 892 in policy rule installation at Firewall B. 894 In Figure 7 the sender indicates in the PATH message which policy rule 895 to install by adding this information to the packet filter. Host A uses 896 the IP address 139.23.203.23 and the destination IP address (Host B) is 897 17.12.23.5. Note that the transport protocol is not mentioned since it 898 is not helpful. The first firewall (FW 1) installs the indicated policy 899 rule (packet filter with "allow / without logging" action). The message 900 is forwarded to the next CASP aware node (FW 2). Because of the peer-to- 901 peer trust assumption FW 2 trusts FW1 for the correctness of the 902 provided parameters. The identity of the signaling message originator 903 might be included in the signaling messages addressed toward the other 904 end host. Policy rules are installed at both firewalls. When the 905 signaling message reaches Host B then a CREATE message is returned in 906 response and includes the same packet filter (unmodified). Note that 907 the packet filter is always directional (especially for the CREATE 908 message in response to a PATH message this is applicable). The CREATE 909 message installs the policy rules at the two firewalls. The CREATE 910 message finally reaches Host A who can immediately start to transmit 911 data traffic towards Host B. 913 +------------------------------+ +-----------------------------+ 914 | +------+ +------+ | | +------+ +--------+ | 915 | |Host A| Network | FW 1 | | | | FW 2 | Network | Host B | | 916 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 917 +-+--+-------------------+-----+ +----+-----------------+----+-+ 918 |Path(PF= | | | 919 |(src=139.23.203.23, | | | 920 | dst=17.12.23.5, | | | 921 | sport=5000, | | | 922 | dport=600) | | | 923 |--------------------->| | | 924 | |Path(PF= | | 925 | |(src=139.23.203.23,| | 926 | | dst=17.12.23.5, | | 927 | | sport=5000, | | 928 | | dport=600) | | 929 | |------------------>| | 930 | | |Path(PF= | 931 | | |(src=139.23.203.23, | 932 | | | dst=17.12.23.5, | 933 | | | sport=5000, | 934 | | | dport=600) | 935 | | |--------------------->| 936 | | |Create(PF= | 937 | | |(src=139.23.203.23, | 938 | | | dst=17.12.23.5, | 939 | | | sport=5000, | 940 | | | dport=600) | 941 | | |<---------------------| 942 | |Create(PF= | | 943 | |(src=139.23.203.23,| | 944 | | dst=17.12.23.5, | | 945 | | sport=5000, | | 946 | | dport=600) | | 947 | |<------------------| | 948 |Create(PF= | | | 949 |(src=139.23.203.23, | | | 950 | dst=17.12.23.5, | | | 951 | sport=5000, | | | 952 | dport=600) | | | 953 |<---------------------| | | 954 | Data Traffic (unidirectional) | 955 |================================================================>| 957 Figure 7: Receiver-Initiated Message Flow with Firewalls 958 The following issues arise with the description of the message flow of 959 Figure 7: 961 � Should packet filter information included in the PATH and CREATE 962 message. packet filter information in the PATH message could be 963 temporarily stored at middleboxes (firewalls in this example). 964 The CREATE message would then only refer to existing state 965 information. 967 � It does not seem to be useful to have a stateless version of the 968 PATH message. Do we want to support such a stateless version? 970 � If the Path message fails then no policy rules are installed. The 971 signaling message flow has to be restarted. 973 Figure 7 does not contain NATs, micro-/macro-mobility specific message 974 flows or any form of tunneling. Hence no mid-path packet filter 975 modification is necessary, otherwise such a packet filter modification 976 would be required. Entities, which are aware of micro-/macro-mobility 977 protocols (for example a MAP or a home agent), are no middleboxes in the 978 traditional sense. Since they have an impact on the packet filter and on 979 the data traffic it would be necessary to treat them as artificial 980 middlebox to properly address flow identifications along the path. If no 981 such treatment takes place then the wrong policy rules are installed at 982 firewalls with the consequence that the entire protocol interaction is 983 useless. In this description we assume that packet filter attributes are 984 based on information used for routing (i.e. IP addresses). 986 10.2 Sender-Initiated Message Flow with Firewalls 988 The following message flow shows the protocol behavior in case of a 989 sender-initiated signaling message exchange with two administrative 990 domains (Network A and B) and two firewalls (FW 1 and FW 2). No NAT and 991 other devices requiring modifications to the packet filter are used. 992 This message flow also assumes a peer-to-peer trust relationship. 993 Cryptographic credentials which support end-to-middle authentication 994 (Host A-to-FW 2) can be included by Host A into the CREATE message. 996 The message flow in Figure 8 is similar to Figure 7. The CREATE message 997 contains the packet filter and immediately (after authentication, 998 authorization and verification) causes the installation of policy rules. 999 The signaling message sender might request a RESPONSE message. In case 1000 of NATs along the path such a RESPONSE message is very useful to return 1001 NAT binding information. 1003 This scenario does not require packet filter modification along the 1004 path. No NAT binding is returned with the optional RESPONSE message. 1006 +------------------------------+ +-----------------------------+ 1007 | +------+ +------+ | | +------+ +--------+ | 1008 | |Host A| Network | FW 1 | | | | FW 2 | Network | Host B | | 1009 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1010 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1011 |Create(PF= | | | 1012 |(src=139.23.203.23, | | | 1013 | dst=17.12.23.5, | | | 1014 | sport=5000, | | | 1015 | dport=600) | | | 1016 |--------------------->| | | 1017 | |Create(PF= | | 1018 | |(src=139.23.203.23,| | 1019 | | dst=17.12.23.5, | | 1020 | | sport=5000, | | 1021 | | dport=600) | | 1022 | |------------------>| | 1023 | | |Create(PF= | 1024 | | |(src=139.23.203.23, | 1025 | | | dst=17.12.23.5, | 1026 | | | sport=5000, | 1027 | | | dport=600) | 1028 | | |--------------------->| 1029 | | | [Response] | 1030 | | |<---------------------| 1031 | | [Response] | | 1032 | |<------------------| | 1033 | [Response] | | | 1034 |<---------------------| | | 1035 | Data Traffic (unidirectional) | 1036 |================================================================>| 1038 Figure 8: Sender-Initiated Message Flow with Firewalls 1040 The following issue arises with the description of the message flow of 1041 Figure 8: 1043 � If a verification error is caused during the CREATE message 1044 processing then some firewalls might have installed policy rules 1045 whereas others have never seen the signaling message. A RESPONSE 1046 message indicating an error could leave installed state in place 1047 or cause already established state to be removed automatically. 1049 10.3 Receiver-Initiated Message Flow with a Firewall and a NAT 1051 The message flow in Figure 9 introduces a middlebox with NAT 1052 functionality (NAT 1), in addition to a firewall at Network B, along the 1053 path between Host A and Host B. Note that NAT 1 might additionally have 1054 firewall functionality which would require to install pinhole opening 1055 and NAT binding policy rules. The message flow assumes that Host A with 1056 source IP address 10.1.0.5 wants to transmit data traffic at source port 1057 1200 (for example UDP / not shown in this example) to destination 1058 address 17.12.23.5 at destination port number 600. Host A does not 1059 requires a particular NAT binding, hence no NAT-Object is required 1060 within the initial PATH message. In any case a NAT binding will be 1061 included within the NAT-Object returned in the RESPONSE message. Instead 1062 the provided NAT binding is provided as a NAT-Object in response. If 1063 Host A would like to request a particular NAT binding then the NAT- 1064 Object has to be included in the initial PATH message. 1066 As soon as the signaling message reaches NAT 1 a NAT binding is 1067 requested and the result of this request is placed into the Traffic 1068 selector field (i.e. src ip address is changed from 10.1.0.5 to 1069 139.23.203.30 and the sport is rewritten from 1200 to 5000). When the 1070 signaling messages is successfully processed by FW 2 and forwarded to 1071 Host B a CREATE message with the indicated packet filter is returned. A 1072 copy of the received packet filter is placed into the NAT-Object. By 1073 returning the NAT-Object information, Host A is able to learn which IP 1074 address and port , hence no NAT-Object is required within the initial 1075 PATH message. In any case a NAT binding will be included within the NAT- 1076 Object returned in the RESPONSE message. The CREATE message is routed 1077 backwards toward Host A (since the path is pinned down). 1079 The exchange of end-to-end messages after a successful signaling message 1080 exchange might be required to exchange parameters about the subsequent 1081 data traffic. Finally Host A starts to transmit data packets to Host B. 1083 10.4 Sender-Initiated Message Flow with a Firewall and a NAT 1085 Figure 10 shows a sender-initiated signaling message flow whereby FW 2 1086 in Network B initially rejects the signaling message due to an 1087 authentication/authorization failure. The returned RESPONSE message 1088 includes among the error code, information about the entity creating the 1089 error (in this case FW2@NetworkB) and optionally a challenge value. The 1090 challenge value allows Host A to either provide a freshness guarantee 1091 based on the challenge value and/or based on a timestamp. The usage of 1092 CMS allows Host A and Network B to use symmetric and asymmetric 1093 credentials for authentication. In any case a Credential object is 1094 attached to the CREATE signaling message. The Credential object 1095 securely binds a timestamp or a sequence number (to prevent replay 1096 +------------------------------+ +-----------------------------+ 1097 | +------+ +------+ | | +------+ +--------+ | 1098 | |Host A| Network | NAT 1| | | | FW 2| Network | Host B | | 1099 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1100 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1101 |Path(PF= | | | 1102 |(src=10.1.0.5, | | | 1103 | dst=17.12.23.5, | | | 1104 | sport=1200, |Path(PF= | | 1105 | dport=600) |(src=139.23.203.23,| | 1106 |--------------------->| dst=17.12.23.5, | | 1107 | | sport=5000, |Path(PF= | 1108 | | dport=600) |(src=139.23.203.23, | 1109 | |------------------>| dst=17.12.23.5, | 1110 | | | sport=5000, | 1111 | | | dport=600) | 1112 | | |--------------------->| 1113 | | | | 1114 | | |Create(PF= | 1115 | | |(src=139.23.203.23, | 1116 | |Create(PF= | dst=17.12.23.5, | 1117 | |(src=139.23.203.23,| sport=5000, | 1118 | | dst=17.12.23.5, | dport=600); | 1119 |Create(PF= | sport=5000, | NAT-Object= | 1120 |(src=10.1.0.5, | dport=600); |(src=139.23.203.23, | 1121 | dst=17.12.23.5, | NAT-Object= | dst=17.12.23.5, | 1122 | sport=1200, |(src=139.23.203.23,| sport=5000, | 1123 | dport=600); | dst=17.12.23.5, | dport=600)) | 1124 | NAT-Object= | sport=5000, |<---------------------| 1125 |(src=139.23.203.23, | dport=600)) | | 1126 | dst=17.12.23.5, |<------------------| | 1127 | sport=5000, | | | 1128 | dport=600)) | | | 1129 |<---------------------| | | 1130 | | | | 1131 | For example: SIP Signaling | 1132 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 1133 | | | | 1134 | Data Traffic (unidirectional) | 1135 |================================================================>| 1137 Figure 9: Receiver-Initiated Message Flow with a Firewall and a NAT 1139 attacks), identities, lifetime and possibly packet filter information to 1140 the cryptographic credentials. The RESPONSE message might return a NAT- 1141 Object if a NAT was present along the path. 1143 Host A retransmits a new signaling message. After verification of the 1144 request and the credentials FW 2 forwards the message to Host B. As in 1145 previous examples Host B returns a RESPONSE message with a NAT-Object 1146 back to Host A. 1148 The message flow shows the following protocol features: 1150 � End-to-Middle Authentication by including a CMS object 1151 (Credential object) to the signaling message after the 1152 authentication/authorization failure. If the Credential object is 1153 included into the first CREATE signaling message then no such 1154 error message is returned. However in that case replay protection 1155 can only be based on timestamps (loosely synchronized clocks). 1157 � A NAT-Object is included in the RESPONSE message which provides 1158 information about the NAT binding. 1160 � The RESPONSE message indicating an error could also return a NAT- 1161 Object to provide initial information about the existence of a 1162 NAT. 1164 � The same protocol operations can be used without NATs (only 1165 firewalls). 1167 10.5 Sender-Initiated NAT/Firewall Traversal with Authorization Token 1169 The next scenario is slightly more complicated in the sense that 1170 authorization information for Network B is provided by Host B. Host B 1171 first request an authorization token from an entity in the local network 1172 by some means. This token is then communicated to Host A using an end- 1173 to-end protocol such as SIP or HTTP. This token then provides the 1174 necessary trust for Network B to allow the CREATE message to install 1175 policy rules at FW 2. Note that this message flow is different compared 1176 to the scenario described in Figure 10. In this case no pre-established 1177 cryptographic credentials between Host A and Network B are present 1178 before the protocol is used between Host A and Host B. 1180 The sender-initiated message flow is similar to the above-described 1181 flows with the only exception that the Authorization Token is included. 1182 The token is removed at FW 2 after successful verification. 1184 10.6 Sender-Initiated Firewall Signaling only at the Access Network 1185 +------------------------------+ +-----------------------------+ 1186 | +------+ +------+ | | +------+ +--------+ | 1187 | |Host A| Network | NAT 1| | | | FW 2| Network | Host B | | 1188 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1189 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1190 |Create(PF= | | | 1191 |(src=10.1.0.5, |Create(PF= | | 1192 | dst=17.12.23.5, |(src=139.23.203.23,| | 1193 | sport=1200, | dst=17.12.23.5, | | 1194 | dport=600) | sport=5000, | | 1195 |--------------------->| dport=600) | | 1196 | |------------------>| | 1197 | |Response(ErrorCode=| | 1198 |Response(ErrorCode= |"Auth. Required", | | 1199 |"Auth. Required", | FW2@NetworkB, | | 1200 | FW2@NetworkB, | challenge=0x7a..8,| | 1201 | challenge=0x7a..8, |<------------------| | 1202 |<---------------------| | | 1203 |Create(PF= | | | 1204 |(src=10.1.0.5, | | | 1205 | dst=17.12.23.5, |Create(PF= | | 1206 | sport=1200, |(src=139.23.203.23,| | 1207 | dport=600) | dst=17.12.23.5, |Create(PF= | 1208 | Credentials(...)) | sport=5000, |(src=10.1.0.5, | 1209 |--------------------->| dport=600) | dst=17.12.23.5, | 1210 | | Credentials(...)) | sport=1200, | 1211 | |------------------>| dport=600) | 1212 | | |--------------------->| 1213 | | | Response( | 1214 | | Response( | NAT-Object(...)) | 1215 | Response( | NAT-Object(...)) |<---------------------| 1216 | NAT-Object(...)) |<------------------| | 1217 |<---------------------| | | 1218 | | SIP Signaling | | 1219 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 1220 | | | | 1221 | Data Traffic (unidirectional) | 1222 |================================================================>| 1224 Figure 10: Sender-Initiated Message Flow with a Firewall and a NAT 1226 Sometimes people argue that the signaling message exchange should be 1227 done locally at the network access only because per-flow signaling 1228 messages are not processed in the core network. Instead of sending the 1229 +------------------------------+ +-----------------------------+ 1230 | +------+ +------+ | | +------+ +--------+ | 1231 | |Host A| Network | NAT 1| | | | FW 2| Network | Host B | | 1232 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1233 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1234 | | | Authorization | 1235 | | | Token | 1236 | | | Request | 1237 | | |<---------------------| 1238 | | | Authorization | 1239 | | End-to-End | Token | 1240 | | Communication | Response | 1241 | | (Authorization |--------------------->| 1242 | | Token) | | 1243 |<----------------------------------------------------------------| 1244 |Create(PF= | | | 1245 |(src=10.1.0.5, | | | 1246 | dst=17.12.23.5, |Create(PF= | | 1247 | sport=1200, |(src=139.23.203.23,| | 1248 | dport=600); Token) | dst=17.12.23.5, |Create(PF= | 1249 |--------------------->| sport=5000, |(src=10.1.0.5, | 1250 | | dport=600); Token)| dst=17.12.23.5, | 1251 | |------------------>| sport=1200, | 1252 | | | dport=600) | 1253 | | |--------------------->| 1254 | | | Response( | 1255 | | | NAT-Object(...)) | 1256 | | Response( |<---------------------| 1257 | | NAT-Object(...)) | | 1258 | Response( |<------------------| | 1259 | NAT-Object(...)) | | | 1260 |<---------------------| | | 1261 | | SIP Signaling | | 1262 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| 1263 | | | | 1264 | Data Traffic (unidirectional) | 1265 |================================================================>| 1267 Figure 11: Sender-Initiated NAT/Firewall Traversal with Authorization 1268 Token 1270 signaling messages from one access network to the other whereby the 1271 signaling messages are transparent in the core each host transmits 1272 signaling messages independently in its own network. Although the 1273 concept sounds very simple at the first glance it turns out to be very 1274 complex in the generic case. Most difficulties appear because of the 1275 asymmetric routing architecture. Establishing policy rules in the uplink 1276 direction is fairly simple and requires only a mechanism which allows 1277 some sort of scoping (i.e. signaling messages have to terminate 1278 somewhere in the access network) without actually indicating the end- 1279 point. Casp provides means for scoping and local access network 1280 signaling. However the installation of policy rules on the downlink 1281 direction is complicated because some topology information inside the 1282 network must be known in order to avoid policy rule creation at the 1283 wrong devices. Hence there is a built-in risk to cause the protocol to 1284 fail (i.e. to install policy rules at the wrong location). 1286 For the message flow described in Figure 12 we assume the following 1287 protocol behavior: 1289 � Host A and Host B initiate a bi-directional packet filter 1290 establishment with a scope restricted to the local access network 1291 only. Without some sort of bi-directional signaling message 1292 exchange, a TRIGGER message is required to initiate a downlink 1293 Traffic Selection establishment. 1295 � Based on the characteristics of local signaling message exchanges 1296 at both access networks, assumptions about the topology must be 1297 made (or some topology information must be known). 1299 � In this simplified message flow no NAT device is present. 1301 � Host A has a-priori knowledge about the packet filter for the 1302 inbound traffic (i.e. src=17.12.23.5 and sport=601). 1304 With the initial CREATE message Host A already supplies packet filter 1305 information for the bi-directional reservation (i.e. the CREATE message 1306 by Host A is followed by another CREATE message from FW 1). To kept the 1307 CREATE signaling message within the local access network scoping is 1308 used. Indicating a particular IP address might also be possible but 1309 often the endpoint is unknown to the end host. As a result of successful 1310 processing a CREATE message is returned in response with the already 1311 provided packet filter. 1313 Optionally an end-to-end message communication might follow to transmit 1314 packet filter information from Host A to Host B. In most cases some 1315 communication is however required. Similar as in Network A a CREATE 1316 message is initiated by the end host with the Next object set to another 1317 CREATE message. 1319 +------------------------------+ +-----------------------------+ 1320 | +------+ +------+ | | +------+ +--------+ | 1321 | |Host A| Network | FW 1 | | | | FW 2 | Network | Host B | | 1322 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1323 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1324 |Create(PF=(src=139.23.205.5, | | 1325 | dst=17.12.23.5, sport=5000, dport=600); | | 1326 | Next=Create(PF=(src=17.12.23.5, | | 1327 | dst=139.23.205.5,sport=601,dport=5001)); | | 1328 | Scope=NetworkA) | | | 1329 |--------------------->| | | 1330 |Create(PF= | | | 1331 |(src=17.12.23.5, | | | 1332 | dst=139.23.205.5, | | | 1333 | sport=601, | | | 1334 | dport=5001)) | | | 1335 |<---------------------| | | 1336 | | End-to-End | | 1337 | | Communication | | 1338 | | (PF) - Optional | | 1339 |<--------------------------------------------------------------->| 1340 | |Create(PF=(src=17.12.23.5, | 1341 | | dst=139.23.205.5, sport=601, dport=5001);| 1342 | | Next=Create(PF=(src=139.23.205.5, | 1343 | | dst=17.12.23.5, sport=5000, dport=600)); | 1344 | | Scope=NetworkB) | | 1345 | | |<---------------------| 1346 | | |Create(PF= | 1347 | | |(src=139.23.205.5, | 1348 | | | dst=17.12.23.5, | 1349 | | | sport=5000, | 1350 | | | dport=600)) | 1351 | | |--------------------->| 1352 | Data Traffic (bi-directional) | 1353 |<===============================================================>| 1355 Figure 12: Sender-Initiated Firewall Signaling only at the Access 1356 Network 1358 Finally if everything was successful data can be exchanged in both 1359 directions on port 5001<-601 and a 5000->600. 1361 10.7 Sender-Initiated NAT and Firewall Traversal within the Access 1362 Network 1363 The message flow described in Figure 13 extends the description in 1364 Figure 12 by using a uni-directional signaling exchange. As a 1365 consequence of this extension a TRIGGER message is required to cause a 1366 downlink signaling message to be sent within Network B. In order to 1367 avoid this message Network B could intercept the end-to-end message 1368 exchange to trigger a signaling message to Host B. However this 1369 approach might suffer from the problem to be able to read and evaluate 1370 end-to-end signaling messages. 1372 In addition, a NAT device is used in Network A which requires Host A to 1373 request a NAT binding and the corresponding NAT-Object which is then 1374 communicated to Host B. Using the packet filter information inside the 1375 NAT-Object Host B learns the public IP address and port information of 1376 the data traffic transmitted by Host A. 1378 The access network signaling message exchange requires some topology 1379 information as explained in previous figures. The TRIGGER message must 1380 cause a downlink signaling message to be initiated by a network device 1381 which where the data traffic of Host A is sent through. This particular 1382 issue will be explained in more detail in a future version of the 1383 document. 1385 A even more difficult example would address a topology where each 1386 network is equipped with a NAT. The same is true for packet filter 1387 installation for data traffic flowing in both directions with one or two 1388 NATs. 1390 11 Security Considerations 1392 Installing packet filters to one or more firewalls is a security 1393 sensitive process. Security protection of signaling messages is 1394 necessary in order to defeat a number of threats. This section gives a 1395 brief discussion of possible threats and addresses their corresponding 1396 countermeasures. 1398 11.1 Threats 1400 Denial of Service: Denial of service attacks can be launched by 1401 modifying messages used during the discovery process. A client 1402 could then be forced to contact a "wrong" firewall which is 1403 outside the data path. Furthermore it is possible to flood a 1404 firewall with bogus request and thereby cause massive state 1405 and computational resources to be allocated as part of the key 1406 exchange process. Furthermore an adversary can modify the 1407 packet filter of a request to cause a large number of packet 1408 filters to be allocated. An adversary might also remove 1409 administrator installed packet filters which are not related 1411 +------------------------------+ +-----------------------------+ 1412 | +------+ +------+ | | +------+ +--------+ | 1413 | |Host A| Network | NAT 1| | | | FW 2 | Network | Host B | | 1414 | +--+---+ A +--+---+ | | +--+---+ B +---+----+ | 1415 +-+--+-------------------+-----+ +----+-----------------+----+-+ 1416 |Create(PF= | | | 1417 |(src=192.168.1.5, | | | 1418 | dst=17.12.23.5, | | | 1419 | sport=5000, | | | 1420 | dport=600); | | | 1421 | Scope=NetworkA) | | | 1422 |--------------------->| | | 1423 |Response( | | | 1424 |NAT-Object= | | | 1425 |(src=139.23.203.30, | | | 1426 | dst=17.12.23.5, | | | 1427 | sport=8000, | | | 1428 | dport=600)) | End-to-End | | 1429 |<---------------------| Communication | | 1430 | | (NAT-Object) | | 1431 |<--------------------------------------------------------------->| 1432 | | |Trigger(PF= | 1433 | | |(src=139.23.205.30, | 1434 | | | dst=17.12.23.5, | 1435 | | | sport=8000, | 1436 | | | dport=600); | 1437 | | | Scope=NetworkB) | 1438 | | |<---------------------| 1439 | | |Create(PF= | 1440 | | |(src=139.23.205.30, | 1441 | | | dst=17.12.23.5, | 1442 | | | sport=8000, | 1443 | | | dport=600)) | 1444 | | |--------------------->| 1445 | Data Traffic (uni-directional) | 1446 |================================================================>| 1448 Figure 13: Sender-Initiated NAT and Firewall Traversal within the Access 1449 Network 1451 to previous packet filter installations by users. 1453 Man-in-the-Middle: MITM attacks are possible during the discovery 1454 process where the entity of a firewall is discovered. In this 1455 case the user might be convinced to communicate with a 1456 firewall which is not the case. Many of these attacks are 1457 related to the discovery mechanism and therefore also 1458 described in [1]. Further threats which are not specific to 1459 the scout mechanism but also related to the next-hop discovery 1460 mechanism require further investigation (such as SLP, DHCP, 1461 DNS, etc.). The authors of some of these configuration 1462 mechanisms have already identified potential vulnerabilities 1463 and provide the corresponding security protection. 1465 Eavesdropping: An eavesdropper might be able to learn some 1466 installed packet filters by listening to the signaling message 1467 communication between a client and a firewall. Furthermore it 1468 might be possible to learn an exchanged authorization tokens 1469 between the two entities or between entities along the path. 1470 Since the session identifier is used to uniquely identify 1471 state established along entities along the path an adversary 1472 might reuse this identifier to refer to existing state 1473 information. 1475 Integrity Violation: By modifying a request message, an adversary 1476 can delete installed firewall filters, install filters using a 1477 different authorization identity or to create filters with a 1478 large lifetime. 1480 Masquerading: An adversary might gain information by querying 1481 installed packet filters at a firewall by masquerading the 1482 identify of a real user. This might be used for subsequent 1483 attacks. 1485 Rogue Firewall: An adversary at a compromised firewall might 1486 exploit an existing trust relationship to install or remove 1487 filters at other firewalls. Furthermore it is possible to 1488 return a NAT object with wrong information causing subsequent 1489 data traffic to be send to an arbitrary location. 1491 Unauthorized Access: A regular user might install firewall filters 1492 although he is not allowed because of missing authorization. 1493 Administrators are usually very concerned about installing 1494 packet filters from users access from an external network. 1496 Replay Attacks: An adversary might eavesdrop CASP-NATFW signaling 1497 messages and use them later for a replay attack. Furthermore 1498 an adversary might be able to collect authorization tokens and 1499 reuse them in a different context or later in time to open 1500 holes into a firewall. 1502 Privacy Violation: Adversaries can learn about the NI and NR's 1503 identities participating in the message exchange by 1504 eavesdropping information exchanged between the two end- 1505 systems. Especially authorization tokens exchanged between 1506 end-systems outside the CASP protocol (as explained in Section 1507 4.4) represent a vulnerability. 1509 11.2 Countermeasures 1511 To prevent the above-listed attacks a number of countermeasures are 1512 taken: 1514 Denial of Service: To limit denial of service attacks a number of 1515 countermeasure were taken. First the scout protocol (and other 1516 configuration mechanisms) experience some protection to 1517 prevent basic attacks. Furthermore it is necessary to mutually 1518 authenticate and authorize both peers after establishing a 1519 transport layer connection as described in [1]. Since the 1520 authentication and key exchange protocol requires state and 1521 computational resources it has to be resistant against denial 1522 of service attacks. When transmitting CASP-NATFW specific 1523 information protection of the requests itself is necessary to 1524 prevent an adversary from object modification which otherwise 1525 would cause unpredictable behavior. 1527 Man-in-the-Middle: MITM attacks during the discovery phase are 1528 prevented by secure configuration mechanisms. The scout 1529 protocol experiences limited security protection by its 1530 nature. However an authentication and authorization step is 1531 required after learning the identity of the next CASP peer. 1532 MITM adversaries will experience difficulties launching a 1533 successful attack after transport layer connection 1534 establishment because of the signaling message protection. 1536 Eavesdropping: Eavesdropping of signaling messages is prevented by 1537 using either IPSec ESP (without NULL encryption) or by using 1538 TLS (with encryption cipher-suites). It is therefore not 1539 possible to learn authorization tokens, session identifiers or 1540 other firewall packet filter specific information that might 1541 be useful for an adversary eavesdropping on for example a 1542 wireless link. With the suggested security protection 1543 eavesdropping is therefore only possible at CASP-NATFW aware 1544 nodes participating in the signaling message exchange. This 1545 is, however, intentional and required for the operation of the 1546 protocol. 1548 Integrity Violation: Modifying the content of signaling packets is 1549 prevented by either IPSec or TLS. Exchanged information 1550 thereby experiences both confidentiality as well as integrity 1551 protection. The usage of integrity protection with IPSec ESP 1552 is strongly recommended. 1554 Masquerading: Spoofing an identity to be able to delete or query 1555 installed packet filter information is prevented by 1556 authentication of the originator (i.e. data origin 1557 authentication) of transmitted signaling messages. For the 1558 establishment of the required security associations mutual 1559 authentication is assumed. 1561 Rogue CASP-NATFW Node: Firewalls are security sensitive network 1562 devices. An adversary can use a compromised firewall in a 1563 number of ways. To prevent a compromised firewall to harm 1564 other firewalls, trust might be limited and strong 1565 verification of request might be required. In case of missing 1566 peer-to-peer trust relationships more sophisticated protocol 1567 handling (as described in 4.3 and 4.4) is necessary. Such a 1568 handling makes it more difficult for an adversary to perform a 1569 successful attack. Note that any malicious CASP-NATFW (or CASP 1570 node in general) can impact the security of other entities 1571 (not just firewalls). 1573 Unauthorized Access: Differentiation of access rights between 1574 various users and user-groups is common. The same type of 1575 authorization mechanisms based on access control lists can be 1576 applied. If authorization tokens are used then additionally a 1577 locally known user must be able to request such a token. For 1578 the trust relationship described in 4.3 one administrative 1579 domain must have a pre-established security association. The 1580 establishment of such this security association is usually 1581 bound to specific access control rights. 1583 Privacy Violation: Encryption of information about user identities 1584 contained in authorization token prevents an adversary from 1585 obtaining user specific information. Currently only a keyed 1586 message digest function (HMAC) is provided to protect the 1587 authorization token content against modification. Either a 1588 custom mechanisms for encrypting some token parts or CMS 1589 encryption could be used to provide the necessary protection. 1590 Further investigation is required. 1592 Linking authorization between different protocols, to strict policy rule 1593 creation by the end host, is possible with authorization tokens which 1594 contain information about the application, policy rule, authorization 1595 decision, lifetime, etc. An authorization token can be based on CMS or 1596 on a custom security mechanism such as defined in [10,11]. 1598 To summarize: CASP uses security mechanisms described in [1]. Securing 1599 the messaging layer in a CASP-peer to CASP-peer fashion is provided 1600 either by IPsec or by TLS. In some cases security protection between 1601 neighboring peers is not sufficient. Non peer-to-peer protection of 1602 client layer objects is provided by CMS which allows CASP-NATFW objects 1603 defined in this document to be encapsulated and protected by CMS. 1605 12 Conclusion 1607 CASP-NATFW aims to provide a long-term solution to communicate with NATs 1608 and Firewalls with the following properties: 1610 Routing of Signaling Messages: CASP with its scout discovery 1611 mechanisms allows signaling messages to follow the path of the 1612 data traffic towards a destination. This assumes that standard 1613 routing is used. CASP, however, operates independent of the 1614 underlying routing mechanism. Route changes can be detected by 1615 the scout protocol and signaling message transmission is 1616 adopted accordingly. Other mechanisms for detecting route 1617 changes can also be used such as routing protocols. 1619 Security Protection: Creating holes into a firewall is a sensitive 1620 task that requires trust and an appropriate security 1621 protection of the signaling messages in order to be 1622 successful. Trust assumptions between the participating 1623 entities thereby determine whether the task of installing 1624 packet filters at a firewall is possible at all. CASP-NATFW 1625 thereby reuses the security mechanisms introduced by CASP. 1626 Still some additional security mechanisms described in this 1627 document have to be used to provide secure protocol operation. 1629 Flexibility in Message Delivery: Signaling messages can be 1630 triggered by any node along the path. In most cases, however, 1631 it is the responsibility of the signaling message initiator 1632 (typically the end host) to provide the necessary information 1633 policy rules install. CASP messages might terminate at any 1634 CASP peer along the path. Hence it is not necessary to forward 1635 the messages to the final destination. The decision whether to 1636 furthermore forward the signaling message toward the 1637 destination can be caused by the initiator (by including CASP 1638 specific information) or the decision could also be forced for 1639 example by a non CASP-aware firewall. Such a device might not 1640 forward CASP message. An example is an authorization failure 1641 generated because of lacking trust (and proper credentials by 1642 the signaling initiator). 1644 Error Resilience: CASP was designed based on the soft-state 1645 principle to allow orphan states to time-out automatically. 1647 End Host Topology Unawareness: Routing signaling messages along the 1648 data path allows CASP aware nodes to reflect topology 1649 information into the processing of CASP signaling messages. 1650 Processing of Filters is an example where local topology and 1651 protocol information need to be available to ensure proper 1652 behavior. Filter handling is already defined in CASP [1]. 1653 Defining them at the CASP M-Layer is necessary since this 1654 object is used by more than one client layer protocol. The 1655 Filter used in CASP-QoS [12] messages might require 1656 modification by a NAT along the path. Mid-path modification of 1657 the packet filter allows the end host to be topology unaware. 1658 If topology information needs to be incorporated into the 1659 signaling message processing then it should be done at the 1660 locations where the corresponding information is easily 1661 available (for example at the individual CASP-NATFW aware 1662 nodes along the path). 1664 13 Open Issues 1666 � The format of the objects need more work. 1668 � The structure of the authorization token needs more 1669 investigation. There is also a question about a custom token 1670 format or a CMS object. Both have advantages and disadvantages. 1672 � Terminology needs to be aligned with the Midcom Requirements and 1673 Framework drafts. Issues (such as groups of policy rules) 1674 discussed in these documents have to be mapped against the issues 1675 in this draft. 1677 � Packet filter attributes need some work to avoid the complex 1678 verification in case of overlapping rules. It must not be 1679 possible to prevent an administrator-created deny policy rule to 1680 become ineffective by an added allow policy rule with an 1681 overlapping port range. Hence it might be necessary to have an 1682 additional verification step to prevent these type of problems. 1684 � The NAT-Object might not necessarily be required, the approach 1685 taken in [6] could be used. The policy rule creator uses a filter 1686 with an internal address/port pair, an optional inside 1687 address/port pair (called in this document a local destination 1688 address/port pair used for twice NAT) with no parameters, as well 1689 as the external address/port pair (remote entity that will 1690 receive the data flow). In case there is a NAT on the path, the 1691 NAT will provide an outside address/pair (translated 1692 address/port) if it was firewall the outside address/pair would 1693 be the external address/pair. 1695 14 Acknowledgements 1697 We would like to thank (in alphabetical order) Steffen Fries, Xiaoming, 1698 Fu, Joerg Ottensmayer and Martin Reinhardt for their comments to this 1699 draft. 1701 A Object Format Details 1703 For concreteness, we describe a strawman packet format below. 1705 All CASP messages are composed of one or more TLV (type-length-value) 1706 objects. Within each object, elements are aligned on multiples of their 1707 size, to speed processing. All objects have lengths of a multiple of 32 1708 bits. The length field in the object indicates the number of 32-bit 1709 words. 1711 We describe messages and objects as pseudo-C structures. Elements are 1712 enumerated in transmission order. We use the data types uint8, uint16, 1713 uint32, uint64, uint128 to identify unsigned integers with 8, 16, 32, 64 1714 or 128 bits, respectively. 1716 Definitions for IPv4 and IPv6 address for the usage with Traffic 1717 Selectors are already provided in [1]. 1719 IPSec ESP and AH SPIs is four bytes in length. 1721 typedef struct uint32 SPI; 1723 Using a custom authorization token format might be more lightweight. 1724 (TBD: Authorization tokens can either be defined as CMS objects or as a 1725 objects with a custom structure. Using CMS object would simplify its 1726 definition and would allow a more generic usage. However CMS objects are 1727 larger in size than custom build tokens. Some investigation is required 1728 to find the optional usage.) 1730 The following fields could be included in such a token: 1732 typedef struct { 1733 uint32 ID; 1734 Identity token_creator, token_requestor, token_user; 1735 Identity src_addr, dst_addr; 1736 NTP_TIMESTAMP timestamp; 1737 uint8 AlgorithmID; 1738 uint8 HMAC[20]; 1739 ...Object describing the authorized PF.... 1740 } AuthToken; 1742 An authorization token is identified by a 32-bit number. The src_addr 1743 and the dst_addr attribute might contains an IPv4, IPv6 address or a 1744 FQDN. The Identity can either be a generic Unicode and ASCII ID, a FQDN 1745 or a URI. Unicode Identifiers (Unicode_ID), ASCII Identifiers and FQDNs 1746 are defined in [13]. The Uniform Resource Identifiers (URI) is defined 1747 in [14]. 1749 Since a NAT may change the source address it is possible to specify a 1750 FQDN, URI or an ASCII/Unicode ID or to omit the field. The 1751 token_creator specifies the identity of the entity which was responsible 1752 for the creation of the token. Information about this entity is 1753 necessary to route the token to the same entity for verification. 1754 Information about the entity requesting the token might be required. 1755 Finally the user identity obtained from authentication might be 1756 included. Especially if authentication to a firewall in the middle of 1757 the CASP-chain is required then this information provides additional 1758 authorization information. 1760 For cryptographic protection of the authorization token a keyed message 1761 digest HMAC [15] is used whereby the used algorithm (MD5, SHA-1) is 1762 indicated in the AlgorithmID field. The secret key necessary for the 1763 HMAC computation needs to be locally known only since verification is 1764 done at the token creator. The format of the NTP timestamp is defined 1765 in [16]. Finally the object contains information about the authorized 1766 packet filter. Since a NAT might change some of this information its 1767 usefulness is questionable. 1769 B Authors' Addresses 1771 Henning Schulzrinne 1772 Dept. of Computer Science 1773 Columbia University 1774 1214 Amsterdam Avenue 1775 New York, NY 10027 1776 USA 1777 EMail: schulzrinne@cs.columbia.edu 1779 Hannes Tschofenig 1780 Siemens AG 1781 Otto-Hahn-Ring 6 1782 81739 Munich 1783 Germany 1784 EMail: Hannes.Tschofenig@siemens.com 1785 Cedric Aoun 1786 Nortel Networks 1787 France 1788 EMail: cedric.aoun@nortelnetworks.com 1790 C Bibliography 1792 [1] H. Schulzrinne, H. Tschofenig, X. Fu, and A. McDonald, "Casp - 1793 cross-application signaling protocol," internet draft, Internet 1794 Engineering Task Force, 2003. Work in progress. 1796 [2] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan, 1797 "Middlebox communication architecture and framework," Internet Draft, 1798 Internet Engineering Task Force, Mar. 2002. Work in progress. 1800 [3] M. Shore, "The TIST (topology-insensitive service traversal) 1801 protocol," Internet Draft, Internet Engineering Task Force, May 2002. 1802 Work in progress. 1804 [4] M. Shore, "Towards a network-friendlier midcom," Internet Draft, 1805 Internet Engineering Task Force, June 2002. Work in progress. 1807 [5] H. Tschofenig and D. Kroeselberg, "Security threats for nsis," 1808 internet draft, Internet Engineering Task Force, 2003. Work in 1809 progress. 1811 [6] M. Stiemerling, J. Quittek, and T. Taylor, "Midcom protocol 1812 semantics," Internet Draft, Internet Engineering Task Force, 2002. Work 1813 in progress. 1815 [7] P. Srisuresh and M. Holdrege, "IP network address translator (NAT) 1816 terminology and considerations," RFC 2663, Internet Engineering Task 1817 Force, Aug. 1999. 1819 [8] L. Amini and H. Schulzrinne, "Observations from router-level 1820 internet traces," in DIMACS Workshop on Internet and WWW Measurement, 1821 Mapping and Modeling, (Piscataway, New Jersey) , Feb. 2002. 1823 [9] J. Manner et al. , "Localized RSVP," Internet Draft, Internet 1824 Engineering Task Force, May 2002. Work in progress. 1826 [10] L. Hamer, B. Gage, and H. Shieh, "Framework for session set-up with 1827 media authorization," Internet Draft, Internet Engineering Task Force, 1828 July 2002. Work in progress. 1830 [11] L. Hamer, B. Gage, M. Broda, B. Kosinski, and H. Shieh, "Session 1831 authorization for RSVP," Internet Draft, Internet Engineering Task 1832 Force, July 2002. Work in progress. 1834 [12] H. Schulzrinne, H. Tschofenig, X. Fu, and J. Eisl, "A quality-of- 1835 service resource allocation client for casp," internet draft, Internet 1836 Engineering Task Force, 2003. Work in progress. 1838 [13] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, 1839 and R. Hess, "Identity representation for RSVP," RFC 3182, Internet 1840 Engineering Task Force, Oct. 2001. 1842 [14] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource 1843 identifiers (URI): generic syntax," RFC 2396, Internet Engineering Task 1844 Force, Aug. 1998. 1846 [15] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: keyed-hashing for 1847 message authentication," RFC 2104, Internet Engineering Task Force, Feb. 1848 1997. 1850 [16] D. L. Mills, "Network time protocol (version 3) specification, 1851 implementation," RFC 1305, Internet Engineering Task Force, Mar. 1992. 1853 Table of Contents 1855 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1856 2 Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 1857 3 General Limits of In-Path Firewall Signaling . . . . . . 3 1858 4 Trust Relationships . . . . . . . . . . . . . . . . . . . 4 1859 4.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . . . 5 1860 4.2 Intra-domain Trust Relationship . . . . . . . . . . . . . 5 1861 4.3 Required End-to-Middle Trust Relationship . . . . . . . . 7 1862 4.4 Missing Network-to-Network Trust Relationship . . . . . . 8 1863 4.5 Off-Path Signaling . . . . . . . . . . . . . . . . . . . 12 1864 5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 13 1865 6 NAT Involvement . . . . . . . . . . . . . . . . . . . . . 13 1866 7 Operation . . . . . . . . . . . . . . . . . . . . . . . . 15 1867 8 Typical Policy Rule Attributes . . . . . . . . . . . . . 17 1868 9 Objects . . . . . . . . . . . . . . . . . . . . . . . . . 18 1869 9.1 Logging Action . . . . . . . . . . . . . . . . . . . . . 18 1870 9.2 ApplicationID . . . . . . . . . . . . . . . . . . . . . . 18 1871 9.3 Next . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1872 9.4 Authorization Token . . . . . . . . . . . . . . . . . . . 19 1873 9.5 CMS Credential Object . . . . . . . . . . . . . . . . . . 19 1874 9.6 Time . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1875 9.7 Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1876 9.8 Status . . . . . . . . . . . . . . . . . . . . . . . . . 19 1877 10 Basic Protocol Behavior . . . . . . . . . . . . . . . . . 20 1878 10.1 Receiver-Initiated Message Flow with Firewalls . . . . . 20 1879 10.2 Sender-Initiated Message Flow with Firewalls . . . . . . 22 1880 10.3 Receiver-Initiated Message Flow with a Firewall and a 1881 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1882 10.4 Sender-Initiated Message Flow with a Firewall and a 1883 NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1884 10.5 Sender-Initiated NAT/Firewall Traversal with 1885 Authorization Token . . . . . . . . . . . . . . . . . . . . . . . . 26 1886 10.6 Sender-Initiated Firewall Signaling only at the 1887 Access Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 1888 10.7 Sender-Initiated NAT and Firewall Traversal within 1889 the Access Network . . . . . . . . . . . . . . . . . . . . . . . . . 30 1890 11 Security Considerations . . . . . . . . . . . . . . . . . 31 1891 11.1 Threats . . . . . . . . . . . . . . . . . . . . . . . . . 31 1892 11.2 Countermeasures . . . . . . . . . . . . . . . . . . . . . 34 1893 12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . 36 1894 13 Open Issues . . . . . . . . . . . . . . . . . . . . . . . 37 1895 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . 38 1896 A Object Format Details . . . . . . . . . . . . . . . . . . 38 1897 B Authors' Addresses . . . . . . . . . . . . . . . . . . . 39 1898 C Bibliography . . . . . . . . . . . . . . . . . . . . . . 40