Origin rute yang valid hanya memberi sedikit informasi tentang hubungan yang direpresentasikan oleh bagian lain AS_PATH. Sebuah prefix dapat berasal dari AS yang berwenang tetapi tetap melewati urutan AS yang bertentangan dengan struktur customer-to-provider yang diharapkan. Autonomous System Provider Authorization, atau ASPA, menambahkan objek RPKI bertanda tangan untuk masalah kedua tersebut.

Per September 2026, ASPA masih ditetapkan dalam Internet-Draft IETF aktif, belum sebagai RFC yang telah diterbitkan. Draft profil ASPA saat ini mendefinisikan objek bertanda tangan, sedangkan draft verifikasi saat ini mendefinisikan prosedur untuk menerapkan data ASPA tervalidasi pada AS_PATH BGP. Status tersebut penting secara operasional: field dan prosedurnya masih dapat berubah sampai spesifikasi menyelesaikan proses standardisasi.

Customer menandatangani provider set miliknya

Objek ASPA diterbitkan oleh pemegang identifier Customer AS. Payload-nya menyebut satu atau lebih Provider AS yang diotorisasi customer untuk menyediakan transit. Objek tersebut memakai kerangka signed object RPKI, sehingga validasi mengikat pengesahan itu ke sertifikat RPKI yang memuat identifier Customer AS.

Arahnya sengaja dibuat spesifik:

Customer AS 64520
      |
      +---- mengotorisasi ----> Provider AS 64510
      |
      +---- mengotorisasi ----> Provider AS 64500

Customer tidak menandatangani peta topologi Internet secara sembarang. Pernyataannya sempit dan hanya menyangkut hubungan provider miliknya sendiri. Jika customer memiliki beberapa provider transit, profil tersebut meminta semuanya tercantum dalam provider set. AS route server non-transparent yang dipakai customer juga disertakan; route server transparent yang tidak memasukkan ASN ke AS_PATH diperlakukan berbeda.

AS tanpa provider transit dapat memakai bentuk AS 0 yang dijelaskan draft. Bentuk tersebut menyatakan tidak adanya hubungan Provider AS, bukan mengotorisasi AS 0 sebagai network transit nyata.

Otorisasi dievaluasi sebagai pasangan berurutan

Draft verifikasi mereduksi data ASPA tervalidasi menjadi primitif yang berguna: untuk dua AS yang berbeda, periksa apakah AS kedua merupakan provider yang disahkan oleh AS pertama.

Secara konseptual:

authorized(customer, provider)

ASPA ada dan mencantumkan provider  -> Provider+
ASPA ada tetapi provider tidak ada  -> Not Provider+
tidak ada ASPA valid untuk customer -> No Attestation

Ketiga hasil itu tidak setara. Not Provider+ adalah informasi negatif dari pengesahan yang tersedia. No Attestation berarti verifier tidak memiliki pernyataan ASPA valid untuk Customer AS tersebut. Menganggap data yang tidak tersedia sebagai pernyataan negatif dapat menghasilkan kesimpulan keliru selama deployment masih parsial.

Pembedaan ini memungkinkan verifikasi ASPA beroperasi ketika cakupan belum lengkap. Sebuah path dapat memiliki cukup data hubungan bertanda tangan untuk menunjukkan kontradiksi, atau memiliki celah yang memaksa hasil tidak pasti.

Verifikasi AS_PATH memeriksa bentuk valley yang valid

Draft verifikasi saat ini memodelkan AS_PATH terkompresi dengan up-ramp dan down-ramp. Pada up-ramp, hop berurutan bergerak dari customer menuju provider. Pada down-ramp, hubungan yang sama dievaluasi dalam arah traversal sebaliknya. Kedua ramp dapat bertemu pada sebuah apex atau dipisahkan satu hop lateral.

Pasangan ASPA tervalidasi menetapkan batas untuk ramp tersebut. Jika pengesahan yang tersedia membuktikan bahwa kedua batas tidak dapat mencakup bentuk path yang diizinkan prosedur, AS_PATH berstatus Invalid. Jika pengesahan yang tidak tersedia menyisakan lebih dari satu interpretasi, hasilnya dapat berupa Unknown. Jika tidak, prosedur menghasilkan Valid.

Hasil tersebut membahas struktur hubungan yang terlihat dalam AS_PATH. Itu bukan tanda tangan kriptografis atas setiap BGP UPDATE dan tidak membuktikan bahwa setiap AS benar-benar meneruskan rute sesuai kebijakan.

ASPA dan validasi origin mencakup pernyataan berbeda

Data Route Origin Authorization mengikat prefix ke AS yang diizinkan menjadi origin. Data ASPA mengikat Customer AS ke AS yang diotorisasi sebagai provider. Pernyataan bertanda tangan tersebut karena itu menjawab persoalan keamanan routing yang berbeda.

Route leak dapat mempertahankan origin yang sah. Dalam kondisi itu, Route Origin Validation tetap dapat melaporkan origin valid sementara pemeriksaan path berbasis ASPA mendeteksi struktur hubungan yang tidak konsisten dengan pengesahan provider yang tersedia.

Perbedaan sebaliknya juga penting. Hubungan provider tidak memberi otorisasi origin untuk sebuah prefix. ASPA bukan pengganti ROA atau Route Origin Validation. Penerapan keduanya menyediakan informasi bertanda tangan untuk dua bagian terpisah dari keputusan routing: otorisasi origin dan hubungan provider di sepanjang path.

ASPA juga berbeda dari BGP Roles dan OTC

BGP Roles dan atribut Only to Customer dari RFC 9234 membawa konteks hubungan serta propagasi di dalam BGP. ASPA menempatkan otorisasi provider di RPKI dan memungkinkan verifier membandingkan struktur AS_PATH dengan pengesahan tervalidasi.

Kontrol tersebut dapat menangani masalah route leak yang berkaitan dari posisi berbeda. OTC dapat menandai batas propagasi saat rute bergerak di antara router yang berpartisipasi. Verifikasi ASPA dapat memeriksa hubungan yang direpresentasikan AS_PATH memakai data RPKI yang divalidasi secara eksternal.

Tidak satu pun mekanisme membuat seluruh kebijakan routing terlihat secara global. Hubungan komersial dapat lebih kompleks daripada label customer-provider sederhana, dan local policy tetap menentukan penerimaan serta export rute di luar pemeriksaan yang didefinisikan protokol.

Data provider yang stale dapat menghasilkan keputusan buruk

Nilai keamanan ASPA bergantung pada registrasi yang akurat. Jika Customer AS tidak mencantumkan provider yang sebenarnya, path yang memuat hubungan tersebut kemudian dapat terlihat tidak konsisten dengan provider set bertanda tangan. Jika customer mencantumkan AS yang sebenarnya bukan provider, kemampuan deteksi berkurang karena pengesahan mengizinkan hubungan yang semestinya tidak diterima sebagai bukti hop customer-to-provider.

Perubahan provider karena itu memiliki siklus data control plane. Penambahan, penghapusan, atau migrasi hubungan transit memerlukan pemeliharaan ASPA yang sesuai. Draft verifikasi saat ini juga membahas kasus migrasi AS ketika ASN yang dikonfigurasi secara global dan ASN legacy dapat perlu direpresentasikan sementara dalam data ASPA customer.

Validitas kriptografis tidak memperbaiki isi operasional yang salah. Objek yang ditandatangani dengan benar tetapi stale tetap mengautentikasi pernyataan stale tersebut secara tepat.

Klaim keamanannya tetap terbatas

ASPA menyediakan otorisasi bertanda tangan untuk hubungan provider dan dasar bagi verifikasi AS_PATH yang terstruktur. Klaim terkuatnya bukan bahwa sebuah path BGP dapat dipercaya secara universal. Verifier melihat pengesahan untuk Customer AS yang berpartisipasi, celah untuk AS tanpa data ASPA valid, dan hanya AS_PATH yang disajikan oleh rute.

Draft saat ini juga menjelaskan kasus ketika manipulasi path oleh provider dapat lolos dari deteksi. Batas ini berasal dari modelnya: ASPA mengautentikasi pernyataan customer tentang provider; ASPA tidak mengubah AS_PATH menjadi urutan yang ditandatangani secara end-to-end.

Dengan batas tersebut tetap dipertahankan, ASPA memperluas RPKI melampaui otorisasi origin prefix. Mekanisme ini menambahkan hubungan provider yang dapat diverifikasi secara kriptografis sehingga route leak dan inkonsistensi path tertentu dapat terlihat oleh kebijakan BGP tanpa berpura-pura mengodekan setiap kesepakatan antardomain.

Cybersecurity RPKI BGP Routing Security ASPA