idnits 2.17.1 draft-palet-v6ops-ipv6security-02.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 566. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 20, 2005) is 6999 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: '3' is defined on line 485, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 489, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 499, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-vives-v6ops-ipv6-security-ps-02 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Palet 3 Internet-Draft A. Vives 4 Expires: August 24, 2005 Consulintel 5 G. Martinez 6 A. Gomez 7 University of Murcia (UMU) 8 February 20, 2005 10 IPv6 Distributed Security Requirements 11 draft-palet-v6ops-ipv6security-02.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 24, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 The security policies currently applied in Internet with IPv4, 47 doesn't longer apply for end-to-end security models which IPv6 will 48 enable. 50 Today, each network is often secured by one or several devices (i.e. 51 security gateway or border firewall in the simplest configuration), 52 which become a bottleneck for the end-to-end security model with 53 IPv6. 55 In addition, users and devices start to be nomadic, moving between 56 different networks that could have different security policies. 58 A distributed and dynamic approach is consequently required, as 59 already described by [1]. 61 All these points and others are discussed in [2] as a reason of 62 concern for the security administrator when operating IPv6 networks. 63 In this document the problem is accepted and a step forward is done 64 defining the requirements for a possible solution. 66 How these requirements are satisfied by a possible solution is out of 67 the scope of the present document. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Security Definition . . . . . . . . . . . . . . . . . . . . 4 73 3. Distributed Security Model . . . . . . . . . . . . . . . . . 5 74 4. The Host . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1 Interior Security . . . . . . . . . . . . . . . . . . . . 6 76 4.2 The Visiting Node . . . . . . . . . . . . . . . . . . . . 6 77 4.3 Default Security . . . . . . . . . . . . . . . . . . . . . 7 78 4.4 Other Considerations . . . . . . . . . . . . . . . . . . . 7 79 5. Security Policy Server and Protocol . . . . . . . . . . . . 8 80 6. Non-security-capable Nodes and Security Workload 81 Distribution . . . . . . . . . . . . . . . . . . . . . . . . 9 82 7. Location of the Security Policy Server . . . . . . . . . . . 9 83 8. Security Mechanism Modules . . . . . . . . . . . . . . . . . 10 84 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 10 85 10. Security Considerations . . . . . . . . . . . . . . . . . . 11 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 12.1 Normative References . . . . . . . . . . . . . . . . . . 11 89 12.2 Informative References . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 91 Intellectual Property and Copyright Statements . . . . . . . 14 93 1. Introduction 95 Today's Internet paradigms for security need a revision with the 96 deployment of IPv6, as suggested in [2], offering end-to-end security 97 capabilities. 99 Current security policies based on a centric approach with unique 100 border devices don't longer apply, the so-called network-based 101 security. Often they are based in a firewall or security gateway and 102 statically configured rules, which don't work in all the situations, 103 for example, they don't consider the internal threats. 105 Additionally, the network-based security model is deeply incompatible 106 with the model of virtual organizations that is fundamental to Grid 107 computing, where virtual organizations cross all traditional security 108 boundaries. 110 Users and devices start to be nomadic. They often move from one 111 network to another and this needs to be taken in consideration to 112 keep the security of the complete visited network abd the nomadic 113 host. 115 Keeping today's static security model seems to be the wrong approach, 116 which interferes with the end-to-end features and advantages of IPv6. 118 Enforcing the nomadic users and devices to connect to Internet by 119 means of the security gateway, in tunnel mode, is often equivalent to 120 disable the IPsec protocol on each node, not allowing the use of 121 transport mode and consequently invalidating one of the key IPv6 122 advantages. 124 The lack of end-to-end secure communication and in general the 125 current network-based security model, specially in enterprise 126 networks, prevents innovation. 128 On the other hand, it is also true and perfectly understandable that 129 there is a need to enforce security in the networks, in such way that 130 the security administrator has always the control over it. 132 2. Security Definition 134 As this document tries to stablish the security requirements for an 135 IPv6 network, the definition of what is understood as security is of 136 capital importance. 138 We use security in the "big scope" of the word, trying to include as 139 much as possible. In other words, a host, a network or some 140 information, will be secure when no attacks could succeed against 141 them. A success will mean compromise of availability, integrity, 142 confidentiality or authenticity. The realistic objective is to be as 143 much secure as possible in a precise moment. 145 So the security solution should include a number of mechanisms to 146 provide security to network devices. Current mechanisms could be 147 integrated in the solution and defined in the security policy. For 148 example there could be active firewalling together with Intrusion 149 detection, antivirus software and system update mechanisms. 151 Security mechanisms should also include techniques to mitigate the 152 danger in case of a compromised host and/or network. 154 3. Distributed Security Model 156 As described in [2], a possible security scheme is the distributed 157 one [1], as an alternative to the network-based model. 159 The aim is to keep, or even more, be able to increase the security in 160 the network as a whole and simultaneously keep the control of it 161 under the security administrator hands, while the individual nodes 162 can take advantage of end-to-end and secure end-to-end 163 communications. 165 The basic idea is simple: the Security Policy is centrally defined 166 using the Policy Specification Language and distributed to each host 167 by means of a Policy Exchange Protocol. The Network Entities need to 168 be authenticated in order to be trusted. See [2] for more details. 170 These hosts must respect the security policy of the network where 171 they are attached. In case of a conflict which is not automatically 172 resoluble, a resolution arbitration mechanism should be established. 174 The effect is simple to understand: instead of a one or a few 175 firewalls, each one being a point of failure for the complete 176 network(s), that could be attacked or fail, creating a bottleneck for 177 all the communications, there will be a number of firewalls (at every 178 host) configured according to a central policy, which increase the 179 scalability, reliability, efficiency and performance of the complete 180 network. 182 This is often becoming possible in most of the nodes because even if 183 IPsec and encryption are enforced for most of the communications, 184 nodes often have powerful CPUs with unused cycles that will easily 185 accommodate the extra required workload. In case of small devices, 186 they may not have those resources, and still need to rely on other 187 devices for performing security functions on their behalf. 189 On the other hand, the central firewalls will be able to dedicate CPU 190 cycles to new functions, or be able to protect bigger networks. 192 4. The Host 194 With IPv6 and the distributed security model the host play a crucial 195 role in the network security, in other words, the security mechanisms 196 are moved to each host. 198 As said above the entities, in this case the hosts, should 199 authenticate themselves in order to be trusted. This will be a 200 requirement of a possible solution. 202 4.1 Interior Security 204 With this approach, the security of each host is not only towards 205 communications with Internet or other networks, but also with the 206 rest of the nodes in the same network. 208 This means an increase in the overall security and the possibility to 209 isolate individual nodes if required. 211 4.2 The Visiting Node 213 This distributed security model is valid not only for fixed nodes, 214 i.e. desktop computers, but specially interesting and important for 215 those nodes like laptops and PDAs, which keep moving among different 216 networks. Vice versa, this model is of key importance for those 217 networks that receive visits from nodes that are not under the 218 control of the network/security administrator. 220 Different visited networks have different security requirements. 221 Consequently is required that those nomadic nodes dynamically 222 accommodate their own security policy to the one defined in the 223 visited network and arbitrate the conflict resolution between 224 different policies. 226 Nodes attaching to a network via VPNs, RAS, dial-up modems or other 227 similar means can also be considered as visiting nodes, as they can 228 also create a path between the visited network and any other network 229 where they are actually connected. They must also be able to 230 dynamically configure their own security to match the one existing in 231 the visited network. 233 When a node is attached to a visited network and receives the visited 234 Network's security policy, basically there are two possible 235 situations: 237 1. The network security policy is equivalent or less restrictive 238 than the node configuration. In this case, the node could not 239 change its security policy configuration or relax its 240 restrictions if needed for some applications, always following 241 the received security policy. For this some degree of 242 granularity in the security policy specification and enforcement 243 should be given. 245 2. The network security policy is more restrictive than the actual 246 node configuration. In this case, the node will adapt its 247 security configuration to at least match the one indicated by the 248 security policy. 250 A possible solution should take into account the case of a device 251 attaching to the network and not following the security policy, 252 either because it does not want to or because is not able to. 254 The alternative often used today to accomplish this, is by means of 255 manual changes in the configuration of the visiting node, but they 256 are always prone to errors and dangerous to be considered useful and 257 secure enough, specially considering that the visiting node can be 258 already infected from previous connections to other non-protected 259 networks (home network, hot-spot, ...). 261 4.3 Default Security 263 The nodes can be attached to a network which doesn't offer any 264 protection means, not only against external attacks, but also those 265 coming from the same network, for example, in hot-spots, public 266 networks, ad-hoc networks or even networks temporarily setup for 267 conferences. 269 The distributed security model addresses this case because the host 270 will have all the necessary means to protect itself. A Possible 271 solution must take this into account and have an appropriated 272 mechanism to detect the connection to a foreign network and apply the 273 correspondent security policy, previously defined by the host 274 security administrator. 276 This security Policy applied in foreign networks and/or in case of 277 not having connectivity with the Policy Enforcement Point will be 278 called the Default Security Policy. 280 4.4 Other Considerations 282 A requirement will be to offer Policy Change Facilities allowing the 283 user or the host security administrator to change security settings. 284 Also the switching between two or more allowed security policies 285 could be implemented. 287 5. Security Policy Server and Protocol 289 In order to achieve the benefits of the distributed security model, 290 and at the same time provide the mean for the adequate and dynamic 291 control of the overall network security by the network/security 292 administrator, a security policy server is required. 294 The policy server(s) function could replace the main functionality of 295 the central firewall and complement it. The security administrator 296 will define the security rules required by all the networks and/or 297 individual nodes. 299 A requirement will be to have a reliable Security Policy distribution 300 mechanism. For example, the different nodes could query to the 301 policy server to learn about the network security policy and adapt 302 themselves in order to match it. The policy server could also 303 request information and security status to the nodes. 305 Until the node performs and acknowledge the required security policy 306 configuration update, it must not be allowed to transfer/receive data 307 to/from other nodes either in the network or other connected 308 networks. 310 The security policy server can also dynamically update the security 311 policy for the complete network or specific nodes. This can be done 312 in response to a security administrator decision, or other 313 situations, like information received from an external or internal 314 attack, detected by an intrusion detection system, firewall or even 315 by nodes inside the network. 317 The security policy should be administered at a network level or 318 individually for every node, upon decision of the network/security 319 administrator. 321 A single standard Policy definicion Language and a Policy Exchange 322 protocol are required for the signaling between the nodes, security 323 policy servers, firewalls (including node or host firewalls), 324 intrusion detections systems, honey pots, routers, and any other 325 elements implicated in the overall network and nodes security. 327 Following this approach, the security administrator will use a PMT 328 (Policy Management Tool), to edit the policies and distribute them 329 via PXP (Policy Exchange Protocols) to the PEP (Policy Enforcement 330 Points), in this case the end nodes. 332 For the interaction with IPsec policies, it seems appropriate the 333 existing IPsecCPIM [5]. 335 To guarantee the self-security of this model, the security policy 336 being communicated to the nodes should be digitally signed, in order 337 to provide integrity, origin authentication and non-repudiate 338 authenticity of the source. 340 6. Non-security-capable Nodes and Security Workload Distribution 342 Increase in security often means increase in processing power. Some 343 nodes could not have the required CPU cycles to afford the complete 344 required security policy. 346 Another requirement will be to take into account this, what we will 347 call non-security-capable nodes. 349 The possible solution could fragment the security enforcement in 350 different levels establishing a ligh set of security requirements for 351 those kind of nodes. Another alternative is that the noces could be 352 partitioned from the network and treated as non-security-capable 353 nodes. Alternatively, the firewalls or even other security-capable 354 nodes with free resources, could act as trusted security gateways for 355 the non-security-capable nodes. 357 How to address this requirement is out of the scope of this document. 359 Despite the adopted solution, it seems only possible if minimum 360 security verification can be done by those nodes, i.e. digital 361 signature verification. 363 It could be even considered a system to provide a kind of security 364 workload-balancing. 366 7. Location of the Security Policy Server 368 Firewalls and security gateways are expensive devices and they are 369 required to sit at the border of the network. They also require 370 qualified personal to manage them. 372 In the case of the distributed security model, the security policy 373 server isn't required to be collocated as a border device. 375 This provides the opportunity to have this device not only inside the 376 network, but also at any other point in Internet. 378 This opens the doors to new services and business models that provide 379 very sophisticated security services, especially for Home, SOHO and 380 SMEs. 382 Some possible "ideal" locations for the security policy servers could 383 be Internet Exchanges [6] or in general PoPs, ISPs, and other similar 384 central Internet locations. 386 8. Security Mechanism Modules 388 As said above, the security mechanism implemented could address 389 several security problems by means of a number of tools. 391 The basic ones should be firewall, IDS (Intrusion Detection System), 392 Anti-virus and software version checker. 394 These different tools could be thought as modules for both the policy 395 definition and enforcement and the solution implementation. 397 9. Conclusions 399 In this document it was accepted that a problem will arise with the 400 network-based security scheme and the deployment of IPv6. Also the 401 security scheme that was in mind during the requirements definition 402 was the host-based or the distributed one [2]. 404 Possible solutions to addresses the requirements outlined in this 405 document is out of the scope and will be defined elsewhere. 407 The Distributed Security Scheme has been described as the one that 408 best fits as a solution to the Security Problem Stated [2]. This 409 doesn't mean that the solution must follow this scheme strictly but 410 seems to be useful at least as a guideline. 412 The purpose of this document is to give some abstract requirements of 413 a possible solution. 415 As a summary of what has been seen above, we can outline the 416 following requirements: 418 1. The solution must try to address as much as possible, in the 419 sense of being able to protect against different threats using a 420 number of mechanisms. The recommended ones are firewall, IDS, 421 Anti-virus and software version control. 423 2. There must be a control mechanism to detect if a node is not 424 following the appropriate security policy. This allows the 425 solution to be prepared to receive foreign hosts. 427 3. The solution must allow the hosts to move to other networks under 428 the same security policy, under a different one or under no 429 security at all. 431 4. The security policy and its enforcement must be given with a 432 certain degree of granularity in order to ease the different 433 policies comparison and use. 435 5. A Security Policy Specification tool must be provided. This tool 436 should use a single standard Security Policy Specification 437 Language. 439 6. A reliable Security Policy Distribution mechanism must be 440 provided. This mechanism should use a single standard Policy 441 Exchange Protocol. 443 7. A reliable Security Policy Enforcement mechanism must be 444 provided. 446 8. A reliable entity identity's authentication mechanism must be 447 provided. 449 9. The solution must be dynamic in the sense of being able to 450 respond to security events and adapt the policies accordingly. 452 10. Related to the previous one, a mechanism of "alarm distribution" 453 is recommended, allowing the hosts to report security events to 454 other hosts even in the case of, for example, problems in the 455 Security Policy Server. The idea is that a distributed system 456 could be more robust than a client-server one. 458 11. The solution must ease the security administrator's work 459 allowing, for example, the centralized Security Policy 460 management, i.e., definition, distribution and updating. 462 10. Security Considerations 464 This document is concerned entirely with security. TBD. 466 11. Acknowledgements 468 The authors would like to acknowledge the inputs from Cesar Olvera, 469 Brian Carpenter, Satoshi Kondo, Pekka Savola and the European 470 Commission support in the co-funding of the Euro6IX project, where 471 this work is being developed. 473 12. References 475 12.1 Normative References 476 12.2 Informative References 478 [1] Bellovin, S., "Distributed Firewalls", November 1999, 479 . 481 [2] Vives, A. and J. Palet, "IPv6 Security Problem Statement", 482 Internet-Draft draft-vives-v6ops-ipv6-security-ps-02, October 483 2004. 485 [3] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. 486 Sastry, "The COPS (Common Open Policy Service) Protocol", 487 RFC 2748, January 2000. 489 [4] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., 490 Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS 491 Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. 493 [5] Jason, J., Rafalow, L. and E. Vyncke, "IPsec Configuration 494 Policy Information Model", RFC 3585, August 2003. 496 [6] Morelli, M., "Advanced IPv6 Internet Exchange model", 497 Internet-Draft draft-morelli-v6ops-ipv6-ix-00, July 2004. 499 [7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 500 "SEcure Neighbor Discovery (SEND)", 501 Internet-Draft draft-ietf-send-ndopt-06, July 2004. 503 Authors' Addresses 505 Jordi Palet Martinez 506 Consulintel 507 San Jose Artesano, 1 508 Alcobendas - Madrid 509 E-28108 - Spain 511 Phone: +34 91 151 81 99 512 Fax: +34 91 151 81 98 513 Email: jordi.palet@consulintel.es 514 Alvaro Vives Martinez 515 Consulintel 516 San Jose Artesano, 1 517 Alcobendas - Madrid 518 E-28108 - Spain 520 Phone: +34 91 151 81 99 521 Fax: +34 91 151 81 98 522 Email: alvaro.vives@consulintel.es 524 Gregorio Martinez 525 University of Murcia (UMU) 526 Campus de Espinardo s/n 527 Murcia 528 E-30071 - Spain 530 Phone: +34 968 364 607 531 Fax: +34 968 364 151 532 Email: gregorio@um.es 534 Antonio F. Gomez Skarmeta 535 University of Murcia (UMU) 536 Campus de Espinardo s/n 537 Murcia 538 E-30071 - Spain 540 Phone: +34 968 364 607 541 Fax: +34 968 364 151 542 Email: skarmeta@um.es 544 Intellectual Property Statement 546 The IETF takes no position regarding the validity or scope of any 547 Intellectual Property Rights or other rights that might be claimed to 548 pertain to the implementation or use of the technology described in 549 this document or the extent to which any license under such rights 550 might or might not be available; nor does it represent that it has 551 made any independent effort to identify any such rights. Information 552 on the procedures with respect to rights in RFC documents can be 553 found in BCP 78 and BCP 79. 555 Copies of IPR disclosures made to the IETF Secretariat and any 556 assurances of licenses to be made available, or the result of an 557 attempt made to obtain a general license or permission for the use of 558 such proprietary rights by implementers or users of this 559 specification can be obtained from the IETF on-line IPR repository at 560 http://www.ietf.org/ipr. 562 The IETF invites any interested party to bring to its attention any 563 copyrights, patents or patent applications, or other proprietary 564 rights that may cover technology that may be required to implement 565 this standard. Please address the information to the IETF at 566 ietf-ipr@ietf.org. 568 Disclaimer of Validity 570 This document and the information contained herein are provided on an 571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 572 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 573 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 574 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 575 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 578 Copyright Statement 580 Copyright (C) The Internet Society (2005). This document is subject 581 to the rights, licenses and restrictions contained in BCP 78, and 582 except as set forth therein, the authors retain all their rights. 584 Acknowledgment 586 Funding for the RFC Editor function is currently provided by the 587 Internet Society.