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
|
<pre>Internet Engineering Task Force (IETF) W. George
Request for Comments: 8206 Neustar
Updates: <a href="./rfc8205">8205</a> S. Murphy
Category: Standards Track PARSONS, Inc.
ISSN: 2070-1721 September 2017
<span class="h1">BGPsec Considerations for Autonomous System (AS) Migration</span>
Abstract
This document discusses considerations and methods for supporting and
securing a common method for Autonomous System (AS) migration within
the BGPsec protocol.
Status of This Memo
This is an Internet Standards Track document.
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). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8206">https://www.rfc-editor.org/info/rfc8206</a>.
Copyright Notice
Copyright (c) 2017 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="https://trustee.ietf.org/license-info">https://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">George & Murphy Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.2">1.2</a>. Documentation Note . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. General Scenario . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. RPKI Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3.1">3.1</a>. Origin Validation . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Path Validation . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2.1">3.2.1</a>. Outbound Announcements (PE-->CE) . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2.2">3.2.2</a>. Inbound Announcements (CE-->PE) . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Requirements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Outbound (PE-->CE) . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.2">5.2</a>. Inbound (CE-->PE) . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.3">5.3</a>. Other Considerations . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.4">5.4</a>. Example . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6">6</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
A method of managing a BGP Autonomous System Number (ASN) migration
is described in <a href="./rfc7705">RFC 7705</a> [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>]. Since it concerns the handling
of AS_PATH attributes, it is necessary to ensure that the process and
features are properly supported in BGPsec [<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>] because BGPsec is
explicitly designed to protect against changes in the BGP AS_PATH,
whether by choice, by misconfiguration, or by malicious intent. It
is critical that the BGPsec protocol framework be able to support
this operationally necessary tool without creating an unacceptable
security risk or exploit in the process.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <a href="https://www.rfc-editor.org/bcp/bcp14">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp14">14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="grey">George & Murphy Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Documentation Note</span>
This document uses ASNs from the range reserved for documentation as
described in <a href="./rfc5398">RFC 5398</a> [<a href="./rfc5398" title=""Autonomous System (AS) Number Reservation for Documentation Use"">RFC5398</a>]. In the examples used here, they are
intended to represent Globally Unique ASNs, not ASNs reserved for
private use as documented in <a href="./rfc1930#section-10">Section 10 of RFC 1930</a> [<a href="./rfc1930" title=""Guidelines for creation, selection, and registration of an Autonomous System (AS)"">RFC1930</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. General Scenario</span>
This document assumes that the reader has read and understood the ASN
migration method discussed in <a href="./rfc7705">RFC 7705</a> [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>] including its
examples (see <a href="#section-2">Section 2</a> of the referenced document), as they will be
heavily referenced here. The use case being discussed in <a href="./rfc7705">RFC 7705</a>
[<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>] is as follows: For whatever the reason, a provider is in
the process of merging two or more ASes, where eventually one
subsumes the other(s). BGP AS confederations [<a href="./rfc5065" title=""Autonomous System Confederations for BGP"">RFC5065</a>] are not
enabled between the ASes, but a mechanism is being used to modify
BGP's default behavior and allow the migrating Provider Edge (PE)
router to masquerade as the old ASN for the Provider-Edge-to-
Customer-Edge (PE-CE) eBGP (external BGP) session, or to manipulate
the AS_PATH, or both. While BGPsec [<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>] does have a method to
handle standard confederation implementations, it is not applicable
in this exact case. This migration requires a slightly different
solution in BGPsec than for a standard confederation because unlike
in a confederation, eBGP peers may not be peering with the "correct"
external ASN, and the forward-signed updates are for a public ASN,
rather than a private one; so, there is no expectation that the BGP
speaker would strip the affected signatures before propagating the
route to its eBGP neighbors.
In the examples in <a href="#section-5.4">Section 5.4</a>, AS64510 is being subsumed by AS64500,
and both ASNs represent a Service Provider (SP) network (see Figures
1 and 2 in <a href="./rfc7705">RFC 7705</a> [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>]). AS64496 and 64499 represent
end-customer networks. References to PE, CE, and P routers mirror
the diagrams and references in <a href="./rfc7705">RFC 7705</a>.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. RPKI Considerations</span>
The methods and implementation discussed in <a href="./rfc7705">RFC 7705</a> [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>] are
widely used during network integrations resulting from mergers and
acquisitions, as well as network redesigns; therefore, it is
necessary to support this capability on any BGPsec-enabled routers/
ASNs. What follows is a discussion of the potential issues to be
considered regarding how ASN migration and BGPsec [<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>]
validation might interact.
One of the primary considerations for this document and migration is
that service providers (SPs) rarely stop after one
<span class="grey">George & Murphy Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
merger/acquisition/divestiture; they end up accumulating several
legacy ASNs over time. Since SPs are using migration methods that
are transparent to customers and therefore do not require
coordination with customers, they do not have as much control over
the length of the transition period as they might with something
completely under their administrative control (e.g., a key roll).
Because they are not forcing a simultaneous migration (i.e., both
ends switch to the new ASN at an agreed-upon time), there is no
incentive for a given customer to complete the move from the old ASN
to the new one. This leaves many SPs with multiple legacy ASNs that
don't go away very quickly, if at all. As solutions were being
proposed for Resource Public Key Infrastructure (RPKI)
implementations to solve this transition case, the WG carefully
considered operational complexity and hardware scaling issues
associated with maintaining multiple legacy ASN keys on routers
throughout the combined network. While SPs who choose to remain in
this transition phase indefinitely invite added risks because of the
operational complexity and scaling considerations associated with
maintaining multiple legacy ASN keys on routers throughout the
combined network, saying "don't do this" is of limited utility as a
solution. As a result, this solution attempts to minimize the
additional complexity during the transition period, on the assumption
that it will likely be protracted. Note that while this document
primarily discusses service provider considerations, it is not solely
applicable to SPs, as enterprises often migrate between ASNs using
the same functionality. What follows is a discussion of origin and
path validation functions and how they interact with ASN migrations.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Origin Validation</span>
Route Origin Validation as defined by <a href="./rfc6480">RFC 6480</a> [<a href="./rfc6480" title=""An Infrastructure to Support Secure Internet Routing"">RFC6480</a>] does not
require modification to enable AS migration, as the existing protocol
and procedure allow for a solution. In the scenario discussed in <a href="./rfc7705">RFC</a>
<a href="./rfc7705">7705</a> [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>], AS64510 is being replaced by AS64500. If there are
any existing routes originated by AS64510 on the router being moved
into the new ASN, new Route Origination Authorizations (ROAs) for the
routes with the new ASN should be generated, and they should be
treated as new routes to be added to AS64500. However, we also need
to consider the situation where one or more other PEs are still in
AS64510 and are originating one or more routes that may be distinct
from any that the router under migration is originating. PE1 (which
is now a part of AS64500 and instructed to use "Replace Old AS" as
defined in [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>] to remove AS64510 from the path) needs to be
able to properly handle routes originated from AS64510. If the route
now shows up as originating from AS64500, any downstream peers'
validation check will fail unless a ROA is *also* available for
AS64500 as the origin ASN. In addition to generating a ROA for 65400
for any prefixes originated by the router being moved, it may be
<span class="grey">George & Murphy Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
necessary to generate ROAs for 65400 for prefixes that are
originating on routers still in 65410, since the AS replacement
function will change the origin AS in some cases. This means that
there will be multiple ROAs showing different ASes authorized to
originate the same prefixes until all routers originating prefixes
from AS64510 are migrated to AS64500. Multiple ROAs of this type are
permissible per <a href="./rfc6480#section-3.2">Section 3.2 of RFC 6480</a> [<a href="./rfc6480" title=""An Infrastructure to Support Secure Internet Routing"">RFC6480</a>] so managing origin
validation during a migration like this is merely applying the
defined case where a set of prefixes are originated from more than
one ASN. Therefore, for each ROA that authorizes the old ASN (e.g.,
AS64510) to originate a prefix, a new ROA MUST also be created that
authorizes the replacing ASN (e.g., AS64500) to originate the same
prefix.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Path Validation</span>
BGPsec path validation requires that each router in the AS path
cryptographically sign its update to assert that "every Autonomous
System (AS) on the path of ASes listed in the UPDATE message has
explicitly authorized the advertisement of the route to the
subsequent AS in the path" (see <a href="./rfc8205#section-1">Section 1 of RFC 8205</a> [<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>]).
Since the referenced AS-migration technique explicitly modifies the
AS_PATH between two eBGP peers who are not coordinating with one
another (are not in the same administrative domain), no level of
trust can be assumed; therefore, it may be difficult to identify
legitimate manipulation of the AS_PATH for migration activities when
compared to manipulation due to misconfiguration or malicious intent.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Outbound Announcements (PE-->CE)</span>
When PE1 is moved from AS64510 to AS64500, it will be provisioned
with the appropriate keys for AS64500 to allow it to forward-sign
routes using AS64500. However, there is no guidance in the BGPsec
protocol specification [<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>] on whether or not the forward-signed
ASN value is required to match the configured remote AS to validate
properly. That is, if CE1's BGP session is configured as "remote AS
64510", the presence of "local AS 64510" on PE1 will ensure that
there is no ASN mismatch on the BGP session itself, but if CE1
receives updates from its remote neighbor (PE1) forward-signed from
AS64500, there is no guidance as to whether the BGPsec validator on
CE1 still considers those valid by default. <a href="./rfc4271#section-6.3">Section 6.3 of RFC 4271</a>
[<a href="./rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>] mentions this match between the ASN of the peer and the
AS_PATH data, but it is listed as an optional validation, rather than
a requirement. We cannot assume that this mismatch will be allowed
by vendor implementations, so using it as a means to solve this
migration case is likely to be problematic.
<span class="grey">George & Murphy Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Inbound Announcements (CE-->PE)</span>
Inbound is more complicated, because the CE doesn't know that PE1 has
changed ASNs, so it is forward-signing all of its routes with
AS64510, not AS64500. The BGPsec speaker cannot manipulate previous
signatures and therefore cannot manipulate the previous AS path
without causing a mismatch that will invalidate the route. If the
updates are simply left intact, the ISP would still need to publish
and maintain valid and active public keys for AS 64510 if it is to
appear in the BGPsec_PATH signature so that receivers can validate
that the BGPsec_PATH signature arrived intact/whole. However, if the
updates are left intact, this will cause the AS path length to be
increased, which is unacceptable as discussed in <a href="./rfc7705">RFC 7705</a> [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Requirements</span>
In order to be deployable, any solution to the described problem
needs to consider the following requirements, listed in no particular
order. BGPsec:
o MUST support AS migration for both inbound and outbound route
announcements (see Sections <a href="#section-3.2.1">3.2.1</a> and <a href="#section-3.2.2">3.2.2</a>), without reducing
BGPsec's protections for route path.
o MUST NOT require any reconfiguration on the remote eBGP neighbor
(CE).
o SHOULD NOT require global (i.e., network-wide) configuration
changes to support migration. The goal is to limit required
configuration changes to the devices (PEs) being migrated.
o MUST NOT lengthen the AS path during migration.
o MUST operate within existing trust boundaries, e.g., can't expect
remote side to accept pCount=0 (see <a href="./rfc8205#section-4.2">Section 4.2 of RFC 8205</a>
[<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>]) from untrusted/non-confederation neighbor.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Solution</span>
As noted in <a href="./rfc8205#section-4.2">Section 4.2 of RFC 8205</a> [<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>], BGPsec already has a
solution for hiding ASNs where increasing the AS path length is
undesirable. So a simple solution would be to retain the keys for
AS64510 on PE1 and forward-sign towards CE1 with AS64510 and
pCount=0. However, this would mean passing a pCount=0 between two
ASNs that are in different administrative and trust domains such that
it could represent a significant attack vector to manipulate BGPsec-
signed paths. The expectation for legitimate instances of pCount=0
(to make a route server that is not part of the transit path
<span class="grey">George & Murphy Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
invisible) is that there is some sort of existing trust relationship
between the operators of the route server and the downstream peers
such that the peers could be explicitly configured by policy to
accept pCount=0 announcements only on the sessions where they are
expected. For the same reason that things like "Local AS" [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>]
are used for ASN migration without end-customer coordination, it is
unrealistic to assume any sort of coordination between the SP and the
administrators of CE1 to ensure that they will by policy accept
pCount=0 signatures during the transition period; therefore, this is
not a workable solution.
A better solution presents itself when considering how to handle
routes coming from the CE toward the PE, where the routes are
forward-signed to AS64510, but will eventually need to show AS64500
in the outbound route announcement. Because both AS64500 and AS64510
are in the same administrative domain, a signature from AS64510
forward-signed to AS64500 with pCount=0 would be acceptable as it
would be within the appropriate trust boundary so that each BGP
speaker could be explicitly configured to accept pCount=0 where
appropriate between the two ASNs. At the very simplest, this could
potentially be used at the eBGP boundary between the two ASNs during
migration. Since the AS_PATH manipulation described above usually
happens at the PE router on a per-session basis and does not happen
network-wide simultaneously, it is not generally appropriate to apply
this AS-hiding technique across all routes exchanged between the two
ASNs, as it may result in routing loops and other undesirable
behavior. Therefore, the most appropriate place to implement this is
on the local PE that still has eBGP sessions with peers expecting to
peer with AS64510 (using the transition mechanisms detailed in <a href="./rfc7705">RFC</a>
<a href="./rfc7705">7705</a> [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>]). Since that PE has been moved to AS64500, it is not
possible for it to forward-sign AS64510 with pCount=0 without some
minor changes to the BGPsec behavior to address this use case.
AS migration is using AS_PATH and remote AS manipulation to act as if
a PE under migration exists simultaneously in both ASNs even though
it is only configured with one global ASN. This document describes
applying a similar technique to the BGPsec signatures generated for
routing updates processed through this migration machinery. Each
routing update that is received from or destined to an eBGP neighbor
that is still using the old ASN (64510) will be signed twice, once
with the ASN to be hidden and once with the ASN that will remain
visible. In essence, we are treating the update as if the PE had an
internal BGP hop and the update was passed across an eBGP session
between AS64500 and AS64510, configured to use and accept pCount=0,
while eliminating the processing and storage overhead of creating an
actual eBGP session between the two ASNs within the PE router. This
will result in a properly secured AS path in the affected route
updates, because the PE router will be provisioned with valid keys
<span class="grey">George & Murphy Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
for both AS64500 and AS64510. An important distinction here is that
while AS migration under standard BGP4 is manipulating the AS_PATH
attribute, BGPsec uses an attribute called the "Secure_Path" (see
<a href="./rfc8205#section-3.1">Section 3.1 of RFC 8205</a> [<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>]) and BGPsec-capable neighbors do
not exchange AS_PATH information in their route announcements.
However, a BGPsec neighbor peering with a non-BGPsec-capable neighbor
will use the information found in the Secure_Path to reconstruct a
standard AS_PATH for updates sent to that neighbor. Unlike in the
Secure_Path where the ASN to be hidden is still present but ignored
when considering the AS path (due to pCount=0), when reconstructing
an AS_PATH for a non-BGPsec neighbor, the pCount=0 ASNs will not
appear in the AS_PATH at all (see <a href="./rfc8205#section-4.4">Section 4.4 of RFC 8205</a> [<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>]).
This document is not changing existing AS_PATH reconstruction
behavior, merely highlighting it for clarity.
The procedure to support AS migration in BGPsec is slightly different
depending on whether the PE under migration is receiving the routes
from one of its eBGP peers ("inbound" as in <a href="#section-3.2.2">Section 3.2.2</a>) or
destined toward the eBGP peers ("outbound" as in <a href="#section-3.2.1">Section 3.2.1</a>).
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Outbound (PE-->CE)</span>
When a PE router receives an update destined for an eBGP neighbor
that is locally configured with AS-migration mechanisms as discussed
in <a href="./rfc7705">RFC 7705</a> [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>], it MUST generate a valid BGPsec signature as
defined in <a href="./rfc8205">RFC 8205</a> [<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>] for _both_ configured ASNs. It MUST
generate a signature from the new (global) ASN forward-signing to the
old (local) ASN with pCount=0, and then it MUST generate a forward
signature from the old (local) ASN to the target eBGP ASN with
pCount=1 as normal.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Inbound (CE-->PE)</span>
When a PE router receives an update from an eBGP neighbor that is
locally configured with AS-migration mechanisms (i.e., the opposite
direction of the previous route flow), it MUST generate a signature
from the old (local) ASN forward-signing to the new (global) ASN with
pCount=0. It is not necessary to generate the second signature from
the new (global) ASN because the Autonomous System Border Router
(ASBR) will generate that when it forward-signs towards its eBGP
peers as defined in normal BGPsec operation. Note that a signature
is not normally added when a routing update is sent across an iBGP
(internal BGP) session. The requirement to sign updates in iBGP
represents a change to the normal behavior for this specific
AS-migration scenario only.
<span class="grey">George & Murphy Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Other Considerations</span>
In the inbound case discussed in <a href="#section-5.2">Section 5.2</a>, the PE is adding BGPsec
attributes to routes received from or destined to an iBGP neighbor
and using pCount=0 to mask them. While this is not prohibited by
BGPsec [<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>], BGPsec-capable routers that receive updates from
BGPsec-enabled iBGP neighbors MUST accept updates with new (properly
formed) BGPsec attributes, including the presence of pCount=0 on a
previous signature, or they will interfere with this method. In a
similar fashion, any BGPsec-capable route-reflectors in the path of
these updates MUST reflect them transparently to their BGPsec-capable
clients.
In order to secure this set of signatures, the PE router MUST be
provisioned with valid keys for _both_ configured ASNs (old and new),
and the key for the old ASN MUST be kept valid until all eBGP
sessions are migrated to the new ASN. Downstream neighbors will see
this as a valid BGPsec path, as they will simply trust that their
upstream neighbor accepted pCount=0 because it was explicitly
configured to do so based on a trust relationship and business
relationship between the upstream and its neighbor (the old and new
ASNs).
Additionally, <a href="./rfc7705#section-4">Section 4 of RFC 7705</a> [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>] discusses methods in
which AS migrations can be completed for iBGP peers such that a
session between two routers will be treated as iBGP even if the
neighbor ASN is not the same ASN on each peer's global configuration.
As far as BGPsec is concerned, this requires the same procedure as
when the routers migrating are applying AS-migration mechanisms to
eBGP peers, but the router functioning as the "ASBR" between old and
new ASN is different. In eBGP, the router being migrated has direct
eBGP sessions to the old ASN and signs from old ASN to new with
pCount=0 before passing the update along to additional routers in its
global (new) ASN. In iBGP, the router being migrated is receiving
updates (that may have originated either from eBGP neighbors or other
iBGP neighbors) from its downstream neighbors in the old ASN and MUST
sign those updates from old ASN to new with pCount=0 before sending
them on to other peers.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Example</span>
The following example will illustrate the method being used above.
As with previous examples, PE1 is the router being migrated, AS64510
is the old ASN, which is being subsumed by AS64500, the ASN to be
permanently retained. 64505 is another external peer, used to
demonstrate what the announcements will look like to a third-party
peer that is not part of the migration. Some additional notation is
used to delineate the details of each signature as follows:
<span class="grey">George & Murphy Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
The origin BGPsec Signature Segment takes the form:
sig(Target ASN, (pCount,...,Origin ASN), NLRI) key.
Intermediate BGPsec Signature Segments take the form:
sig(Target ASN,...,(pCount,...,Signer ASN),...,NLRI) key.
(pCount,...,ASN) refers to the new Secure_Path Segment added to the
BGPsec_PATH attribute by the ASN (Origin ASN or Signer ASN).
"Equivalent AS_PATH" refers to what the AS_PATH would look like if it
was reconstructed to be sent to a non-BGPsec peer, while the
Securedpath shows the AS path as represented between BGPsec peers.
Note: The representation of Signature Segment generation is being
simplified here somewhat for the sake of brevity; the actual details
of the signing process are as described in Sections <a href="#section-4.1">4.1</a> and <a href="#section-4.2">4.2</a> of
[<a href="./rfc8205" title=""BGPsec Protocol Specification"">RFC8205</a>]. For example, what is covered by the signature also
includes Flags, Algorithm Suite Identifier, NLRI length, etc. Also,
the key is not carried in the update; instead, the Subject Key
Identifier (SKI) is carried.
<span class="grey">George & Murphy Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
Before Merger
64505
|
ISP B ISP A
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
CE-2 to PE-2: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499)
Securedpath=(64499)
length=sum(pCount)=1
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-2 to PE-1: sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-1 to CE-1: sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH= (64510,64500,64499)
Securedpath=(64510,64500,64499)
length=sum(pCount)=3
<span class="grey">George & Murphy Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
Migrating, route flow outbound PE-1 to CE-1
64505
|
ISP A' ISP A'
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
CE-2 to PE-2: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499)
Securedpath=(64499)
length=sum(pCount)=1
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-2 to PE-1: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499)
Securedpath=(64499)
length=sum(pCount)=1
#PE-2 sends to PE-1 (in iBGP) the exact same update
#as it received from AS64499.
PE-1 to CE-1: sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
sig(64510,...,(pCount=0,...,64500),...,N)K_64500-PE2 (*)
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64510,64499)
Securedpath=(64510, 64500 (pCount=0),64499)
length=sum(pCount)=2 (length is NOT 3)
#PE-1 adds the Secure_Path Segment in (*) acting as AS64500
#PE-1 accepts (*) with pCount=0 acting as AS64510,
#as it would if it received (*) from an eBGP peer
<span class="grey">George & Murphy Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
Migrating, route flow inbound CE-1 to PE-1
64505
|
ISP A' ISP A'
CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2
<span class="h2"><a class="selflink" id="section-64496" href="#section-64496">64496</a> Old_ASN: 64510 </span> Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
CE-1 to PE-1: sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64496)
Securedpath=(64496)
length=sum(pCount)=1
PE-1 to PE-2: sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1 (**)
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64496)
Securedpath=(64510 (pCount=0),64496)
length=sum(pCount)=1 (length is NOT 2)
#PE-1 adds the Secure_Path Segment in (**) acting as AS64510
#PE-1 accepts (**) with pCount=0 acting as AS64500,
#as it would if it received (**) from an eBGP peer
#PE-1, as AS64500, sends the update including (**) to PE-2 (in iBGP)
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64500,64496)
Securedpath=(64500,64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3)
PE-2 to CE-2: sig(64499,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64500,64496)
Securedpath=(64500, 64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3)
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
This document does not require any IANA actions.
<span class="grey">George & Murphy Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
<a href="./rfc7705">RFC 7705</a> [<a href="./rfc7705" title=""Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute"">RFC7705</a>] discusses a process by which one ASN is migrated
into and subsumed by another. Because this process involves
manipulating the AS_Path in a BGP route to make it deviate from the
actual path that it took through the network, this migration process
is attempting to do exactly what BGPsec is working to prevent.
BGPsec MUST be able to manage this legitimate use of AS_Path
manipulation without generating a vulnerability in the RPKI route
security infrastructure, and this document was written to define the
method by which the protocol can meet this need.
The solution discussed above is considered to be reasonably secure
from exploitation by a malicious actor because it requires both
signatures to be secured as if they were forward-signed between two
eBGP neighbors. This requires any router using this solution to be
provisioned with valid keys for both the migrated and subsumed ASN so
that it can generate valid signatures for each of the two ASNs it is
adding to the path. If the AS's keys are compromised, or zero-length
keys are permitted, this does potentially enable an AS_PATH
shortening attack, but these are existing security risks for BGPsec.
<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-RFC2119">RFC2119</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>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC7705">RFC7705</a>] George, W. and S. Amante, "Autonomous System Migration
Mechanisms and Their Effects on the BGP AS_PATH
Attribute", <a href="./rfc7705">RFC 7705</a>, DOI 10.17487/RFC7705, November 2015,
<<a href="https://www.rfc-editor.org/info/rfc7705">https://www.rfc-editor.org/info/rfc7705</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8205">RFC8205</a>] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", <a href="./rfc8205">RFC 8205</a>, DOI 10.17487/RFC8205,
September 2017, <<a href="https://www.rfc-editor.org/info/rfc8105">https://www.rfc-editor.org/info/rfc8105</a>>.
<span class="grey">George & Murphy Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC1930">RFC1930</a>] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)",
<a href="https://www.rfc-editor.org/bcp/bcp6">BCP 6</a>, <a href="./rfc1930">RFC 1930</a>, DOI 10.17487/RFC1930, March 1996,
<<a href="https://www.rfc-editor.org/info/rfc1930">https://www.rfc-editor.org/info/rfc1930</a>>.
[<a id="ref-RFC4271">RFC4271</a>] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", <a href="./rfc4271">RFC 4271</a>,
DOI 10.17487/RFC4271, January 2006,
<<a href="https://www.rfc-editor.org/info/rfc4271">https://www.rfc-editor.org/info/rfc4271</a>>.
[<a id="ref-RFC5065">RFC5065</a>] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", <a href="./rfc5065">RFC 5065</a>,
DOI 10.17487/RFC5065, August 2007,
<<a href="https://www.rfc-editor.org/info/rfc5065">https://www.rfc-editor.org/info/rfc5065</a>>.
[<a id="ref-RFC5398">RFC5398</a>] Huston, G., "Autonomous System (AS) Number Reservation for
Documentation Use", <a href="./rfc5398">RFC 5398</a>, DOI 10.17487/RFC5398,
December 2008, <<a href="https://www.rfc-editor.org/info/rfc5398">https://www.rfc-editor.org/info/rfc5398</a>>.
[<a id="ref-RFC6480">RFC6480</a>] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", <a href="./rfc6480">RFC 6480</a>, DOI 10.17487/RFC6480,
February 2012, <<a href="https://www.rfc-editor.org/info/rfc6480">https://www.rfc-editor.org/info/rfc6480</a>>.
Acknowledgements
Thanks to Kotikalapudi Sriram, Shane Amante, Warren Kumari, Terry
Manderson, Keyur Patel, Alia Atlas, and Alvaro Retana for their
review comments.
The authors particularly wish to acknowledge Kotikalapudi Sriram,
Oliver Borchert, and Michael Baer for their review and suggestions
for the examples in <a href="#section-5.4">Section 5.4</a>, which made an important contribution
to the quality of the text.
Additionally, the solution presented in this document is an amalgam
of several Secure Inter-Domain Routing (SIDR) interim meeting
discussions plus a discussion at IETF 85, collected and articulated
thanks to Sandy Murphy.
<span class="grey">George & Murphy Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8206">RFC 8206</a> BGPsec AS Migration September 2017</span>
Authors' Addresses
Wesley George
Neustar
45980 Center Oak Plaza
Sterling, VA 20166
United States of America
Email: wesgeorge@puck.nether.net
Sandy Murphy
PARSONS, Inc.
7110 Samuel Morse Drive
Columbia, MD 21046
United States of America
Phone: +1 443-430-8000
Email: sandy@tislabs.com
George & Murphy Standards Track [Page 16]
</pre>
|
