idnits 2.17.1 draft-oneill-mipv6-cao-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 1) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 473 instances of too long lines in the document, the longest one being 192 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 576 has weird spacing: '...mply as a res...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Now the option type for the CAO, given the above, is also '110' so that the option will be discarded by a Defined processor of the option, if that node does not understand the option. At an option enforcement point, the option processing will also discard the packet by default if the CAO is not understood. The discarder, whether a Defined processor of the option, or an OEP, must generate an ICMP message back to the sender in the case of a unicast packet, including the CAO and the reason for the discard, so that the sender can distinguish between a node that does not support the CAO, and a node that has explicitly discarded the packet due to a range of CAO errors such as 'topologically incorrect (ingress filtering)' or incorrect binding (in a HA). The option MUST not be modified by a Defined option processor, but an enforcing processor such as an option enforcement point MAY modify the CAO if it fully understands the CAO semantics. -- 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 (19 Sept 2002) is 8156 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MIP-Multicast' is mentioned on line 101, but not defined -- Looks like a reference, but probably isn't: '11' on line 680 == Unused Reference: 'RFC2026' is defined on line 829, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (ref. 'MIPv4') (Obsoleted by RFC 5944) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-18 -- Possible downref: Normative reference to a draft: ref. 'MIP-multicast' Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Personal A. O'Neill 2 Internet Draft Flarion Technologies 3 Document: draft-oneill-mipv6-cao-00.txt 19 Sept 2002 4 Expires: Mar 2003 6 MIPv6 Care of Address Option 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 30 Copyright (C) The Internet Society (2002). All Rights Reserved. 32 Abstract 34 IPv6 and MIPv6 has constrained the HoA to being used within forward 35 and reverse tunnels via the HA. In the unicast case, the MN can then activate 36 Route Optimisation to bypass the HA in both directions by securely installing 37 a Binding Cache Entry into the CN. The MN then sends from the CCoA source 38 address to the CN directly into the foreign multicast system, and includes 39 the Home Address Option (HAO) so that the changing CCoA is masked from the 40 transport layer. 42 This draft defines the Care of Address Option, which carries the current CCoA 43 of the MN. The CAO can be included in a Hop By Hop Header or Destination 44 header and used instead of the packet source address for unicast ingress 45 filtering and multicast RPF purposes. This enables a MN to potentially use 46 the HoA as a source address on the foreign network, and to inform the CNs of 47 the evolving MN location. 49 INDEX 50 Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 52 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . . . . 3 56 3. Terminology used in this document . . . . . . . . . . . . . . . . . 3 58 4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. The Ingress Filtering problem . . . . . . . . . . . . . . . . 4 60 4.2. The Mobile Source Tracking problem . . . . . . . . . . . . . . 5 62 5. High-Level processing Rules for the CAO . . . . . . . . . . . . . . 5 63 5.1. Option Enforcement Points and Ingress Filtering. . . . . . . . 5 64 5.2. Existing MIPv6 Processing Rules for the HoA Source Address . . 7 65 5.3. Modified Processing Rules for the Foreign Network. . . . . . . 9 66 5.4. MN Location Exchange . . . . . . . . . . . . . . . . . . . . . 9 67 5.5. CAO Specific Processing Rules at the CN. . . . . . . . . . . . 11 69 6. Format and Usage Rules for the Care of Address Option . . . . . . . 13 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 15 73 8. Notice Regarding Intellectual Property Rights . . . . . . . . . . . 16 75 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 Mobile IP for IPv4 enables the MN to use its HoA as a source address on the 82 foreign subnet when forwarding to the CN either directly or via the HA using 83 reverse tunnelling. The native forwarding follows the optimal route to the CN 84 but incurs the risk of being discarded by ingress filtering routers due to 85 the topologically incorrect source address. IPv6 and MIPv6 have therefore 86 constrained the HoA to being used as a source address when either at home or 87 within a reverse tunnel from a foreign subnet via the HA of the MN. The CN 88 then returns packets to the MN HoA, via the HA, and the forward HA to MN 89 tunnel based on the CCoA in the HA binding for the MN. In the unicast case, 90 the MN can then activate Route Optimisation to bypass the HA in both 91 directions by securely installing a Binding Cache Entry into the CN. The MN 92 then sends from the CCoA source address to the CN directly via the foreign 93 unicast or multicast system, and includes the Home Address Option (HAO) in 94 the unicast packets so that the changing CCoA is masked from the transport 95 layer. The CN sends directly to the MN using a routing header. In the 96 multicast case, the persistent HoA cannot be used as a multicast source 97 address because such packets will fail the multicast reverse path forwarding 98 check. The MN must instead use its CCoA on the foreign network as its source 99 address, and a new multicast tree must be built for each new CCoA on each MN 100 hand-off to ensure that the multicast source address is topologically 101 correct. These multicast issues are discussed in detail in [MIP-Multicast]. 103 This draft defines the Care of Address Option, which carries the current 104 location of the MN in the form of the CCoA or the HoA, within either a Hop By 105 Hop or a Destination Header. The Hop By Hop or Destination header based CAO 106 can be used to both redirect ingress filtering / multicast RPF checks so that 107 the MN can use its HoA as a source address from the foreign network directly 108 with the CN. The Destination Header based CAO can in addition be used to 109 inform the CN of the location of the MN when either reverse tunnelling to the 110 HA or on the home network, and hence when ingress filtering checks would 111 already succeed. They also inform the CN of the current location of the MN. 112 This information is stored by the CN in an Inverse Binding Cache Entry, which 113 may be used by high-layer mobility aware processes, and may also be used to 114 improve Route Optimisation procedures. 116 The CN can reflect a CAO back to the MN in a Destination header either 117 directly or via the HA using a routing header, to close the verification loop 118 so that the MN can be reasonably confident that the CN knows the desired 119 binding between the MN HoA and the MN CCoA. 121 The CAO, whilst primarily designed for unicast communications, may also be 122 used to enable the HoA to be used as a multicast source address on a foreign 123 subnet to pass multicast RPF checks, and address the efficiency limitations 124 of MIPv6 multicast. The multicast details of this are not covered in this 125 draft but are described at a high-level in [MIP-multicast]. 127 2. Conventions used in this document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 130 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 131 be interpreted as described in RFC-2119 [RFC2119]. 133 3. Terminology used in this document 135 Much of the terminology used in this document borrows from Mobile IPv4 136 [MIPv4] and [MIPv6] specifications and drafts. This draft introduces and uses 137 the following additional terminology. 139 Care of Address Option (CAO) - an option included in an IPv6 Hop by Hop or 140 Destination Header that is used to redirect source address checks to the CCoA 141 rather than the source address (HoA) of the packet and to indicate to the CN 142 the present location of the MN. The CAO may also be reflected back to the MN 143 in a Destination Header to verify the contents of the triggering CAO that was 144 received at the CN. 146 Inverse Binding Cache Entry - an optional entry in a table at the CN that has 147 the mapping between the MN HoA and its evolving location as well as details 148 of how and when the CAO was received, and if, how and when the CAO was 149 verified. As a result, any IBCE explicitly includes a measure of confidence 150 in the entry for each MN and implied or explicitly stated constraints on its 151 use by the CN. 153 Option Enforcement Point (OEP) - a node that inspects options within 154 extension headers when the header type would not otherwise have caused 155 this node to process the options, such as with a firewall. A node that is 156 defined by the header type as able to process the option is a Defined node. 158 4. Motivation 160 4.1. The Ingress Filtering Problem 162 MIPv4 MNs can use the HoA as a source address for unicast packets from the 163 foreign subnet without using a reverse tunnel to the HA. In the case of a FA, 164 the MIP binding information between the HoA and the CoA is known and trusted, 165 and therefore the Access Router containing the FA can enable the 166 topologically incorrect source address to be forwarded safely. However, this 167 still risks the packet being discarded by ingress filtering in internal nodes 168 that are not aware of the secure MIP binding information between the HoA and 169 the CoA. 171 In MIPv6, the use of the HoA as a unicast source address when sending direct 172 to the CN is prevented and the MN must instead only use the HoA when reverse 173 tunnelling packets to the CN via the HA. Route Optimisation can then be used 174 to securely install a Binding Cache Entry (BCE) in the CN so that the CN and 175 MN can then directly communicate using the CCoA of the MN as a network 176 address. The Home Address Destination Option and the Type 2 Routing Header is 177 then used to enable the network layer to forward packets whilst maintaining 178 the HoA as the transport layer view of the MN address. Unfortunately, Route 179 Optimisation has significant security issues and places a significant burden 180 on the MN during hand-off. For this reason it is likely to be inappropriate 181 in many circumstances and a lightweight method of optimising one leg of the 182 path might therefore be useful. 184 One potential mechanism is to use the MN HoA as a source address on a foreign 185 network, but add the CCoA of the MN into the CAO within a Hop By Hop Header, 186 to affect all routers that wish to undertake ingress filtering. All such 187 routers must first check for the existence of the CAO. Its presence 188 informs the router that the ingress filtering should be performed on the 189 address in the CAO option rather than on the packet source address. In 190 addition, the MN must only issue such packets from the network on which the 191 CCoA is valid. All IPv6 Access Routers MUST implement ingress filtering on 192 the source address but MAY, along with any other IPv6 router, be enhanced to 193 support redirected ingress filtering checks on the CAO in the Hop By Hop 194 header. Routers implementing CAO based ingress filtering MUST check the 195 validity of the address in the CAO within the Hop By Hop Header and 196 discard any packet with an incorrect Option value. In the absence of the CAO 197 in the Hop By Hop Header, the ingress filtering is performed on the 198 packet source address. An incorrect CAO / source address is an IPv6 unicast 199 address that is received on the wrong interface according to unicast routing. 201 An alternative mechanism is to once again use the MN HoA as a source address 202 but this time include the CAO within a Destination Header. This requires that 203 unicast ingress filtering and multicast RPF checks in routers need to occur 204 independently of the IPv6 header processing rules. This is reasonable given 205 that a MN cannot be trusted to request its own packets to be policed and 206 therefore offers a potentially lightweight alternative to the Hop By Hop 207 Header. 209 An ingress access router that supports a redirected ingress filtering check, 210 using the CAO, SHOULD advertise this capability in its router advertisement. 211 This is so that a MN can avoid trying to send packets directly from a 212 foreign network that does not support the CAO. A MN SHOULD NOT include a CAO 213 unless this capability has been advertised. In addition, an access router MAY 214 indicate if the whole visited domain supports the CAO option throughout that 215 domain so that the MN can aggressively use the CAO at each new access router 216 in an operator's domain during hand-off. 218 4.2. The Mobile Source Tracking Problem 220 A MN that uses its HoA as a source address might also wish to inform 221 appropriate CNs of its current CCoA, and of CCoA changes, for a range of 222 reasons. This is true whether the MN is at home, sending natively from a 223 foreign network or reverse-tunnelling from that foreign network to its home 224 network. The CN can then maintain an Inverse Binding Cache Entry for the MN 225 that tracks its movement and address details of its locations. The IBCE can 226 be built in multiple ways and with different levels of confidence in the 227 binding information. 229 Applications can then have an API with the IBCE and hence subscribe to 230 mobility events or to CCoA specific information. For example, the presence of 231 an unchanging CAO provides the CN with a very good reason to support RO with 232 this MN due to the likely low rate of binding updates from such a slow moving 233 / stationary MN. In addition, being optionally informed of the new CCoA by 234 the MN enables the CNs to automatically track the movement of the MN through 235 the topology. Applications might also wish to delay sending new packets for a 236 short time whilst the MN is undertaking a hand-off, or receivers might wish 237 to perform less aggressive buffer management for real-time applications. 238 Sessions with specific MNs might also be scoped such that service would only 239 be provided to MNs when either at home, or when they are at CCoAs under 240 specific prefixes such as the home or local domain. This draft does not 241 motivate the new mechanisms on the above specific examples but instead is 242 using them simply to indicate the potential usefulness of the API to the 243 location information. 245 5. High-level Processing Rules for the CAO 247 5.1. Option Enforcement Points and Ingress Filtering 249 IPv6 header processing rules state that the header options within an 250 extension header are processed by nodes according to 'defined' rules of that 251 header. So Hop By Hop Header options, for example, are processed by all hops. 252 In addition, header processing rules state that such processing nodes must 253 process the options according to the three most significant bits of the 254 option type, where for example, code 110 means that the packet should be 255 dropped if the option is unrecognised and the option cannot be modified on 256 route. 258 Clearly though a router that wishes to police the contents of packets, for 259 policy and firewall reasons, cannot rely on a MN creating packets with 260 suitable header types that will enable the enforcement point to check out all 261 the options in a defined manner according to the extension header processing 262 rules. For an arbitrary enforcement point to be fully capable of correctly 263 checking extension header options, every packet from every node would need to 264 carry all options within a Hop By Hop header, with the option type code at 265 '111'. This would naturally result in an arbitrarily located option 266 enforcement point discarding packets with options that it did not understand, 267 and whose threats it cannot assess, as well as modifying options it did not 268 like. This however is clearly not practical as it removes much of the 269 functionality of option processing. 271 Therefore an arbitrary option enforcement point must be able to 272 examine packet options both by ignoring extension header processing rules 273 that would normally prevent it from examining all options, as well as 274 ignoring the option type code and instead treating all options as '110' by 275 default. The likely exception is for end to end options that are within a 276 Destination Header, and either below any routing header that itself is not 277 end to end (ie type 2 ok), or absent a routing header. Only if the option 278 enforcement point fully understands the option will it likely apply 279 additional enforcement processing, including rewriting the option value (as 280 if option code 'XX1') and recalculating the CRC to match. This draft neither 281 requests nor recommends such behaviour by a general OEP on behalf of the CAO, 282 whose requirements are instead detailed below. 284 Now the option type for the CAO, given the above, is also '110' so that the 285 option will be discarded by a Defined processor of the option, if that node 286 does not understand the option. At an option enforcement point, the 287 option processing will also discard the packet by default if the CAO is not 288 understood. The discarder, whether a Defined processor of the option, or an 289 OEP, must generate an ICMP message back to the sender in the case of a 290 unicast packet, including the CAO and the reason for the discard, so that the 291 sender can distinguish between a node that does not support the CAO, and a 292 node that has explicitly discarded the packet due to a range of CAO errors 293 such as 'topologically incorrect (ingress filtering)' or incorrect binding 294 (in a HA). The option MUST not be modified by a Defined option processor, but 295 an enforcing processor such as an option enforcement point MAY modify the CAO 296 if it fully understands the CAO semantics. 298 The following is then the expected behaviour through nodes such as access 299 routers and other general OEPs; 301 If a legacy node is neither CAO-aware nor a Defined option processor, then 302 it will pass the CAO unless it is an Option Enforcement Point in which 303 case the packet will be dropped. 305 If the legacy node is a Defined option processor but is not CAO-aware then 306 it will drop the packet as a result of normal CAO processing rules. 308 If the router is CAO-aware but not a Defined option processor, then it is 309 an option enforcement point that may undertake CAO-aware ingress 310 filtering. If it does so, then the packet will be passed or dropped based 311 on the topological correctness of the CAO contents. Other option 312 enforcement rules might also be applied to the CAO to decide on the 313 packets fate including passing it if the legacy ingress filtering process 314 succeeds on the packet source address. Given that the CAO is only used to 315 bypass the ingress filtering check, passing a packet on this check should 316 be safe for any OEP. 318 If the router is CAO-aware and a Defined option processor then the node 319 can also support CAO-based ingress filtering. The packet will then be 320 discarded on the topological correctness of the CAO and other such rules 321 in this draft, and the option will not be modified by the node as 322 indicated by the option type. 324 If any node is a legacy ingress filtering node, which means it does not 325 support CAO-aware ingress filtering, then the arriving packet might also 326 be dropped or passed as a result of an incorrect source address. 328 The use of the CAO within a Destination Header is preferred to its use within 329 a Hop By Hop Header because the latter will require all nodes on the path to 330 be CAO aware for the packet to be correctly forwarded. In contrast, the use 331 of the Destination Header requires only the 'Destinations' to be CAO-aware, 332 along with any Option Enforcement Points on the path. Henceforth, this draft 333 will only discuss the CAO in the Destination Header but in all cases the Hop 334 By Hop Header can also be used. The Destination Header may be utilised above 335 or below the Routing Header. When above the routing header it will be 336 inspected by all destinations visited according to the routing header. When 337 below the Router header and optionally below an ESP header, only the ultimate 338 destination will process the CAO in the Destination Header. The appropriate 339 choice by the MN is to by default place the CAO within a Destination Header 340 above any routing header and ESP header. Specific situations do exist however 341 when the CAO can be safely encrypted. If the Destination Header is below any 342 ESP header then only the MN can verify that the CAO is correct and the 343 existence of the ESP header ensures the CAO has not been modified on route. 345 It is a minimum expectation of this draft that all IPv6 access routers 346 undertake ingress filtering on the packet source address and will discard 347 topologically incorrect source addresses. It is recommended by this draft 348 that all IPv6 access routers support CAO based ingress filtering. It is 349 required by this draft that all such access routers indicate their support 350 for CAO in their Router Advertisements, to avoid a MN attempting that which 351 is unavailable and as a result risking packet discard. It is recommended by 352 this draft that the Router Advertisement indicate whether or not the 353 operators domain supports CAO processing so that the MN can aggressively use 354 the MN HoA as a source address. It is also required by this draft that a HA 355 advertise its capability to support CAO processing to the MN through Router 356 Advertisements on the home network, and through suitable advisory and error 357 messages during MIP signalling. The details of these messages are for further 358 study. 360 5.2. Existing MIPv6 Processing Rules for the HoA Source Address 362 The following nomenclature is used to describe the supporting figures in this 363 draft when describing the use of the CAO. 365 MN - Mobile Node 366 CN - Correspondent Node 367 HA - Home Agent 368 HoA - Home Address from HA 369 CCoA - Co-located Care of Address from foreign network 370 HAR - Home Access Router (default router on the home network) 371 FAR - Foreign Access Router (default router on the foreign network) 372 OEP - A general Option Enforcement Point that passes CAO packets. 373 R - A general core router on the path of the packet.. 375 ^ - the destination node according to the current destination address 376 > - a node traversed by that packet 377 [ - an encapsulating node 378 ] - a decapsulating node 379 I - a node that undertakes a legacy ingress filtering check on source 380 address. 381 E - an option enforcement point that supports enhanced CAO-based ingress 382 filtering. 383 H - a Defined node that supports enhanced CAO-based ingress filtering 384 X - a node that discards a packet due to an incorrect source address 385 S - an option enforcement point that snoops and passes the CAO unaffected. 387 Figure 1 shows a schematic of the possible forwarding paths between the MN 388 and the CN, when the MN is on its home or a foreign network, and the MN uses 389 its HoA as a source address. The FAR, HAR and HA are at least option 390 enforcement points but may also be Defined option processors. The FAR and HAR 391 are CAO aware ingress filtering nodes. 393 ____ _____ ___ ____ _____ ___ ____ 394 | | | | | | | | | | | | | | 395 | MN | | FAR | | R | | HA | | HAR | | R | | CN | 396 |____| |_____| |___| |____| |_____| |___| |____| 398 A -------------------------------------------------->I--------->--------->^ 399 B ------------------>IX 400 C [=================>I==========>=========>]H------->I--------->--------->^ 402 Figure 1: Existing processing Rules 404 In flow A, the HAR examines the packet source address and because it is valid 405 will be forwarded to the CN. 407 In flow B, the FAR examines the packet source address and because it is 408 invalid on the foreign network (not from a prefix on the FAR) then the packet 409 will be dropped. 411 In flow C, the MN is reverse tunnelling so the MN will encapsulate in the 412 CCoA which will pass source address ingress filtering examination in the FAR. 413 The HA decapsulates, checks the CCoA source address against the registered 414 binding, and forwards the successful packet to the CN. The HAR examines the 415 packet source address which again passes because it is the MN HoA. 417 5.3. Modified Processing Rules for the Foreign Network 419 In figure 2 we examine the basic changes brought about by this draft. 421 ____ _____ ___ ____ _____ ___ ____ 422 | | | | | | | | | | | | | | 423 | MN | | FAR | |OEP| | HA | | HAR | | R | | CN | 424 |____| |_____| |___| |____| |_____| |___| |____| 426 B' ------------------>E--------->E------------------------------>--------->^ 428 Figure 2: Modified processing Rules from the Foreign Network. 430 In case B', the MN is again on the foreign network but this time uses the 431 Destination Header to carry the CAO containing the MN CCoA. This means that 432 only a router on the path that chooses to enforce options (as an OEP) can 433 undertake CAO based ingress filtering. Any such router, that does not 434 understand the CAO, will drop the packet by default, but may pass the packet 435 if the CAO is topologically correct. Therefore, if all the Option Enforcement 436 Points between the MN and the CN are all CAO aware then this will ensure that 437 the MN can send directly to the CN and avoid reverse tunnelling to the HA. 438 The FAR MUST advertise its support for the CAO enhanced ingress filtering in 439 the Router Advertisement and the MN should only use the HoA source address 440 directly with the CN if this advertisement is received. 442 5.4. MN Location Exchange 444 Figure 3 illustrates the different forms of communication that a MN can now 445 undertake as a result of this draft, and illustrates how the MN can in 446 addition provide the CN with its location. The MN needs to set a flag, the 447 filter flag (F), in the CAO to indicate whether or not the CAO or the source 448 address is to be used for ingress filtering. If the filter flag is set then 449 the ingress filtering is on the contents of the CAO whilst if it is not set 450 then the ingress filtering is on the source address. The diagram also 451 includes the cases when the MN tries to lie about its location to illustrate 452 the level of confidence that the CN can place in the contents of the CAO. 454 Note that the CAO need only contain a topologically correct address. A MN can 455 choose to set the P bit in the CAO, include only the access router prefix 456 (most significant 64 bits) and hide the MNs current EUI-64. This is useful if 457 the MN HoA does not itself include that EUI-64, the MN therefore wishes to 458 hide its terminal information from the CN, and/or the MN wishes to deny the 459 CN reachability to its CCoA, yet reveals its topological location and share 460 its movement history and mobility events with the CN. When the P bit is not 461 set, the CN is informed that the contained CCoA is a valid communications 462 address. The P bit setting must therefore be policed by the HA and access 463 routers whilst also policing the CCoA contents and the other CAO flags. The 464 MN may include the address of its default router whilst also setting the P 465 Bit whereas if just the prefix is included then the lower 64 bits are zeroed. 467 ____ _____ ___ ____ _____ ___ ____ 468 | | | | | | | | | | | | | | 469 | MN | | FAR | |OEP| | HA | | HAR | | R | | CN | 470 |____| |_____| |___| |____| |_____| |___| |____| 472 A ------------------------------------------------->E--------->I--------->^ 473 No CAO (packet delivered but location hidden) 474 CAO=HoA, F=0 (to support legacy ingress filtering nodes) 475 CAO=HoA, F=1 (will pass CAO aware OEPs) 476 CAO=fake, F=0 (not allowed by HAR) 477 CAO=fake, F=1 (will be dropped during CAO checks in any node) 479 B' ------------------>E--------->E----------------------------->I--------->^ 480 No CAO (packet dropped at FAR due to incorrect source address) 481 CAO=CCoA, F=1 (to preserve the topologically incorrect source address) 482 CAO=fake, F=1 (a false location causes the packet to be dropped) 483 CAO=fake, F=0 (not allowed by FAR) 485 C [=================>I==========>=========>]H------->E-------->I--------->^ 486 No CAO (packet delivered but location hidden) 487 CAO=CCoA, F=0 (to avoid discard due to the topologically incorrect CAO) 488 CA0=CCoA, F=1 (will be discarded during CAO checks in any node) 489 CAO=HoA, F=0/1 (not allowed by HA) 490 CAO=fake, F=0 (not allowed by HA) 491 CAO=fake, F=1 (not allowed by HA & dropped during CAO checks in any node) 493 Figure 3: MN location exchange 495 In case A, the MN is at home and can optionally put a CAO into a Destination 496 Header containing the HoA of the MN. The filter flag is best set to F=0 but 497 MAY be F=1. The HAR MUST be able to check and recognise either a source 498 address or a CAO that contains an address that is not from the home network. 500 In case B', similar processing rules apply except that the omission of the 501 CAO is no longer possible and hence the CN always learns the CCoA and the 502 EUI-64 of the MN. The FAR must be able to check and recognise a CAO that 503 contains an address that is not from the foreign network. 505 In case C, the MN is reverse tunnelling and the HA is used to assist the HAR 506 in being able to distinguish between a packet from a foreign MN that can have 507 a CAO=(CCoA=foreign, F=0) and a home MN that cannot (i.e. MN is lying about 508 its location). The HAR can distinguish between packets from a MN and those 509 from the HA due to the link-layer addresses and the RA from the HA. However, 510 if this link-layer information is not considered sufficient for all cases, 511 then the MN MUST use a type 0 routing header containing the CN address and 512 set the inner packet destination address to that of the HA. The HA is then a 513 Defined processor of the CAO and after swapping the CN address into the 514 destination address, the HA address will remain in the RH which will be 515 received by the HAR. The HAR must be configured with, or learn securely the 516 HA addresses on the home network, so that packets checked by the HA can be 517 distinguished at L3, from those that have been sent directly by MNs or 518 indirectly via MNs pretending to be HAs. The HAR then discards packets where 519 the CAO=(CCoA=foreign, F=0) except if received via a trusted HA. 521 5.5 CAO Specific Processing Rules at the CN 523 The inclusion of a Care of Address option within either a Hop by Hop or a 524 Destination Header does not affect the destination node's processing of this 525 single packet but can create or modify state in the correspondent node in the 526 form of an Inverse Binding Cache Entry (IBCE). The CN MAY inspect the 527 evolving contents of the CAO and as a result MAY build an Inverse Binding 528 Cache Entry (IBCE). This IBCE can be used by the CN to track the location of 529 the MN in the topology if the MN so desires and for the networking stack and 530 high-layer processes to be aware of hand-off activity and MN location. 531 Specifically, the CAO can contain flags, that signal mobility events to the 532 CN such as the M flag (movement) when a hand-off is starting on the old CCoA. 533 However, the presence of a Care of Address option in a received packet MUST 534 NOT alter the contents of the receiver's Route Optimisation Binding Cache and 535 MUST NOT cause any changes in the routing of subsequent packets sent by this 536 receiving node without additional activity. 538 The contents of the CAO in an Hop By Hop option header has been fully 539 verified by the routing infrastructure as being topologically correct. The 540 contents of the CAO in a Destination header has been partially verified by 541 the routing infrastructure and fully verified by the home or foreign network. 542 In either case, this does not prevent a 'man in the middle' attacker within 543 the infrastructure or on the access link of the CN from modifying the 544 contents of the CAO and replacing it with a topologically correct CAO at that 545 location, which henceforth will still pass CAO based ingress filtering on 546 route to the CN. Additional security processes are therefore required for the 547 CN to fully trust the MN location for Route Optimisation purposes, which are 548 not the subject of this draft. In all other cases, the IBCE is simply used 549 for MN location tracking and provides little incentives for an attacker to go 550 to great expense just to affect the contents of the IBCE. 552 ____ _____ ___ ____ _____ ___ ____ 553 | | | | | | | | | | | | | | 554 | MN | | FAR | |OEP| | HA | | HAR | |OEP| | CN | 555 |____| |_____| |___| |____| |_____| |___| |____| 557 A ^------------------------------------------------S<----------S<---------- 559 B' ^-----------------S<---------S<---------H<-------S<----------S<---------- 561 C ^-----------------S<---------S<---------H<-------S<----------S<---------- 563 Figure 4: CAO reflection. 565 In the absence of an SA to authenticate or encrypt the CAO within a 566 Destination Header, the CN can acquire additional confidence in the contents 567 of the CAO through the reflection process (figure 4). The CN MAY reflect back 568 the contents of a received CAO to a MN, using a Destination Header, within 569 session response packets, or when those are not available, MIP signalling 570 packets. This reflection MUST be undertaken immediately on receipt of a 571 triggering CAO to avoid the contents of the CAO becoming stale, which would 572 result in a failed verification and a discarded response packet. The receipt 573 of a reflected CAO informs the MN that the CN is maintaining an IBCE for the 574 MN, as well as the current location of the MN contained in that IBCE at that 575 CN. The MN can therefore detect whether the CN has an incorrect location 576 created through an attack or simply as a result of a CN bug. The MN SHOULD 577 discard packets containing an incorrect CAO entry and return an ICMP message 578 back to the CN, reporting the failure of the CAO. The ICMP message MUST 579 include the erroneous CAO and the reason for the failure. The MN MAY 580 alternatively process the packet and send a new CAO to the CN immediately. 581 The CN may also use a reflected CAO entry of 'all 0' to autonomously request 582 a CAO update from the MN. The reflection process ensures that an attacker 583 must be on both paths to be able to modify both the inbound and the outbound 584 CAO. The Reflected CAO is also ameniable to end to end security, whilst the 585 use of the triggering CAO for ingress filtering and RPF redirection generally 586 prevents this. However, the CN may well prefer to have both the MN and its HA 587 verify the reflected CAO as Defined processors, which then requires the CN to 588 use a routing header and place the Destination Header above that routing 589 header. 591 The combination of a triggering CAO in an extension header followed 592 by a reflected CAO in a Destination Header, enacted periodically during a 593 session, gives the CN a high level of confidence that its IBCE does indeed 594 contain the current and evolving location of the MN. In both these cases, and 595 potentially in other cases, the IBCE may assist with subsequent installation 596 of Route Optimisation between the MN and the CN. A session in which the MN 597 and CN are periodically and mutually verifying the MN location (HoA/CoA 598 binding) may provide significant levels of confidence in advance of the Route 599 Optimisation procedure and in so doing potentially reduce the additional 600 message exchanges presently envisaged in the base MIPv6 spec. Essentially, 601 the CAO is a proactive binding tracking mechanism whilst the COT(I)/HOT(I) 602 sequence is a reactive mechanism enacted at the point of hand-off. 604 The IBCE contents might also be useful for identifying candidate sessions for 605 the installation of route optimisation because a MN with a stable or slow 606 moving location is preferable to one with high-mobility dynamics due to the 607 significant security and signalling load (bandwidth/latency costs) required 608 with RO each time the MN undertakes a hand-off. Finally, the movement 609 information of the MN in the IBCE can be used for policy and application 610 control of sessions that are affected by either location, roaming or mobility 611 events. 613 The specific additional security requirements necessary to complement the CAO 614 processing for its use in Route optimisation is not covered by this draft. 616 6. Format and Usage Rules for the Care of Address Option 618 The Care of Address option is encoded in type-length-value (TLV) format 619 as follows: 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Option Type | Option Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 |R F P T H M Reserved bits | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | | 629 + + 630 | | 631 + Care of Address + 632 | | 633 + + 634 | | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Option Type 638 TBA 639 Option Length 640 This field MUST be set to 16. 641 R bit 642 When unset this indicates that this is the CAO of the sender. 643 When set this indicates that this is the CAO of the receiver and the 644 CAO has been reflected. 645 F bit 646 When set it indicates that the ingress filtering MUST be undertaken 647 on the address in the CAO. 648 When unset it means that the ingress filtering MUST be conducted on 649 the packet source address. 650 P bit 651 When set, this indicates that the Care of Address field includes the 652 prefix of the MN only. 653 H bit 654 When set this indicates that the CAO will be verified by the MN HA 655 and may be used by a CN to indicate that the location may be fake. 656 M bit 657 When set this indicates that the MN is starting a hand-off from the 658 location address included in the CAO. 660 Care of Address 661 The present Care of Address (location) of the mobile node, which can be 662 either the MN CCoA or the HoA. It can be either the full address of the 663 location, the prefix of the access router or a fake address. 665 A CAO with the R bit unset can appear in either the Hop By Hop or 666 Destination Headers in a packet, but not both at the same time. Within the 667 same packet, a reflected CAO with the R bit set MAY also be included in a 668 Destination Header. A CAO with the R bit set SHOULD NOT appear in a Hop By 669 Hop Header. Therefore, the Care of Address Option with the same R bit 670 setting, MUST NOT appear twice in the same packet header. A CAO with the R 671 bit unset can appear at most N times within a N-fold encapsulated packet. A 672 CAO with the R bit set can also appear at most N times within a N-fold 673 encapsulated packet. 675 IPv6 requires that options appearing in a Hop-by-Hop Options 676 header or Destination Options header be aligned in a packet so that 677 multi-octet values within the Option Data field of each option fall 678 on natural boundaries (i.e., fields of width n octets are placed at 679 an integer multiple of n octets from the start of the header, for 680 n = 1, 2, 4, or 8) [11]. The alignment requirement [11] for the Care of 681 Address option is 8n+6. 683 The Care of Address Option MAY be included in a Hop by Hop Header when; 685 - the MN is at home, or at a foreign network and either sends directly to 686 the CN or reverse tunnels to the CN via its HA, and 687 - the MN uses its HoA as the source address 689 The Care of Address Option MAY be included in a Destination Header when; 691 - the MN is at home, or at a foreign network and either sends directly to 692 the CN or reverse tunnels to the CN via its HA, and 693 - the MN uses its HoA as the source address. 695 The Care of Address Option MAY be reflected in a Destination Header when; 697 - the CN has received a CAO from the MN, 698 - the CN has created an IBCE for the MN, and 699 - the CN is sending to that MN HoA either directly, or 700 - the CN is sending to that MN HoA via its HA. 702 Multicast addresses, link-local addresses, loopback addresses, IPv4 703 mapped addresses, and the unspecified address, MUST NOT be used 704 within a Care of Address option. 706 The Care of Address option in the Hop By Hop Header MUST be placed as 707 follows: 709 - Before the Destination Header, if that header is present 711 - Before the Routing Header, if that header is present 713 - Before the Fragment Header, if that header is present 715 - Before the AH Header or ESP Header, if either one of those 716 headers is present 718 The Care of Address option in the Destination Header SHOULD be placed as 719 follows: 721 - After any Hop By Hop Header 723 - Before the Routing Header, if that header is present 725 - Before the Fragment Header, if that header is present 727 - Before the ESP /AUTH Header, if this header is present 729 This enables the Routing Header to formally control which nodes, such as 730 the HA and MN, process the CAO in the Destination Header but means that 731 the CAO cannot be encrypted. The HA and any other OEP MAY also snoop the 732 CAO in unencrypted packets that pass through it as part of existing MIP 733 operations. 735 The Care of Address option in the Destination Header MAY be placed as 736 follows: 738 - After any Hop By Hop Header 740 - After the Routing Header, if that header is present 742 - After the Fragment Header, if that header is present 744 - After the ESP Header, if this header is present 746 This enables the CAO contents to be encrypted and ensures only the CN can 747 process the CAO. The appropriate rules for the AH header have not been 748 included merely for simplicity reasons but it is clear that ESP and the 749 Auth header can be used to authenticate the contents of the CAO and build 750 trust in the IBCE at the CN. 752 7. Security Considerations 754 The Care of Address Option provides an optional facility for the MN to send 755 directly to the CN yet still potentially pass ingress filtering, and /or to 756 inform the CNs of its topological movement. This draft does not specifically 757 recommend, nor suggest standardisation of, the usage of such information by 758 the CN network and higher layers. 760 The source address of such packets is the HoA of the MN, and the HoA also 761 serves as the return address. The MN can include the CAO in such packets but 762 this option does not in any way affect the routing of subsequent packets. The 763 packet source address and the returned packets destination address are always 764 the same, being equal to the MN HoA. Packets containing the CAO do not 765 therefore offer the redirection threats that were originally offered by MNs 766 originating packets from the CCoA, and including the Home Address Option 767 (HAO). This redirection threat resulted is such packets being banned in the 768 base spec unless the MN/CN have securely installed a BCE in the CN, and this 769 ban forces a MN to have to reverse tunnel packets to the HA in the absence of 770 RO. 772 If the MN wishes to hide its location it can simply not include a CAO. 773 Packets are not being rerouted based on the CAO and even if they were, it 774 would only affect its own communication so the MN has little incentive to lie 775 about its location and its mobility events. 777 The CAO processing rules ensure that the MN cannot abuse the CAO system and 778 significantly mislead the CN. The access routers on both home and foreign 779 networks must specifically prevent a MN from including an address into the 780 CAO that is not its own and that has not been policed by the HA, but is valid 781 at the access router and hence would have passed CAO based ingress filtering 782 checks. An attacker on the same network as the MN can potentially try to send 783 packets using the HoA and CCoA of another MN but clearly cannot otherwise 784 intercept, or interfere with, the communications between the MN and the CN. 785 This is true whether or not the CAO is added and is simply an additional 786 requirement on the access router to be able to deny such opportunities to 787 attackers. 789 Ongoing communications between a MN and a CN based on the HoA, provides the 790 CN with confidence that the MN is reachable at the HoA at some arbitrary 791 subnet via the HA. The inclusion of the CAO in a subset of packets from that 792 MN provides the CN with a reasonable level of confidence that the MN is at 793 that CCoA. A man in the middle attacker can at best modify the CAO and the 794 CRC of a packet, but in doing so can neither hijack communications nor 795 reroute packets. This is because return packets are still routed via the HA 796 and will be correctly delivered to the MN at its presently registered CoA. 797 The attacker could install an invalid CAO into a packet that might well fail 798 upstream ingress filtering checks. This would cause the packet to be 799 discarded but such an attacker could have removed the packet itself, so the 800 addition of the CAO simply opens more subtle ways of discarding packets at 801 significant expense to the attacker. The attacker can add a topologically 802 correct address into the CAO from its location on the path to the CN, and 803 then change it back on the return path but this offers nothing directly to 804 the attacker at significant cost to itself. Additional security processes are 805 however clearly needed to enable the IBCE to be used for Route Optimisation. 807 The use of the IBCE for Route Optimisation is not covered in this draft in 808 detail and therefore a detailed security analysis of this has not been 809 undertaken in this document. 811 8. Notice Regarding Intellectual Property Rights 813 Flarion's submissions will conform with RFC 2026. Flarion may seek patent 814 protection on some or all of the technical information submitted by its 815 employees in connection with the IETF's standards process. If part(s) of a 816 submission by Flarion is (are) included in a standard and Flarion owns 817 patent(s) and/or pending patent application(s) that are essential to 818 implementation of such included part(s) in said standard, Flarion is prepared 819 to grant a license on fair, reasonable, reciprocal (license back) and non- 820 discriminatory terms on such included part(s). 822 9. Acknowledgements 824 Many thanks to George Tsirtsis for reviews of this document and for 825 motivating improvements in the design of CAO enhanced ingress filtering. 827 10. References 829 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 830 RFC 2026, October 1996. 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement 833 Levels", BCP 14, RFC 2119, March 1997 835 [MIPv4] C. Perkins, Ed., 'IP Mobility Support for IPv4', RFC 3344, August 836 2002. 838 [MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", Internet-Draft, 839 draft-ietf-mobileip-ipv6-18.txt (work in progress), 22 March 2002. 841 [MIP-multicast] A. O'Neill, 'Mobility Management and IP Multicast', 842 Internet-draft, draft-oneill-mip-multicast-00.txt (work in progress), 5 July 843 2002. 845 Appendix A: CAO based RPF Check 847 In general, all routers in a network will be multicast enabled and as such 848 will undertake multicast RPF checks. A CAO based RPF check uses the contents 849 of the CAO rather than the multicast source address for the RPF check. This 850 requires either that all multicast routers must be option enforcement points 851 and to enable them to process the CAO option, or that the Hop By Hop Header 852 be mandated for all multicast packets issued by MNs when away from home. The latter is not unreasonable given all modes are likely to be multicast routers, and any that are not will be tunnelled over and hence such nodes will also not see the Hop By Hop header. 854 Author's Addresses 856 Alan O'Neill 857 Flarion Technologies 858 Phone: +1 908 947 7033 859 Email: oneill@flarion.com