idnits 2.17.1 draft-soliman-firewall-control-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1763. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5898 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2434' is defined on line 1589, but no explicit reference was found in the text == Unused Reference: 'RFC2710' is defined on line 1596, but no explicit reference was found in the text == Unused Reference: 'RFC3024' is defined on line 1600, but no explicit reference was found in the text == Unused Reference: 'RFC3344' is defined on line 1603, but no explicit reference was found in the text == Unused Reference: 'RFC3519' is defined on line 1606, but no explicit reference was found in the text == Unused Reference: 'RFC3775' is defined on line 1610, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 1613, but no explicit reference was found in the text == Unused Reference: 'RFC3963' is defined on line 1616, but no explicit reference was found in the text == Unused Reference: 'RFC4213' is defined on line 1626, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1629, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 1632, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 1636, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-18 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. 'I-D.ietf-nsis-nslp-natfw') ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Soliman 3 Internet-Draft Elevate Technologies 4 Intended status: Standards Track G. Daley 5 Expires: August 28, 2008 6 S. Krishnan 7 Ericsson 8 February 25, 2008 10 Firewall Control for Public Access Networks (FCON) 11 draft-soliman-firewall-control-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 28, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document proposes a new mechanism that allows end nodes to 45 signal its preferences for traffic filters to a firewall function in 46 the network or to another node that controls the firewall function in 47 the network. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 7 54 4. Firewall Scenarios . . . . . . . . . . . . . . . . . . . . . . 9 55 5. PDP Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 56 5.1. DHCP extensions . . . . . . . . . . . . . . . . . . . . . 12 57 5.1.1. PDP Sub-Option Format . . . . . . . . . . . . . . . . 13 58 6. Authorization Mechanism . . . . . . . . . . . . . . . . . . . 15 59 6.1. Proof of ownership . . . . . . . . . . . . . . . . . . . . 15 60 6.2. Firewall request policy . . . . . . . . . . . . . . . . . 16 61 7. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 17 62 7.1. The Request Message Format . . . . . . . . . . . . . . . . 17 63 7.2. The Response Message Format . . . . . . . . . . . . . . . 18 64 7.3. The Init Message . . . . . . . . . . . . . . . . . . . . . 19 65 7.4. The Init Acknowledgement Message . . . . . . . . . . . . . 20 66 7.5. Protocol Options . . . . . . . . . . . . . . . . . . . . . 21 67 7.5.1. The Acknowledgement Option . . . . . . . . . . . . . . 21 68 7.5.2. The Filter Identifier Option . . . . . . . . . . . . . 22 69 7.5.3. The Nonce Option . . . . . . . . . . . . . . . . . . . 23 70 7.5.4. The Timestamp Option . . . . . . . . . . . . . . . . . 24 71 7.5.5. The IP Address Option . . . . . . . . . . . . . . . . 25 72 7.5.6. The Cookie Option . . . . . . . . . . . . . . . . . . 27 73 7.5.7. The Public Key Option . . . . . . . . . . . . . . . . 28 74 7.5.8. The Lifetime Option . . . . . . . . . . . . . . . . . 29 75 7.5.9. The Certificate Option . . . . . . . . . . . . . . . . 30 76 7.5.10. The Digital Signature Option . . . . . . . . . . . . . 31 77 8. Establishing a Secure Connection . . . . . . . . . . . . . . . 34 78 9. Creating New entries . . . . . . . . . . . . . . . . . . . . . 35 79 10. Updating Entries . . . . . . . . . . . . . . . . . . . . . . . 37 80 11. Requesting an IPv4 Address . . . . . . . . . . . . . . . . . . 38 81 12. Timeouts and Retransmissions . . . . . . . . . . . . . . . . . 39 82 12.1. Session Start Delays . . . . . . . . . . . . . . . . . . . 39 83 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 84 14. Security Considerations . . . . . . . . . . . . . . . . . . . 41 85 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 86 16. Normative References . . . . . . . . . . . . . . . . . . . . . 43 87 Appendix A. Dynamic PDP Discovery (Informative) . . . . . . . . . 45 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 89 Intellectual Property and Copyright Statements . . . . . . . . . . 48 91 1. Requirements notation 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Introduction 99 The need for network protection has led operators to deploy firewalls 100 with typical configurations that limit the traffic coming into or out 101 of a network to the administrators configuration. An administrators 102 configuration is typically static and affects all users within the 103 network. While such security measure is regarded as successful and 104 is widely deployed, it has several drawbacks from a user and network 105 operator's points of view. The assumption in such deployments is 106 that there is a common configuration that satisfies all users. That 107 is, the same type of applications are used by all network users and 108 that all users do not need to be reachable unless they initiate a 109 connection. Alternatively, in some deployment scenarios, e.g. IP 110 Multimedia System (IMS) in 3GPP, the assumption is that externally 111 initiated connection will use a signaling protocol, through local 112 proxies, and therefore a local firewall can be manipulated by such 113 proxies to allow such connections. Another assumption in deploying 114 firewalls is that there is a Trusted side (the administrator's 115 network) and an Untrusted side (The Internet). This is reasonable in 116 a network where you assume no one on the inside of the network would 117 intentionally try to attack the network infrastructure. 119 The assumptions above are clearly workable in a network where there 120 is a defined behaviour for the users. For instance enterprise 121 network users can easily be told what applications and protocols are 122 acceptable for the users according to company policy. However, in a 123 public network, such restrictions cannot be made without introducing 124 serious limitations on users. Furthermore, in a public network, one 125 can no longer assume that users on the inside are trusted. This is 126 especially true in networks with anonymous users as well as users who 127 may not be competent in protecting their own infrastructure. 129 The need for firewalling traffic still exists in public networks. 130 Operators may wish to provide general protection for their 131 infrastructure and users. At the same time, there is a clear need 132 for flexibility in order to allow users a high degree of freedom in 133 choosing the applications and protocols that they want to run. The 134 firewall function may also be located closer to the user than the 135 traditional deployment of firewalls on the core edge of the network. 136 This allows for greater scalability by allowing the firewall function 137 to serve a smaller number of users, which reduces bottlenecks in the 138 core. This is particularly useful for IPv6 networks where there 139 should be no need for Network Address Translators. 141 To allow for a more flexible firewall deployment, both in the 142 location and configuration of the firewall, this document proposes a 143 new mechanism that allows end nodes to signal its preferences for 144 traffic filters to a firewall function in the network or to another 145 node that controls the firewall function in the network. The 146 mechanism introduced in this document allows for a high degree of 147 fexibility and security. A generic mechanism for firewall control 148 has the following advantage: 150 o Removes the reliance on specific application proxies for 151 signalling to allow incoming connections. 153 o Allows easy deployment of new services without requiring specific 154 application gateways. 156 o Allows easy deployment of new protocols that may not be known to 157 the firewall and would otherwise be blocked. 159 o Allows maximum user control, which provides the finest granularity 160 for firewall configuration. 162 One of the approaches for firewall control can be found in 163 [I-D.ietf-nsis-nslp-natfw]. However, this approach assumes a form of 164 pre-established trust. With mobility becoming the norm on the 165 Internet, it is difficult to assume trust without the use of global 166 Public Key Infrastructure (PKI), which is not available today. Other 167 approaches to firewall control include the presence of application 168 proxies that are either colocated or physically separate from the 169 firewall. The mechanism introduced in this document allows end nodes 170 to signal their preferences directly to the firewall, or to another 171 entity that controls the firewall. Hence, this mechanism allows 172 network operators to continue the use of application proxies that 173 control the firewall, while adding this new mechanism as a generic 174 option. 176 3. Protocol operation 178 The FCON protocol allows nodes to send its preferences to a Policy 179 Decision Point (PDP) in order to configure a firewall with those 180 preferences. The PDP may be located anywhere in the network, 181 including the access router sharing the node's link. Furthermore, it 182 may be colocated with the firewall. FCON allows the node to create 183 new entries, add entries, as well as, modify or delete existing 184 entries. FCON uses ICMP for transporting its messages between the 185 node in question and the PDP. FCON can also be used to request the 186 allocation of a unique IPv4 address and one or more port numbers by a 187 Network Address Translator (NAT). 189 | 190 | 191 +--------+ +---------+ 192 | PDP | 2.PDP/PEP Protocol |Firewall/| 193 | |<--------------------->| NAT | 194 +--------+ (out of scope) +---------+ 195 ^ | 196 | | 197 | 1. FCON Protocol | 198 | | 199 | | 200 +--------+ 3. Data Stream | +--------+ 201 | IPv6 |--------------------------->O------------->| Peer | 202 | Node | <-----O--------------| Node | 203 +--------+ | +--------+ 204 | 206 Figure 1: Communication architecture 208 Nodes that implement FCON first need to discover the IP address of 209 the PDP in order to send future messages. The PDP's address is 210 either included in a router advertisement option or a new DHCPv6 211 option. Alternative discovery mechanisms are described in Appendix 212 A. Following the discovery phase, a node may start sending messages 213 to the PDP requesting that certain protocols or port numbers be 214 opened for its traffic on a firewall or Policy Enforcement Point 215 (PEP). A node may also request a unique IPv4 address and one or more 216 port numbers for NAT traversal. All entries created by a node have a 217 lifetime associated with them and MUST be refreshed in order to avoid 218 losing them. The lifetime is set by the PDP and cached by the node 219 using FCON. 221 Depending on the network configuration, from the end host's point of 222 view, the PDP may be colocated with a firewall or separated. 224 Moreover, both functions could be colocated with an access router or 225 located within the core network. The protocol between the PDP and 226 the firewall is outside the scope of this document. Authentication 227 and authorization of FCON messages takes place by the PDP. The PDP 228 is assumed to be authenticated with the firewalls through one of 229 several methods, including manual configuration of security 230 associations, public key-based authentication, or any other method 231 deemed appropriate by the network administrator. 233 Message authentication and authorization is a critical component of 234 the FCON protocol. Different deployment models may have different 235 requirements for authentication and authorization. In some 236 deployments the use of public keys and trusted certificates can be 237 sufficient to authorize an end node for FCON messages. Examples of 238 such deployments may include enterprise or home networks. Other 239 deployments may require proof that the sender is authorized to 240 perform the action requested. Given the information exchanged in the 241 FCON messages, it is sufficient for a node to prove the ownership of 242 the address included in a message to be authorized to perform the 243 requested action provided that such action does not violate the 244 network administrator's policies. Hence, the PDP first needs to know 245 that a sending node owns the address included in the message, then 246 ensure that the request does not violate any known policies. 247 Following such verification the PDP would configure the firewall/NAT 248 with the necessary information requested by the end node. 250 This specification allows FCON security to be based on self-generated 251 public keys and Cryptographically Generated Addresses (CGAs). This 252 allows nodes to provide the necessary address ownership credentials 253 in those deployments that require it. Alternatively, public keys 254 associated with PKI can be used for deployments that do not require 255 proof of address ownership. 257 4. Firewall Scenarios 259 This section describes limitations in current firewall deployment, 260 and illustrates challenges in attempting to control firewalls 261 dynamically using FCON. Scenarios are described which motivate 262 features described in this document. 264 Manual policy firewalls describe the state of the art, with respect 265 to deployed networks. A management platform acts as a static policy 266 decision point, propagating policy out to one or more policy 267 enforcement points. Such an environment is displayed in Figure 2. 268 Connection state creation occurs when data plane packets compliant 269 with policy are received. 271 Static firewalls such as these may exist where the PDP and PEP are 272 collapsed into the same entity, and long term configuration occurs on 273 the same device where connection state is created. 275 PEP 276 ^ 277 / 278 / 279 / 280 PDP---\ 281 \ 282 \ 283 V 284 Host====================> PEP=====================>Peer 285 Connection 286 State 287 Creation 289 Figure 2: Static Firewall 291 As shown in Figure 2, where connection state is required for inbound 292 packet flows, the PEP's preconfigured policy is used to create 293 inbound connection state. Such connections are available at all 294 times, and depend upon the specificity of the PDP's inbound policy in 295 order to maintain internal network security. These inbound 296 communications remain available regardless of the lifetime of the 297 individual server applications. 299 PEP 300 ^ 301 / 302 / 303 / 304 PDP---\ 305 \ 306 \ 307 V 308 PEP 309 Server <=====================O<=============== Client 311 Connection 312 State 313 Creation 315 Figure 3: Inbound Connection on Static Firewall 317 Problems emerged when people attempted to support peer-to-peer 318 applications with dynamic source and destination addresses. This is 319 illustrated in Figure 4. Transport layer connection state is unable 320 to identify the upper layer inbound connection associated with the 321 peer-to-peer application. Inbound packets are dropped on the 322 secondary session unless the Firewall snoops and understands the 323 specific protocol, and the inbound policy is loosened to permit such 324 inbound sessions. 326 PEP 327 ^ 328 / 329 / 330 / 331 PDP---\ 332 \ 333 \ 334 V P2P Signaling 335 Host =======================>PEP====================> Peer 336 X<======================= 338 Figure 4: Peer-to-Peer Connection on Static Firewall 340 By enabling dynamic signalling, a host can inform the network 341 elements of its intention to send packets with a particular source 342 and destination address, and transport profile. This means that the 343 policy decision and enforcement can occur at the time that the 344 session is established, and adapt specifically to the needs of the 345 network's current transmission profile. 347 In Figure 5, the host informs the PDP which protocols are expected 348 through the network gateways using a Request message to create a flow 349 decriptor entry in the firewall. The PDP indicates whether the 350 session will be allowed, and state created on the PEP. In this case, 351 a Response message is sent, indicating that the PDP believes the 352 communications are allowed. 354 Request 356 /----------------PDP.. 357 //----------------/ . 358 // ACK . 359 / V V 360 Host =====================>PEP======================= > Dest 362 Figure 5: Outbound Session with PDP Signaling 364 In many environments, multiple Firewalls exist on the path to the 365 Internet. This is shown in Figure 6. 367 Signalling is either performed to a single PDP which passes 368 information to both PEPs, or to a separate PDP for each PEP. By 369 using separate PDPs, different trust policy and vendor independence 370 may be readily achieved. This may particularly be applicable where 371 the internal firewall is operated by an enterprise, and the exterior 372 firewall by a service provider. 374 Request 375 /---------------->PDP.. 376 //-----------------/ . 377 // ACK . 378 / V V 379 Host======================>PEP============>PEP============>Dest 380 \ ^ | ^ 381 \ \ ACK | . 382 \ \----------------------O------------\ . 383 \---------------------->O----------->PDP 384 Request | 386 Figure 6: Multiple On-Path Firewalls 388 5. PDP Discovery 390 5.1. DHCP extensions 392 In order to configure PDPs on hosts using the existing access 393 infrastructure, a DHCP option is provided. 395 The option format includes PDPs with destination coverage information 396 on a per-PDP basis in a suboption format. This would allow for 397 specific PDPs to have jurisdiction over different network ranges (for 398 example, for a Data Centre, and an Internet Firewall). 400 The DHCP option for identifying PDPs is described using the format: 402 0 1 2 3 403 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | OPTION_FC_PDP | option-len | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | | 408 + + 409 | PDP Sub-option 1 | 410 + + 411 | | 412 + + 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 . . 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | | 418 + + 419 | | 420 + PDP Sub-option N + 421 | | 422 + + 423 | | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 7: FCON PDP Discovery DHCPv6 Option 428 OPTION_FC_PDP 430 Assigned DHCP option code for PDP discovery. TBD. 432 option-len 433 The length of the entire option in bytes, less 4 435 PDP Sub-option 437 A sub option containing information for each PDP the host should 438 configure. 440 5.1.1. PDP Sub-Option Format 442 Each PDP has its own IP address and validity information. 444 0 1 2 3 445 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | PDP-SOPT | Prefixes | suboption-len | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 + + 451 | PDP IP Address | 452 + + 453 | | 454 + + 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | PrefixLen1 | Prefix 1 .... | 458 +-+-+-+-+-+-+-+-+ + 459 | . 460 . . 461 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | | PrefixLen2 | Prefix2... | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 464 | . 465 . . 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 . . 469 . . 470 . . 471 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | | PrefixLenN | PrefixN... | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 474 . . 475 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 +-+-+-+-+-+-+-+-+ 479 Figure 8: FCON PDP Discovery DHCPv6 Option 481 PDP-SOPT 483 A sub option 485 Prefixes 487 The number of prefixes covered by this PDP. 489 suboption-len 491 The length of the PDP sub-option in bytes, including all fields. 493 PDP IP Address 495 The IP Address of the PDP which is used as a destination for FCON 496 requests. 498 PrefixLen i 500 The length of the next prefix, in bits. 502 Prefix i 504 The space consumed by the Prefix is the number of bytes required 505 to store the prefix (PrefixLen i/8), rounded up to the nearest 506 integer. A Prefix of 0::/0 is encoded with a zero length Prefix 507 Field, and indicates the PDP is responsible for all destinations. 509 6. Authorization Mechanism 511 The protocol described in this document uses a two step authorization 512 procedure. The right to control the firewall will be granted if 514 o The node making the request is behind the firewall and owns the IP 515 address 517 o The request made by the node is allowed by local firewall policy. 519 6.1. Proof of ownership 521 This document relies on Cryptographically Generated Addresses (CGAs) 522 as defined in [RFC3972] in order to prove that the requesting node 523 owns the address from which the firewall control request was sent. 524 This is possible because the CGA address of the node is derived based 525 on a hash of the public key of node with other known pieces of 526 information like the prefix. The procedure for verification of CGA 527 addresses is described in Section 5 of [RFC3972]. If the PDP receive 528 a signed firewall control request message that includes the public 529 key and the CGA of the requester it can verify that the sender of the 530 request indeed owns the address and that the address corresponds to 531 the public key carried in the message. Since creating this signature 532 requires the corresponding private key of the public key contained in 533 the message, it can also conclude that the message has not been 534 tampered with. In addition to this, to prevent replay attacks, the 535 PDP can verify that the sender is in fact reachable and alive, using 536 a to be defined FCON protocol message that uses nonces to verify that 537 the received message was not replayed from an earlier run of the 538 protocol. e.g. The PDP could send a nonce to the requesting node in 539 this message encrypted by the public key of the requesting node. 540 Only the requesting node can decrypt this message and obtain the 541 nonce. Then it needs to increment the nonce and encrypt it and send 542 it back to the PDP. Once the PDP receives this message it can be 543 assured that the requester is alive and reachable. If either of 544 these tests fail, the PDP rejects the firewall configuration request 545 with an error that indicates that the address ownership was not 546 confirmed. 548 Please note that the PDP does not have to verify who owns the public 549 key. It just needs to verify whether the owner of the address is the 550 same as the owner of the public key contained in the signed message. 551 It can do so solely based on the information contained in the message 552 prefix of the address, public key etc., by running the algorithm 553 mentioned earlier. 555 6.2. Firewall request policy 557 Once the PDP has verified that the requesting node owns the concerned 558 address and is reachable, the PDP needs to start processing the 559 request message itself. Since it is possible that the firewall 560 control request may not conform to administrative policy, the PDP 561 verifies that the request falls within the parameters specified by 562 such policy. If it does, the PDP starts acting on the request and 563 sends configuration messages to the necessary firewall(s). If not, 564 the PDP rejects the firewall configuration request with an error that 565 indicates that the request did not comply with local administrative 566 policy. 568 7. Protocol Messages 570 FCON uses ICMPv6 for transporting its messages. The protocol is 571 based on a request respose message exchange. Hence, two ICMP message 572 types are needed. The ICMP Code field is used to distinguish 573 different types of FCON messages. Each message can contain one or 574 more options. This sections lists all protocol messages and options. 576 7.1. The Request Message Format 578 The Request message is sent from the end node to the PDP. The 579 purpose of the message depends on the options included. For each 580 operation described in this specification a specific set of options 581 must be included. The format of the request message is shown below. 583 0 1 2 3 584 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Session Id | Reserved | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Message Id | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Figure 9: The Request Message Format 593 Session Id 595 An unsigned 16-bit integer that includes a session identifier. 596 The session identifier is initially picked by the end node when a 597 security association is created with the PDP. The Session Id MUST 598 be unique for a particular end node, which is identified by its 599 public key. 601 Reserved 603 This field MUST be set to zero by the sender and ignored by the 604 receiver. 606 Message Id 608 This field include a message identifier. The message identifier 609 is a simple counter incremented by 1 for every new message. This 610 field is used to match responses with their correcponding 611 requests. 613 7.2. The Response Message Format 615 The Response message is sent from the PDP to the end node in response 616 to a request message sent from the end node. The response message 617 includes the same Session Id and Message Id that were included in the 618 sender's Request message. The Response message may contain several 619 options. The options contained in a given message depend on the type 620 of operation requested in the Request message. The format for the 621 Response message is shown below. 623 0 1 2 3 624 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Session Id | Reserved | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Message Id | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 10: The Response Message Format 633 Session Id 635 An unsigned 16-bit integer that includes a session identifier. 636 The session identifier is initially picked by the end node when a 637 security association is created with the PDP. The Session Id MUST 638 be unique for a particular end node, which is identified by its 639 public key. 641 Reserved 643 This field MUST be set to zero by the sender and ignored by the 644 receiver. 646 Message Id 648 This field include a message identifier. The message identifier 649 is a simple counter incremented by 1 for every new message. A 650 Response message's identifier is set to the message identifier of 651 the corresponding request message. 653 7.3. The Init Message 655 The Init message is sent from the end node to the PDP in order to 656 establish a secure association before sending further requests. This 657 message MUST NOT include information about flows that need to be 658 installed in the firewall. Instead, the message contains the end 659 node's security credentials and a challenge for the PDP. 661 0 1 2 3 662 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Session Id | Sec Mode | Reserved | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Message Id | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 Figure 11: The Init Message Format 671 Session Id 673 An unsigned 16-bit integer that includes a session identifier. 674 The session identifier is initially picked by the end node when a 675 security association is created with the PDP. The Session Id MUST 676 be unique for a particular end node, which is identified by its 677 public key. 679 Sec Mode 681 This field indicates the type of credentials used to establish the 682 security association. A value of 1 indicates the use of self- 683 generated public keys. A value of 2 indicates the use of trusted 684 certificates, which are either signed by the same administrative 685 authority or a trusted third party. 687 Reserved 689 This field MUST be set to zero by the sender and ignored by the 690 receiver. 692 Message Id 694 This field include a message identifier. The message identifier 695 is a simple counter incremented by 1 for every new message. 697 7.4. The Init Acknowledgement Message 699 0 1 2 3 700 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Session Id | Sec Mode | Status | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Message Id | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 Figure 12: The Init Acknowledgement Message Format 709 Session Id 711 An unsigned 16-bit integer that includes the session identifier 712 included in the Init message. 714 Sec Mode 716 This field includes the same value for the Sec Mode field included 717 in the Init message if the Status field indicated a successful 718 operation. Otherwise, the field includes the value supported by 719 the PDP. 721 Status 723 This field indicates the success or failure of the processing of 724 the Init message. Values below 128 indicate success, while values 725 of 128 and above indicate failure. 727 Message Id 729 This field includes the value of the Message Id that was included 730 in the Init message being responded to. 732 The following values are reserved for the Status field: 734 0 Success 736 128 Reason unspecified 738 129 Security mode not supported 740 130 Invalid format 742 131 Certificate not accepted 744 7.5. Protocol Options 746 7.5.1. The Acknowledgement Option 748 The Acknowledgement Option is used to carry information about a 749 requested operation. The format of the Acknowledgement option is 750 shown below. 752 0 1 2 3 753 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Type | Length | Status | Reserved | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 Figure 13: The Acknowledgement Option Format 760 Type 762 A value assigned to this option. 764 Length 766 The length of this option in 8-octet units. 768 Status 770 This field indicates whether an operation was a success or a 771 failure. Values of 128 and higher indicate failure. Otherwise 772 this field indicates a successful operation. 774 Reserved 776 MUST be set to zero by the sender and ignored by the receiver. 778 The following values are reserved for the Status field: 780 0 Indicates Success. 782 128 Failure, reason unspecified. 784 129 Message poorly formed. 786 130 Unknown session identifier. 788 131 Flow descriptor format not supported 790 132 Action not supported. 792 133 Security Information Required. 794 134 Liveness Proof Required. 796 7.5.2. The Filter Identifier Option 798 The filter identifier option is used to encode information that 799 describes a flow and the treatment needed for such flow. A host may 800 request that a flow be allowed, blocked, or removed from the 801 firewall, which defaults to the firewalls original settings. 803 0 1 2 3 804 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Type | Length | Index | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Action | Format | PRI | Reserved | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Flow descriptor...... 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Figure 14: The Flow Identifier Option Format 815 Type 817 A value assigned to this option. TBA 819 Length 821 The length of this option in 8-octet units. 823 Index 825 A Unique value that identifies a particular flow description. 826 This value is assigned to the flow description by the end node. 828 Action 830 This field indicates the type of operation requested by the end 831 node for the flow included in the option. The following values 832 are assigned to this field. A Value of 1 indicates a request to 833 Allow the flow. 2 indicates a request to Block a flow. 3 indicates 834 a request to Update a flow. 4 indicates a request to Delete a 835 flow. 837 Format 838 This field indicates the format used for the flow descriptior. 839 Values TBA 841 PRI 843 This field indicates the priority of a particular flow. A lower 844 value indicates a higher priority. A value of 1 indicates the 845 highest priority. A value of zero is not allowed by this 846 specification. The rpiority field is needed in cases where two 847 flow descriptions overlap while having conflicting Action fileds. 848 The Action field included in the option with higher priority takes 849 precedence. 851 Reserved 853 This field MUST be set to zero by the sender and ignored by the 854 receiver. 856 7.5.3. The Nonce Option 858 The Nonce Option is illustrated in Figure 15 and is used to ensure 859 freshness in acknowledgements from the PDP to the requesting FCON 860 node. It works by making sure that the PDP copies the Nonce Option 861 from the request into the response. The Nonce is checked along with 862 other freshness and authentication information before 864 As such, a new Nonce MUST be selected for each transmission of a 865 request message. PDPs receiving a valid request message MUST copy 866 the Nonce option into the response, regardless of the status of any 867 individual flow. 869 The Nonce MUST be unpredictable, and SHOULD contain hardware 870 generated randomness, where possible. 872 0 1 2 3 873 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Type | Length | | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 877 | ... Nonce | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 Figure 15: The Nonce Option Format 882 Type 883 A value assigned to this option. 885 Length 887 The length of this option in 8-octet units. 889 Nonce 891 The Nonce is a block of data selected by the requester to be sent 892 to the PDP. the entire length of the Nonce block MUST NOT exceed 893 384 bits. It MUST contain at least 64 bits of unpredictable 894 random data. It SHOULD contain significantly more randomness. 896 PDPs receiving the Nonce SHOULD cache it to ensure that duplicate 897 request packets are not processed from the same source. 899 7.5.4. The Timestamp Option 901 The Timestamp option format is used to ensure attackers are unable 902 create state in the future by replaying signed FCON messages. It 903 relies on congruence between clock information within nodes and PDPs, 904 and therefore has some limitations where secured time synchronization 905 is not available 907 The following option format follows the principles and message 908 formats as described in the [RFC3971], except that its protections 909 may be weaker when operating in a multi-hop domain. 911 0 1 2 3 912 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Type | Length | Reserved | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 916 | | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | | 919 + Timestamp + 920 | | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 Figure 16: The Timestamp Option Format 925 Type 927 A value assigned to this option. 929 Length 930 The length of this option in 8-octet units. 932 Timestamp 934 A 64-bit unsigned integer field containing a timestamp. The value 935 indicates the number of seconds since January 1, 1970, 00:00 UTC, 936 by using a fixed point format. In this format, the integer number 937 of seconds is contained in the first 48 bits of the field, and the 938 remaining 16 bits indicate the number of 1/64K fractions of a 939 second. 941 Each FCON message MUST contain the Timestamp option, and recipients 942 SHOULD ensure that Timestamps are valid to prove freshnes of the 943 message. 945 Processing of this option follows that for SEND, except that that the 946 corresponding figures for clock drift and fuzz are more lenient. 947 This allows for longer attack windows of attack against FCON 948 infrastructures, but also allows for deviations in packet transfer 949 delays on multi-hop networks and the extended duration of the state 950 created in Firewalls, as opposed to Neighbour Discovery: 952 TIMESTAMP_DELTA 600 seconds (10 minutes) 954 TIMESTAMP_FUZZ 6 seconds 956 TIMESTAMP_DRIFT 1 % (0.01) 958 7.5.5. The IP Address Option 960 The IP address option is used by a node to request a unique IPv4 961 address and one or more port numbers. 963 0 1 2 3 964 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Type | Length | PadLen | Protocol1 | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 . . 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | | ProtocolN | Padding... | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Interior Port 1 | Exterior Port 1 | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Interior Address 1 | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Exterior Address 1 | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 . . 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Interior Port N | Exterior Port N | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Interior Address N | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Exterior Address N | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 Figure 17: The IP Address Option Format 989 Type 991 A value assigned to this option. 993 Length 995 The length of this option in 8-octet units 997 Padlen 999 The length in bytes of the Padding field 1001 Protocol i 1003 The ith IP protocol number 1005 Padding 1007 This field SHOULD be set to zero by the sender and ignored by the 1008 receiver. 1010 Interior Port i 1011 The 16 bit Transport layer internal identifier of the of the ith 1012 session for which a mapping is requested. Where such identifiers 1013 do not make sense for a particular protocol, this field SHOULD be 1014 set to zero 1016 Exterior Port i 1018 The 16 bit Transport layer identifier of the of the ith session 1019 for which a mapping is requested. Where such identifiers do not 1020 make sense for a particular protocol , this field SHOULD be set to 1021 zero Requesters SHOULD set this field to zero, if they wish the 1022 PDP to assign a port 1024 Exterior Address i 1026 The address of the ith external IP address to which a mapping is 1027 requested. Requesters SHOULD set this field to zero, if they wish 1028 the PDP to assign an address. 1030 Interior Address i 1032 The address of the ith internal IP address for which a mapping is 1033 requested 1035 7.5.6. The Cookie Option 1037 The Cookie Option contains a string of information chosen by the PDP 1038 to the host to when requesting further security credentials. 1040 The cookie can contain any information which the PDP desires, and the 1041 cookie must be returned to the PDP along with credential information 1043 When the host sends further credential information it MUST add the 1044 cookie to the Init or SEND Certification Path Advertisements sent to 1045 validate the credentials. 1047 0 1 2 3 1048 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Type | Length |C| Reserved | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | | 1053 . . 1054 . Cookie . 1055 | | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 Figure 18: The Cookie Option Format 1060 Type 1062 The assigned type of this option (TBD). 1064 Length 1066 The length of this option in 8-octet units. 1068 C 1070 The Flag indicating Certificate Path Discovery is ok (Flag Set). 1072 This flag being set allows the response to use [RFC3971] 1073 Certifcation Path Advertisement Messages to convey the list of 1074 certificates for the respondent. If this flag is not set, the 1075 sender MUST use Init messages instead. 1077 This Cookie is required to appear in all such messages (IANA 1078 Note). 1080 Length 1082 A string of bytes chosen by the PDP to ensure liveness of 1083 responses. The entire option, carrying this field needs to be 1084 copied into an INIT for transmission to the PDP, along with 1085 credential information. 1087 7.5.7. The Public Key Option 1089 The Public Key option is used to provide information to the PDP about 1090 the identity being used to sign the message. By using the key 1091 information in this option, or a cached copy, the PDP can use 1092 information in the Digital Signature Option, to verify the message's 1093 integrity. 1095 This Option MUST be present in the message sent from a particular 1096 host to a PDP, and from a PDP to a host with which it has not 1097 communicated, unless the same information is provided within the 1098 message using a Certificate Option. If a host or PDP communicate 1099 with each other during a period where security state is still in 1100 existence, then the sender MAY leave this option out. 1102 Where a receiving endpoint does not support a Key Type, it may 1103 indicate this to the far end in an acknowledgement but otherwise 1104 SHOULD NOT create any state in PEPs. 1106 0 1 2 3 1107 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Type | Length | Key Type | Pad Length | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Public Key Information ... 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | ... Padding | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 Figure 19: The Public Key Option Format 1118 Type 1120 A value assigned to this option. TBA 1122 Length 1124 The length of this option in 8-octet units. 1126 Key Type 1128 A description of the keying information to be supplied in the 1129 following Public Key Information field. The algorithms and 1130 formats to be supported are to be determined. A type value of 1 1131 is CGA with the Public Key Information containing information 1132 compatible with [RFC3972] formats. 1134 Pad Length 1136 The length of the pad in bytes 1138 Public Key Information 1140 A stream of bytes describing a public key accordingto the 1141 algorithm specific format specified in they Key Type. 1143 Padding 1145 This field SHOULD be set to zero by the sender and ignored by the 1146 receiver. 1148 7.5.8. The Lifetime Option 1150 This lifetime option is included in the Response and Init 1151 Acknowledgement messages from the PDP to the end node to indicate the 1152 lifetime for the entries in a Request message or to indicate the 1153 lifetime of a security association, respectively. The option format 1154 is shown below. 1156 0 1 2 3 1157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Type | Length | Reserved | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Time | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 Figure 20: The Lifetime Option Format 1166 Type 1168 A value assigned to this option. 1170 Length 1172 The length of this option in 8-octet units. 1174 Reserved 1176 This field MUST be set to zero by the sender and ignored by the 1177 receiver. 1179 Time 1181 This field contains the lifetime in units of seconds. 1183 7.5.9. The Certificate Option 1185 The Certificate option contains a digital certificate issued by one 1186 of the Certificate Authorities in the sender's trust chain. It 1187 provides information about trust delegated to the sender or its 1188 authorizing authorities. This option follows the same format as in 1189 [RFC3971], and the certificates can be sent in Certification Path 1190 Advertisement messages, between hosts and PDPs. 1192 The Certificate Option MAY be included in an FCON request or response 1193 message instead of including the Public Key option. It is 1194 RECOMMENDED that only one of the Public Key Option or Certificate 1195 Option is included in any FCON request or response message. 1197 0 1 2 3 1198 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | Type | Length | Cert Type | Reserved | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Certificate ... 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | ... Padding | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 Figure 21: The Certificate Option Format 1209 Type 1211 A value assigned to this option. 1213 Length 1215 The length of this option in 8-octet units. 1217 Cert Type 1219 The type of certificate presented in the Certificate field. Type 1220 1 is an X.509v3 digital certificate. 1222 Certificate 1224 A stream of bytes describing a one of the sender's certificates 1225 from it's trust chain. The format of a particular certificate is 1226 governed by the Cert Type. 1228 Padding 1230 This field SHOULD be set to zero by the sender and ignored by the 1231 receiver. 1233 7.5.10. The Digital Signature Option 1235 The Digital Signature Option MUST be included in every FCON message, 1236 and authenticates the preceding message contents. It does this by 1237 performing a signature over the message contents by the key 1238 identifies in the Key Hash field. It is always placed last in any 1239 sequence of options, before presentation for transmission. 1241 If multiple identities are signing the message, the most specific 1242 user signs the message with the first digital signature option, over 1243 all options preceding that one. Subsequent signers include all 1244 required option information to ensure validation of their message 1245 after this signature, and then include their own digital signature at 1246 the end, signing over all included options, including the previous 1247 digital signature. This allows user level and host level 1248 authentication within the same message, and provides distinction 1249 between administrative and non-power users on a multi-user server. 1251 If a device receives a digital signature and is unable to identify 1252 the Public Key to which the signature is tied, it may challenge the 1253 sender, or silently discard the received FCON message. Therefore, it 1254 is important to include the Public Key Option in a message unless it 1255 is known that the peer device is known to have recently received it. 1257 0 1 2 3 1258 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Type | Length | Sign Type | Pad Length | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | | 1263 + + 1264 | | 1265 + Key Hash + 1266 | | 1267 + + 1268 | | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | | 1271 . Digital Signature ... . 1272 | | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | ... Padding | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 Figure 22: The Digital Signature Option Format 1279 Type 1281 A value assigned to this option. 1283 Length 1285 The length of this option in 8-octet units. 1287 Sign Type 1288 The type of digital signature used within the Digital Signature 1289 field of this option. 1291 Type 1 is allocated as a PKCS 1.5 Digital Signature over the field 1292 sequence as described in [RFC3971]. 1294 Pad Length 1296 The length of the Padding field in octets. 1298 Key Hash 1300 The left most (most significant) 128 bits of an SHA-1 hash over 1301 the public key information included in a Public Key Information 1302 field of a Public Key Option. 1304 Digital Signature 1306 A digital signature of the format specified in the field Sign 1307 Type. This signature is over the entire message, including the 1308 ICMPv6 Pseudo Header, and all options up to and preceding this 1309 option. 1311 The length of the Digital Signature field is the length in octets 1312 of the message subtracting 12 octets for fixed length fields, and 1313 the contents of the Pad Length field. 1315 Padding 1317 This field SHOULD be set to zero by the sender and ignored by the 1318 receiver. 1320 8. Establishing a Secure Connection 1322 A host wishing to request that state be created on a PEP signals a 1323 PDP with either an Init message containing credential information, or 1324 a Request message containing the filter information describing the 1325 host's intended protocol behaviour. 1327 Either of these messages MUST contain the Public Key Option (or a 1328 Substituted Certificate Option containing the relevant Public Key) 1329 and a Digital Signature Option, along with Timestamp and Nonce 1330 information. In addition, the Init message contains a unique session 1331 identifier field selected by the requesting node. This session 1332 identifier field will be used for subsequent signaling of other 1333 messages upon successful establishment of a secure session. 1335 If the PDP can determine from the contents of the message that it 1336 believes the host is an acceptable requester, it can respond to the 1337 request with the appropriate success acknowledgement in the Init 1338 Acknowledgement message. 1340 If the PDP is not able to authemticate or authorize the credentials 1341 for the host, it replies with an Init-Ack or Response containing a 1342 non success response code, and a Cookie Option. Where the host 1343 wishes to establish a secure connection, the host must return this 1344 same cookie in the subsequent message (or messages for trust chains 1345 which exceed a single packet). 1347 The host may then send additional information in the form of either a 1348 sequence of Certificate Path Advertisements, if allowed in the Cookie 1349 option. Finally, when all credentials are transmitted, the host 1350 again sends an Init message containing the last received cookie. 1352 For the case where the Init-Ack contained the failure code "Liveness 1353 Test Needed", no further credentials are required, although an Init 1354 MUST be resent containing the received Cookie Option. 1356 9. Creating New entries 1358 Entries consist of one or more flow identification options that are 1359 sent from an end node to the PDP. In order to create entries the end 1360 node must send a Request message to the PDP. The Request message 1361 MUST contain and appropriate session identifier value, and a Message 1362 identifier. The message identifier can be implemented as a 1363 monotonously increasing counter. The Request message contains the 1364 following options: 1366 o One or more Flow Identification options. Each option contains a 1367 unique Index field, an appropriate Action field, a format field 1368 indicating the format of the flow descriptor and an appropriate 1369 priority in the PRI field. 1371 o The Nonce option 1373 o The Digital Signature option. 1375 Upon receiving the Request message, the PDP verifies the signature in 1376 the message. If the verification fails, the message is silently 1377 discarded. 1379 Upon successful verification of the Request message, the PDP checks 1380 the message header. If the session identifier is not known, the PDP 1381 sends a Response message with the same session and message 1382 identifiers and includes and Acknowledgement option with the status 1383 field set to 130. 1385 If the message is correctly formed, the PDP inspects each flow 1386 identification option. If an error is found in any of the flow 1387 options, the PDP sends a Response message with the Acknowledgement 1388 indicating failure with the appropriate error code. The failed 1389 options MUST be included in the Response message. successful options 1390 are processed by the PDP. 1392 The process of updating existing flows is described in Section 10. 1394 If all options are processed successfully, the PDP sends a Response 1395 message. The session and message identifier fields are set to the 1396 same value in the Request message. The Response message includes the 1397 following options: 1399 o The Acknowledgement option. This option's status field indicates 1400 success 1402 o The Lifetime option. This option includes the lifietime 1403 associated with the new entries. The end node needs to refresh 1404 those entries before the lifetime expires. 1406 o The nonce option. 1408 o The Digital Signature option. 1410 Note that the process of adding new entries does not require the end 1411 nodes to send all existing entries. Only new flows need to be 1412 included in the Request message. 1414 10. Updating Entries 1416 Updating existing entries may take place due to the need for changing 1417 the flow description, deleting an existing entry, or simply 1418 refreshing an entry before its timer expires. When refreshing 1419 entries there is no need for the requesting node to send the entire 1420 Flow identifier option in a Request message. It is sufficient to 1421 send the option without the flow descriptor. 1423 Updating entries is done using the same Request message as described 1424 in Section 9 Upon receiving the Request message, the PDP verifies the 1425 Digital signature option. If the verification failed, the message is 1426 silently discarded. 1428 After successfully verifying the message, the PDP processes each flow 1429 identifier option for formatting, flow descriptor (if the FID field 1430 indicates a new flow) and the Action field. If all of the flow 1431 identifier options are rejected, the PDP responds with a Response 1432 message, including the acknowledgement option, which indicates 1433 failure with an appropriate error code. 1435 If some of the filter identifier options are rejected and others are 1436 accepted, the PDP responds with the Response message, including the 1437 acknowledgement option, which indicates partial success. The 1438 Response message also includes the lifetime option with an 1439 appropriate lifetime for the accepted options. In addition, the 1440 Response message includes all of the failed options. Each of the 1441 failed options includes a Status field, which indicates the reason 1442 for failure. 1444 After receiving the Response message, the requesting node updates its 1445 list of accepted entries and the corresponding lifetimes for those 1446 entries. 1448 11. Requesting an IPv4 Address 1450 A requesting node may wish to know the public IPv4 address and port 1451 numbers allocated to it by a NAT for one or more of its applications. 1452 To do that, it can request one or more IP addresses and port numbers 1453 while specifying the protocol that it wants to use. This is done by 1454 sending a Request message that includes the following options: 1456 o The IP address option. 1458 o The nonce option. 1460 o The digital signature option. 1462 Upon receiving the Request message, the PDP verifies the digital 1463 signature included. If the verification failed, the PDP silently 1464 discards the message. 1466 If the PDP allows nodes to request an IPv4 address, it can proceed 1467 with the processing of the IP address option. Otherwise, the PDP 1468 rejects the request by sending a Response message with an 1469 acknowledgement option contaiing the appropriate error code. 1471 If the IP address option is valid, the PDP proceeds to allocate the 1472 requested address(es) and port numbers. The method used by the PDP 1473 to communicate with the NAT/firewall is outside the scope of this 1474 document. 1476 If after allocating the IP address to the requesting node, the PDP 1477 sends a Response message including the IP address option, which 1478 includes the allocated addresses and ports, the nonce option, the 1479 lifetime option and the digital signature option. 1481 Upon receiving the Response message and verifying the digital 1482 signature option, the requesting node can use the IP address(es) and 1483 ports allocated in the message for the duration of the lifitime 1484 option. Should the requesting node wish to refresh the allocated 1485 addresses and ports, it MUST send the Request message with the IP 1486 address option including all the previously allocated IP addresses 1487 and ports. 1489 12. Timeouts and Retransmissions 1491 Where a host receives no response to a packet sent directly to a PDP, 1492 it may need to retransmit its initial packet. Each request MAY be 1493 transmitted up to four (4) times, each with a different Nonce and 1494 updated TimeStamp. Separation between one transmission and its next 1495 should be performed such that timeouts are exponential. RECOMMENDED 1496 timeouts are 1,2 and 4 seconds. A host SHOULD delay an initial 1497 retransmission by between 0 and 100ms, to ensure any retransmissions 1498 are serialized. 1500 The PDP never sends packets to the host, except in response to an 1501 FCON message. In order to respond in sufficient time, it is 1502 recommended that the PDP respond without induced delay to any packet 1503 sent directly to its IP address. 1505 12.1. Session Start Delays 1507 When a new session is established, if a data plane transmission 1508 delays until FCON acknowledgements are received, there is likely to 1509 be significant added delay for every TCP or UDP session creation. It 1510 is therefore recommended that FCON immediately precedes packet 1511 transmission on the data plane, where it is not harmful to lose one 1512 or two of the initial packets. This may for example, be the case 1513 with unreliable protocols such as VoIP. 1515 Also, when a host has one or more existing communications open in 1516 negotiation with a PDP, it is possible to send the packets 1517 immediately after sending the FCON request. This optimizes for the 1518 case where new state is able to be created immediately, and reduces 1519 latency at the risk of causing packet loss and retransmission on 1520 initial packets. 1522 Where a host has not communicated to a PDP previously, it MAY induce 1523 additional delay before sending the data plane packets, in order to 1524 limit additional delays due to retransmission and timeout at the 1525 Transport Layer of the data session. 1527 Significantly, when FCON packet loss or delay occurs on the 1528 signalling path, this means that packet loss or delay will ensue, 1529 with the timings described in the prior section. 1531 13. IANA Considerations 1533 TBD 1535 14. Security Considerations 1537 Certain assumptions underly the initial version of this draft, which 1538 need to be considered appropriately. Firstly, the role of CGAs in 1539 providing proof of address ownership in this protocol is primarily an 1540 enabler, and may be insufficient in some environments to authorize 1541 communications for a particular destination. 1543 This may particularly be the case for devices with multiple users, 1544 where individuals have permission to access specific data services, 1545 but others are excluded. CGAs at host level granularity are 1546 insufficient to distinguish which of the users is attempting a 1547 communication. 1549 Mechanisms which could be used to provide such distinction are user- 1550 level digital signatures over the filter message contents and 1551 freshness information, in addition to CGA information. Additionally, 1552 to ensure that the PDP only has to process a single digital 1553 signature, subsets users on multi-host systems could be allocated 1554 CGAs tied to their own public key information while using that host. 1556 Therefore FCON messages from different users on a system would have 1557 different security credentials, and still allow CGA authorization. 1558 The internal processes on the host to allow for signing such messages 1559 is beyond the scope of this document, but it is easy to envisage an 1560 ICMP message signing service which a user subscribes to, that uses 1561 the subscribed private-key credentials to sign FCON and SEND 1562 messages. 1564 Regardless of the identity of the message signer, FCON request 1565 messages require authentication of the node, and the response 1566 messages require proof of the PDP's identity in order to prevent 1567 denial-of-service through spoofing attacks. Denial of service can 1568 occur due to the requirement to process digital signatures on 1569 response messages. Hosts which detect many excessive responses from 1570 PDPs, such as would indicate a denial-of-service attempt MAY defer 1571 processing digital signatures on responses, and rely on freshness and 1572 Nonce information in the message itself to determine if a digital 1573 signature needs to be processed. This limits denial . of service 1574 attacks to those who are able to guess nonces, or are on the path to 1575 the PDP. 1577 15. Acknowledgements 1578 16. Normative References 1580 [I-D.ietf-nsis-nslp-natfw] 1581 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 1582 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1583 draft-ietf-nsis-nslp-natfw-18 (work in progress), 1584 February 2008. 1586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1587 Requirement Levels", BCP 14, RFC 2119, March 1997. 1589 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1590 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1591 October 1998. 1593 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1594 (IPv6) Specification", RFC 2460, December 1998. 1596 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1597 Listener Discovery (MLD) for IPv6", RFC 2710, 1598 October 1999. 1600 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 1601 revised", RFC 3024, January 2001. 1603 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1604 August 2002. 1606 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 1607 Network Address Translation (NAT) Devices", RFC 3519, 1608 May 2003. 1610 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1611 in IPv6", RFC 3775, June 2004. 1613 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1614 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1616 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1617 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1618 RFC 3963, January 2005. 1620 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1621 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1623 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1624 RFC 3972, March 2005. 1626 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1627 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1629 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1630 Architecture", RFC 4291, February 2006. 1632 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1633 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1634 September 2007. 1636 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1637 Address Autoconfiguration", RFC 4862, September 2007. 1639 Appendix A. Dynamic PDP Discovery (Informative) 1641 In some of the described scenarios, it may not be feasible to 1642 prepopulate the endpoints with information for all of the relevant 1643 PDPs responsible for firewall policy along a particular data path. 1644 For these scenarios, sending data to an existing configured PDP may 1645 be insufficient to create state in all firewalls on the path. This 1646 may lead to packets being dropped, even though signalling has been 1647 performed, and all known signaling accomplished. 1649 One mechanism to ensure that all PDPs for a data path are informed of 1650 changes is to send CREATE packets along the path at the time 1651 establishing a data connection. Such packets would be sent to the 1652 same IP source and destination as the packets in the data stream, but 1653 the IP packet would contain the Router-Alert Hop-By-Hop option 1654 [RFC2460]. 1656 Enforcement or Decision Point devices which receive such probes, 1657 would refer the packet for processing, and identify that the ICMP 1658 message contained a CREATE operation. The message filter contents 1659 would then define which sessions are requested to be allowed through 1660 the firewall. 1662 Depending upon policy, the PDP or PEP would either DENY the data 1663 flow, sending a CREATE-NACK message, refer the sender to an 1664 appropriate PDP using the PDP-REDIRECT message, or create the state 1665 for the session according to the filter, and send a CREATE-ACK. In 1666 the case that the session state creation is refused or redirected, 1667 the CREATE packet packet itself is dropped. In the alternative case 1668 where state is created, the CREATE packet should be forwarded onward 1669 toward its destination. At this stage, the potential to create 1670 multiple responses to a single message is the primary danger of this 1671 method. 1673 An alternative which increases setup latency is to drop the CREATE 1674 packet when new state is created, and send a CREATE-ACK. On each 1675 successive CREATE packet which does not alter session state, the 1676 CREATE packet is passed onward towards the destination. This removes 1677 any multiplication attacks, but causes delay of up to N x RTT for N 1678 policy devices along the path. 1680 Similar operations for UPDATE would also occur, with state being 1681 created if it didn't exist, or replaced in the case it already was in 1682 place. 1684 Once a host discovers that a Policy Decision Point exists on a 1685 particular path, it can then signal directly to it. Devices can add 1686 these to the PDPs discovered using DHCP or other mechanisms. 1688 Even though the packets are sent between the same source and 1689 destination addresses as those of the data session, they may travel a 1690 different path to the actual data stream, for example due to load 1691 balancing. In such a case, a PDP or PEP which receives the CREATE or 1692 UPDATE method can send a PDP-REDIRECT, to refer the origin to the 1693 appropriate policy decision point for the data flows. 1695 Where a host application accepts inbound packets passively, it may be 1696 useful to ensure that Policy enforcement and decision points beyond 1697 the DHCP configured range are included in signaling. Such can be 1698 achieved by configuring a filter describing the allowed inbound 1699 source and destination addresses of packets and addressing a hop-by- 1700 hop CREATE packet to a set of potential inbound source addresses. 1702 Such probing can be limited in terms of the number of addresses to 1703 probe, as well as the time-to-live of the packet itself, in order to 1704 prevent impacts upon the network. 1706 Authors' Addresses 1708 Hesham Soliman 1709 Elevate Technologies 1711 Email: hesham@elevatemobile.com 1713 Greg Daley 1715 Email: hoskuld@hotmail.com 1717 Suresh Krishnan 1718 Ericsson 1719 8400 Blvd Decarie 1720 Town of Mount Royal, Quebec 1721 Canada 1723 Email: suresh.krishnan@ericsson.com 1725 Full Copyright Statement 1727 Copyright (C) The IETF Trust (2008). 1729 This document is subject to the rights, licenses and restrictions 1730 contained in BCP 78, and except as set forth therein, the authors 1731 retain all their rights. 1733 This document and the information contained herein are provided on an 1734 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1735 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1736 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1737 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1738 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1739 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1741 Intellectual Property 1743 The IETF takes no position regarding the validity or scope of any 1744 Intellectual Property Rights or other rights that might be claimed to 1745 pertain to the implementation or use of the technology described in 1746 this document or the extent to which any license under such rights 1747 might or might not be available; nor does it represent that it has 1748 made any independent effort to identify any such rights. Information 1749 on the procedures with respect to rights in RFC documents can be 1750 found in BCP 78 and BCP 79. 1752 Copies of IPR disclosures made to the IETF Secretariat and any 1753 assurances of licenses to be made available, or the result of an 1754 attempt made to obtain a general license or permission for the use of 1755 such proprietary rights by implementers or users of this 1756 specification can be obtained from the IETF on-line IPR repository at 1757 http://www.ietf.org/ipr. 1759 The IETF invites any interested party to bring to its attention any 1760 copyrights, patents or patent applications, or other proprietary 1761 rights that may cover technology that may be required to implement 1762 this standard. Please address the information to the IETF at 1763 ietf-ipr@ietf.org. 1765 Acknowledgment 1767 Funding for the RFC Editor function is provided by the IETF 1768 Administrative Support Activity (IASA).