idnits 2.17.1 draft-suhopark-hello-wsn-00.txt: -(221): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(230): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(260): 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): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 433. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 9 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 8) being 65 lines 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 84 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** There are 9 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 == Line 350 has weird spacing: '... robust acces...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '2' is defined on line 337, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 344, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 349, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 352, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 357, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 359, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 362, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 367, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 370, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 373, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 376, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 379, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Suho Park 2 Expires: June 8, 2006 KT 3 Md. Abdul Hamid 4 Kyung Hee University 5 Choong Seon Hong 6 Kyung Hee University 7 December, 2005 9 Routing Security in Sensor Network: 10 HELLO Flood Attack and Defense 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on June 8, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 In this document, We consider Wireless Sensor Network (WSN) security and 45 focus our attention to tolerate damage caused by an adversary who has 46 compromised deployed sensor node to modify, block, or inject packets. We 47 adopt a probabilistic secret sharing protocol where secrets shared between 48 two sensor nodes are not exposed to any other nodes. Adapting to WSN 49 characteristics, we incorporate these secrets with bidirectional 50 verification and multipath routing to multiple base stations to defend 51 against HELLO flood attacks. We then analytically show that our defense 52 mechanisms against HELLO flood attack can tolerate damage caused by an 53 intruder 54 HELLO Flood Attack and Defense 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . ........... . 2 60 2. Contribution of the Proposal . . . . . . . . . . . . . 3 62 3. Network Assumption and Threat Model . . . . . . . . ... 3 64 4. Key Sharing Protocol . . . . . . . . ................. 3 66 4.1 Secret instantiation by Tree Protocol . . . . .... ... 3 68 4.2 Computing the vulnerability of security. . . . . . . . 4 70 5. Counter Measure against Hello Flood Attacks 71 (Bidirectional Verification). . . . . . ................ 5 73 5.1 Problem of Bidirectional verification... . . . . . . . 6 75 6. Multi-Path Multi-Base Station Data Fowarding. . ...... 6 77 7. Conclusion................................ . . . . . . 7 79 1. Introduction 81 In a large-scale sensor network individual sensors are subject to 82 security compromise. Where the nature of communication is broadcast and, 83 hence, an attacker can overhear messages posted by any sensor node; 84 security is an important issue here. Wireless Sensor Networks (WSNs) are 85 comprised of many small and resource constrained sensor nodes that are 86 deployed in an environment to gather sensed data and forward that data 87 to interested legal users. Advances in micro-electro-mechanical systems 88 (MEMS) technology allow sensors to be reprogrammable, self-localizing, 89 and to support low-energy, wireless, multi-hop networking, while requiring 90 only minimal pre-configuration. To support the reliability of coordinated 91 control, management, and reporting functions, the sensor networks are 92 self-organizing with both decentralized control and autonomous sensor 93 behavior, resulting in a sophisticated processing capability [5]. 94 sinkhole attacks, Sybil attacks, wormholes, HELLO flood attacks, 95 acknowledgement spoofing are well known attacks that try to manipulate 96 sensed data. HELLO flood attack is introduced in [3]. Many protocols 97 require nodes to broadcast HELLO packets to announce themselves to their 98 HELLO Flood Attack and Defense 100 neighbors, and a node receiving such a packet may assume that it is within 101 (normal) radio range of the sender. This assumption may be false: a 102 laptop-class attacker broadcasting routing or other information with 103 large enough transmission power could convince every node in the network 104 that the adversary is its neighbor. In this paper we consider routing security 105 against HELLO flood attack. 107 2. Contribution of the Proposal 109 The main contributions of our proposal are as follows: 110 1. We present probabilistic secret sharing protocol adopted from [1] 111 where, a small increase in the number of secrets maintained by a user 112 substantially reduces the probability of privacy compromise. And it is 113 beneficial for the case where the sensor nodes do not have the capability 114 to hold sufficient secret to ensure privacy. We show how these secrets can 115 be used to route packets in a secured way. 116 2.Then we propose defense mechanisms against HELLO flood attack 117 using the secrets that nodes share among themselves. 119 3. Network Assumption and Threat Model 121 We consider a network composed of moderately large number of resource 122 constrained sensor nodes. We further assume that the sensor nodes are 123 deployed in high density, e.g. battlefield deployments. Each sensor node 124 has a communication range such that if the distance between two sensors is 125 more than this range, they can not communicate. We also assume that the 126 communications channels are bidirectional, i.e. if a node y can receive a 127 message from z, then it can also send a message to z. 128 We assume that an adversary can pose the following threat: 129 �An attacker can cause a HELLO flood attack by advertising a very high 130 quality route to the base station. So, every node in the network could 131 cause a large number of nodes to attempt to use this route thereby sending 132 the legitimate packets beyond the actual destination. 134 4. Key Sharing Protocol 136 In this section, we present the probabilistic protocol, the tree 137 protocol, for assigning the initial secrets. We will describe the 138 single tree protocol and then compute the multiple trees based key 139 assignment. 141 4.1 Secret instantiation by Tree Protocol 143 We present single tree and then multiple tree protocol. For each of these 144 versions, we first identify the secret distribution protocol that determines 145 the secrets that each user should get. Then, we present the secret selection 146 protocol; when two users need to communicate, they use this protocol to 147 determine a shared secret that they should use. Subsequently, we compute the 148 probability of compromise. 150 HELLO Flood Attack and Defense 152 K1 153 / \ 154 / \ 155 K2 K3 156 / \ / \ 157 K4 K5 K6 K7 158 / \ / \ / \ / \ 159 S1S2S3 S4 S5 S6S7 S8 161 Fig. 1. Single tree key assignment 163 We organize the secrets in a tree (Fig. 1). Each non-leaf node is associated 164 with a secret and each leaf is associated with a sensor node. Each sensor node 165 is assigned an ID that identifies its location in the tree. Finally each sensor 166 node is provided the secrets along the path towards the root. Thus, node s1 167 has the secrets, k1, k2 and k4. 169 When two nodes, say, s1 and s2, want to exchange messages during their 170 effective communication, they first exchange their identities. Then, they 171 identify their least common ancestor and based on the secret distribution 172 mechanism, the common secret associated with this ancestor will be available 173 to both s1 and s2. So, the secret associated with the ancestor will be used 174 for communication between s1 and s2. For example, two nodes s1 and s2 want 175 to communicate then they will use secret key k4 whereas if s1 and s5 want to 176 communicate then they will use secret key k1. 178 4.2 Computing the vulnerability of security 180 Let x be an intruder that can observe the communication between any two 181 arbitrary nodes y and z. We calculate what is the probability that x knows 182 the shared secret that y and z use. During this analysis, let the degree of 183 the secret-tree be d. Now, we consider different cases based on the shared 184 secret that y and z use during communication. First, we consider the 185 probability that y and z use the secret at the root (level 1). Such a 186 situation arises if z is not a descendant of the level-2-ancestor of y. 187 Thus, the probability of this case is d - 1/d. And, in this case, the 188 probability that x is aware of the secret that y and z use is 1; all users 189 in the secret-tree have the secret associated with the root. Next, we 190 consider the probability that y and z use the secret at level 2 in the tree. 191 Such a situation arises if z is a descendant of the level-2-ancestor of y 192 and z is not a descendant of the level-3-ancestor of y. Thus, the probability 193 of this case is 1/d X (d - 1)/d. Moreover, x is aware of the shared secret 194 between y and z iff x is a descendant of the level-2-ancestor of y. Thus, 195 the probability of this case is 1/d.Continuing thus, the probability of 196 compromise, pc, that x is aware of the shared secret used by y and z is 197 d/(d+1). 199 Multiple Tree Protocol: Secret distribution is the same as single tree protocol 200 with one exception where the position of all sensor nodes is not identical. 201 Because, Clearly, if we use two trees where the position of all users is 202 HELLO Flood Attack and Defense 204 identical and if x knows the secret (used by y and z) in the first tree then, 205 by definition, x will know the secret in the second tree. Hence, when we use 206 multiple trees to reduce the probability of compromise the probability that x 207 knows the secret in one secret-tree should be independent of the probability 208 that l knows the secret in another tree. This can be achieved if there is no 209 correlation between the locations of a sensor node across two trees. Given T 210 secret-trees, each with degree d, the probability that x knows secrets from 211 all the trees is (d/(d + 1))T. 213 5. Counter Measure against Hello Flood Attacks (Bidirectional Verification) 215 Many protocols require nodes to broadcast HELLO packets to announce 216 themselves to their neighbors, and a node receiving such a packet may assume 217 that it is within (normal) radio range of the sender. This assumption may be 218 false: a laptop-class attacker broadcasting routing or other information 219 with large enough transmission power could convince every node in the network 220 that the adversary is its neighbor. To launch this kind of attack, an 221 adversary�s packet sending range must be bigger than a normal node�s sending 222 range. If each sensor node constructs a set of reachable neighbor nodes, and 223 is only willing to receive REQ messages from this set of neighbor nodes, then 224 REQ messages from an adversary transmitted with larger power will be ignored. 225 Thus, the damage from a HELLO flood attack can be restricted within a small 226 range. 227 To defend against attack, each request (REQ) message forwarded by a node is 228 encrypted with a key. As we have shown from the tree protocol that any two 229 sensor nodes share some common secrets, the new encryption key is generated 230 on-the-fly (i.e. during communication). In this way, any node�s reachable 231 neighbors can decrypt and verify the REQ message while the attacker will not 232 know the key and will be prevented from launching the attack. We show that the 233 new key combined with the echo-back mechanism can well protect this attack. 234 We see that the message exchange won�t be blocked by an adversary when 235 bidirectional verification is applied. 237 Each node locally broadcasts an echo message to its neighbor with format: 238 s1-->: ECHO||Enew-key (IDs1||nonce) 239 Where, ECHO is the message type, ID is the ID of the sensor node s1, 240 nonce is the random number. If a node, say, s2 receives this message, 241 it sends echo reply with format: 242 S2-->s1: ECHOBACK||Enew-key (IDs2||nonce). 243 When node s1 receives this message, it records node s2 as its verified neighbor. 244 If an attacker obtains the shared secrets after a node has received its new 245 encrypted key, it can not know the new pairwise key. Computing the pairwise 246 key is more robust and secure in multiple tree protocol as we have described 247 earlier, where we have shown that the probability of compromise of a secret is 248 very low. However, if an attacker obtains the new key, it can initiate echo-back 249 many times by sending several echo messages. The attacker can generate false 250 identities and can initiate Sybil attack, adding new nodes with false 251 identities. To prevent such attacks, node should destroy its new key from 252 memory after a certain time that is long enough to set up pairwise keys with 253 all its neighbors. Again, during communication, it can calculate new key from 254 the secrets they share. 256 HELLO Flood Attack and Defense 258 5.1 Problem of Bidirectional verification 260 As we have stated that this defense against �HELLO flood?attack is to 261 verify the bidirectionality of a link before taking meaningful action 262 based on a message received over that link. But, this defense gets less 263 effectiveness when an attacker has a highly sensitive receiver as well as 264 a powerful transmitter. If an attacker compromises a node before the 265 feedback message, it can block all its downstream nodes by simple dropping 266 feed back messages. And thus, such an attacker can easily create a 267 wormhole to every node within range of its transmitter/receiver. 268 Since the links between these nodes and attacker are bidirectional, 269 the above approach will unlikely be able to locally detect or prevent 270 a �HELLO flood? We propose a different way of reliable exchange of 271 messages among nodes and base stations. We show that when any particular 272 node has different route to send data, this problem is solved. 274 6. Multi-Path Multi-Base Station Data Fowarding 276 We describe how a sensor node can forward its sensed data to multiple 277 routes i.e. multiple base stations in case where an attacker manages to 278 compromise a sensor node. We assume that, there are a number of base 279 stations in the network who have control over specific number of nodes 280 and also, there are common means of communications among base stations. 281 Each base station has all the secrets those are shared by all the sensor 282 nodes according to the key assignment protocol described earlier.Given 283 the shared secrets and the generated new key between two sensor nodes, 284 the operation of setting up different routing paths is as follows: 286 Step 1: As each sensor node shares some common keys according to the 287 secret distribution protocol (i.e. Multiple Tree Protocol), every node 288 uses the echo-back scheme to identify its neighbor nodes and sets up 289 pairwise new key with its verified neighbor nodes. Then it uses its new 290 key to exchange messages among them. 292 Step 2: Each base station broadcasts its request (REQ) message to its 293 neighbor nodes with the following format: 295 REQ||IDs||Ekey(IDB||HCN) 297 Here, REQ is the message type, IDs is the ID of the sending node s, 298 IDB is the base station ID who generated this request message, Ekey is 299 the key that is common between any node to which base station floods 300 the message and HCN is the base station�s one-way hash chain number. 301 Receiving node verifies that the REQ comes from the base station, then 302 it forwards the REQ to its neighbor node, say, y, with the format: 304 REQ||IDy||Enew-key(IDB||HCN) 306 Step 3: When any ordinary node say, y, receives this REQ message, it 307 checks the sender ID. If s is y�s verified neighbor, y decrypts and 308 authenticates the sender with computed new key Enew-key. If the message 309 sender is valid, it replaces the HCN with the new value and encrypts the 310 HELLO Flood Attack and Defense 312 REQ message with its Enew-key and broadcasts the newly encrypted message. 313 For example, where four base stations with their 314 communication range and sensor nodes with their communication range, 315 if any message comes from a malicious node, the message won�t be 316 forwarded to that node, instead, the sensing node will take a different 317 route to send data. Any base station, when receives the sensed data, 318 it can cooperate with other base stations to interpret the sensed data as 319 base station is powerful enough to communicate among themselves. 321 7. Conclusion 323 Our work described the defense against HELLO flood attack by introducing 324 bidirectional verification and multi path routing using shared secret 325 between sensor nodes. We have adopted a probabilistic key assignment 326 among sensor nodes and during communication, each node can calculate a 327 pairwise key using these common secrets and hence improving the network 328 resilience against security threats. The key objective of our approach 329 is to tolerate damage caused by an adversary who has captured deployed 330 sensor nodes and is intent on injecting, modifying or blocking packets. 332 REFERENCES 334 [1] S. S. Kulkarni, M. G. Gouda, and A. Arora, Secret instantiation 335 in ad-hoc networks, Special Issue of Elsevier Journal of Computer 336 Communications on Dependable Wireless Sensor Networks, pp. 1-5, May 2005. 337 [2] F. Ye, H. Luo, S. Lu, and L. Zhang, Statistical En-Route Filtering 338 of Injected False Data in Sensor Networks, IEEE Journal on Selected 339 Areas in Communications, vol. 23, no. 4, April 2005. 340 [3] C. Karlof and D.Wagner, Secure routing in wireless sensor networks: 341 Attacks and countermeasures,Elsevier AdHoc Networks Journal, Special 342 Issue on Sensor Network Applications and Protocols, 1(2):293-315, 343 September 2003. 344 [4] R. Di Pietro, L. V. Mancini, and S. Jajodia, Providing secrecy in 345 key management protocols for large wireless sensors networks, Journal 346 of AdHoc Networks, 1(4), pp.455-468, 2003. 347 [5] V. Wen, A. Perrig, and R. Szewczyk, SPINS: Security suite for sensor 348 networks, in Proc. ACM MobiCom, pp. 189?99, 2001. 349 [6] H. Luo, J. Kong, P. Zerfos, S. Lu, and L. Zhang, URSA: Ubiquitous 350 and robust access control for mobile ad hoc networks,?Proc. IEEE/ACM 351 Trans. Netw., vol. 12, no. 6, pp. 1049?063, Oct. 2004. 352 [7] A. Arora, P. Dutta, S. Bapat, V. Kulathumani, H. Zhang, V. Naik, V. 353 Mittal, H. Cao, M. Demirbas, M. Gouda, Y. Choi, and et al., A Line in 354 the Sand: A Wireless Sensor Network for Target Detection, Classification, 355 and Tracking, Computer Networks (Elsevier), Special Issue on Military 356 Communications Systems and Technologies, 46(5):pp.605-634, December 2004. 357 [8] J.R. Douceur, The Sybil attack, in: 1st International Workshop on 358 Peer-to-Peer Systems (IPTPS _02), 2002. 359 [9] Y. Hu, A. Perrig, and D. Johnson, Rushing attacks and defense in 360 wireless ad hoc network routing protocols, Proceedings of the Second ACM Workshop on 361 Wireless Security (WiSe03), San Diego, CA, USA, September 2003. 362 [10] H. Chan, A. Perrig, D. Song, Random key predistribution schemes 363 for sensor networks, IEEE Symposium on Security and Privacy, 2003. 365 HELLO Flood Attack and Defense 367 [11] W. Du, J. Deng, Y. Han, P. Varshney, pairwise key pre-distribution 368 scheme for wireless sensor networks, ACM Conference on Computer and 369 Communications Security (CCS), pp. 42-51, 2003. 370 [12] Y. Zhang, W. Lee, Intrusion detection in wireless ad hoc networks, 371 ?in: Proceedings of the Sixth Annual International Conference on Mobile 372 Computing and Networking, pp. 275-283, 2000. 373 [13] S. Yi, P. Naldurg, R. Kravets, Security-aware ad hocrouting for 374 wireless networks, Proceedings of the 2001 ACM International Symposium 375 on Mobile Ad Hoc Networking and Computing, ACM Press, New York, 376 [14] D. Braginsky, D. Estrin, Rumour routing algorithm for sensor 377 networks, Proceedings of First ACM International Workshop on Wireless Sensor 378 Networks and Applications, 2002. 379 [15] A. Manjeshwar, D. Agrawal, TEEN: a routing protocol for enhanced 380 efficiency in wireless sensor networks, Proceedings of 1st International Workshop 381 on Parallel and Distributed Computing Issues in Wireless Networks and 382 Mobile Computing, 2001. 384 AUTHOR'S ADDRESS 386 Questions about this document can also be directed to the author: 388 Suho Park 389 Next Generation Internet Division 390 Future Technology Research Department 391 KT Advanced Technology Laboratory 392 1 woomyun, secho, Seoul, Korea 393 Tel : +82 526-5479 394 suhopark@kt.co.kr 396 Md. Abdul Hamid 397 Networking Lab 398 Department of Computer Engineering 399 Kyung Hee University 400 1 Seocheon, Giheung, Yongin, Gyeongi-Do, 449-701, Korea 401 Email: hamid@networking.khu.ac.kr 403 Choong Seon Hong 404 Department of Computer Engineering 405 Kyung Hee University 406 1 Seocheon, Giheung, Yongin, Gyeongi-Do, 449-701, Korea 407 E-mail : cshong@khu.ac.kr 409 Intellectual Property Statement 411 The IETF takes no position regarding the validity or scope of any 412 Intellectual Property Rights or other rights that might be claimed to 413 pertain to the implementation or use of the technology described in 414 this document or the extent to which any license under such rights 415 might or might not be available; nor does it represent that it has 416 made any independent effort to identify any such rights. Information 417 on the procedures with respect to rights in RFC documents can be 418 found in BCP 78 and BCP 79. 420 Copies of IPR disclosures made to the IETF Secretariat and any 421 assurances of licenses to be made available, or the result of an 422 attempt made to obtain a general license or permission for the use of 423 such proprietary rights by implementers or users of this 424 specification can be obtained from the IETF on-line IPR repository at 425 http://www.ietf.org/ipr. 427 HELLO Flood Attack and Defense 429 The IETF invites any interested party to bring to its attention any 430 copyrights, patents or patent applications, or other proprietary 431 rights that may cover technology that may be required to implement 432 this standard. Please address the information to the IETF at 433 ietf-ipr@ietf.org. 435 Disclaimer of Validity 437 This document and the information contained herein are provided on an 438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 439 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 440 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 441 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 442 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 445 Copyright Statement 447 Copyright (C) The Internet Society (2005). This document is subject 448 to the rights, licenses and restrictions contained in BCP 78, and 449 except as set forth therein, the authors retain all their rights. 451 Acknowledgment 453 Funding for the RFC Editor function is currently provided by the 454 Internet Society.