idnits 2.17.1 draft-petrescu-nemo-threats-01.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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-petrescu-nemo-threats-xx', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-petrescu-nemo-threats-xx', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-petrescu-nemo-threats-xx', but the file name used is 'draft-petrescu-nemo-threats-01' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 21) being 60 lines 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 245 instances 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 == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (January 2004) is 7407 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: '7' is defined on line 975, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 987, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 991, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 995, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 998, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1001, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1004, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1027, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-rpsec-routing-threats-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rpsec-routing-threats (ref. '3') == Outdated reference: A later version (-03) exists of draft-ietf-nemo-basic-support-02 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '5') == Outdated reference: A later version (-08) exists of draft-ietf-ospf-ospfv3-auth-04 == Outdated reference: A later version (-02) exists of draft-jung-nemo-threat-analysis-01 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-02 == Outdated reference: A later version (-11) exists of draft-ietf-ipsec-rfc2402bis-05 ** Obsolete normative reference: RFC 2406 (ref. '12') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Normative reference to a draft: ref. '16' -- Possible downref: Normative reference to a draft: ref. '17' ** Obsolete normative reference: RFC 2223 (ref. '18') (Obsoleted by RFC 7322) -- Unexpected draft version: The latest known version of draft-rescorla-auth-mech is -01, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '19' ** Obsolete normative reference: RFC 2828 (ref. '21') (Obsoleted by RFC 4949) Summary: 10 errors (**), 1 flaw (~~), 20 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft A. Petrescu 2 Document: draft-petrescu-nemo-threats-xx.txt A. Olivereau 3 Expires: July 2004 C. Janneteau 4 H.-Y. Lach 5 Motorola 6 January 2004 8 Threats for Basic Network Mobility Support (NEMO threats) 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes security threats related to the network 34 mobility base protocol (NEMO). Threats of Mobile IPv6 for Mobile 35 Hosts are only briefly touched when in need of support of related 36 NEMO threats. The NEMO signalling between MR and HA, as well as 37 the forwarding information at HA and nested mobility configurations 38 are considered to be the main sensitive points of the protocol. 39 Existing tools of Mobile IPv6 protection between MH and HA (IPsec), 40 dynamic routing protocol authentication, NEMO prefix table, ingress 41 filtering checks at HA and tunnel encapsulation limiting are 42 presented as protocol features affording protection against 43 threats. NEMO threats for which there are no protections are 44 briefly mentioned. 46 Table of Contents 48 Status of this Memo................................................i 49 Abstract...........................................................i 50 Conventions Used in this Document..................................1 51 1. Introduction and Overview.......................................1 52 2. Interactions between MR and HA..................................4 53 3. Interactions between several MR's of same HA....................7 54 4. Forwarding Information Updates at HA............................7 55 5. Nested Mobility.................................................8 56 6. Other Threats...................................................8 57 Acknowledgements...................................................8 58 A. IPsec Architecture for Nested Mobility..........................8 59 B. IPsec Protection of Binding Updates and Acknowledgements.......10 60 C. IPsec non-Protection of Home Agent Discovery Messaging.........18 61 References........................................................19 62 Changes...........................................................21 63 Copyright Notice..................................................22 65 Conventions used in this document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 69 this document are to be interpreted as described in RFC-2119 [2]. 71 In addition to the NEMO terminology [5], four additional terms were 72 useful for descriptions within this document. 74 Binding Update: an IPv6 datagram that contains a Mobility Header 75 whose MH Type field is 0x5; it is sent by a Mobile 76 Node to its Home Agent. 78 Binding Acknowledgement: an IPv6 datagram that contains a Mobility 79 Header whose MH Type field is 0x6; it is 80 sent by a Home Agent in response to a 81 Binding Update received from a Mobile 82 Node. 84 Mobile Security Gateway: an entity acting simultaneously as a NEMO 85 Mobile Router and as an IPsec Security 86 Gateway. 88 Home Security Gateway: an entity acting simultaneously as a NEMO 89 Home Agent and as an IPsec Security Gateway. 91 1. Introduction and Overview 93 The Network Mobility base protocol [4] describes means for a Mobile 94 Router using Mobile IPv6 [8] to offer continuous connectivity for a 95 set of hosts and routers within a moving network, to the Internet. 96 A moving network has a relatively stable internal IP structure and 97 will usually not transit traffic. The Mobile Router is part of the 98 moving network and moves together with all nodes of it. 100 Documents desribing protocols should contain a Security Section 101 [18][20]. Section 8 of the NEMO base protocol is such a section; 102 it contains briefly outlined guidelines on the methods to use to 103 offer a relatively high level of security (IPsec, HA ingress 104 filtering and routing protocol verifications indications). 106 This document presents the characteristics of the initial threat 107 model that was used as basis for developping the respective 108 Security Considerations section. 110 A Mobile Router implements most functionalities of a Mobile IPv6 111 Mobile Host [8]. Notable additions include the R-bit management 112 and NEMO-specific modes (implicit and explicit). A NEMO Home Agent 113 implements most functionalities of a Mobile IPv6 HA with the the 114 additions of R-bit management, the two modes and, additionally, 115 interactions with its forwarding information (routing table) 116 management. There are no new messages introduced by the base NEMO 117 document [4] when compared to Mobile IPv6 [8]. The modified 118 messages are: Binding Update, Binding Acknowledgement, Home Agent 119 Discovery Request and Home Agent Discovery Reply. New R-bit fields 120 have been included in the Binding Update and the Home Agent 121 Discovery Request and Reply; a new MNP field has been introduced in 122 the Binding Update; the Status field of a Binding Acknowledgement 123 contains new values. 125 A new mobility configuration introduced by NEMO with respect to 126 Mobile IPv6 mobility is the "nested" configuration, in which two 127 moving networks served by different Mobile Routers (each with its 128 own Home Agent) attach one under the other. A simpler case of 129 nested mobility appears when one Mobile Host visits a moving 130 network (MH and MR having different Home Agents). 132 While Route Optimization is currently an integral part of the 133 Mobile IPv6 specification for Mobile Hosts, it is not a part of the 134 behaviour of a Mobile Router or of that of a NEMO Home Agent. 136 Thus, this document describes security threats that pertain to: (1) 137 interactions between MR and its HA, (2) interactions between 138 several MR's served by same HA, (3) threats relating to forwarding 139 information updates at HA and, finally and (4) threats related to 140 nested mobility. 142 Another document attempting to describe threats in the NEMO context 143 is [9]. 145 This document avoids description of threats relating to Route 146 Optimization for moving networks, to Mobile IPv6 for Mobile Hosts, 147 to multihoming for moving networks; other generic mobility threats 148 exist whose solutions are proposed by PANA, AAA and SEND Working 149 Groups. For threats relating to Mobile IPv6 for Mobile Hosts, 150 reader is referred to section 15.1 of [8], to [1] and [16]. For 151 threats relating to access granting and control, or threats of IPv6 152 behaviour on same link, please see the above mentioned Working 153 Group documents. For threats on the routing protocol (eventually 154 used between MR and HA) see [3]. 156 The current network mobility base specification [4] requires that 157 all signaling messages between the Mobile Router and the Home Agent 158 MUST be authenticated by IPsec. The use of IPsec to protect Mobile 159 IPv6 signaling messages is described in detail in the HA-MN IPsec 160 specification [1]. Using AH and/or ESP between MR and HA is of 161 paramount importance in order to protect against a wide range of 162 attacks. 164 The Internet IPsec architecture can be particularized for Mobile 165 Routers by distinguishing two cases: (1) IPsec protection in 166 transport mode for NEMO signalling and (2) IPsec protection in 167 tunnel mode for NEMO traffic between LFN and CN. 169 AH/ESP used in transport mode for NEMO signalling protects Binding 170 Updates, Binding Acknowledgements (but does not protect Home Agent 171 Address Discovery Requests and Home Agent Address Discovery 172 Replies). They are exchanged between the Mobile Router (Mobile 173 Security Gateway) and Home Agent (Home Security Gateway): 175 +--------+ +--------+ 176 | Mobile | AH/ESP transport mode | Home | 177 | Sec GW |========================| Sec GW | 178 | (MR) | | (HA) | 179 +--------+ +--------+ 181 AH/ESP used in tunnel mode for NEMO traffic protects all fields of 182 all IP datagrams exchanged between LFN and CN, including 183 application-level data: 185 +--------+ AH/ESP tunnel mode +--------+ 186 +-----+ | Mobile |________________________| Home | +----+ 187 | LFN |.....| Sec GW |........................| Sec GW |.....| CN | 188 +-----+ | (MR) |------------------------| (HA) | +----+ 189 +--------+ +--------+ 191 This IPsec architecture for moving networks can be extended to 192 nested network mobility configurations, by means of encapsulating 193 tunneling. See section A for illustrations of IPsec for nested 194 mobility. 196 Other means of protecting communication between MR and HA are 197 needed in certain cases; they include the use of the NEMO Prefix 198 Table, the prefix-extended ingress filtering technique [6] used by 199 the NEMO Home Agent and the tunnel encapsulation limiting. If 200 further additional tools are needed, a good overview of 201 authentication mechanisms in the Internet can be found in [19]. 203 Last but not least, even if IPsec, ingress filtering, Prefix Table 204 and tunnel encapsulation limiting are used, we acknowledge the 205 existence of other security risks with the NEMO base protocol. 206 They stem mainly from the lack of certain security features of the 207 underlying Mobile IPv6 protoocol. For example: attacks on the R 208 bit within the Home Agent Discovery messaging, and location privacy 209 risks. 211 2. Interactions between MR and HA 213 T.1 Threat on the MNP field (redirection threat): the simplest and 214 most important (but avoidable) threat of the NEMO basic support 215 protocol is the redirection of traffic of all addresses within a 216 Mobile Network Prefix. An attacker sending an un-protected NEMO 217 Binding Update to a Home Agent for a certain MNP is actually 218 instructing that Home Agent to forward all traffic for MNP towards 219 the address of the attacker. The gravity of the risk is more 220 important than in the case of Mobile Hosts; an attacker Mobile Host 221 could re-direct only one legitimate Home Address, while with NEMO 222 an attacker MR could re-direct all the addresses within an MNP. 223 Moreover, the risk is all the more important since attacker MR can 224 be positioned anywhere in the Internet, NEMO is not restrained to a 225 closed system. In order to avoid this risk actually realizing, it 226 is important to protect all signalling messages between MR and HA 227 by IPsec (this is also required by [1] and [8]). In general, if HA 228 uses AH/ESP transport mode for all NEMO signalling with the 229 legitimate MR then attacker MR is not able to realize such a 230 re-direction attack, because AH/ESP in transport mode covers the 231 MNP field of the BU. 233 T.2 Threat on the R bit of BU: An attacker Mobile Host asks its 234 Home Agent to forward all traffic addressed to addresses within MNP 235 to its current Care-of Address. Normally, Mobile Hosts do not send 236 the R-bit in the Binding Update. An attacker Mobile Host can 237 specify the R-bit and thus receiving traffic addressed to other 238 addresses than simply to its Home Address. However, if IPsec is 239 used, the R-bit in the BU is covered both by AH and ESP in 240 transport mode, so if HA and MH have a trust relationship it is 241 assumed that MH will not specify the R bit. 243 T.3 Threat on the Status field of BAck: an attacker entity on the 244 path between legitimate MR and HA modifies the Status field of the 245 Binding Acknowledgement sent by the HA to MR. It is assumed that 246 MR has previously sent a BU to HA with the R-bit set and that HA 247 replied with Status 140 (Mobile Router Operation not Permitted). 248 The attacker entity substitutes 141 (Invalid Prefix) for 140 and 249 thus leads MR into re-sending Binding Updates to Home Agent 250 (instead of stopping sending Binding Updates). However, the AH/ESP 251 headers cover the Status field of the BAck and thus attacker can 252 not tamper with the Status field, invalidating this threat. 254 T.4 Threat on switching between modes: MR sends BU in implicit mode 255 to HA, HA replies back positively, using MNP from external means 256 (not from BU). During this time, the attacker gained knowledge of 257 the MR's Home Address, sends BU to HA in explicit mode for the same 258 Home Address but a MNP specified in the BU, different than what HA 259 already has. HA replies back positively to MR and switches to 260 explicit mode and a different MNP. Threat is two-fold: on one hand 261 HA would stop forwarding packets of the legitimate MNP towards the 262 legitimate MR; on the other hand HA would start forwarding packets 263 of a false MNP towards the legitimate MR. 265 IPsec can not help protecting against attacker MR obtaining the 266 Home Address of the legitimate MR (it is not covered by ESP when 267 legitimate MR sends BU or receives BAck). However, IPsec can 268 protect against the attacker MR specifying an illegitimate MNP 269 within a BU; the MNP field in the BU is covered by ESP in transport 270 mode. 272 The description of this threat started with MR using implicit mode 273 and attacker trying explicit mode. The description applies equally 274 well if the initial step was in explicit mode and second step used 275 implicit mode. 277 T.5 Threat on the R bit of Home Agent Discovery Request: an 278 attacker on the path between legitimate MR and HA transforms the R 279 bit from 1 to 0. The Home Agents thus receive a request for 280 non-NEMO Home Agents and will not set the R bit in the Reply 281 message. Thus the MR is led into believing there is no HA on the 282 home link supporting Mobile Routers. IPsec does not protect 283 against this threat since the Home Agent Address Discovery Request 284 is not protected neither by AH nor by ESP headers. 286 T.6 Threat on the R bit of Home Agent Discovery Reply: an attacker 287 entity on the path between legitimate MR and HA transforms the R 288 bit from 1 to 0. It is assumed that, initially, the MR has sent a 289 Home Agent Address Discovery message to the home network with the 290 R-bit set, thus requesting responses from HA's that support Mobile 291 Routers; it is also assumed that the HA replied a legitimate Reply 292 containing the R bit set. The effect of this threat is that MR is 293 falsely led into believing that no HA on the home network can 294 support Mobile Routers. IPsec does not protect against this threat 295 since the Home Agent Address Discovery Reply is not protected 296 neither by AH nor by ESP headers. 298 T.7 Threat of address spoofing: when attacker needs to send an 299 unreasonably large amount of IP packets to a target without risk of 300 his current address being identified, it could do so by two means. 301 First, it would set the src address of the packets to another 302 address, at random (thus "spoofing" a legitimate address, or 303 "masquerading" as that address). However, the first-hop router 304 might forbid forwarding packets whose source address are not 305 topologically correct at that particular router (ingress filtering 306 [6]). Second, if ingress filtering at the access router is in 307 place, the MH might first encapsulate towards HA, thus tricking the 308 access router; HA decapsulates and "bombs" the actual target by 309 using MH's Home Address as source address. However, the ingress 310 filtering technique is used at the HA as well; Mobile IPv6 requires 311 HA of MH to only forward those packets from MH if the src address 312 of the outer header to match a Care-of Address entry in the BC and 313 the src address in the inner header to match the home address field 314 of the same entry. The NEMO base specification offers further help 315 by requiring the Home Address to match a Mobile Network Prefix 316 owned by the Mobile Router. If is obvious that this threat applies 317 to Mobile IPv6 for Mobile Hosts and, where Mobile IPv6 for Mobile 318 Hosts offers protection, it automatically offers protection for 319 Mobile Routers as well. 321 T.8 Threat on location privacy: [it is not immediately clear to 322 authors whether location privacy can be qualified as a NEMO 323 security threat per se or as a particular risk of open 324 communications in mobile environments.] 326 In the context of Mobile Hosts (not Mobile Routers), location 327 privacy represents the desire of a Mobile Host to not reveal, or 328 hide, its current association Care-of Address (its location) - Home 329 Address (its permanent identifier) from an attacker listening on 330 the path between MH and HA. It is not a desire to hide only one 331 address, but the association. It is sufficient for an attacker 332 wishing to find the current location of a victim Mobile Host to 333 snoop traffic between the victim and its Home Agent. When the 334 Mobile Host changes its location and updates the Home Agent, a pair 335 of Binding Update/Acknowledgement messages is communicated. An 336 attacker on the path can find the association Home Address - 337 Care-of Address of the Mobile Host, even if AH and/or ESP headers 338 are used to protect the two packets. Both AH and ESP for Binding 339 Updates and Acknowledgements are used in transport mode (not tunnel 340 mode), thus the base header (containing the Care-of Address and the 341 Home Agent address), the Destination Options header and the Routing 342 Header Type 2 (containing the Home Address) are transmitted in 343 clear (but message integrity, and implicitely integrity of the Home 344 Address and the Care-of Address, is afforded by AH), see section 345 B.6. 347 In the context of NEMO, the location privacy can be described as 348 the desire of a Local Fixed Node within a moving network to not 349 reveal, or hide, the location triplet LFN Home Address - MR Care-of 350 Address - MR Home Address. An attacker outside the moving network 351 and on the path between the Mobile Router and its Home Agent could 352 snoop packets. If the bidirectional tunnel between the Mobile 353 Router and its Home Agent is not protected by ESP, then attacker 354 can find the LFN Home Address in the src field of the inner packet 355 sent by MR to HA and the MR Care-of Address in the src field of the 356 outer base header. The MR Home Address could have been obtained 357 from the Binding Update or the Binding Acknowledgement, as 358 described in the previous paragraph. In this way, attacker can 359 gain knowledge of the triplet LFN Home Address - MR Home Address - 360 MR Care-of Address. However, if MR uses ESP tunnel mode protection 361 for the bidirectional tunnel, then attacker has no means to gain 362 visibility of the LFN Home Address. 364 Thus, even if location privacy might be considered as a security 365 threat, it is mostly a risk for Mobile Hosts, and can not be 366 qualified as a NEMO risk; the association Home Address - Care-of 367 Address of a Mobile Host might be revealing location information 368 but the location triplet can not be revealed if ESP is used for 369 non-signaling traffic between MR and HA. 371 T.9 Threat on the Routing Header Type 2: attacker modifies the type 372 of the routing header type 2 of a Binding Acknowledgement sent by 373 HA to MR and substitues 0 for 2. In addition attacker may specify 374 a number of addresses within this fake type 0 routing header. The 375 risk is that attacker provokes bombing attacks and stays hidden 376 (its address does not appear in the packet); it is the Home Agent's 377 and the Mobile Router's addresses that appear in the attack. The 378 risk is typically a Mobile IPv6 for hosts risk, but it is more 379 important in the case of Mobile Routers because Mobile Hosts are 380 not expected to implement routing header software, or are expected 381 to implement type 2 routing headers exclusively (for Mobile Hosts). 382 However, all routers (Mobile Routers included) are expected to 383 implement routing headers type 0, thus they are more at risk with 384 this threat. Protection against this risk is again offered by AH 385 which covers all fields of the Routing Header Type 2. 387 3. Interactions between several MR's of same HA 389 T.10 DoS threat on peer MR by attacker spoofing a legitimate MR's 390 Care-of Address. A similar threat exists in the case of Mobile 391 IPv6 for Mobile Hosts, but is less important than in the case of 392 NEMO. 394 In the context of Mobile IPv6 for Mobile Hosts, consider two Mobile 395 Hosts belonging to the same Home Agent; each MH is trusted by the 396 Home Agent (with IPsec). The victim MH and the attacker MH are 397 both visiting the same foreign network. The attacker MH reads the 398 Care-of Address of the victim from the Binding Update or 399 Acknowledgement that victim exchanges with HA. The attacker MH 400 sends Binding Update for the victim's CoA and its own Home Address. 401 Thus the HA will forward all traffic intended to attacker's Home 402 Address towards victim's Care-of Address, even though IPsec is 403 correctly being used. 405 This threat applies in the NEMO context as follows: consider a 406 legitimate MR with prefix MNP and an attacker MR with a different 407 prefix, both served by the same HA. Each MR shares a set of keys 408 with HA. The attacker MR could instruct the HA to add MNP in the 409 binding cache, relating it to its own Home Address (instead of to 410 the legitimate MR's Home Address), thus effectively denying service 411 to the legitimate MR and redirecting the entire traffic to MNP 412 towards the attacker MR. Even if HA uses IPsec, it could not 413 protect against attacker MR's claiming the legitimate MR's MNP. 414 However, the prefix table specified by NEMO base protocol 415 associates a MR's Home Address to the MNP that it owns, thus 416 constituting a means for MR to check against attacker MR claiming a 417 prefix it does not actually own. 419 4. Forwarding Information Updates at HA 421 How current routing protocols routers authentify each other, how 422 they lack a concept of "prefix ownership" (see the "address 423 ownership problem" [17]). How the prefix table might help with 424 this. How routing protocols authentication could be interpreted to 425 solve the potential "prefix ownership" problem. The use of the 426 prefix table to help authorizing the injection of route updates is 427 different than the use of the same prefix table in explicit mode in 428 order to authorize insertion of bindings (in NEMO explicit mode), 429 as presented in threat T.x. 431 The current base NEMO specification contains: 433 When the Mobile Router is running a dynamic routing protocol as 434 described in section 7, it injects routing update messages into 435 the Home Link. The Home Agent MUST verify that the Mobile 436 Router is allowed to send routing updates before processing the 437 messages and propagating the routing information. 439 5. Nested Mobility 441 T.11 DoS threat on TLMR due to too many levels of nested networks: 442 several moving networks may attach one under the other thus forming 443 a nested aggregation of moving networks ("levels" can be pictured 444 as follows: first MR attached under TLMR makes it for a one-level 445 aggregation of moving networks; a second MR attached under TLMR is 446 still a one-level aggregation; were the second MR attached under 447 the first MR, it would have been a two-level aggregation). 449 Naturally, the top-level MR will forward traffic of all moving 450 networks attached under it. When the number of levels is large, 451 this may become an overload on the original expectations of the 452 capabilities of this Mobile Router (overload in the form of more 453 cycles dedicated to IPv6 Fragmentation and Reassembly, as well as 454 Path MTU calculations), thus becoming a DoS attack. 456 It is thus possible for MR to need to limit the number of levels of 457 moving networks nesting under it; it could use the Tunnel 458 Encapsulation option by setting a limit on the number of levels of 459 mobile networks below it. 461 Nested mobility configurations appear also when Mobile Hosts visit 462 mobile networks. However, all Mobile Hosts will always attach to a 463 same level; given a mobile network, it is not possible to build a 464 more than one-level nested aggregation only by adding Mobile Hosts 465 (MH's don't attach one under the other). Thus, the above mentioned 466 threat of nested configurations is pertinent to nested moving 467 networks exclusively. 469 6. Other Threats 471 Other threats exist. 473 Acknowledgements 475 Threats related to network mobility have been discussed on the IETF 476 NEMO WG list, whose members are acknowledged here. 478 Seongho Cho provided significant feedback about several threats. 480 A. IPsec Architecture for Nested Mobility 482 The IPsec architecture can be particularized for nested mobility 483 cases by using nested encapsulation. In the figure below we 484 picture the protection of NEMO signalling between MR1 and its HA 485 (HA_MR1), when the moving network of MR1 is nesting within the 486 moving network of MR2 (it is assumed that the MR2 has already 487 performed NEMO signalling with its own HA - HA_MR2). The first 488 level of IPsec protection is offered by the AH/ESP transport mode 489 between MR1 and HA_MR1 (1). The second level is offered by AH/ESP 490 tunnel mode between MR2 and HA_MR2 (2). 492 +--------+ +--------+ +--------+ +--------+ 493 | | | | | | | | 494 | Mobile | | Mobile |__2__| Home |___| Home | 495 | Sec GW |=1=| Sec GW |=====| Sec GW |===| Sec GW | 496 | (MR1) | | (MR2) |-----|(HA_MR2)|---|(HA_MR1)| 497 | | | | | | | | 498 +--------+ +--------+ +--------+ +--------+ 500 The IPsec protection of application-level traffic between LFN and 501 CN, when LFN belongs to a nested moving network is pictured below. 502 The first level of protection is offered by the AH/ESP tunnel mode 503 between MR1 and HA_MR1 while the second is offered by the AH/ESP 504 tunnel mode between MR2 and HA_MR2. 506 +--------+ +--------+ +--------+ +--------+ 507 | | | |__2__| | | | 508 +-----+ | Mobile |_1_| Mobile |_____| Home |___| Home | +----+ 509 | LFN |..| Sec GW |...| Sec GW |.....| Sec GW |...| Sec GW |..| CN | 510 +-----+ | (MR1) |---| (MR2) |-----|(HA_MR2)|---|(HA_MR1)| +----+ 511 | | | |-----| | | | 512 +--------+ +--------+ +--------+ +--------+ 514 A parcticular case of nested mobility configuration is the visit of 515 of a MH within a moving network. The signalling protection is 516 offered by AH/ESP in transport mode between MH and HA_MH (1) and by 517 AH/ESP offered by AH/ESP in tunnel mode between MR and HA_MR (2). 519 +--------+ +--------+ +-------+ 520 +--+ | Mobile |___________2____________| Home | | | 521 |MH|===1====| Sec GW |========================| Sec GW |==| HA_MH | 522 +--+ | (MR) |------------------------| (HA_MR)| | | 523 +--------+ +--------+ +-------+ 525 Still in the case of nested mobility of a MH within a moving 526 network, the application-level traffic between MH and CN is offered 527 a first level of protection by the AH/ESP tunnel mode between MH 528 and HA_MN (1) and a second level by the AH/ESP tunnell mode between 529 MR and HA_MR (2). 531 +--------+ +--------+ +-------+ 532 +---+ | |_________2________| | | | 533 | |_1__| Mobile |__________________| Home |___| | +----+ 534 |MH |....| Sec GW |..................| Sec GW |...| HA_MH |....| CN | 535 | |----| (MR) |------------------| (HA_MR)|---| | +----+ 536 +---+ | |------------------| | | | 537 +--------+ +--------+ +-------+ 539 B. IPsec Protection of Binding Updates and Acknowledgements 541 In this section, we used the following NEMO messages for threat 542 analysis: Binding Update, Binding Acknowldegement. The following 543 fields have been considered as relevant for NEMO threat analysis: 545 -src and dst addresses in the base header. 546 -the Home Address in the Destination Options 0 header of the 547 Binding Update. 548 -the R bit in the AHLKR field of the Binding Update. 549 -the Prefix Len and Mobile Network Prefix fields in a Binding 550 Update sent in explicit mode. 551 -the Routing Type, Segments Left and Home Address fields in the 552 Routing Header Type 2 of the Binding Acknowledgement. 553 -the Status field of the Binding Acknowledgement. 555 In building the packet formats below, the following notation was 556 used: 558 *: NEMO field, or bit or value introduced by NEMO base protocol, or 559 containing helpful information for realization of the 560 NEMO-related risks described in this document. 561 x: authenticated field, as covered by AH ICV. 562 y: encrypted field, as part of ESP payload data. 563 z: authenticated field, as part of ESP authentication data. 565 For example, fields that are marked (*xyz) are helping realizing 566 threats, but are protected by AH and ESP non-NULL authentication, 567 thus rendering most NEMO threats impossible; fields that are only 568 marked (*) are not protected, thus might constitute security risks. 570 In the following sections, pairs consisting of a Binding Update and 571 the corresponging Binding Acknowledgement are illustrated. Each 572 section describes two pairs: the pair when MR is in a foreign 573 network followed by the pair when MR is returning to the home 574 network. Section B.1 presents unprotected pairs while section B.6 575 presents pairs protected both by AH and ESP in transport mode (ESP 576 with non-NULL authentication algorithm). Intermediary sections use 577 transport mode AH exclusively or transport mode ESP exclusively (ESP 578 with or without authentication algorithm). 580 B.1 Unprotected BU and BAck when MR in foreign network 582 Base Header Base Header 583 src: CoA (*) src: Home Agent address (*) 584 dst: Home Agent address (*) dst: CoA (*) 585 Destination Options Routing Header 586 Home Address: Home Address (*) Routing Type: 2 (*) 587 Mobility Header Segments Left: 1 (*) 588 Header Len Home Address: Home Address (*) 589 MH Type: Mobility Header 590 Reserved: Header Len: 591 Checksum: MH Type: 592 Message Data Reserved: 593 Seq # Checksum: 594 AHLKR (*) Message Data 595 Lifetime: Status (*) 596 Mobility Options K: 597 Alternate CoA: CoA Reserved 598 Mobile Net Prefix Option Seq #: 599 Prefix Len: (*) Lifetime: 600 Mobile Net Prefix: (*) Mobility Options 601 Binding Refresh Advice 602 Refresh Interval: 604 Unprotected BU and BAck when MR returns home 606 Base Header Base Header 607 src: Home Address (*) src: Home Agent address (*) 608 dst: Home Agent address (*) dst: Home Address (*) 609 Mobility Header Mobility Header 610 Header Len Header Len: 611 MH Type: MH Type: 612 Reserved: Reserved: 613 Checksum: Checksum: 614 Message Data Message Data 615 Seq # Status (*) 616 AHLKR (*) K: 617 Lifetime: Reserved 618 Mobility Options Seq #: 619 Mobile Net Prefix Option Lifetime: 620 Prefix Len: (*) Mobility Options 621 Mobile Net Prefix: (*) Binding Refresh Advice 622 Refresh Interval: 624 B.2 AH protected BU and BAck when MR in foreign network 626 Base Header Base Header 627 src: CoA (*x) src: Home Agent address (*x) 628 dst: Home Agent address (*x) dst: CoA (*x) 629 Destination Options Routing Header 630 Home Address: Home Address (*x) Routing Type: 2 (*x) 631 Authentication Header Segments Left: 1 (*x) 632 SPI: Home Address: Home Address(*x) 633 Seq No: Authentication Header 634 ICV: SPI: 635 Mobility Header Seq No: 636 Header Len ICV: 637 MH Type: Mobility Header 638 Reserved: Header Len: 639 Checksum: MH Type: 640 Message Data Reserved: 641 Seq # Checksum: 642 AHLKR (*x) Message Data 643 Lifetime: Status (*x) 644 Mobility Options K: 645 Alternate CoA: CoA Reserved 646 Mobile Net Prefix Option Seq #: 647 Prefix Len: (*x) Lifetime: 648 Mobile Net Prefix: (*x) Mobility Options 649 Binding Refresh Advice 650 Refresh Interval: 652 AH protected BU and BAck when MR returns home 654 Base Header Base Header 655 src: Home Address (*x) src: Home Agent address (*x) 656 dst: Home Agent address (*x) dst: Home Address (*x) 657 Authentication Header Authentication Header 658 SPI: SPI: 659 Seq No: Seq No: 660 ICV: ICV: 661 Mobility Header Mobility Header 662 Header Len Header Len: 663 MH Type: MH Type: 664 Reserved: Reserved: 665 Checksum: Checksum: 666 Message Data Message Data 667 Seq # Status (*x) 668 AHLKR (*x) K: 669 Lifetime: Reserved 670 Mobility Options Seq #: 671 Mobile Net Prefix Option Lifetime: 672 Prefix Len: (*x) Mobility Options 673 Mobile Net Prefix: (*x) Binding Refresh Advice 674 Refresh Interval: 676 B.3 ESP NULL auth algo for BU and BAck when MR in foreign network 678 Base Header Base Header 679 src: CoA (*) src: Home Agent address (*) 680 dst: Home Agent address (*) dst: CoA (*) 681 Destination Options Routing Header 682 Home Address: Home Address (*) Routing Type: 2 (*) 683 ESP Header Segments Left: 1 (*) 684 SPI: Home Address: Home Address (*) 685 Seq No: ESP Header 686 Mobility Header SPI: 687 Header Len Seq No: 688 MH Type: Mobility Header 689 Reserved: Header Len: 690 Checksum: MH Type: 691 Message Data Reserved: 692 Seq # Checksum: 693 AHLKR (*y) Message Data 694 Lifetime: Status (*y) 695 Mobility Options K: 696 Alternate CoA: CoA Reserved 697 Mobile Net Prefix Option Seq #: 698 Prefix Len: (*y) Lifetime: 699 Mobile Net Prefix: (*y) Mobility Options 700 ESP Trailer Binding Refresh Advice 701 Refresh Interval: 702 ESP Trailer 704 ESP NULL auth algo for BU and BAck when MR returns home 706 Base Header Base Header 707 src: Home Address (*) src: Home Agent address (*) 708 dst: Home Agent address (*) dst: Home Address (*) 709 ESP Header ESP Header 710 SPI: SPI: 711 Seq No: Seq No: 712 Mobility Header Mobility Header 713 Header Len Header Len: 714 MH Type: MH Type: 715 Reserved: Reserved: 716 Checksum: Checksum: 717 Message Data Message Data 718 Seq # Status (*y) 719 AHLKR (*y) K: 720 Lifetime: Reserved 721 Mobility Options Seq #: 722 Mobile Net Prefix Option Lifetime: 723 Prefix Len: (*y) Mobility Options 724 Mobile Net Prefix: (*y) Binding Refresh Advice 725 ESP Trailer Refresh Interval: 726 ESP Trailer 727 B.4 ESP non-NULL auth algo for BU and BAck when MR in foreign network 729 Base Header Base Header 730 src: CoA (*) src: Home Agent address (*) 731 dst: Home Agent address (*) dst: CoA (*) 732 Destination Options Routing Header 733 Home Address: Home Address (*) Routing Type: 2 (*) 734 ESP Header Segments Left: 1 (*) 735 SPI: Home Address: Home Address (*) 736 Seq No: ESP Header 737 Mobility Header SPI: 738 Header Len Seq No: 739 MH Type: Mobility Header 740 Reserved: Header Len: 741 Checksum: MH Type: 742 Message Data Reserved: 743 Seq # Checksum: 744 AHLKR (*yz) Message Data 745 Lifetime: Status (*yz) 746 Mobility Options K: 747 Alternate CoA: CoA Reserved 748 Mobile Net Prefix Option Seq #: 749 Prefix Len: (*yz) Lifetime: 750 Mobile Net Prefix: (*yz) Mobility Options 751 ESP Trailer Binding Refresh Advice 752 ESP Auth Refresh Interval: 753 ESP Trailer 754 ESP Auth 756 ESP non-NULL auth algo for BU and BAck when MR returns home 758 Base Header Base Header 759 src: Home Address (*) src: Home Agent address (*) 760 dst: Home Agent address (*) dst: Home Address (*) 761 ESP Header ESP Header 762 SPI: SPI: 763 Seq No: Seq No: 764 Mobility Header Mobility Header 765 Header Len Header Len: 766 MH Type: MH Type: 767 Reserved: Reserved: 768 Checksum: Checksum: 769 Message Data Message Data 770 Seq # Status (*yz) 771 AHLKR (*yz) K: 772 Lifetime: Reserved 773 Mobility Options Seq #: 774 Mobile Net Prefix Option Lifetime: 775 Prefix Len: (*yz) Mobility Options 776 Mobile Net Prefix: (*yz) Binding Refresh Advice 777 ESP Trailer Refresh Interval: 778 ESP Auth ESP Trailer 779 ESP Auth 780 B.5 AH and ESP NULL for BU and BAck when MR in foreign network 782 Base Header Base Header 783 src: CoA (*x) src: Home Agent address (*x) 784 dst: Home Agent address (*x) dst: CoA (*x) 785 Destination Options Routing Header 786 Home Address: Home Address (*x) Routing Type: 2 (*x) 787 Authentication Header Segments Left: 1 (*x) 788 SPI: Home Address: Home Address(*x) 789 Seq No: Authentication Header 790 ICV: SPI: 791 ESP Header Seq No: 792 SPI: ICV: 793 Seq No: ESP Header 794 Mobility Header SPI: 795 Header Len Seq No: 796 MH Type: Mobility Header 797 Reserved: Header Len: 798 Checksum: MH Type: 799 Message Data Reserved: 800 Seq # Checksum: 801 AHLKR (*xy) Message Data 802 Lifetime: Status (*xy) 803 Mobility Options K: 804 Alternate CoA: CoA Reserved 805 Mobile Net Prefix Option Seq #: 806 Prefix Len: (*xy) Lifetime: 807 Mobile Net Prefix: (*xy) Mobility Options 808 ESP Trailer Binding Refresh Advice 809 Refresh Interval: 810 ESP Trailer 811 AH and ESP NULL for BU and BAck when MR returns home 813 Base Header Base Header 814 src: Home Address (*x) src: Home Agent address (*x) 815 dst: Home Agent address (*x) dst: Home Address (*x) 816 Authentication Header Authentication Header 817 SPI: SPI: 818 Seq No: Seq No: 819 ICV: ICV: 820 ESP Header ESP Header 821 SPI: SPI: 822 Seq No: Seq No: 823 Mobility Header Mobility Header 824 Header Len Header Len: 825 MH Type: MH Type: 826 Reserved: Reserved: 827 Checksum: Checksum: 828 Message Data Message Data 829 Seq # Status (*xy) 830 AHLKR (*xy) K: 831 Lifetime: Reserved 832 Mobility Options Seq #: 833 Mobile Net Prefix Option Lifetime: 834 Prefix Len: (*xy) Mobility Options 835 Mobile Net Prefix: (*xy) Binding Refresh Advice 836 ESP Trailer Refresh Interval: 837 ESP Trailer 838 B.6 AH and ESP non-NULL for BU and BAck when MR in foreign network 840 Base Header Base Header 841 src: CoA (*x) src: Home Agent address (*x) 842 dst: Home Agent address (*x) dst: CoA (*x) 843 Destination Options Routing Header 844 Home Address: Home Address (*x) Routing Type: 2 (*x) 845 Authentication Header Segments Left: 1 (*x) 846 SPI: Home Address: Home Address(*x) 847 Seq No: Authentication Header 848 ICV: SPI: 849 ESP Header Seq No: 850 SPI: ICV: 851 Seq No: ESP Header 852 Mobility Header SPI: 853 Header Len Seq No: 854 MH Type: Mobility Header 855 Reserved: Header Len: 856 Checksum: MH Type: 857 Message Data Reserved: 858 Seq # Checksum: 859 AHLKR (*xyz) Message Data 860 Lifetime: Status (*xyz) 861 Mobility Options K: 862 Alternate CoA: CoA Reserved 863 Mobile Net Prefix Option Seq #: 864 Prefix Len: (*xyz) Lifetime: 865 Mobile Net Prefix: (*xyz) Mobility Options 866 ESP Trailer Binding Refresh Advice 867 ESP Auth Refresh Interval: 868 ESP Trailer 869 ESP Auth 870 AH and ESP non-NULL for BU and BAck when MR returns home 872 Base Header Base Header 873 src: Home Address (*x) src: Home Agent address (*x) 874 dst: Home Agent address (*x) dst: Home Address (*x) 875 Authentication Header Authentication Header 876 SPI: SPI: 877 Seq No: Seq No: 878 ICV: ICV: 879 ESP Header ESP Header 880 SPI: SPI: 881 Seq No: Seq No: 882 Mobility Header Mobility Header 883 Header Len Header Len: 884 MH Type: MH Type: 885 Reserved: Reserved: 886 Checksum: Checksum: 887 Message Data Message Data 888 Seq # Status (*xyz) 889 AHLKR (*xyz) K: 890 Lifetime: Reserved 891 Mobility Options Seq #: 892 Mobile Net Prefix Option Lifetime: 893 Prefix Len: (*xyz) Mobility Options 894 Mobile Net Prefix: (*xyz) Binding Refresh Advice 895 ESP Trailer Refresh Interval: 896 ESP Auth ESP Trailer 897 ESP Auth 899 C. IPsec non-Protection of Home Agent Discovery Messaging 901 In this section, we used the following NEMO messages for threat 902 analysis: Home Agent Address Discovery and Home Agent Address Reply. 903 The following fields have been considered as relevant for NEMO 904 threat analysis: 906 -src and dst addresses in the base header. 907 -the R bit in the ICMPv6 discovery and reply messages. 908 -the R bit in the Home Agent Information Option of the Reply 909 message. 911 In building the packet formats below, the following notation was 912 used: 914 *: NEMO field, or bit or value introduced by NEMO base protocol, or 915 containing helpful information for realization of the 916 NEMO-related risks described in this document. 917 x: authenticated field, as covered by AH ICV. 918 y: encrypted field, as part of ESP payload data. 919 z: authenticated field, as part of ESP authentication data. 921 For example, fields that are marked (*xyz) are helping realizing 922 threats, but are protected by AH and ESP non-NULL authentication, 923 thus rendering most NEMO threats impossible; fields that are only 924 marked (*) are not protected, thus might constitute security risks. 926 C.1 Unprotected Home Agent Address Discovery and Reply 928 Base Header Base Header 929 src: CoA (*) src: Home Agent address (*) 930 dst: Home Agents anycast (*) dst: CoA (*) 931 ICMPv6 message ICMPv6 message 932 Type Type 933 Code Code 934 Checksum Checksum 935 Identifier Identifier 936 R (*) R (*) 937 Home Agent Information Option 938 Type 939 Length 940 R (*) 942 Remark the the Agent Discovery messages are not protected at all by 943 IPsec and may lead to important security threats. NEMO threat 944 analysis is concerned solely by the use of the R bit of these 945 messages, and by the risks involved on tampering with the integrity 946 or the confidentiality of this bit exclusively. 948 References 950 [1] Arkko, J., Devarapalli, V. and Dupont, F., "Using IPsec to 951 Protect Mobile IPv6 Signaling between Mobile Nodes and Home 952 Agents" (work in progress). Internet Draft, IETF. 953 draft-ietf-mobileip-mipv6-ha-ipsec-06.txt. June 2003. 955 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 956 Levels", BCP 14, RFC 2119, March 1997. 958 [3] Barbir, A., Murphy, S. and Yang, Y., "Generic Threats to 959 Routing Protocols". Internet Draft, IETF. 960 draft-ietf-rpsec-routing-threats-02.txt. August 2003. 962 [4] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P., 963 "Nemo Basic Support Protocol" (work in progress). Internet 964 Draft, IETF. draft-ietf-nemo-basic-support-02.txt. December 965 2003. 967 [5] Ernst, T. and Lach, H.-Y, "Network Mobility Support 968 Terminology", Internet Draft, 969 IETF. draft-ietf-nemo-terminology-00.txt. May 2003. 971 [6] Ferguson, P. and Senie, D., "Network Ingress Filtering: 972 Defeating Denial of Service Attacks which employ IP Source 973 Address Spoofing", BCP 38, RFC 2827, May 2000. 975 [7] Gupta, M. and Melam, N., "Authentication/Confidentiality for 976 OSPFv3" (work in progress). Internet Draft, IETF. 977 draft-ietf-ospf-ospfv3-auth-04.txt. December 2003. 979 [8] Johnson, D., Perkins, C. and Arkko, J., "Mobility Support in 980 IPv6" (work in progress). Internet Draft, 981 IETF. draft-ietf-mobileip-ipv6-24.txt. June 2003. 983 [9] Jung, S., Zhao, F., Wu, F., Kim, H. and Sohn, S., "Threat 984 Analysis for NEMO" (work in progress). Internet Draft, IETF. 985 draft-jung-nemo-threat-analysis-01.txt. October 2003. 987 [10] Kent, S. and Seo, K., "Security Architecture for the Internet 988 Protocol" (work in progress). Internet Draft, 989 IETF. draft-ietf-ipsec-rfc2401bis-02.txt. January 2004. 991 [11] Kent, S., "IP Authentication Header" (work in progress). 992 Internet Draft, IETF. draft-ietf-ipsec-rfc2402bis-05.txt. 993 September 2003. 995 [12] Kent, S. and Atkinson, R., "IP Encapsulating Security Payload 996 (ESP)", RFC 2406, November 1998. 998 [13] Madson, C., "The Use of HMAC-MD5-96 within ESP and AH", RFC 999 2403, November 1998. 1001 [14] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher 1002 Algorithm with Explicit IV", RFC 2405, November 1998. 1004 [15] Madson, C. and Glenn, R., "The Use of HMAC-SHA-1-96 within ESP 1005 and AH", RFC 2404, November 1998. 1007 [16] Nikander, P., Harkins, D., Patil, B., Roberts, P., Nordmark, 1008 E. and Makin, A., "Threat Models introduced by Mobile IPv6 and 1009 Requirements for Security in Mobile IPv6" (work in progress). 1010 Internet Draft, IETF. 1011 draft-team-mobileip-mipv6-sec-reqts-00.txt. December 2001. 1013 [17] Nikander, P., "An Address Ownership Problem in IPv6" (work in 1014 progress). Internet Draft, IETF. 1015 draft-nikander-ipng-address-ownership-00.txt. February 2001. 1017 [18] Postel, J. and Reynolds, J., "Instructions to RFC Authors", 1018 RFC 2223, October 1997. 1020 [19] Rescorla, E., "A Survey of Authentication Mechanisms" (work in 1021 progress). Internet Draft, IETF. 1022 draft-rescorla-auth-mech-02.txt. October 2003. 1024 [20] Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text 1025 on Security Considerations", BCP 72, RFC 3552, July 2003. 1027 [21] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000. 1029 Changes 1031 November 2003: revision 00 submitted. 1032 January 2004: revision 01 submitted. 1033 -added appendices with detailed packet formats. 1034 -added the threat on Home Agent Discovery messaging. 1035 -added detailed explanations on existing threats and how IPsec 1036 headers protect. 1037 -eliminated the highly generic threats on Confidentiality and 1038 Integrity to better focus on NEMO specific threats. 1040 Authors' Addresses 1042 Alexandru Petrescu Christophe Janneteau 1043 Motorola Labs Motorola Labs 1044 Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin 1045 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 1046 France France 1047 Phone: +33 1 69354827 Phone: +33 1 69352548 1048 Alexandru.Petrescu@motorola.com Christophe.Janneteau@motorola.com 1050 Alexis Olivereau Hong-Yon Lach 1051 Motorola Labs Motorola Labs 1052 Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin 1053 Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 1054 France France 1055 Phone: +33 1 69352516 Phone: +33 1 69352536 1056 Alexis@motorola.com Hong-Yon.Lach@motorola.com 1058 Copyright (C) The Internet Society (2004). All Rights Reserved. 1060 This document and translations of it may be copied and furnished to 1061 others, and derivative works that comment on or otherwise explain it 1062 or assist in its implementation may be prepared, copied, published and 1063 distributed, in whole or in part, without restriction of any kind, 1064 provided that the above copyright notice and this paragraph are 1065 included on all such copies and derivative works. However, this 1066 document itself may not be modified in any way, such as by removing 1067 the copyright notice or references to the Internet Society or other 1068 Internet organizations, except as needed for the purpose of developing 1069 Internet standards in which case the procedures for copyrights defined 1070 in the Internet Standards process must be followed, or as required to 1071 translate it into languages other than English. 1073 The limited permissions granted above are perpetual and will not be 1074 revoked by the Internet Society or its successors or assigns. 1076 This document and the information contained herein is provided on an 1077 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1078 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1079 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1080 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1081 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1083 Funding for the RFC editor function is currently provided by the 1084 Internet Society.