-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-ss-grow-rpki-as-cones-00.txt
448 lines (286 loc) · 15.4 KB
/
draft-ss-grow-rpki-as-cones-00.txt
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
Global Routing Operations J. Snijders
Internet-Draft NTT
Intended status: Informational M. Stucchi
Expires: November 3, 2018 RIPE NCC
May 2, 2018
RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous
Systems Numbers To Facilitate BGP Filtering
draft-ss-grow-rpki-as-cones-00
Abstract
This document describes a way to define groups of Autonomous System
numbers in RPKI [RFC6480]. We call them AS-Cones. AS-Cones provide
a mechanism to be used by operators for filtering BGP-4 [RFC4271]
announcements.
Requirements Language
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 3, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Snijders & Stucchi Expires November 3, 2018 [Page 1]
Internet-Draft RPKI AS Cones May 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Format of AS-Cone objects . . . . . . . . . . . . . . . . . . 3
2.1. Policy definition object . . . . . . . . . . . . . . . . 3
2.1.1. Naming convention for Policy definition objects . . . 3
2.1.2. ASN.1 format of a Policy Definition object . . . . . 3
2.1.3. Naming convention for neighbour relationships . . . . 4
2.2. AS-Cone definition object . . . . . . . . . . . . . . . . 4
2.2.1. Naming convention for AS-Cone objects . . . . . . . . 4
2.2.2. ASN.1 format of an AS-Cone . . . . . . . . . . . . . 5
3. Validating an AS-Cone . . . . . . . . . . . . . . . . . . . . 5
4. Recommendations for use of AS-Cones at Internet Exchange
points . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Publication of AS-Cones as IRR objects . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The main goal of the Resource Public Key Infrastructure (RPKI) system
[RFC6480] is to support improved security for the global routing
system. This is achieved through the use of information stored in a
distributed repository system comprised of signed objects. A
commonly used object type is the Route Object Authorisation (ROAs),
which describe the prefixes originated by ASNs.
There is however no way for an operator to assert the routes for its
customer networks, making it difficult to use the information carried
by RPKI to create meaningful BGP-4 filters without relying on RPSL
[RFC2622] as-sets.
Snijders & Stucchi Expires November 3, 2018 [Page 2]
Internet-Draft RPKI AS Cones May 2018
This memo introduces a new attestation object, called an AS-Cone. An
AS-Cone is a digitally signed object with the goal to enable
operators to define a set of customers that can be found as "right
adjacencies", or transit customer networks, facilitating the
construction of prefix filters for a given ASN, thus making routing
more secure.
2. Format of AS-Cone objects
AS-Cones are composed of two types of distinct objects:
o Policy definitions; and
o The AS-Cones themselves.
These objects are stored in ASN.1 format and are digitally signed
according to the same rules and conventions applied for RPKI ROA
Objects ([RFC6482]).
2.1. Policy definition object
A policy definition contains a list the upstream and peering
relationships for a given Autonomous System that need an AS-Cone to
be used for filtering. For each relationship, an AS-Cone is
referenced to indicate which BGP networks will be announced to the
other end of the relationship.
The default behaviour for a neighbour, if the relationship is not
explicitly described in the policy, is to only accept the networks
originated by the ASN. This means that a stub ASN does not have to
set up any AS-Cone nor any description or policy.
Only one AS-Cone can be supplied for a given relationship. If more
than one AS-Cone needs to be announced in the relationship, then it
is mandatory to create a third AS-Cone that includes those two.
2.1.1. Naming convention for Policy definition objects
A Policy object is referenced using the Autonomous System number it
refers to, preceded by the string "AS".
2.1.2. ASN.1 format of a Policy Definition object
Snijders & Stucchi Expires November 3, 2018 [Page 3]
Internet-Draft RPKI AS Cones May 2018
ASNPolicy DEFINITIONS ::=
BEGIN
Neighbours ::= SEQUENCE OF Neighbour
Neighbour ::= SEQUENCE
{
ASN INTEGER (1..4294967296),
ASCone VisibleString
}
Version ::= INTEGER
LastModified ::= GeneralizedTime
Created ::= GeneralizedTime
END
ASN.1 format of a Policy definition object
2.1.3. Naming convention for neighbour relationships
When referring to a neighbour relationship contained in a Policy
definition object the following convention should be used:
ASX:ASY
Where X is the number of the AS holder and Y is the number of the ASN
intended to use the AS-Cone object to generate a filter.
2.2. AS-Cone definition object
An AS-Cone contains a list of the downstream customers and AS-Cones
of a given ASN. The list is used to create filter lists by the
networks providing transit or a peering relationship with the ASN.
An AS-Cone can reference another AS-Cone if a customer of the
operator also has defined an AS-Cone to be announced upstream.
2.2.1. Naming convention for AS-Cone objects
AS-Cones MUST have a unique name for the ASN they belong to. Names
are composed of ASCII strings up to 255 characters long and cannot
contain spaces.
In order for AS-Cones to be unique in the global routing system,
their string name is preceded by the AS number of the ASN they are
part of, followed by ":". For example, AS-Cone "EuropeanCustomers"
for ASN 65530 is represented as "AS65530:EuropeanCustomers" when
referenced from a third party.
Snijders & Stucchi Expires November 3, 2018 [Page 4]
Internet-Draft RPKI AS Cones May 2018
2.2.2. ASN.1 format of an AS-Cone
ASCone DEFINITIONS ::=
BEGIN
Entities ::= SEQUENCE OF Entity
Entity CHOICE
{
ASN INTEGER (1..4294967296),
OtherASCone VisibleString
}
Version ::= INTEGER
LastModified ::= GeneralizedTime
Created ::= GeneralizedTime
END
ASN.1 format of an AS-Cone
3. Validating an AS-Cone
The goal of AS-Cones is to be able to recursively define all the
originating ASNs that define the customer base of a given ASN,
including all the transit relationships. This means that through AS-
Cones, it is possible to create a graph of all the neighbour
relationships for the customers of a given ASN.
In order to validate a full AS-Cone, we have to assume that a network
operator already runs an RPKI validator software. The software
provides access to a validated cache containing all the Policy
definitions and AS-Cone objects. Validation occurs following the
description in: [RFC6488].
In order to validate a full AS-Cone, an operator should perform the
following steps:
1. For Every downstream ASN, the operator takes its policy
definition file and collects a list of ASNs for the cone by
looking at the following data, in exact order:
1. A policy for the specific relationship, in the form of
ASX:ASY, where ASX is the downstream ASN, and ASY is the ASN
of the operator validating the AS-Cone;
2. If there is no specific definition for the relationship, the
ASX:Default policy;
Snijders & Stucchi Expires November 3, 2018 [Page 5]
Internet-Draft RPKI AS Cones May 2018
If none of the two objects above exists, then the operator should
only consider the ASN of its downstream to be added to the list.
2. These objects can either point to:
1. An AS-Cone; or
2. An ASN
3. If the definition points to an AS-Cone, the operator looks for
the object referenced, which should be contained in the validated
cache;
4. If the validated cache does not contain the referenced object,
then the validation moves on to the next downstream network;
5. If the validated cache contains the referenced object, the
validation process evaluates every entry in the AS-Cone. For
each entry:
1. If there is a reference to an ASN, then the operator adds the
ASN to the list for the given AS-Cone;
2. If there is a reference to another AS-Cone, the validating
process should recursively process all the entries in that
AS-Cone first, with the same principles contained in this
list.
Since the goal is to build a list of ASNs announcing routes in
the AS-Cone, then if an ASN or an AS-Cone are referenced more
than once in the process, their contents should only be added
once to the list. This is intended to avoid endless loops, and
in order to avoid cross-reference of AS-Cones
6. When all the AS-Cones referenced in the policies have been
recursively iterated, and all the originating ASNs have been
taken into account, the operator can then build a full prefix-
list with all the prefixes originated in its AS-Cone. This can
be done by querying the RPKI validator software for all the
networks originated by every ASN referenced in the AS-Cone.
4. Recommendations for use of AS-Cones at Internet Exchange points
When an operator is a member of an internet exchange point, it is
recommended for it to create at least a Default policy.
In case of a peering session with a route server, the operator could
publish a policy pointing to the ASN of the route server. A route
Snijders & Stucchi Expires November 3, 2018 [Page 6]
Internet-Draft RPKI AS Cones May 2018
server operator, then, could build strict prefix filtering rules for
all the participants, and offer it as a service to its members.
5. Publication of AS-Cones as IRR objects
AS-Cones are very similar to AS-Set RPSL Objects, so they could also
be published in IRR Databases as AS-Set objects. Every ASN contained
in an AS-Cone, and all the AS-Cones referenced should be considered
as member: attributes. The naming convention for AS-Cones (ASX:AS-
Cone) should be maintained, in order to keep consistency between the
two databases.
6. Security Considerations
TBW
7. IANA Considerations
This memo includes no request to IANA.
8. Contributors
The following people contributed significantly to the content of the
document:
9. Acknowledgments
The authors would like to thank ...
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Snijders & Stucchi Expires November 3, 2018 [Page 7]
Internet-Draft RPKI AS Cones May 2018
10.2. Informative References
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
"Routing Policy Specification Language (RPSL)", RFC 2622,
DOI 10.17487/RFC2622, June 1999,
<https://www.rfc-editor.org/info/rfc2622>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>.
Authors' Addresses
Job Snijders
NTT Communications
Theodorus Majofskistraat 100
Amsterdam 1065 SZ
The Netherlands
Email: [email protected]
Massimiliano Stucchi
RIPE NCC
Stationsplein, 11
Amsterdam 1012 AB
The Netherlands
Email: [email protected]
Snijders & Stucchi Expires November 3, 2018 [Page 8]