idnits 2.17.1 draft-vives-v6ops-ipv6-security-ps-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 814. ** 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.) 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 6976 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) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '4') (Obsoleted by RFC 4941) == Outdated reference: A later version (-02) exists of draft-chown-v6ops-port-scanning-implications-01 -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '7') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '8') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3576 (ref. '9') (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '12') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '13') (Obsoleted by RFC 6275) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Vives 3 Internet-Draft J. Palet 4 Expires: August 24, 2005 Consulintel 5 P. Savola 6 CSC/FUNET 7 February 20, 2005 9 IPv6 Security Problem Statement 10 draft-vives-v6ops-ipv6-security-ps-03.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 24, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 Today, each network is often secured by a unique device (i.e. 46 security gateway or firewall) that becomes a bottleneck for the 47 end-to-end security model with IPv6. The deployment of IPv6 enabled 48 devices and networks bring some issues, which must be addressed by 49 security administrators in order to guarantee at least the same level 50 of security that is obtained nowadays with IPv4 and network-based 51 (including perimeter-based) security schemes, allowing at the same 52 time all the IPv6 advantages. 54 The most important issues are the rediscovery of end-to-end 55 communications, the availability of IPsec in all IPv6 stacks, the 56 increase in the number and type of IP devices and also the increase 57 in the number of nomadic devices, connecting to different networks 58 that could have different security policies. 60 The security policies and architectures currently applied in Internet 61 with IPv4 do no longer apply for end-to-end security models which 62 IPv6 will need. This document outlines the advantages and drawbacks 63 of both security schemes: network/perimeter-based and distributed. 65 This document aims to identify IPv6 issues that justify the need of a 66 distributed security model for IPv6, that is, simply to show that a 67 security problem will arise with the deployment of IPv6 networks if 68 nothing is done. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Network-based versus Host-based Security . . . . . . . . . . . 5 74 2.1 Network-based Security . . . . . . . . . . . . . . . . . . 5 75 2.2 Host-based Security . . . . . . . . . . . . . . . . . . . 7 76 3. IPv6 Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 3.1 End-to-End . . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.2 IPsec-encrypted ESP-traffic in transport mode . . . . . . 11 79 3.3 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 3.4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 3.4.1 Link-local addresses . . . . . . . . . . . . . . . . . 13 82 3.4.2 New Multicast addresses . . . . . . . . . . . . . . . 13 83 3.5 Multihoming . . . . . . . . . . . . . . . . . . . . . . . 14 84 3.6 Randomly Generated Addresses . . . . . . . . . . . . . . . 14 85 3.7 Neighbor Discovery Weakness . . . . . . . . . . . . . . . 15 86 3.8 Routing Header . . . . . . . . . . . . . . . . . . . . . . 15 87 3.9 Home Address Option . . . . . . . . . . . . . . . . . . . 16 88 3.10 Embedded Devices . . . . . . . . . . . . . . . . . . . . . 16 89 4. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 91 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 7.1 Normative References . . . . . . . . . . . . . . . . . . . 17 94 7.2 Informative References . . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 96 Intellectual Property and Copyright Statements . . . . . . . . 19 98 1. Introduction 100 This document will cope only with IPv6 issues related to security, 101 i.e., it will try to answer the following question: How would the 102 deployment of IPv6 affect the security of a network? This network 103 could be a dual-stack network with IPv6 traffic from IPv6 capable 104 nodes, or an IPv6 only network. 106 The deployment of IPv6 enabled devices and networks forces the 107 security administrator to consider several issues: 109 o The rediscovery of end-to-end communications. 111 o The availability of IPsec in all IPv6 stacks. 113 o The increase in the number and type of IP devices. 115 o The increase in the number of nomadic devices, connecting and 116 moving between different networks. 118 The security policies and architectures currently applied in Internet 119 with IPv4 no longer apply for end-to-end security models which IPv6 120 will enable. This document outlines the advantages and drawbacks of 121 both the security schemes: network/perimeter-based and distributed. 123 Also IPv6 issues will be identified that justify the need of 124 distributed security for IPv6, that is, simply to show that a 125 security problem will arise with the deployment of IPv6 networks if 126 traditional schemes are used. 128 The following issues are out of scope of this document and will be 129 addressed elsewhere: 131 o State the security requirements for the described IPv6 scenarios. 133 o Propose a solution or architecture to address the problem stated 134 in this document. 136 o To address security problems derived from the use of transition 137 mechanisms. 139 Last but not least, this document contains a brief definition of what 140 we understand by "security". We use security in the "big scope" of 141 the word, trying to include as much as possible. In other words, a 142 host, a network or some information, will be secure when no attacks 143 could succeed against them. A success will mean compromise of 144 availability, integrity, confidentiality or authenticity. The 145 realistic objective is to be as much secure as possible in a precise 146 moment. It will be part of the requirements to establish which kind 147 of security is given using a number of mechanisms. 149 For clarity, in the rest of this document, network-based security 150 includes also the perimeter-based model. 152 2. Network-based versus Host-based Security 154 In this section two different approaches are analyzed to be used 155 later in the rationale about the security problems that IPv6 could 156 introduce 158 2.1 Network-based Security 160 This is the most used scheme, where the security of a host depends on 161 the point of the network it is connected to. 163 The perimeter scheme is the simplest one (see Fig. 1) and is based 164 in the topology of the network. The security policy is enforced in a 165 central host or firewall (FW), which provides secure network 166 connectivity to one or more network segments. The FW will be what an 167 "outside" host sees when tries to attack the network. Attacks coming 168 from the same LAN segment are not protected by the FW. Different 169 nodes (even different addresses in the same node) may have different 170 policies. 172 In a more advanced form of perimeter security, the different networks 173 could be protected from each other, or a number of internal firewalls 174 could be used as well. This way some networks could be protected 175 from hosts in other internal network 176 /-------\ 177 / \ 178 | Internet | 179 \ / 180 \---+---/ 181 | 182 | Policy Enforcement Point 183 +---+---+ 184 LAN-1 | | DMZ-1 185 ----+---------+ FW +-------+---- 186 | | | | 187 +-+--+ +---+---+ +--+-+ 188 | H1 | | | S1 | 189 +----+ |LAN-2 +----+ 190 | 191 +----+ | 192 | H2 +--+ 193 +----+ | 195 Figure 1: Perimeter Security 197 This model is based on the following assumptions: 199 o The threats come from "outside" the FW, basically the Internet. 201 o Everybody from the same LAN segment is trusted. 203 o The protected nodes won't go "outside" where FW won't be able to 204 protect them. 206 o There are no backdoors on the network (modem, WLAN, other 207 connections). 209 o The hosts will not need to be accessed directly from outside (at 210 least in a general manner, i.e., potentially all ports on all 211 hosts). 213 The main advantage of this scheme is its simplicity and easiness as 214 the elements and points of configuration are reduced to the minimum, 215 requiring few/no protocols and mechanisms to implement the security. 217 In case of a more complex configuration, where multiple FW are 218 deployed within an organization network, the complexity will 219 increase. 221 The drawbacks of this model are: 223 o This is a centralized model: Single point of failure for both 224 performance and availability. If the FW fails, then all the 225 networks connected to it loose network connectivity unless 226 specific fail-over techniques are applied. 228 o A big percentage of the threats come from inside the FW, and are 229 not addressed by this security model, especially when internal 230 firewalls are not deployed. 232 o The most dangerous threats, in the sense that one may not be able 233 to protect from them, come from inside the FW. 235 o The FW usually acts as NAT and/or proxy box, interfering or even 236 disallowing end-to-end communications. In complex configurations, 237 even more than one level of NAT/proxy could appear. 239 o Transport mode secured communications (using IPsec ESP for 240 example) need special solutions ([1]). 242 o The same security policy may be enforced for all the nodes of each 243 network connected to the FW, but it is also possible to have 244 separate policies for all hosts. In any case, an error in the FW 245 will equally expose all hosts in a network. 247 o Virtual organizations, for example those using GRID models, don't 248 work with traditional centralized security models. 250 o The lack of secure end-to-end prevents innovation. 252 2.2 Host-based Security 254 Host based security model, already introduced by [2], is based on the 255 idea of enforcing the security policy in each network host from a 256 central control point. 258 The three main elements identified in the distributed security model 259 are: 261 o Policy Specification Language. 263 o Policy Exchange Protocol. 265 o Authentication of Entities. 267 The basic idea is simple: the Security Policy is centrally defined 268 using the Policy Specification Language and distributed to each host 269 by means of the Policy Exchange Protocol. The Network Entities need 270 to be authenticated in order to be trusted, for example to allow an 271 incoming connection or to trust the received Security Policy. 273 The biggest challenge, however, is trusting that the hosts comply to 274 the rules they've received, for example that the user can't just 275 disable the firewall if (s)he dislike the policy; of course, this 276 only can happen in the case (s)he has administrative rights for that 277 (often not the case in non-personal systems, those not owned by the 278 end user). It seems that one ore more network entities would have to 279 keep watch over the hosts in order to detect if they are not 280 following the received policy. At first look the more appropriated 281 entity seems to be one that knows the security policy, for example 282 the one that distributes it. 284 From a security point of view this model somehow eases the work to 285 the "enemies", putting the Policy Enforcement Point in their hands. 286 So not only mechanisms to prevent direct attacks to the security 287 solution must be developed but mechanisms to minimize the 288 consequences. 290 /-------\ 291 / \ 292 | Internet | 293 +------+ \ / 294 |Sec. | \---+---/ 295 |Policy| | 296 +--+---+ | 297 | /-+-\ 298 | | \ / | LAN-3 299 -+---+------+ x +-------+-- 300 LAN-1 | (*) | / \ | | (*)Policy Enforcement Point 301 +--+-+ \-+-/ +-+--+ 302 | H1 | | LAN-2 | H3 | 303 +----+ | +----+ 304 | (*) 305 +--+-+ 306 | H2 | 307 +----+ 309 Figure 2: Host-based Security 311 This model is based on the following assumptions: 313 o Each host can be uniquely and securely identified. 315 o The security policy could be applied in one or more of the 316 following levels: network, transport and application. 318 o The threat comes from anywhere in the network. 320 o The intruder has no physical access to the protected network hosts 321 (what about malicious users? See other topics section). 323 o "Outside" hosts may be able to access all hosts "Inside", 324 depending on the policies. 326 The advantages of this model are: 328 o The security policy can be host-specific. 330 o A host can take better decisions as it knows what it is doing or 331 trying to do, that means it can better detect strange packets. 332 For example, it could allow mail traffic to only one application 333 on the system. 335 o Enables the usage of end-to-end applications level security (e.g., 336 web services security standards). 338 o Enables better protection from attacks by the "internal" users, 339 and possibly even to a degree from those in the local segment. 340 For example address spoofing can be detected and avoided coming 341 from the same LAN segment, without router participation. 343 o Can protect a host independent of the topology, i.e., wherever the 344 host is connected. 346 o Does not need specific devices to secure a host (consider the case 347 of a single host with a CPE (Customer Premises Equipment), if the 348 CPE has no (user-controllable) firewall functions). 350 o Can control the outgoing attempts from each host, avoiding local 351 network misbehavior or malicious practices. 353 o The collection of audit information could be more complete in a 354 distributed model, despite the processing of that information is 355 done in a distributed or centralized fashion. 357 o It maintains the centralized control of the security policies, 358 from where they are distributed to each host (central decisions, 359 local enforcement). 361 The drawbacks of this model are: 363 o It is more complex than the perimeter one. 365 o The uniqueness and secured identification of hosts is not trivial, 366 for example using certificates [2]. 368 o The hosts must be trusted (or designed appropriately) so that they 369 will operate according to the policy. For example, it must be 370 impossible to disable the firewall functions or if the policy is 371 not followed network communication is not allowed. 373 o A host that becomes compromised or infected with a worm or virus 374 in any case can't be trusted to operate according to the policies, 375 as the worms/viruses probably first create holes or disable the 376 protections if they can. 378 o It may be challenging to design the system so that policy updates 379 are made available to the nodes which may not be network-reachable 380 all the time. 382 o It may be difficult to distinguish a misbehaving application from 383 a legitimate application (for example, many email worms may be 384 channeled through the MUA which must be authorized to send the 385 mails to operate correctly). 387 o Because of having a centralized Policy Decision Point (PDP) from 388 where the Security Policies are distributed a weakness is 389 introduced in form of a central point of failure unless more 390 complexity is added, for example with a distributed/replicated 391 system. 393 o The host security is in some sense 'server-dependant'. It must be 394 able to detect the lost of connectivity with the PDP and act in 395 consequence. It also seems that being disconnected from the PDP 396 for a long period could be dangerous. 398 3. IPv6 Issues 400 When IPv6 is deployed, either in an existing IPv4 network or in a new 401 IPv6-only network, the security administrator must take into account 402 that IPv6 traffic will be different from the IPv4. 404 IPv6 enabled nodes will likely have global addresses, which means 405 they may be reachable from any other IPv6 node in the Internet. A 406 security administrator can prevent this by using local addressing 407 and/or firewalls, but the benefits of IPv6 may not be fully realized 408 if so. 410 The differences between IPv4 and IPv6 change the type of attacks 411 which IPv6 networks are likely to see. 413 Also mention that there are studies that conclude that the rollout of 414 dedicated IPv4 firewalls in the internal network to regulate internal 415 network communication causes the same work that dedicated firewalling 416 on hosts. 418 3.1 End-to-End 420 The global availability of end-to-end communication is one of the 421 benefits of IPv6, and provides the required framework for further 422 innovation, where technologies like P2P and GRID, among others, can 423 be widely spread with no problems in a seamless way. However, 424 end-to-end communication also means that every host should be 425 reachable from any other host, including the ones from "outside". It 426 can lead to an increase in the possibility of being attacked, such as 427 cracking, DoS, etc. 429 In the network-based security model, these threats are normally 430 solved by disabling every end-to-end communications between inside 431 and outside, but this is not a solution for those who want to use 432 end-to-end communications. 434 Some possible solutions to cracking are outlined in [3], one of them 435 being a host firewall. 437 Several researches are ongoing regarding DoS prevention, and some of 438 these solutions need to be adopted to provide security for such 439 end-to-end communications. 441 3.2 IPsec-encrypted ESP-traffic in transport mode 443 As stated in [3], section 5, there is a problem with the IPv6 444 encrypted traffic (IPsec ESP mechanism in transport mode, for 445 example) and the network-based security model. 447 The idea is that a host inside the network can establish an encrypted 448 communication channel with other host outside of the network. A 449 middlebox (for example the perimeter firewall) won't be able to 450 inspect the contents of such a communication. 452 In [3] some possible solutions are outlined, one of them being a host 453 firewall. 455 3.3 Mobility 457 In parallel to the increase in the number of devices, IPv6 458 facilitates that those devices are "mobile", that is, can easily move 459 from one network to another using Mobile IPv6 or just disconnecting 460 from one and connecting to another. 462 Because of the amount of addresses available and the facilities given 463 by Autoconfiguration mechanisms together with the mentioned rise of 464 the number of IP devices, this kind of behavior should be taken into 465 account by the security administrator, as these devices will be 466 connected to networks where they have no control and consequently, no 467 responsibility. 469 A possible solution for these devices is the use of host based 470 security, enabled in every network it is connected. The policies and 471 mechanisms should be described elsewhere. 473 3.4 Addresses 475 Regarding the addresses in IPv6 must be taken into account that: 477 o The amount of addresses is much bigger for a given network. 479 o Each host will have more than one address which are probably 480 globally routable. 482 o An IPv6 node can use randomly generated addresses [4]. 484 o The IPv6 addresses are more human error prone that the IPv4 ones. 486 That means: 488 o To scan a given network whole range of addresses and ports will 489 take a really big effort [5]. It would be easier to do that by 490 sniffing a LAN segment looking for existent addresses. 492 o The common way of identifying a host by means of its IP address 493 will be more difficult to use. 495 o If a host uses randomly generated addresses [4], it could be 496 problematic to identify a host using its IP address for security 497 policy matching purposes. 499 o The Security Administrator should be careful when establishing, 500 for example, an ACL (Access Control List) as the common practice 501 is to use raw IP addresses (instead of DNS names). Some mechanism 502 would be desirable to prevent these mistakes. 504 Regarding the scan of addresses, [5] demonstrates that the "brute 505 force" scanning would make no sense for an IPv6 address range, 506 typically a minimum of /64. 508 A host based security scheme would protect the other hosts from the 509 compromised one. 511 The idea behind all this is that the new IPv6 address scheme and 512 mechanisms will somehow protect from existent attack techniques but 513 we can be sure that they will adapt themselves to the new scheme and 514 we have to act consequently being prepared. 516 The IPv6 addressing scheme eases the work of identifying a user host, 517 becoming a privacy threat. There are two IPv6 features to be 518 considered, the host identifier created from the MAC address by the 519 address autoconfiguration and the user network prefix. 521 The first one could be used to identify a user independently of the 522 network to which it is attached. As a solution the randomly 523 generated addresses were defined. 525 The second one refers to the fact that every user will receive at 526 least a /64 prefix and so all the hosts coming from one user network 527 could be identified by the network prefix. In IPv4 it is common to 528 use a temporary address assignment scheme for the home user, 529 resulting in changes of its assigned address. 531 3.4.1 Link-local addresses 533 In IPv6 we have got the link-local addresses that allows a host that 534 connects to a network to have IP connectivity without any external 535 help. 537 Even if this is quite useful, also represents a security problem 538 because allows a host to attack the network it is connected to. This 539 must be taken into account by the security administrator. 541 As a guideline, we should not simply rely on trusting by default 542 those sessions which are from link local addresses. It is better to 543 restrict to use link local address to some fundamental services, 544 until the host is trusted. 546 3.4.2 New Multicast addresses 548 In IPv6 new multicast addresses are defined than identifies resources 549 in a well known manner. This can enable an enemy to locate and 550 attack those key resources with no need of a time consuming address 551 search. 553 This kind of addresses have an scope field. This means that many of 554 such services would have either link-local scope. Note that these 555 addresses are used for the protocol itself, for example in the 556 autoconfiguration process. This kind of addresses must be taken into 557 account by a security solution that addresses inside attacks. 559 There are also global-scope addresses that must be published to the 560 outside. This kind of services must be protected and monitored by a 561 security solution that addresses outside attacks. 563 For an updated IPv6 multicast addresses list see [6]. 565 3.5 Multihoming 567 As said above the IPv6 capable interface could have more than one 568 IPv6 global address. This will be the case in multihomed networks, 569 where more than one network prefix could be used to have access to 570 the IPv6 world. 572 If the security policy is based on rules which use IP addresses as an 573 identifier, it must be taken into account that a single host could be 574 behind different addresses with different prefixes. 576 Also the case of a host with more than one interface, each one with 577 one or more different addresses should be taken into account. If 578 more than one interface is using the network infrastructure with 579 different addresses, the Security Administrator should be able to 580 identify that the same host is behind all these addresses. 582 3.6 Randomly Generated Addresses 584 Whatever security model is being used, in case of using randomly 585 generated addresses, the host identifier part is randomly generated 586 by the host to be used temporarily [4]. 588 The consequence is that it will be harder for a security 589 administrator to define a policy rule (access rule) in the security 590 enforcement point to identify end nodes in all cases. For example a 591 node could generate a DoS attack generating a lot of traffic using a 592 random source address. The security administrator could not just 593 block the host's network prefix because there could be other valid 594 hosts within that network. Even in the case of a detection 595 mechanism, the attacking node could change its random source address. 597 So the Security Administrator should take into account the randomly 598 generated addresses when receiving incoming packets from outside of 599 its security domain. Its decision could be for example to allow 600 access to public services, like web servers, but not to allow or put 601 special attention to connections to end nodes inside its network. To 602 put special attention could be for example, to inspect packets up to 603 application level or to dedicate more IDS resources. 605 3.7 Neighbor Discovery Weakness 607 As said above, one of the assumptions of the host-based security 608 model is that all hosts in the network are non trusted, the possible 609 threats coming from the same LAN segment must be taken into account, 610 in this case the ones coming from Neighbor Discovery (ND) [7][8]. 612 Note that this is not possible within the network-based security 613 model, although some detection mechanism could be implemented, 614 nothing can be done to protect the hosts. 616 There are some ways to interfere in the normal behavior of the 617 autoconfiguration process, causing redirection of traffic and/or DoS 618 (Denial of Service). 620 Special attention must be put on Router Advertisement (RA), Router 621 Solicitation (RS), Neighbor Solicitation (NS), Neighbor Advertisement 622 (NA) and Redirect messages. See [9] for a detailed explanation of 623 possible threats. 625 Using host firewalls and/or IDS (Intrusion Detection Systems) for 626 protecting hosts against these threats is very likely a wrong 627 approach, as that would basically imply reinventing SEND [10][11]; it 628 is better to use SEND instead. 630 There is no easy protection against these threats as the ND features 631 (e.g., using link-local or the unspecified addresses) are needed 632 before a host can authorize itself to the other network components. 634 3.8 Routing Header 636 IPv6 protocol defines some extension headers, among them is the 637 Routing Header [12]. All IPv6 endpoints are required to process this 638 header resulting in the forwarding of the IPv6 packet. 640 Using the routing header a list of one or more nodes through which 641 the packet must pass, in its path from source to destination, is 642 created. Basically what happens is that the destination address is 643 changed in each host where the routing header is processed. This 644 mechanism, for example, could be used to reach hosts beyond 645 network-based security mechanisms. 647 The security administrator should establish, in the Security Policy, 648 which hosts, if any, are allowed to forward IPv6 packets with routing 649 header. The security solution must be able to assure that this 650 policy is accomplished by all the hosts under its control. This can 651 be achieved, for example, by disabling IP stack processing of routing 652 headers or by filtering packets with routing headers in each host. 654 The routing header is used in Mobile IPv6. If this functionality is 655 allowed in the network the Security Administrator must take it into 656 account. For example, if administrators filter packets with 657 routing-header, but don't filter ICMPv6 packets regarding 658 Return-Routability, Mobile IPv6 will succeed in route-optimization 659 but can't make the communication because packets with routing-header 660 are rejected. Hence, Mobile IPv6 does not work at all in such 661 configuration. 663 3.9 Home Address Option 665 IPv6 protocol defines some extension headers, among them is the Home 666 Address [13]. All IPv6 endpoints should accept this header. 668 Basically what happens is that the source address of the packet is 669 changed by the Home Address option's address. It is used in a packet 670 sent by a mobile node while away from home, to inform the recipient 671 of the mobile node's home address. This could be used for spoofing. 673 Because this option was defined for Mobile IPv6 use, the security 674 administrator should reject the packet with home address option 675 unless Mobile IPv6 is allowed. 677 3.10 Embedded Devices 679 With the deployment of IPv6 we can expect the avenue of a big amount 680 of new IPv6-enabled devices with few resources, low computing 681 capacity, even low battery capacity. In some cases, this kind of 682 devices will not be able even to perform the minimum set of functions 683 required by the Host-based Security Model. 685 It also should be taken into account that the convergence of both the 686 IPsec capability of every IPv6 stack and the avenue of small devices 687 with few CPU resources could be used for DoS attacks. 689 This should be taken into account when the security requirements are 690 outlined and by the proposed solutions. 692 4. Other Issues 694 Further elaboration is required (TBD) on: 696 o Malicious users: We can't protect the network from malicious users 697 that have physical access to network hosts in the protected 698 network. The objective is to minimize the danger they can cause. 700 o In the host-based security, the host that stores and distributes 701 the security policies seems to be the best option to be the one 702 that acts as IDS information collector. 704 5. Security Considerations 706 This document is concerned entirely with security. 708 6. Acknowledgements 710 The authors would like to acknowledge the inputs of Brian Carpenter, 711 Satoshi Kondo, Shinsuke Suzuki, Peter Bieringer and the European 712 Commission support in the co-funding of the Euro6IX project, where 713 this work is being developed. 715 7. References 717 7.1 Normative References 719 7.2 Informative References 721 [1] "IETF midcom WG", 722 . 724 [2] Bellovin, S., "Distributed Firewalls", November 1999, 725 . 727 [3] Savola, P., "Firewalling Considerations for IPv6", 728 Internet-Draft draft-savola-v6ops-firewalling-02, October 2003. 730 [4] Narten, T. and R. Draves, "Privacy Extensions for Stateless 731 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 733 [5] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", 734 Internet-Draft draft-chown-v6ops-port-scanning-implications-01, 735 July 2004. 737 [6] "IANA's IPv6 Multicast Addresses List", 738 . 740 [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 741 for IP Version 6 (IPv6)", RFC 2461, December 1998. 743 [8] Thomson, S. and T. Narten, "IPv6 Stateless Address 744 Autoconfiguration", RFC 2462, December 1998. 746 [9] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 747 "Dynamic Authorization Extensions to Remote Authentication Dial 748 In User Service (RADIUS)", RFC 3576, July 2003. 750 [10] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 751 "SEcure Neighbor Discovery (SEND)", 752 Internet-Draft draft-ietf-send-ndopt-06, July 2004. 754 [11] Aura, T., "Cryptographically Generated Addresses (CGA)", 755 Internet-Draft draft-ietf-send-cga-06, April 2004. 757 [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 758 Specification", RFC 2460, December 1998. 760 [13] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 761 IPv6", RFC 3775, June 2004. 763 Authors' Addresses 765 Alvaro Vives Martinez 766 Consulintel 767 San Jose Artesano, 1 768 Alcobendas - Madrid 769 E-28108 - Spain 771 Phone: +34 91 151 81 99 772 Fax: +34 91 151 81 98 773 Email: alvaro.vives@consulintel.es 775 Jordi Palet Martinez 776 Consulintel 777 San Jose Artesano, 1 778 Alcobendas - Madrid 779 E-28108 - Spain 781 Phone: +34 91 151 81 99 782 Fax: +34 91 151 81 98 783 Email: jordi.palet@consulintel.es 785 Pekka Savola 786 CSC/FUNET 787 Espoo 788 Finland 790 Email: psavola@funet.fi 792 Intellectual Property Statement 794 The IETF takes no position regarding the validity or scope of any 795 Intellectual Property Rights or other rights that might be claimed to 796 pertain to the implementation or use of the technology described in 797 this document or the extent to which any license under such rights 798 might or might not be available; nor does it represent that it has 799 made any independent effort to identify any such rights. Information 800 on the procedures with respect to rights in RFC documents can be 801 found in BCP 78 and BCP 79. 803 Copies of IPR disclosures made to the IETF Secretariat and any 804 assurances of licenses to be made available, or the result of an 805 attempt made to obtain a general license or permission for the use of 806 such proprietary rights by implementers or users of this 807 specification can be obtained from the IETF on-line IPR repository at 808 http://www.ietf.org/ipr. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights that may cover technology that may be required to implement 813 this standard. Please address the information to the IETF at 814 ietf-ipr@ietf.org. 816 Disclaimer of Validity 818 This document and the information contained herein are provided on an 819 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 820 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 821 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 822 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 823 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 824 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 826 Copyright Statement 828 Copyright (C) The Internet Society (2005). This document is subject 829 to the rights, licenses and restrictions contained in BCP 78, and 830 except as set forth therein, the authors retain all their rights. 832 Acknowledgment 834 Funding for the RFC Editor function is currently provided by the 835 Internet Society.