idnits 2.17.1 draft-jung-nemo-threat-analysis-02.txt: -(414): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 64 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 250 has weird spacing: '...nerates from ...' == 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 'SHOULD not' in this paragraph: If one of the tunnel paths is broken for any reason, the MR(MR1) associated with the faulty path loses Internet connection, and should find an alternative bi-directional tunnel path through another MR2. In this case, MR1 becomes a nested MR of MR2. NEMO basic draft[3] describes that MR SHOULD not respond to the unsolicited RA messages to its egress interface, but according to the MR operations by multihoming draft B.2.2 [6], the MR1 SHOULD listen the RA from alternative MR2 on its ingress interface. At this point, a malicious MR may advertise a RA with a fake CoA to MR1. Then the MR1 will get a wrong CoA information. -- 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 (July 19, 2004) is 7218 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: '1' is defined on line 385, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 397, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 406, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 410, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 412, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '1') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '2') ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '6') ** Obsolete normative reference: RFC 2406 (ref. '8') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2401 (ref. '9') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. '10') (Obsoleted by RFC 4302, RFC 4305) -- No information found for draft-petrescu-nemo-thretas - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' Summary: 12 errors (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group Souhwan Jung 2 Internet-Draft Soongsil University 3 Expires: January 19, 2005 Fan Zhao 4 S. Felix Wu 5 UC Davis 6 HyunGon Kim 7 SungWon Sohn 8 ETRI 9 July 19, 2004 11 Threat Analysis on NEMO Basic Operations 12 draft-jung-nemo-threat-analysis-02 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document describes potential security threats to NEMO basic 43 operations. The threats are mostly related to the integral use of 44 IPsec and IP-in-IP tunnel between MR and HA. Other threats related 45 to the operations of multiple MRs, and potential DoS attacks on MR 46 and HA are also investigated. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 52 this document are to be interpreted as described in RFC-2119. 54 Table of Contents 56 1. Introduction 57 2. Assumptions 58 3. Threats to interactions between MR and HA 59 3.1 Attacks to the MR-HA IPsec Transport SA 60 3.1.1 BU spoofing attack without ingress filtering at MR 61 3.1.2 BU spoofing attack with ingress filtering at MR 62 3.2 Attacks to MR-HA tunnel 63 3.2.1 Attack from inside 64 3.2.2 Attack from outside 65 3.3 Attacks to the signaling messages 66 4. Threats to interaction among MRs 67 4.1 Attacks to multihomed MRs 69 5. DoS attacks to MR or HA 71 Changes from previous version 72 References 73 Authors' Addresses 74 Intellectual Property and Copyright Statements 76 1. Introduction 78 NEwork MObility (NEMO) introduces a network entity called Mobile 79 Router(MR)[2]. MR has different features from mobile host that operates 80 based on Mobile IP technologies[4]. Since MR functions both as a mobile 81 node and a gateway to provide mobile network with Internet access to 82 outside world, it needs specific treatment for managing operations and 83 securities. 85 The MIP/NEMO community has spent quite a lot of efforts in designing 86 security mechanisms to protect critical control messages exchanged among 87 protocol entities such as HA (Home Agent), MN (Mobile Node), or MR 88 (Mobile Router in NEMO). In particular, the authenticity and integrity 89 of the Binding Update (BU) messages SHOULD be protected very well. 91 Otherwise, many malicious attacks such as traffic hijacking or denial 92 of service are possible by intentionally injecting incorrect BU messages. 93 Under both MIP6 and NEMO, IPsec Transport ESP (Encapsulating Security 94 Payload) [8] is used to protect the binding update messages between HA 95 and MN/MR. 97 IPsec itself provides a network layer security service between two 98 network entities, and it nicely integrates a number of strong 99 cryptographic components under its architecture. Due to this strong fact 100 of IPsec security, many Internet protocols, especially in the 101 network layer, have been built on top of the security strength of IPsec. 102 The list is currently growing, but at least, we can include OSPFv6, 103 TRIP (Telephony Routing over IP, under the IP Telephony working group), 104 RSVP/NSIS (Next Step in Signaling), L3VPN, PANA (Protocol for Authentication 105 and Network Access), MobileIP and NEMO. 107 While IPsec itself is indeed quite secure, the security of the protocols 108 using IPsec might still be very questionable. In fact, through our security 109 analysis toward NEMO, we realize that the IPsec architecture itself does 110 NOT specify/mandate its relationship with other functional components 111 (such as packet forwarding, ingress filtering, IP-in-IP tunnel, or 112 application interface) in the same router. 113 Therefore, as will be shown later, most of the IPsec implementers have not 114 considered how to properly glue the IPsec engine with the rest of the 115 system such that the whole system (such as the MR in NEMO) can be easily 116 broken in. In short, IPsec by itself is indeed doing its job securely, 117 but the component putting packets into the IPsec module might not. 119 This draft describes vulnerabilities to the basic operations of 120 NEMO, and discussed its potential security problems, especially, related 121 to IPsec and other tunneling functions. 123 2. Assumptions 125 Many different types of threats to NEMO were described by [11] and [12]. 126 But most of the threats can be easily protected by using existing IPsec 127 AH/ESP through the bi-directional tunnel between MR and HA. Some of 128 threats are not specific to NEMO basic operations, but generic to 129 Mobile IP or host security. 131 The generic threats to NEMO basic operations can be classified into 132 three different categories: threats on the tunnel between MR and HA, 133 threats on the path among multiple MRs, and threats to the MR and HA 134 themselves. 136 Since many serious attacks are possible with a compromised MR/HA, we 137 get rid of the threats derived from a compromised MR/HA. Therefore, we 138 assume the following conditions for further discussion of generic threats 139 to basic NEMO operations. 141 2.1 The IPsec AH/ESP security mechanisms are activated on MR-HA tunnels. 142 2.2 No compromise of the prefix and binding cache tables in HA. 143 2.3 No compromise of critical information like MNP and HoA on MR. 144 2.4 Multiple HAs have their own trust relationships provided by ISP. 145 2.5 No current security mechanisms are applied among multiple MRs. 147 3. Threats to interactions between MR and HA 149 The major threats to the basic operations of mobile network are from 150 the tunneling operations. Tunneled packet can disguise itself using 151 fake source and destination addresses. The MR or HA should be responsible 152 to verify the validity of those packets. Since the basic operation of 153 mobile network is based on the IPsec tunnel and IP-in-IP tunnel between 154 MR and HA, the threats to those tunneling operations will be investigated 155 in this section. 157 3.1 Attacks to the MR-HA IPsec Transport SA 159 Two different potential attack scenarios are presented in this section. 161 3.1.1 BU spoofing attack: no ingress filtering at MR 163 The first case assumes that there is no ingress filtering activated at MR. 164 Figure 1 shows the attack scenario. 166 In the Figure 1, a malicious MNN generates a spoofed packet by setting 167 source address to the HoA of the MR and destination address to the address 168 of HA, and also includes the BU of MR as a payload. The format and contents 169 of the BU message look exactly like a BU from the MR. When the MR received 170 the packet from the attacker, it first saves the packet to the buffer, 171 and checks the security policy database (SPD) of the packet. Since the MR 172 cannot tell the fake packet from the packet from itself at this point, it 173 finds that the packet requires the IPsec processing, and forwards it to 174 the security interface for IPsec processing. Then the IPsec module 175 encapsulates the packet using the ESP transport mode and the associated SA. 176 When the HA received the packet, it verifies the packet by checking the 177 IPsec ESP SA that will be valid because it is encapsulated by a valid MR. 178 Finally, the HA is fooled to believe that the BU is from the MR, and 179 updates the binding cache of itself. 181 MNN MR HA 182 |--------| |----------------| |-----------| 183 | | | |-------|| ESP | |-------| | 184 |Attacker|---------->|-------| IPSec ||====================| | IPSec | | 185 | | | | ^ |-------|| Transport | |-------| | 186 |--------| | |-|--------------| | |-----------| 187 | At this point, MR | checks the packet 188 | cannot tell the fake | using ESP and 189 |-----------| BU from a BU from |-----------| updates Binding 190 |Src=HoA | itself, and applies |Src=CoA | Cache (corrupts 191 |Dst=HA | IPSec ESP. |Dst=HA | binding cache) 192 |... | |ESP | 193 |BU(MNP,CoA)| |... | 194 |-----------| |BU(MNP,CoA)| 195 Attacker |-----------| 196 generates Packet is 197 a fake BU encapsulated 198 with ESP 200 Figure 1. MNN spoofs the BU of the MR without ingress filtering 202 This attack is possible due to two reasons. The first one is that the 203 MR is not using ingress filtering to check the topological correctness 204 of the source address. If the MR checks the source address of the packet, 205 and finds that the source address is set to itself, then it will drop 206 the packet. Another reason is that the MR forgets where the packet came 207 from, once it gets the packets and saves to a buffer. If the MR can 208 distinct the packet stream generated by other nodes (Layer2) from those 209 by itself (Layer4), then the fake packet will not be processed by IPsec, 210 and will be forwarded to HA encapsulated in an IP-in-IP tunnel. 211 Then the attack will fail to modify the binding cache of the HA. 213 3.1.2 BU spoofing attack: with ingress filtering at MR 215 This attack scenario is similar to the first scenario, but assumes the 216 ingress filtering at the MR. Figure 2 shows the attack scenario. 218 In this scenario, the attacker generates a spoofed BU message using 219 IP-in-IP encapsulation as shown in the figure. Now, the outer source 220 address is set to the address MNN and the destination address is set 221 to the address of the MR. The inner source address is set to the HoA 222 of MR and the inner destination address is set to the address of HA. 223 This attack is possible due to the order of packet processing at the 224 MR as shown in the figure. If the MR performs the ingress filtering 225 at first, and then do the tunnel decapsulation, then the fake packet 226 can get through the ingress filtering of the MR. The rest of the story 227 is the same as the first scenario. If the MR do perform the ingress 228 filtering after the tunnel decapsulation, the fake packet can be dropped 229 at the MR in this scenario. Therefore, it is very important to implement 230 multiple functions of the MR in the right order. In real world, 231 the ingress filtering function of the routers are not activated in many 232 cases, and then those routers are exposed to this type of attacks. 234 MNN IP_in_IP MR HA 235 |--------| packet is |----------------------------| |-----------| 236 | | generated ||-------| |------| |-----|| ESP | |-------| | 237 |Attacker|---------->||Ingress|-|tunnel|---|IPSec||===============| | IPSec | | 238 | | | ||filter | |decap | ^ | || Transport | | | | 239 | | | ||-------| |------| | |-----|| | | |-------| | 240 |--------| | |-------------------|--------| | |-----------| 241 | | | checks the 242 |-------------| |-----------| |-----------| packet 243 |Outer Src=MNN| |Src=HoA | |Src=CoA | using ESP 244 |Outer Dst=MR | |Dst=HA | |Dst=HA | and updates 245 |Src=HoA | |... | |ESP | binding 246 |Dst=HA | |BU(MNP,CoA)| |... | cache 247 |... | |-----------| |BU(MNP,CoA)| 248 |BU(MNP,CoA) | At this point, MR cannot |-----------| 249 |-------------| tell the fake BU from a BU Packet is 250 Attacker generates from itself, and applies encapsulated 251 a fake BU using IPSec ESP. with ESP 252 IP-in-IP tunnel 253 Figure 2. MNN spoofs a BU of MR with ingress filtering 255 3.2 Attacks to MR-HA tunnel 256 Processing IP-in-IP packets in a mobile router requires encapsulation 257 and decapsulation module with a dedicated protocol number. 258 Securing IP-in-IP tunneled packets requires a specific security mechanism 259 like IPsec tunnel mode encapsulation. The attacks to the IP-in-IP tunnel 260 can initiate from inside of the mobile network to MR or from outside 261 directly to HA. We will investigate two attack scenarios using MR and HA 262 as stepping stones. 264 3.2.1 Attack from inside 265 Figure 3 shows an attack scenario from inside nodes. 266 In the scenario, an attacker generates a fake IP-in-IP packet setting the 267 external source address to the address of another MNN inside the mobile 268 network and the external destination address to the address of MR. 269 Inside the encapsulation, the internal source address is set to a spoofed 270 IP address and the internal destination address is set to the address of 271 victim machine. Once the MR receives the packets, the MR decapsulates 272 the packets, and recognizes to process the packets using IP-in-IP 273 encapsulation and forward to the HA. 274 Therefore, the MR encapsulates the inside payload in IP-in-IP format 275 (external source address = CoA of MR, external destination address = 276 address of HA), and sends it to HA. HA forwards the packet to the victim 277 machine. The possible attacks from this scenario are IP spoofing or DoS 278 attack to the victim machine. Similar attacks have been known to mobile 279 network communities for a while, but the main point here is that MR can 280 prevent this attack by checking ingress filtering after the GRE decapsulation. 282 |--------| |--------| IP-in-IP |--------| |--------| 283 | | | | tunnel | | | | 284 | MNN |---------->| MR |==============| HA |-------->| Victim | 285 | | | | | | | | | | | 286 |--------| | |--------| | |--------| | |--------| 287 inside | | | 288 attacker | | |--------------| 289 |--------------| |--------------| |Src=spoofed IP| 290 |Ext. Src=MNN | |Ext. Src=CoA | |Dst=victim | 291 |Ext. Dst=MR | |Ext. Dst=HA | |payload | 292 |Src=spoofed IP| |Src=spoofed IP| |--------------| 293 |Dst=victim | |Dst=victim | 294 |payload | |payload | 295 |--------------| |--------------| 296 generates a spoofed 297 IP packet 299 Figure 3. Inside attack using MR and HA as stepping stone 301 3.2.2 Attack from outside 302 In this scenario, similar attacks can be initiated from outside of a mobile 303 network. Figure 4 shows the attack scenario. 305 In the Figure 4, an attacker from outside can generate a spoofed IP-in-IP 306 packet with setting the external source address to the CoA of MR and the 307 external destination address to the address of HA, which includes a spoofed 308 IP address as the internal source address, and the address of the victim 309 machine as the internal destination address. If the access router of the 310 outside attacker activates ingress filtering, this packet can be dropped at 311 the access router. But many routers without ingress filtering will pass 312 through this packet, and then HA may forward the packet to the victim machine. 313 Due to this security problem, most routers do not process the IP-in-IP packets, 314 but MR and HA in mobile networks should process IP-in-IP packets for 315 forwarding the packets from MNN or CN. 317 |--------| IP-in-IP |--------| |--------| 318 | | tunnel | | | | 319 | MR |==============| HA |--------------->| Victim | 320 | | | | | | | 321 |--------| |--------| | |--------| 322 ^ | 323 | |---------------| 324 | |Src=spoofed IP | 325 |---------------| | |Dst=victim | 326 |Ext. Src=CoA | | |payload | 327 |Ext. Dst=HA | | |---------------| 328 |Src=spoofed IP |-------| 329 |Dst=victim | | 330 |payload | |---|outside 331 |---------------| | |attacker 332 generates a spoofed |---| 333 IP-in-IP packet 335 Figure 4. Outside attack using HA as a stepping stone 337 3.3 Modifications of the signaling messages 338 Some part of the signaling messages between MR and HA are delivered in 339 clear text. Therefore, this type of attacks are mostly related to the 340 modification of the signaling messages between MR and HA. For example, 341 the attacker on the path between MR and HA can modify the destination 342 of BU/BA messages to a wrong destination. The mis-destined messages shall 343 be dropped at the destination. 344 Another type of attacks are possible by modifying the flag option bit 345 (e.g. R bit) of the signaling messages. The modified signaling message 346 can be ignored or processed incorrectly at the destination. 348 4. Threats to interactions among multiple MRs 350 4.1 Attacks to multi-homed MRs 352 In case that two or more MR exists on a mobile subnet for multihoming, 353 there may be multiple bi-directional paths to forward packet to a HA or 354 multiple HAs respectively. 356 If one of the tunnel paths is broken for any reason, the MR(MR1) associated 357 with the faulty path loses Internet connection, and should find an 358 alternative bi-directional tunnel path through another MR2. In this case, 359 MR1 becomes a nested MR of MR2. NEMO basic draft[3] describes that MR SHOULD 360 not respond to the unsolicited RA messages to its egress interface, 361 but according to the MR operations by multihoming draft B.2.2 [6], the MR1 SHOULD 362 listen the RA from alternative MR2 on its ingress interface. 363 At this point, a malicious MR may advertise a RA with a fake CoA to MR1. 364 Then the MR1 will get a wrong CoA information. 366 This threat is not directly related to the NEMO basic operation, but to 367 the inter-MR operations. There is no explicit security mechanism for inter-MR 368 operations for multihoming cases, threats related to inter-MR operations 369 SHOULD be considered. 371 5. DoS attack to MR or HA 373 Attackers can initiate packet flooding attack to MR or HA using the 374 MR-HA tunnel. For example, outside attackers can generate a flood of 375 IP-in-IP packets using topologically correct external source address to 376 avoid ingress filtering at their access routers, and make them delivered 377 to the MR via the MR-HA tunnel. HA (or MR) have no way of filtering this 378 type of packet flooding. 379 This type of attack is also possible from inside of mobile networks, but 380 It is not supposed to be common to initiate flooding attack from inside 381 of the mobile network. 383 References 385 [1] Ernst, T., et al, "Network Mobility Support Goals and 386 Requirements", 387 Internet Draft: draft-ietf-nemo-requirements-02.txt (work in 388 progress), February 2004. 389 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 390 Internet Draft: draft-ietf-nemo-terminology-01.txt (work in 391 Progress), February 2004. 392 [3] Devarapalli V., et al, "NEMO Basic Support Protocol", Internet 393 Draft: draft-ietf-nemo-basic-support-03.txt (work in progress), 394 June 2004. 395 [4] Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility Support 396 in IPv6", RFC 3775, June 2004. 397 [5] Petrescu, A., et al, "Issues in Designing Mobile IPv6 Network 398 Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet 399 Draft: draft-petrescu-nemo-mrha-03.txt (work in progress), 400 October 2003. 402 [6] Ng, C. W. and Tanaka, T., "Analysis of Multihoming in Network Mobility 403 Support", Internet Draft: 404 draft-ietf-nemo-multihoming-issues-00.txt (work in progress), 405 July 2004. 406 [7] Arkko, J. et. al. ,"Using IPsec to Protect Mobile IPv6 Signaling 407 between Mobile Nodes and Home Agents," RFC 3776, June 2004. 408 [8] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 409 (ESP)", RFC 2406, November 1998. 410 [9] Kent, S. and R. Atkinson, "Security Architecture for the 411 Internet Protocol", RFC 2401, November 1998. 412 [10] Kent, S. and R. Atkinson, "IP Authentication Header", 413 RFC 2402, November 1998. 414 [11] A. Petrescu, et. al.,�Threats for Basic Network Mobility Support.� 415 Internet Draft: draft-petrescu-nemo-thretas-01.txt (work in progress), 416 January 2004. 417 [12] S. Cho et. al, �Threat for Multi-homed Mobile Networks,� 418 Internet-Draft: draft-cho-nemo-threat-multihoming-00.txt 419 (work in progress), February 2004. 421 Changes from the previous version 422 1. Added assumptions 423 2. Deleted threats from binding errors 424 3. Added DoS attacks 426 Authors' Addresses 428 Souhwan Jung 429 Soongsil University 430 1-1, Sangdo-dong, Dongjak-ku 431 Seoul 156-743 432 KOREA 433 Phone: +82-2-820-0714 434 EMail: souhwanj@ssu.ac.kr 436 Fan Zhao 437 Department of Computer Science 438 University of California, Davis 439 One Shield Avenue 440 Davis, CA 95616 441 USA 442 Phone: +1-530-752-3128 443 EMail: fanzhao@ucdavis.edu 444 Felix Wu 445 Department of Computer Science 446 University of California, Davis 447 One Shield Avenue 448 Davis, CA 95616 449 USA 450 Phone: +1-530-754-7070 451 EMail: wu@cs.ucdavis.edu 453 HyunGon Kim 454 Network Security Department 455 ETRI 456 161 Kajong-Dong, Yusong-Gu 457 Taejon 305-600 458 KOREA 459 Phone: +82-42-860-5428 460 Email: hyungon@etri.re.kr 462 SungWon Sohn 463 Network Security Department 464 ETRI 465 161 Kajong-Dong, Yusong-Gu 466 Taejon 305-600 467 KOREA 468 Phone: +82-42-860-5072 469 Email: swsohn@etri.re.kr 471 Intellectual Property Statement 473 The IETF takes no position regarding the validity or scope of any 474 intellectual property or other rights that might be claimed to 475 pertain to the implementation or use of the technology described in 476 this document or the extent to which any license under such rights 477 might or might not be available; neither does it represent that it 478 has made any effort to identify any such rights. Information on the 479 IETF's procedures with respect to rights in standards-track and 480 standards-related documentation can be found in BCP-11. Copies of 481 claims of rights made available for publication and any assurances 482 of licenses to be made available, or the result of an attempt made 483 to obtain a general license or permission for the use of such 484 proprietary rights by implementors or users of this specification 485 can be obtained from the IETF Secretariat. 486 The IETF invites any interested party to bring to its attention any 487 copyrights, patents or patent applications, or other proprietary 488 rights which may cover technology that may be required to practice 489 this standard. Please address the information to the IETF Executive 490 Director. 492 Full Copyright Statement 494 Copyright (C) The Internet Society (2003). All Rights Reserved. 496 This document and translations of it may be copied and furnished to 497 others, and derivative works that comment on or otherwise explain it 498 or assist in its implementation may be prepared, copied, published 499 and distributed, in whole or in part, without restriction of any 500 kind, provided that the above copyright notice and this paragraph 501 are included on all such copies and derivative works. However, this 502 document itself may not be modified in any way, such as by removing 503 the copyright notice or references to the Internet Society or other 504 Internet organizations, except as needed for the purpose of 505 developing Internet standards in which case the procedures for 506 copyrights defined in the Internet Standards process must be 507 followed, or as required to translate it into languages other than 508 English. 509 The limited permissions granted above are perpetual and will not be 510 revoked by the Internet Society or its successors or assignees. 511 This document and the information contained herein is provided on an 512 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 513 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 514 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 515 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 516 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.