File: rfc2521.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (508 lines) | stat: -rw-r--r-- 14,637 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508






Network Working Group                                            P. Karn
Request for Comments: 2521                                      Qualcomm
Category: Experimental                                        W. Simpson
                                                              DayDreamer
                                                              March 1999


                    ICMP Security Failures Messages


Status of this Memo

   This document defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  Copyright (C) Philip Karn
   and William Allen Simpson (1994-1999).  All Rights Reserved.

Abstract

   This document specifies ICMP messages for indicating failures when
   using IP Security Protocols (AH and ESP).

























Karn & Simpson                Experimental                      [Page i]

RFC 2521                 ICMP Security Failures               March 1999


Table of Contents


     1.     Introduction ..........................................    1

     2.     Message Formats .......................................    1
        2.1       Bad SPI .........................................    2
        2.2       Authentication Failed ...........................    2
        2.3       Decompression Failed ............................    2
        2.4       Decryption Failed ...............................    2
        2.5       Need Authentication .............................    3
        2.6       Need Authorization ..............................    3

     3.     Error Procedures ......................................    3

     SECURITY CONSIDERATIONS ......................................    4

     HISTORY ......................................................    5

     ACKNOWLEDGEMENTS .............................................    5

     REFERENCES ...................................................    5

     CONTACTS .....................................................    6

     COPYRIGHT ....................................................    7

























Karn & Simpson                Experimental                     [Page ii]

RFC 2521                 ICMP Security Failures               March 1999


1.  Introduction

   This mechanism is intended for use with the Internet Security
   Protocols [RFC-1825 et sequitur] for authentication and privacy.  For
   statically configured Security Associations, these messages indicate
   that the operator needs to manually reconfigure, or is attempting an
   unauthorized operation.  These messages may also be used to trigger
   automated session-key management.

   The datagram format and basic facilities are already defined for ICMP
   [RFC-792].

   Up-to-date values of the ICMP Type field are specified in the most
   recent "Assigned Numbers" [RFC-1700].  This document concerns the
   following values:

       40  Security Failures



2.  Message Formats

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |          Pointer              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~     Original Internet Headers + 64 bits of Payload            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type              40

   Code             Indicates the kind of failure:

                      0 = Bad SPI
                      1 = Authentication Failed
                      2 = Decompression Failed
                      3 = Decryption Failed
                      4 = Need Authentication
                      5 = Need Authorization


   Checksum         Two octets.  The ICMP Checksum.

   Reserved         Two octets.  For future use; MUST be set to zero



Karn & Simpson                Experimental                      [Page 1]

RFC 2521                 ICMP Security Failures               March 1999


                    when transmitted, and MUST be ignored when received.

   Pointer          Two octets.  An offset into the Original Internet
                    Headers that locates the most significant octet of
                    the offending SPI.  Will be zero when no SPI is
                    present.

   Original Internet Headers ...
                    The original Internet Protocol header, any
                    intervening headers up to and including the
                    offending SPI (if any), plus the first 64 bits (8
                    octets) of the remaining payload data.

                    This data is used by the host to match the message
                    to the appropriate process.  If a payload protocol
                    uses port numbers, they are assumed to be in the
                    first 64-bits of the original datagram's payload.

   Usage of this message is elaborated in the following sections.


2.1.  Bad SPI

   Indicates that a received datagram includes a Security Parameters
   Index (SPI) that is invalid or has expired.


2.2.  Authentication Failed

   Indicates that a received datagram failed the authenticity or
   integrity check for a given SPI.

   Note that the SPI may indicate an outer Encapsulating Security
   Protocol when a separate Authentication Header SPI is hidden inside.


2.3.  Decompression Failed

   Indicates that a received datagram failed a decompression check for a
   given SPI.


2.4.  Decryption Failed

   Indicates that a received datagram failed a decryption check for a
   given SPI.





Karn & Simpson                Experimental                      [Page 2]

RFC 2521                 ICMP Security Failures               March 1999


2.5.  Need Authentication

   Indicates that a received datagram will not be accepted without
   additional authentication.

   In this case, either no SPI is present, or an unsuitable SPI is
   present.  For example, an encryption SPI without integrity arrives
   from a secure operating system with mutually suspicious users.


2.6.  Need Authorization

   Indicates that a received datagram will not be accepted because it
   has insufficient authorization.

   In this case, an authentication SPI is present that is inappropriate
   for the target transport or application.  The principle party denoted
   by the SPI does not have proper authorization for the facilities used
   by the datagram.  For example, the party is authorized for Telnet
   access, but not for FTP access.


3.  Error Procedures

   As is usual with ICMP messages, upon receipt of one of these error
   messages that is uninterpretable or otherwise contains an error, no
   ICMP error message is sent in response.  Instead, the message is
   silently discarded.  However, for diagnosis of problems, a node
   SHOULD provide the capability of logging the error, including the
   contents of the silently discarded datagram, and SHOULD record the
   event in a statistics counter.

   On receipt, special care MUST be taken that the ICMP message actually
   includes information that matches a previously sent IP datagram.
   Otherwise, this might provide an opportunity for a denial of service
   attack.

   The sending implementation MUST be able to limit the rate at which
   these messages are generated.  The rate limit parameters SHOULD be
   configurable.  How the limits are applied (such as, by destination or
   per interface) is left to the implementor's discretion.










Karn & Simpson                Experimental                      [Page 3]

RFC 2521                 ICMP Security Failures               March 1999


Security Considerations

   When a prior Security Association between the parties has not
   expired, these messages SHOULD be sent with authentication.

   However, the node MUST NOT dynamically establish a new Security
   Association for the sole purpose of authenticating these messages.
   Automated key management is computationally intensive.  This could be
   used for a very serious denial of service attack.  It would be very
   easy to swamp a target with bogus SPIs from random IP Sources, and
   have it start up numerous useless key management sessions to
   authentically inform the putative sender.

   In the event of loss of state (such as a system crash), the node will
   need to send failure messages to all parties that attempt subsequent
   communication.  In this case, the node may have lost the key
   management technique that was used to establish the Security
   Association.

   Much better to simply let the peers know that there was a failure,
   and let them request key management as needed (at their staggered
   timeouts).  They'll remember the previous key management technique,
   and restart gracefully.  This distributes the restart burden among
   systems, and helps allow the recently failed node to manage its
   computational resources.

   In addition, these messages inform the recipient when the ICMP sender
   is under attack.  Unlike other ICMP error messages, the messages
   provide sufficient data to determine that these messages are in
   response to previously sent messages.

   Therefore, it is imperative that the recipient accept both
   authenticated and unauthenticated failure messages.  The recipient's
   log SHOULD indicate when the ICMP messages are not validated, and
   when the ICMP messages are not in response to a valid previous
   message.

   There is some concern that sending these messages may result in the
   leak of security information.  For example, an attacker might use
   these messages to test or verify potential forged keys.  However,
   this information is already available through the simple expedient of
   using Echo facilities, or waiting for a TCP 3-way handshake.

   The rate limiting mechanism also limits this form of leak, as many
   messages will not result in an error indication.  At the very least,
   this will lengthen the time factor for verifying such information.





Karn & Simpson                Experimental                      [Page 4]

RFC 2521                 ICMP Security Failures               March 1999


History

   The text has been extensively reviewed on the IP Security mailing
   list, in January and February of 1995 and again in December 1995.
   The specification is stable, and was forwarded to the IESG by the
   authors for IETF Last Call as a Proposed Standard in March 1996.
   There have been several implementations.


Acknowledgements

   Some of the text of this specification was derived from "Requirements
   for Internet Hosts -- Communication Layers" [RFC-1122] and
   "Requirements for IP Version 4 Routers" [RFC-1812].

   Naganand Doraswamy and Hilarie Orman provided useful critiques of
   earlier versions of this document.

   Stimulating comments were also received from Jeffrey Schiller.

   Special thanks to the Center for Information Technology Integration
   (CITI) for providing computing resources.


References

   [RFC-792]   Postel, J., "Internet Control Message Protocol", STD 5,
               September 1981.

   [RFC-1122]  Braden, R., Editor, "Requirements for Internet Hosts --
               Communication Layers", STD 3, USC/Information Sciences
               Institute, October 1989.

   [RFC-1700]  Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
               USC/Information Sciences Institute, October 1994.

   [RFC-1812]  Baker, F., Editor, "Requirements for IP Version 4
               Routers", Cisco Systems, June 1995.

   [RFC-1825]  Atkinson, R., "Security Architecture for the Internet
               Protocol", Naval Research Laboratory, July 1995.










Karn & Simpson                Experimental                      [Page 5]

RFC 2521                 ICMP Security Failures               March 1999


Contacts

   Comments about this document should be discussed on the
   photuris@adk.gr mailing list.

   Questions about this document can also be directed to:

      Phil Karn
      Qualcomm, Inc.
      6455 Lusk Blvd.
      San Diego, California  92121-2779

          karn@qualcomm.com
          karn@unix.ka9q.ampr.org (preferred)


      William Allen Simpson
      DayDreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

          wsimpson@UMich.edu
          wsimpson@GreenDragon.com (preferred)



























Karn & Simpson                Experimental                      [Page 6]

RFC 2521                 ICMP Security Failures               March 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  Copyright (C) Philip
   Karn and William Allen Simpson (1994-1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain
   it or assist in its implementation may be prepared, copied,
   published and distributed, in whole or in part, without restriction
   of any kind, provided that the above copyright notice and this
   paragraph are included on all such copies and derivative works.
   However, this document itself may not be modified in any way, such
   as by removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed for the
   purpose of developing Internet standards (in which case the
   procedures for copyrights defined in the Internet Standards process
   must be followed), or as required to translate it into languages
   other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Karn & Simpson                Experimental                      [Page 7]