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
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
|
<pre>Internet Engineering Task Force (IETF) J-M. Combes
Request for Comments: 5909 France Telecom Orange
Category: Informational S. Krishnan
ISSN: 2070-1721 Ericsson
G. Daley
Netstar Logicalis
July 2010
<span class="h1">Securing Neighbor Discovery Proxy: Problem Statement</span>
Abstract
Neighbor Discovery Proxies are used to provide an address presence on
a link for nodes that are no longer present on the link. They allow
a node to receive packets directed at its address by allowing another
device to perform Neighbor Discovery operations on its behalf.
Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols
to provide reachability from nodes on the home network when a Mobile
Node is not at home, by allowing the Home Agent to act as proxy. It
is also used as a mechanism to allow a global prefix to span multiple
links, where proxies act as relays for Neighbor Discovery messages.
Neighbor Discovery Proxy currently cannot be secured using Secure
Neighbor Discovery (SEND). Today, SEND assumes that a node
advertising an address is the address owner and in possession of
appropriate public and private keys for that node. This document
describes how existing practice for proxy Neighbor Discovery relates
to SEND.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5909">http://www.rfc-editor.org/info/rfc5909</a>.
<span class="grey">Combes, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Combes, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. IPv6 Mobile Nodes and Neighbor Discovery Proxy . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. IPv6 Fixed Nodes and Neighbor Discovery Proxy . . . . . . <a href="#page-6">6</a>
<a href="#section-2.3">2.3</a>. Bridge-Like ND Proxies . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3">3</a>. Proxy Neighbor Discovery and SEND . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.1">3.1</a>. CGA Signatures and Proxy Neighbor Discovery . . . . . . . <a href="#page-9">9</a>
<a href="#section-3.2">3.2</a>. Non-CGA Signatures and Proxy Neighbor Discovery . . . . . <a href="#page-10">10</a>
<a href="#section-3.3">3.3</a>. Securing Proxy DAD . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-3.4">3.4</a>. Securing Router Advertisements . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4">4</a>. Potential Approaches to Securing Proxy ND . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.1">4.1</a>. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.1.1">4.1.1</a>. Mobile IPv6 and Router-Based Authorization . . . . . . <a href="#page-13">13</a>
<a href="#section-4.1.2">4.1.2</a>. Mobile IPv6 and Per-Address Authorization . . . . . . <a href="#page-13">13</a>
<a href="#section-4.1.3">4.1.3</a>. Cryptographic-Based Solutions . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-4.1.4">4.1.4</a>. Solution Based on the 'Point-to-Point' Link Model . . <a href="#page-14">14</a>
<a href="#section-4.2">4.2</a>. Secured Proxy ND and Bridge-Like Proxies . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-4.2.1">4.2.1</a>. Authorization Delegation . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-4.2.2">4.2.2</a>. Unauthorized Routers and Proxies . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-4.2.3">4.2.3</a>. Multiple Proxy Spans . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-4.2.4">4.2.4</a>. Routing Infrastructure Delegation . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-4.2.5">4.2.5</a>. Local Delegation . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-4.2.6">4.2.6</a>. Host Delegation of Trust to Proxies . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-4.3">4.3</a>. Proxying Unsecured Addresses . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-5">5</a>. Two or More Nodes Defending the Same Address . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-6.1">6.1</a>. Router Trust Assumption . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-6.2">6.2</a>. Certificate Transport . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-6.3">6.3</a>. Timekeeping . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-7">7</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Neighbor Discovery Proxy is defined in IPv6 Neighbor Discovery
[<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>]. It is used in networks where a prefix has to span
multiple links [<a href="./rfc4389" title=""Neighbor Discovery Proxies (ND Proxy)"">RFC4389</a>] but also in Mobile IPv6 [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>] (and so in
Mobile-IPv6-based protocols like Network Mobility (NEMO) [<a href="./rfc3963" title=""Network Mobility (NEMO) Basic Support Protocol"">RFC3963</a>],
Fast Handovers for Mobile IPv6 (FMIPv6) [<a href="./rfc5568" title=""Mobile IPv6 Fast Handovers"">RFC5568</a>], or Hierarchical
Mobile IPv6 (HMIPv6) [<a href="./rfc5380" title=""Hierarchical Mobile IPv6 (HMIPv6) Mobility Management"">RFC5380</a>]) and in the Internet Key Exchange
Protocol (IKE) version 2 (IKEv2) [<a href="./rfc4306" title=""Internet Key Exchange (IKEv2) Protocol"">RFC4306</a>]. It allows a device that
is not physically present on a link to have another advertise its
presence, and forward packets to the off-link device.
<span class="grey">Combes, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Neighbor Discovery Proxy relies upon another device, the proxy, to
monitor for Neighbor Solicitations (NSs), and answer with Neighbor
Advertisements (NAs). These proxy Neighbor Advertisements direct
data traffic through the proxy. Proxied traffic is then forwarded to
the end destination.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Scenarios</span>
This section describes the different scenarios where the interaction
between Secure Neighbor Discovery (SEND) and ND Proxy raises issues.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. IPv6 Mobile Nodes and Neighbor Discovery Proxy</span>
The goal of IPv6 mobility is to allow nodes to remain reachable while
moving around in the IPv6 Internet. The following text is focused on
Mobile IPv6 but the issue raised by the interaction between SEND and
ND Proxy may be the same with Mobile IPv6 based protocols (e.g.,
NEMO, HMIPv6).
For Mobile IPv6 Mobile Nodes (MNs), it is necessary to keep existing
sessions going or to allow new sessions even when one leaves the home
network.
In order to continue existing sessions, when nodes are present on the
home link, the Proxy (i.e., the Home Agent in Mobile IPv6) sends an
unsolicited NA to the all-nodes multicast address on the home link as
specified [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>].
For new sessions, the Proxy, which listens to the MN's address
responds with a Neighbor Advertisement that originates at its own
IPv6 address and has the proxy's address as the Target Link-Layer
Address, but contains the absent mobile in the Target Address field
of the Neighbor Advertisement. In this case, SEND cannot be applied
because the address in the Target Address field is not the same as
the one in the Source Address field of the IP header.
As seen in Figure 1, solicitors send a multicast solicitation to the
solicited nodes multicast address (based on the unicast address) of
the absent node (a mobile node that is away from the home link).
<span class="grey">Combes, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Absent Mobile Proxy Solicitor
NS:SL3=S,DL3=Sol(A),TA=A
+-----+ SL2=s,DL2=sol(a),SLL=s
| |<================
| |
| |================>
+-----+ NA:SL3=P,DL3=S,TA=A,
SL2=p,DL2=s,TLL=p
Legend:
SL3: Source IPv6 Address NS: Neighbor Solicitation
DL3: Destination IPv6 Address NA: Neighbor Advertisement
SL2: Source Link-Layer Address RS: Router Solicitation
DL2: Destination Link-Layer Address RA: Router Advertisement
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 1
While at home, if the MN has configured Cryptographically Generated
Addresses (CGAs) [<a href="./rfc3972" title=""Cryptographically Generated Addresses (CGA)"">RFC3972</a>], it can secure establishment by its on-
link neighbors of Neighbor Cache Entries (NCEs) for its CGAs by using
SEND [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>]. SEND security requires a node sending Neighbor
Advertisements for a given address to be in possession of the public/
private key pair that generated the address.
When an MN moves away from the home link, a proxy has to undertake
Neighbor Discovery signaling on behalf of the MN. In Mobile IPv6,
the role of the proxy is undertaken by the Home Agent. While the
Home Agent has a security association with the MN, it does not have
access to the public/private key pair used to generate the MN's CGA.
Thus, the Home Agent acting as an ND proxy cannot use SEND for the
address it is proxying [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>].
When an MN moves from the home network to a visited network, the
proxy will have to override the MN's existing Neighbor Cache Entries
that are flagged as secure [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>]. This is needed for the Home
Agent to intercept traffic sent on-link to the MN that would
otherwise be sent to the MN's link-layer address.
With the current SEND specification, any solicitation or
advertisement sent by the proxy will be unsecure and thus will not be
able to update the MN's NCE for the home address because it is
flagged as secured. These existing Neighbor Cache Entries will only
time-out after Neighbor Unreachability Detection [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>] concludes
the Home Address is unreachable at the link layer recorded in the
NCE.
<span class="grey">Combes, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Where secured proxy services are not able to be provided, a proxy's
advertisement may be overridden by a rogue proxy without the
receiving host realizing that an attack has occurred. This is
identical to what happens in a network where SEND is not deployed.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. IPv6 Fixed Nodes and Neighbor Discovery Proxy</span>
This scenario is a sub-case of the previous one. In this scenario,
the IPv6 node will never be on the link where the ND messages are
proxied. For example, an IPv6 node gains remote access to a network
protected by a security gateway that runs IKEv2 [<a href="./rfc4306" title=""Internet Key Exchange (IKEv2) Protocol"">RFC4306</a>]. When a
node needs an IP address in the network protected by a security
gateway, the security gateway assigns an address dynamically using
Configuration Payload during IKEv2 exchanges. The security gateway
then needs to receive packets sent to this address; one way to do so
would be to proxy ND messages.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Bridge-Like ND Proxies</span>
The Neighbor Discovery (ND) Proxy specification [<a href="./rfc4389" title=""Neighbor Discovery Proxies (ND Proxy)"">RFC4389</a>] defines an
alternative method to classic bridging. Just as with classic
bridging, multiple link-layer segments are bridged into a single
segment, but with the help of proxying at the IP layer rather than
link-layer bridging. In this case, the proxy forwards messages while
modifying their source and destination MAC addresses, and it rewrites
their solicited and override flags and Link-Layer Address Options.
This rewriting is incompatible with SEND signed messages for a number
of reasons:
o Rewriting elements within the message will break the digital
signature.
o The source IP address of each packet is the packet's origin, not
the proxy's address. The proxy is unable to generate another
signature for this address, as it doesn't have the CGA private key
[<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>].
Thus, proxy modification of SEND solicitations may require sharing of
credentials between the proxied node and the proxying node or
creation of new options with proxying capabilities.
While bridge-like ND proxies aim to provide as little interference
with ND mechanisms as possible, SEND has been designed to prevent
modification or spoofing of advertisements by devices on the link.
<span class="grey">Combes, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Of particular note is the fact that ND Proxy performs a different
kind of proxy Neighbor Discovery to Mobile IPv6 [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>] [<a href="./rfc4389" title=""Neighbor Discovery Proxies (ND Proxy)"">RFC4389</a>].
<a href="./rfc3775">RFC 3775</a> (Mobile IPv6) specifies that the Home Agent as proxy sends
Neighbor Advertisements from its own address with the Target Address
set to the absent Mobile Node's address. The Home Agent's own link-
layer address is placed in the Target Link-Layer Address Option
[<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>]. On the other hand, ND Proxy resends messages containing
their original address, even after modification (i.e., the IP source
address remains the same) [<a href="./rfc4389" title=""Neighbor Discovery Proxies (ND Proxy)"">RFC4389</a>]. Figure 2 describes packet
formats for proxy Neighbor solicitation and advertisement as
specified by <a href="./rfc4389">RFC 4389</a>.
Advertiser Proxy Solicitor
NS:SL3=S,DL3=Sol(A),TA=A, NS:SL3=S,DL3=Sol(A),TA=A,
SL2=p,DL2=sol(a),SLL=p +-----+ SL2=s,DL2=sol(a),SLL=s
<==================| |<================
| |
==================>| |================>
NA:SL3=A,DL3=S,TA=A, +-----+ NA:SL3=A,DL3=S,TA=A
SL2=a,DL2=p,TLL=a SL2=p,DL2=s,TLL=p
Legend:
SL3: Source IPv6 Address NS: Neighbor Solicitation
DL3: Destination IPv6 Address NA: Neighbor Advertisement
SL2: Source Link-Layer Address
DL2: Destination Link-Layer Address
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 2
In order to use the same security procedures for both ND Proxy and
Mobile IPv6, changes may be needed to the proxying procedures in
[<a href="./rfc4389" title=""Neighbor Discovery Proxies (ND Proxy)"">RFC4389</a>], as well as changes to SEND.
An additional (and undocumented) requirement for bridge-like proxying
is the operation of router discovery. Router discovery packets may
similarly modify Neighbor Cache state, and require protection from
SEND.
In Figure 3, the router discovery messages propagate without
modification to the router address, but elements within the message
change. This is consistent with the description of Neighbor
Discovery above.
<span class="grey">Combes, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Advertiser Proxy Solicitor
RS:SL3=S,DL3=AllR, RS:SL3=S,DL3=AllR,
SL2=p,DL2=allr,SLL=p +-----+ SL2=s,DL2=allr,SLL=s
<==================| |<================
| |
==================>| |================>
RA:SL3=A,DL3=S, +-----+ RA:SL3=A,DL3=S,
SL2=a,DL2=p,SLL=a SL2=p,DL2=s,SLL=p
Legend:
SL3: Source IPv6 Address RS: Router Solicitation
DL3: Destination IPv6 Address RA: Router Advertisement
SL2: Source Link-Layer Address
DL2: Destination Link-Layer Address
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 3
Once again, these messages may not be signed with a CGA signature by
the proxy, because it does not own the source address.
Additionally, Authorization Delegation Discovery messages need to be
exchanged for bridge-like ND proxies to prove their authority to
forward. Unless the proxy receives explicit authority to act as a
router, or the router knows of its presence, no authorization may be
made. This explicit authorization requirement may be at odds with
the zero configuration goal of ND proxying [<a href="./rfc4389" title=""Neighbor Discovery Proxies (ND Proxy)"">RFC4389</a>].
An alternative (alluded to in an appendix of ND Proxy [<a href="./rfc4389" title=""Neighbor Discovery Proxies (ND Proxy)"">RFC4389</a>])
suggests that the proxy send Router Advertisements (RAs) from its own
address. As described by ND Proxy, this is insufficient for
providing proxied Neighbor Advertisement service, but may be matched
with Neighbor solicitation and advertisement services using the
proxy's source address in the same way as Mobile IPv6 [<a href="./rfc4389" title=""Neighbor Discovery Proxies (ND Proxy)"">RFC4389</a>]
[<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>]. This means that all router and Neighbor advertisements
would come from the proxied address, but may contain a target address
that allows proxied Neighbor presence to be established with peers on
other segments. Router discovery in this case has the identity of
the original (non-proxy) router completely obscured in router
discovery messages.
The resultant proxy messages would have no identifying information
indicating their origin, which means that proxying between multiple
links would require state to be stored on outstanding solicitations
(effectively a ND only NAT). This level of state storage may be
undesirable.
<span class="grey">Combes, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Mobile IPv6 does not experience this issue when supplying its own
address, since ND messages are never forwarded on to the absent node
(the Home Agent having sufficient information to respond itself).
Authorization from a router may still be required for Router
Advertisement, and will be discussed in <a href="#section-4.2">Section 4.2</a>.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Proxy Neighbor Discovery and SEND</span>
There are currently no existing secured Neighbor Discovery procedures
for proxied addresses, and all Neighbor Advertisements from SEND
nodes are required to have equal source and target addresses, and be
signed by the transmitter (<a href="./rfc3971#section-7.4">Section 7.4 of [RFC3971]</a>).
Signatures over SEND messages are required to be applied on the CGA
source address of the message, and there is no way of indicating that
a message is proxied.
Even if the message is able to be transmitted from the original
owner, differences in link-layer addressing and options require
modification by a proxy. If a message is signed with a CGA-based
signature, the proxy is unable to regenerate a signature over the
changed message as it lacks the keying material.
Therefore, a router wishing to provide proxy Neighbor Advertisement
service cannot use existing SEND procedures on those messages.
A host may wish to establish a session with a device that is not on-
link but is proxied. As a SEND host, it prefers to create Neighbor
Cache Entries using secured procedures. Since SEND signatures cannot
be applied to an existing proxy Neighbor Advertisement, it must
accept non-SEND advertisements in order to receive proxy Neighbor
Advertisements.
Neighbor Cache spoofing of another node therefore becomes trivial, as
any address may be proxy-advertised to the SEND node, and overridden
only if the node is there to protect itself. When a node is present
to defend itself, it may also be difficult for the solicitor
determine the difference between a proxy-spoofing attack, and a
situation where a proxied device returns to a link and overrides
other proxy advertisers [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. CGA Signatures and Proxy Neighbor Discovery</span>
SEND defines one public-key and signature format for use with
Cryptographically Generated Addresses (CGAs) [<a href="./rfc3972" title=""Cryptographically Generated Addresses (CGA)"">RFC3972</a>]. CGAs are
intended to tie address ownership to a particular public/private key
pair.
<span class="grey">Combes, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
In SEND as defined today, Neighbor Discovery messages (including the
IP Addresses from the IPv6 header) are signed with the same key used
to generate the CGA. This means that message recipients have proof
that the signer of the message owned the address.
When a proxy replaces the message's source IPv6 address with its own
CGA, the existing CGA option and RSA signature option would need to
be replaced with ones that correspond to the CGA of the proxy. To be
valid according to the SEND specification, the Target Address of the
Neighbor Advertisement message would need to be replaced also to be
equal to the Source Address [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>].
Additional authorization information may be needed to prove that the
proxy is indeed allowed to advertise for the target address, as is
described in <a href="#section-4">Section 4</a>.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Non-CGA Signatures and Proxy Neighbor Discovery</span>
Where a proxy retains the original source address in a proxied
message, existing security checks for SEND will fail, since fields
within the message will be changed. In order to achieve secured
proxy Neighbor Discovery in this case, extended authorization
mechanisms may be needed for SEND.
SEND provides mechanisms for extension of SEND to non-CGA-based
authorization. Messages are available for Authorization Delegation
Discovery, which is able to carry arbitrary PKIX/X.509 certificates
[<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>].
There is, however, no specification of keying information option
formats analogous to the SEND CGA Option [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>]. The existing
option allows a host to verify message integrity by specifying a key
and algorithm for digital signature, without providing authorization
via mechanisms other than CGA ownership.
The digital signature in SEND is transported in the RSA Signature
Option. As currently specified, the signature operation is performed
over a CGA Message type, and allows for CGA verification. Updating
the signature function to support non-CGA operations may be
necessary.
Within SEND, more advanced functions such as routing may be
authorized by certificate path verification using Authorization
Delegation Discovery.
With non-CGA signatures and authentication, certificate contents for
authorization may need to be determined, as outlined in <a href="#section-4">Section 4</a>.
<span class="grey">Combes, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
While SEND provides for extensions to new non-CGA methods, existing
SEND hosts may silently discard messages with unverifiable RSA
signature options (<a href="./rfc3971#section-5.2.2">Section 5.2.2 of [RFC3971]</a>), if configured only to
accept SEND messages. In cases where unsecured Neighbor Cache
Entries are still accepted, messages from new algorithms will be
treated as unsecured.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Securing Proxy DAD</span>
Initiation of proxy Neighbor Discovery also requires Duplicate
Address Detection (DAD) checks of the address [<a href="./rfc4862" title=""IPv6 Stateless Address Autoconfiguration"">RFC4862</a>]. These DAD
checks need to be performed by sending Neighbor Solicitations, from
the unspecified source address, with the target being the proxied
address.
In existing SEND procedures, the address that is used for CGA tests
on DAD NS is the target address. A Proxy that originates this
message while the proxied address owner is absent is unable to
generate a CGA-based signature for this address and must undertake
DAD with an unsecured NS. It may be possible that the proxy can
ensure that responding NAs are secured though.
Where bridge-like ND proxy operations are being performed, DAD NSs
may be copied from the original source, without modification
(considering they have an unspecified source address and contain no
link-layer address options) [<a href="./rfc4389" title=""Neighbor Discovery Proxies (ND Proxy)"">RFC4389</a>].
If non-CGA-based signatures are available, then the signature over
the DAD NS doesn't need to have a CGA relationship to the Target
Address, but authorization for address configuration needs to be
shown using certificates.
In case there is a DAD collision between two SEND nodes on different
interfaces of the proxy, it is possible that the proxy may not have
the authority to modify the NA defending the address. In this case,
the proxy still needs to modify the NA and pass it onto the other
interfaces even if it will fail SEND verification on the receiving
node.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Securing Router Advertisements</span>
While Router Solicitations are protected in the same manner as
Neighbor Solicitations, the security for Router Advertisements is
mainly based on the use of certificates. Even though the mechanism
for securing RAs is different, the problems that arise due to the
modification of the L2 addresses are exactly the same: the proxy
needs to have the right security material (e.g., certificate) to sign
the RA messages after modification.
<span class="grey">Combes, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Potential Approaches to Securing Proxy ND</span>
SEND nodes already have the concept of delegated authority through
requiring external authorization of routers to perform their routing
and advertisement roles. The authorization of these routers takes
the form of delegation certificates.
Proxy Neighbor Discovery requires a delegation of authority (on
behalf of the absent address owner) to the proxier. Without this
authority, other devices on the link have no reason to trust an
advertiser.
For bridge-like proxies, it is assumed that there is no preexisting
trust between the host owning the address and the proxy. Therefore,
authority may necessarily be dynamic or based on topological roles
within the network [<a href="./rfc4389" title=""Neighbor Discovery Proxies (ND Proxy)"">RFC4389</a>].
Existing trust relationships lend themselves to providing authority
for proxying in two alternative ways.
First, the SEND router authorization mechanisms described above
provide delegation from the organization responsible for routing in
an address domain to the certified routers. It may be argued that
routers so certified may be trusted to provide service for nodes that
form part of a link's address range, but are themselves absent.
Devices which are proxies could either be granted the right to proxy
by the network's router, or be implicitly allowed to proxy by virtue
of being an authorized router.
Second, where the proxied address is itself a CGA, the holder of the
public and private keys is seen to be authoritative about the
address's use. If this address owner was able to sign the proxier's
address and public key information, it would be possible to identify
that the proxy is known and trusted by the CGA address owner for
proxy service. This method requires that the proxied address know or
learn the proxy's address and public key, and that the certificate
signed by the proxied node's is passed to the proxy, either while
they share the same link, or at a later stage.
In both methods, the original address owner's advertisements need to
override the proxy if it suddenly returns, and therefore timing and
replay protection from such messages need to be carefully considered.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Secured Proxy ND and Mobile IPv6</span>
Mobile IPv6 has a security association between the Mobile Node and
Home Agent. The Mobile Node sends a Binding Update to the Home
Agent, to indicate that it is not at home. This implies that the
<span class="grey">Combes, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Mobile Node wishes the Home Agent to begin proxy Neighbor Discovery
operations for its home address(es).
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Mobile IPv6 and Router-Based Authorization</span>
A secured Proxy Neighbor Advertisements proposal based on existing
router trust would require no explicit authorization signaling
between HA and MN to allow proxying. Hosts on the home link will
believe proxied advertisements solely because they come from a
trusted router.
Where the home agent operates as a router without explicit trust to
route from the advertising routing infrastructure (such as in a home,
with a router managed by an ISP), more explicit proxying
authorization may be required, as described in <a href="#section-4.2">Section 4.2</a>.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Mobile IPv6 and Per-Address Authorization</span>
Where proxy Neighbor Discovery is delegated by the MN to the home
agent, the MN needs to learn the public key for the Home Agent, so
that it can generate a certificate authorizing the public/private key
pair to be used in proxying. It may conceivably do this using
Certificate Path Solicitations either over a home tunnel, when it is
away from home, or during router discovery while still at home
[<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>] [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>].
When sending its Binding Update to the HA, the MN would need to
provide a certificate containing the subject's (i.e., proxy HA's)
public key and address, the issuer's (i.e., MN's) CGA and public key,
and timestamps indicating when the authority began and when it ends.
This certificate would need to be transmitted at binding time.
Messaging or such an exchange mechanism would have to be developed.
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Cryptographic-Based Solutions</span>
Specific cryptographic algorithms may help to allow trust between
entities of a same group.
This is the case, for example, with ring signature algorithms. These
algorithms generate a signature using the private key of any member
from the same group, but to verify the signature the public keys of
all group members are required. Applied to SEND, the addresses are
cryptographically generated using multiple public keys, and the
Neighbor Discovery messages are signed with an RSA ring signature
[<a href="#ref-RING" title=""Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Addresses (MCGAs)"">RING</a>]. (Note that the cryptographic algorithms that are the
foundation for [<a href="#ref-RING" title=""Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Addresses (MCGAs)"">RING</a>] and other similar solutions are not widely
accepted in the security community; additional research is needed
before a Standards Track protocol could be developed.)
<span class="grey">Combes, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>. Solution Based on the 'Point-to-Point' Link Model</span>
Another approach is to use the 'Point-to-Point' link model.
In this model, one prefix is provided per MN, and only an MN and the
HA are on a same link. The consequence is the HA no longer needs to
act as ND Proxy.
One way to design such a solution is to use virtual interfaces, on
the MN and the HA, and a virtual link between them. Addresses
generated on the virtual interfaces will only be advertised on the
virtual link. For Mobile IPv6, this results in a virtual Home
Network where the MN will never come back.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Secured Proxy ND and Bridge-Like Proxies</span>
In link-extension environments, the role of a proxy is more
explicitly separated from that of a router. In SEND, routers may
expect to be authorized by the routing infrastructure to advertise
and may provide this authority to hosts in order to allow them to
change forwarding state.
Proxies are not part of the traditional infrastructure of the
Internet, and hosts or routers may not have an explicit reason to
trust them, except that they can forward packets to regions where
otherwise those hosts or routers could not reach.
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Authorization Delegation</span>
If a proxy can convince a device that it should be trusted to perform
proxying function, it may require that device to vouch for its
operation in dealing with other devices. It may do this by receiving
a certificate, signed by the originating device that the proxy is
believed capable of proxying under certain circumstances.
This allows nodes receiving proxied Neighbor Discovery packets to
quickly check if the proxy is authorized for the operation. There
are several bases for such trust, and requirements in proxied
environments, which are discussed below.
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. Unauthorized Routers and Proxies</span>
Routers may be advertising on networks without any explicit
authorization, and SEND hosts will register these routers if there
are no other options [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>]. While proxies may similarly attempt
to advertise without authority, this provides no security for the
routing infrastructure. Any device can be setup as a SEND proxy/
router so long as it signs its own ND messages from its CGA.
<span class="grey">Combes, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
This may not help in the case that a proxy attempts to update
Neighbor Cache Entries for a SEND node that moves between links,
since the SEND node's authority to advertise its own CGA address
would not be superseded by a proxy with no credentials.
<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>. Multiple Proxy Spans</span>
Proxies may have multiple levels of nesting, which allow the network
to connect between non-adjacent segments.
In this case, authority delegated at one point will have to be
redelegated (possibly in a diluted form) to proxies further away from
the origin of the trust.
Trust Proxy A Proxy B Distant
Origin - T Node - D
+-----+ +-----+
| | | |
+-----+ +-----+ +-----+ +-----+
| | | | | |
------------| |------------| |----------
| | | |
+-----+ +-----+
==========> ==============> ==========>
Deleg(A,T) Deleg(B,Deleg(A,T)) Advertise(D, Deleg(B,
Deleg(A,T))
Figure 4
As shown in Figure 4, the Proxy A needs to redelegate authority to
proxy for T to Proxy B; this allows it to proxy advertisements that
target T back to D.
<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>. Routing Infrastructure Delegation</span>
Where it is possible for the proxy to pre-establish trust with the
routing infrastructure, or at least to the local router, it may be
possible to authorize proxying as a function of routing within the
subnet. The router or CA may then be able to certify proxying for
only a subset of the prefixes for which it is itself certified.
If a router or CA provides certification for a particular prefix, it
may be able to indicate that only proxying is supported, so that
Neighbor Cache Entries of routers connected to Internet
infrastructure are never overridden by the proxy, if the router is
present on a segment.
<span class="grey">Combes, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Hosts understanding such certificates may allow authorized proxies
and routers to override the host when assuming proxy roles, if the
host is absent.
Proxy certificate signing could be done either dynamically (requiring
exchanges of identity and authorization information) or statically
when the network is set up.
<span class="h4"><a class="selflink" id="section-4.2.5" href="#section-4.2.5">4.2.5</a>. Local Delegation</span>
Where no trust tie exists between the authority that provides the
routing infrastructure and the provider of bridging and proxying
services, it may still be possible for SEND hosts to trust the
bridging provider to authorize proxying operations.
SEND itself requires that routers be able to show authorization, but
doesn't require routers to have a single trusted root.
A local bridging/proxying authority trust delegation may be possible.
It would be possible for this authority to pass out local-use
certificates, allowing proxying on a specific subnet or subnets, with
a separate authorization chain to those subnets for the routers with
Internet access.
This would require little modification to SEND, other than the
addition of router-based proxy authority (as in <a href="#section-4.2.4">Section 4.2.4</a>), and
proxies would in effect be treated as routers by SEND hosts
[<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>]. Distribution of keying and trust material for the initial
bootstrap of proxies would not be provided though (and may be
static).
Within small domains, key management and distribution may be a
tractable problem, so long as these operations are simple enough to
perform.
Since these domains may be small, it may be necessary to provide
certificate chains for trust anchors that weren't requested in
Certificate Path Solicitations, if the proxy doesn't have a trust
chain to any requested trust anchor.
This is akin to 'suggesting' an appropriate trusted root. It may
allow for user action in allowing trust extension when visiting
domains without ties to a global keying infrastructure. In this
case, the trust chain would have to start with a self-signed
certificate from the original CA.
<span class="grey">Combes, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
<span class="h4"><a class="selflink" id="section-4.2.6" href="#section-4.2.6">4.2.6</a>. Host Delegation of Trust to Proxies</span>
Unlike Mobile IPv6, for bridge-like proxied networks, there is no
existing security association upon which to transport proxying
authorization credentials.
Thus, proxies need to convince Neighbors to delegate proxy authority
to them, in order to proxy-advertise to nodes on different segments.
It will be difficult without additional information to distinguish
between legitimate proxies and devices that have no need or right to
proxy (and may want to make two network segments appear connected).
When proxy advertising, proxies must not only identify that proxying
needs to occur, but provide proof that they are allowed to do so, so
that SEND Neighbor Cache Entries may be updated. Unless the
authorization to update such entries is tied to address ownership
proofs from the proxied host or the verifiable routing
infrastructure, spoofing may occur.
When a host received a proxied Neighbor advertisement, it would be
necessary to check authorization in the same way that authorization
delegation discovery is performed in SEND.
Otherwise, certificate transport will be required to exchange
authorization between proxied nodes and proxies.
Proxies would have to be able to delegate this authorization to
downstream proxies, as described in <a href="#section-4.2.3">Section 4.2.3</a>.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Proxying Unsecured Addresses</span>
Where the original Neighbor Discovery message is unsecured, there is
an argument for not providing secured proxy service for that node.
In both the Mobile IPv6 and extended networks cases, the node may
arrive back at the network and require other hosts to map their
existing Neighbor Cache Entry to the node's link-layer address. The
re-arriving node's overriding of link-layer address mappings will
occur without SEND in this case.
It is notable that without SEND protection any node may spoof the
arrival, and effectively steal service across an extended network.
This is the same as in the non-proxy case, and is not made
significantly worse by the proxy's presence (although the identity of
the attacker may be masked if source addresses are being replaced).
<span class="grey">Combes, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
If signatures over the proxied messages were to be used, re-arrival
and override of the Neighbor Cache Entries would have to be allowed,
so the signatures would indicate that at least the proxy wasn't
spoofing (even if the original sender was).
For non-SEND routers, though, it may be possible for secured proxies
to send signed router advertisement messages, in order to ensure that
routers aren't spoofed, and subsequently switched to different parts
of the extended network.
This has problems in that the origin is again unsecured, and any node
on the network could spoof router advertisement for an unsecured
address. These spoofed messages may become almost indistinguishable
(except for the non-CGA origin address) from unspoofed messages from
SEND routers.
Given these complexities, the simplest method is to allow unsecured
devices to be spoofed from any port on the network, as is the case
today.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Two or More Nodes Defending the Same Address</span>
All the previous sections of this document focused on the case where
two nodes defend the same address (i.e., the node and the proxy).
However, there are also cases where two or more nodes are defending
the same address. This is at least the case for:
o Nodes having the same address, as the Mobile Access Gateway's
(MAG's) ingress link-local address in Proxy Mobile IPv6 (PMIPv6)
[<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>].
o Nodes having a common anycast address [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>].
The problem statement, described previously in this document, applies
for these cases, and the issues are the same from a signaling point
of view.
Multicast addresses are not mentioned here because Neighbor Discovery
Protocol is not used for them.
In the first case, [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] assumes that the security material used
by SEND (i.e., public-private key pair) is shared between all the
MAGs. For the second case, there is no solution today. But, in the
same way, it should be possible to assume that the nodes having a
common anycast address could also share the security material.
<span class="grey">Combes, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
It is important to notice that when many nodes defending the same
address are not in the same administrative domain (e.g., MAGs in
different administrative domains but in the same PMIPv6 domain
[<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>]), sharing the security material used by SEND may raise a
security issue.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Router Trust Assumption</span>
Router-based authorization for Secured Proxy ND may occur without the
knowledge or consent of a device. It is susceptible to the 'Good
Router Goes Bad' attack described in [<a href="./rfc3756" title=""IPv6 Neighbor Discovery (ND) Trust Models and Threats"">RFC3756</a>].
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Certificate Transport</span>
Certificate delegation relies upon transfer of the new credentials to
the proxying HA in order to undertake ND proxy on its behalf. Since
the binding cannot come into effect until DAD has taken place, the
delegation of the proxying authority necessarily predates the return
of the Binding Ack, as described in [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>]. In the case above
described, the home tunnel that comes into creation as part of the
binding process may be required for transport of Certificate Path
Solicitations or Advertisements [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>]. This constitutes a
potential chicken-and-egg problem. Either modifications to initial
home binding semantics or certificate transport are required. This
may be trivial if certificates are sent in the clear between the MN's
Care-of Address (CoA) and the HA without being tunneled.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Timekeeping</span>
All of the presented methods rely on accurate timekeeping on the
receiver nodes of Neighbor Discovery Timestamp Options.
For router-authorized proxy ND, a Neighbor may not know that a
particular ND message is replayed from the time when the proxied host
was still on-link, since the message's timestamp falls within the
valid timing window. Where the router advertises its secured proxy
NA, a subsequent replay of the old message will override the NCE
created by the proxy.
Creating the NCE in this way, without reference to accurate
subsequent timing, may only be done once. Otherwise, the receiver
will notice that the timestamp of the advertisement is old or doesn't
match.
<span class="grey">Combes, et al. Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
One way of creating a sequence of replayable messages that have
timestamps likely to be accepted is to pretend to do an unsecured DAD
on the address each second while the MN is at home. The attacker
saves each DAD defense in a sequence. The granularity of SEND
timestamp matching is around one second, so the attacker has a set of
SEND NAs to advertise, starting at a particular timestamp, and valid
for as many seconds as the original NA gathering occurred.
This sequence may then be played against any host that doesn't have a
timestamp history for that MN, by tracking the number of seconds
elapsed since the initial transmission of the replayed NA to that
victim, and replaying the appropriate cached NA.
Where certificate-based authorization of ND proxy is in use, the
origination/starting timestamp of the delegated authority may be used
to override a replayed (non-proxy) SEND NA, while also ensuring that
the Proxy NA's timestamp (provided by the proxy) is fresh. A
returning MN would advertise a more recent timestamp than the
delegated authority and thus override it. This method is therefore
not subject to the above attack, since the proxy advertisement's
certificate will have a timestamp greater than any replayed messages,
preventing it from being overridden.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgments</span>
James Kempf and Dave Thaler particularly contributed to work on this
document. Contributions to discussion on this topic helped to
develop this document. The authors would also like to thank Jari
Arkko, Vijay Devarapalli, Mohan Parthasarathy, Marcelo Bagnulo,
Julien Laganier, Tony Cheneau, Michaela Vanderveen, Sean Shen, and
Sheng Jiang for their comments and suggestions.
Jean-Michel Combes is partly funded by MobiSEND, a research project
supported by the French 'National Research Agency' (ANR).
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC3775">RFC3775</a>] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", <a href="./rfc3775">RFC 3775</a>, June 2004.
[<a id="ref-RFC3971">RFC3971</a>] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", <a href="./rfc3971">RFC 3971</a>, March 2005.
[<a id="ref-RFC3972">RFC3972</a>] Aura, T., "Cryptographically Generated Addresses (CGA)",
<a href="./rfc3972">RFC 3972</a>, March 2005.
<span class="grey">Combes, et al. Informational [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
[<a id="ref-RFC4291">RFC4291</a>] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", <a href="./rfc4291">RFC 4291</a>, February 2006.
[<a id="ref-RFC4306">RFC4306</a>] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
<a href="./rfc4306">RFC 4306</a>, December 2005.
[<a id="ref-RFC4389">RFC4389</a>] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", <a href="./rfc4389">RFC 4389</a>, April 2006.
[<a id="ref-RFC4861">RFC4861</a>] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", <a href="./rfc4861">RFC 4861</a>,
September 2007.
[<a id="ref-RFC4862">RFC4862</a>] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", <a href="./rfc4862">RFC 4862</a>, September 2007.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC3756">RFC3756</a>] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", <a href="./rfc3756">RFC 3756</a>,
May 2004.
[<a id="ref-RFC3963">RFC3963</a>] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
<a href="./rfc3963">RFC 3963</a>, January 2005.
[<a id="ref-RFC5213">RFC5213</a>] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", <a href="./rfc5213">RFC 5213</a>, August 2008.
[<a id="ref-RFC5280">RFC5280</a>] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", <a href="./rfc5280">RFC 5280</a>, May 2008.
[<a id="ref-RFC5380">RFC5380</a>] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", <a href="./rfc5380">RFC 5380</a>, October 2008.
[<a id="ref-RFC5568">RFC5568</a>] Koodli, R., "Mobile IPv6 Fast Handovers", <a href="./rfc5568">RFC 5568</a>,
July 2009.
[<a id="ref-RING">RING</a>] Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying
using Multi-Key Cryptographically Generated Addresses
(MCGAs)", Work in Progress, August 2005.
<span class="grey">Combes, et al. Informational [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5909">RFC 5909</a> SEND ND Proxy: Problem Statement July 2010</span>
Authors' Addresses
Jean-Michel Combes
France Telecom Orange
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
EMail: jeanmichel.combes@orange-ftgroup.com
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal
QC Canada
EMail: Suresh.Krishnan@ericsson.com
Greg Daley
Netstar Logicalis
Level 6/616 St Kilda Road
Melbourne, Victoria 3004
Australia
Phone: +61 401 772 770
EMail: hoskuld@hotmail.com
Combes, et al. Informational [Page 22]
</pre>
|
