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
|
<pre>Network Working Group J. Luciani
Request for Comments: 2520 Nortel Networks
Category: Experimental H. Suzuki
Cisco Systems
N. Doraswamy
Nortel Networks
D. Horton
CiTR Pty Ltd
February 1999
<span class="h1">NHRP with Mobile NHCs</span>
Status of this Memo
This memo 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). All Rights Reserved.
Abstract
This document describes an extension to NHRP [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>] which would allow
Mobile NHCs to perform a registration with and attach to an NHS in
their home LIS in an authenticated manner.
As described in this document, Mobile NHCs are NHCs which are not
configured with enough information to find a specific serving NHS in
their home LIS, but which have a mechanism to find an NHS (which may
or may not be a serving NHS) to which they will attach. As described
in [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>], an NHC may attach to a 'surrogate' NHS by using a mechanism
such as an anycast address. In this case, the NHC may use the
surrogate NHS to send a NHRP Registration Request toward the NHC's
home LIS where a serving NHS resides. However, as defined in [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>],
packet authentication is performed on a hop by hop basis. In the
mobile NHC case, it is not practical for the mobile NHC be in a
security relationship with every surrogate NHS, thus it is presumably
desirable to have some form of end to end only authentication for the
case of a mobile NHC's registration. This document describes an
authentication extension for NHRP which has such end to end only
semantics.
<span class="grey">Luciani, et al. Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2520">RFC 2520</a> NHRP with Mobile NHCs February 1999</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [<a href="#ref-4" title=""Key words for use in RFCs to Indicate Requirement Levels"">4</a>].
This document describes an extension for Mobile NHCs to use when they
wish to register with their home LIS but initially connect to a non-
serving NHS to do so. The reader is encouraged to read [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>] for more
details on the NHRP registration process.
<span class="h3"><a class="selflink" id="section-2.0" href="#section-2.0">2.0</a> Definition of the NHRP Mobile NHC Authentication Extension</span>
Compulsory = 1
Type = 10 (proposed)
Length = variable
The NHRP Mobile NHC Authentication Extension is carried in NHRP
Registration packets to convey end to end authentication Information.
This extension is defined in contrast to the NHRP Authentication
Extension defined in [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>] which has hop by hop semantics.
This new extension is used when a mobile NHC initially connects to an
NHS which is not one of its serving NHSs and the mobile NHC and
nonserving NHS are not in a security relationship. The mobile NHC
does this in order to send an NHRP Registration Request, via normal
routing and forwarding processes, to one of its serving NHSs with
which it does have a security relationship. As defined in [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>], a
serving NHS is an NHS in the NHC's home LIS with which the NHC will
register. Upon receiving such an NHRP Registration Request, the
serving NHS will do the following: authenticate the sender NHC, set
up a VC to the NHC, and then send an NHRP Resolution Reply in
response on that new VC.
Note that, as defined in [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>], a transit NHS (such as the one to which
the mobile NHC initially connects) must ignore an extension which it
does not understand and that an NHS must not change the order of
extensions in an NHRP packet. Thus, the end to end semantics of this
extension are preserved without causing changes to existing
implementations.
If a serving NHS receives a packet which fails the hop by hop
authentication test defined in [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>] then the NHS MUST generate an
Error Indication of type 'Authentication Failure' and discard the
packet. However in the case where the NHRP Mobile NHC Authentication
Extension is used as described above, sending an Error Indication is
not possible since no route exists back toward the mobile NHC
assuming a VC does not already exist between the mobile NHC and the
<span class="grey">Luciani, et al. Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2520">RFC 2520</a> NHRP with Mobile NHCs February 1999</span>
serving NHS which received the NHRP Registration Request. In this
case, the NHRP Registration Request is merely dropped.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Header Format</span>
The authentication header has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameter Index (SPI) can be thought of as an index into a
table that maintains the keys and other information such as a hash
algorithm. Src and Dst communicate either offline using manual keying
or online using a key management protocol to populate this table. The
sending NHRP entity always allocates the SPI and the parameters
associated with it.
The Src Addr field is a variable length field which contains the
address assigned to the outgoing interface. The length of the field
is obtained from the source protocol length field in the mandatory
part of the NHRP header. The tuple <spi, src addr> uniquely
identifies the key and the other parameters that are used in
authentication.
The length of the authentication data field is dependent on the hash
algorithm used. The Authentication Data field contains the keyed hash
calculated over the following fields: fixed part (with hop count,
packet size and checksum being treated as if set to zero), mandatory
part, and extensions up to and including the Mobile NHC
Authentication extension.
Note that [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>] defines an explicit ordering of extensions such that:
(a) If the Responder Address extension exists then it must appear
before the Authentication Extension.
(b) Any extensions that may be modified in transit (e.g., Forward
Transit Extension, Hop by Hop Authentication Extension) must
appear after the Mobile NHC Authentication Extension.
<span class="grey">Luciani, et al. Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2520">RFC 2520</a> NHRP with Mobile NHCs February 1999</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> SPI and Security Parameters Negotiation</span>
SPI's can be negotiated either manually or using an Internet Key
Management protocol. Manual keying MUST be supported. The following
parameters are associated with the tuple <SPI, src>- lifetime,
Algorithm, Key. Lifetime indicates the duration in seconds for which
the key is valid. In case of manual keying, this duration can be
infinite. Also, in order to better support manual keying, there may
be multiple tuples active at the same time (Dst being the same).
Algorithm specifies the hash algorithm agreed upon by the two
entities. HMAC-MD5-128 [<a href="#ref-2" title=""HMAC: Keyed Hashing for Message Authentication"">2</a>] is the default algorithm and MUST be
implemented. Other algorithms MAY be supported by defining new
values. IANA will assign the numbers to identify the algorithm being
used as described in [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>].
Any Internet standard key management protocol MAY so be used to
negotiate the SPI and parameters.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a> Message Processing</span>
Unauthenticated 'Mobile' Registration Request processing proceeds as
follows [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>]:
- the NHC inserts the internetwork address of a serving NHS in the
'Destination Protocol Address' field; If the NHS address is
unknown, then the NHC inserts its own internetwork address. A '
responder address' extension is optionally added.
- the non-serving NHS forwards the packet along the routed path
based on the contents of the 'Destination Protocol Address'
field.
- the serving NHS which receives the NHRP Registration Request
will set up a direct VCC to NHC after authenticating the request
- the serving NHS will then send the NHRP Registration Reply back
to the NHC on that new VCC. Note that the NHS MUST wait some
configured interval before doing this reply in order to prevent
a race condition from occurring between the VC setup and sending
the NHRP reply packet.
- the NHC will subsequently send all NHRP traffic to the serving
NHS on the direct VCC.
<span class="grey">Luciani, et al. Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2520">RFC 2520</a> NHRP with Mobile NHCs February 1999</span>
When the NHC adds the authentication extension header, it performs a
table look up in order to fetch the SPI and the security parameters
based on the outgoing interface address. If there are no entries in
the table and if there is support for key management, the NHC
initiates the key management protocol to fetch the necessary
parameters. The NHC constructs the Authentication Extension payload
and calculates the hash by zeroing out the authentication data field.
The result is placed in the authentication data field. The src
address field in the payload is the internetwork address assigned to
the outgoing interface.
If key management is not supported and authentication is mandatory,
the packet is dropped and this information is logged.
On the receiving end, the serving NHS fetches the parameters based on
the SPI and the internetwork address in the authentication extension
payload. The authentication data field is extracted before being
zeroed out in order to calculate the hash. It computes the hash on
the entire payload and if the hash does not match, then an "abnormal
event" has occurred.
The keys used by the mobile NHC for communicating with the serving
NHS in NHRP Registration Requests can be used in subsequent
resolution and purge requests made directly to the serving NHS after
receiving the NHRP Registration Reply. However, the authentication
extension defined in [<a href="#ref-1" title=""NBMA Next Hop Resolution Protocol (NHRP)"">1</a>] MUST be used when these keys are applied to
resolution and purge packets.
Hop by Hop Authentication[1] and End to End authentication MAY be
used in combination to provide protection against both spoofing and
denial of service attacks. If only an end-to-end Mobile NHC
Authentication Extension is present, it MAY be the policy of each
transit NHS to reject the NHRP Registration Request based on the
requirement for having a Hop by Hop authentication present. Such a
requirement is a local matter.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a> Security Considerations</span>
It is important that the keys chosen are strong since the security of
the entire system depends on the keys being chosen properly.
End-to-end authentication counters spoofing attacks on the home
subnet through not relying on the potentially compromised chain of
trust. The use of end-end authentication is further described in [<a href="#ref-3" title=""IP Mobility Support"">3</a>].
Hop-by-hop authentication prevents denial of service attacks by
introducing access control at the first point of contact to the NHRP
infrastructure.
<span class="grey">Luciani, et al. Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2520">RFC 2520</a> NHRP with Mobile NHCs February 1999</span>
The security of this extension is performed on an end to end basis.
The data received can be trusted only so much as one trusts the end
point entities in the path traversed. A chain of trust is established
amongst NHRP entities in the path of the NHRP Message. If the
security in an NHRP entity is compromised, then security in the
entire NHRP domain is compromised.
Data integrity covers the entire NHRP payload up to and including the
Mobile NHC Authentication Extension. This guarantees that the data
and extensions covered by this authentication hash were not modified
and that the source is authenticated as well. If the authentication
extension is not used or if the security is compromised, then NHRP
entities are liable to both spoofing attacks, active attacks, and
passive attacks.
There is no mechanism to encrypt the messages. It is assumed that a
standard layer 3 confidentiality mechanism will be used to encrypt
and decrypt messages. It is recommended to use an Internet standard
key management protocol to negotiate the keys between the neighbors.
Transmitting the keys in clear text, if other methods of negotiation
is used, compromises the security completely.
References
[<a id="ref-1">1</a>] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy,
"NBMA Next Hop Resolution Protocol (NHRP)", <a href="./rfc2332">RFC 2332</a>, April 1998.
[<a id="ref-2">2</a>] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing
for Message Authentication", <a href="./rfc2104">RFC 2104</a>, February 1997.
[<a id="ref-3">3</a>] Perkins, C., "IP Mobility Support", <a href="./rfc2002">RFC 2002</a>, October 1996.
[<a id="ref-4">4</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="grey">Luciani, et al. Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2520">RFC 2520</a> NHRP with Mobile NHCs February 1999</span>
Authors' Addresses
James V. Luciani
Nortel Networks
3 Federal Street
Mail Stop: BL3-03
Billerica, MA 01821
Phone: +1 978 916 4734
EMail: luciani@baynetworks.com
Hiroshi Suzuki
Cisco Systems
170 West Tasman Dr.
San Jose, CA 96134
Phone: +1 408 525 6006
EMail: hsuzuki@cisco.com
Naganand Doraswamy
Nortel Networks
3 Federal Street
Mail Stop: BL3-03
Billerica, MA 01821
Phone: +1 978 916 4734
EMail: naganand@baynetworks.com
David Horton
CiTR PTY Ltd
Level 2 North Tower
339 Coronation Drive
Milton, Australia 4064
Phone: +61 7 32592222
EMail: d.horton@citr.com.au
<span class="grey">Luciani, et al. Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2520">RFC 2520</a> NHRP with Mobile NHCs February 1999</span>
Full Copyright Statement
Copyright (C) The Internet Society (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 DISCLAIMS 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.
Luciani, et al. Experimental [Page 8]
</pre>
|
