RIPE NCC-ის რესურსები თავიდან ბოლომდე: ASN, PI/PA სივრცე, route ობიექტები, ROA და RPKI

ASN-ის მიღება ამ ამბის მარტივი ნაწილია. იმას, მისაწვდომი იქნება თუ არა თქვენი პრეფიქსი, წყვეტს მონაცემთა ბაზის ობიექტებისა და კრიპტოგრაფიული დადასტურებების ჯაჭვი, რომლის უმეტესობა ხელით ივსება და თითქმის მთლიანად უხმაუროდ ტყდება. ქვემოთ ეს ჯაჭვია გავლილი თავიდან ბოლომდე, იმ თანმიმდევრობით, რომლითაც რეალურად შენდება.

მაგალითებში თავიდან ბოლომდე ჯგუფის საკუთარი რესურსებია გამოყენებული: AS203136 აანონსებს 185.143.176.0/22-ს, დაფარულს ვალიდური ROA-თი maxLength /22-ით, და multi-homed არის სამ uplink-ზე.

ჯაჭვი თავიდან ბოლომდე#

1. LIR წევრობა RIPE NCC-ში, ან სპონსორი LIR, თუ მხოლოდ PI რესურსები გჭირდებათ.
2. ნომრული რესურსები — ASN, IPv4 და IPv6 სივრცე.
3. RIPE Database-ის ობიექტები — aut-num, inetnum/inet6num, route/route6, as-set, ყველა დაცული mntner-ით.
4. IRR ფილტრები — თქვენი uplink-ები ამ ობიექტებიდან აწყობენ prefix ფილტრებს. თუ ობიექტი არ არსებობს, პრეფიქსი იჭრება მანამ, სანამ BGP პოლიტიკა მას საერთოდ დაინახავს.
5. RPKI — ROA კრიპტოგრაფიულად აკავშირებს პრეფიქსს origin ASN-თან. ქსელები, რომლებიც Route Origin Validation-ს ატარებენ, ამის საწინააღმდეგოს ჭრიან.
6. Route Origin Validation თქვენს როუტერებზე — რომ თქვენც იყოთ დაცული და არა მხოლოდ სხვებს იცავდეთ.

ჯაჭვის ყოველ რგოლს დამოუკიდებლად შეუძლია, ინტერნეტიდან ამოგაგდოთ.

ASN და მისამართების სივრცე#

ASN-ის მოთხოვნას სჭირდება მარშრუტიზაციის პოლიტიკა: რომელ ქსელებთან გექნებათ peering და დასაბუთება, რომ multi-homed ხართ ან იქნებით. ერთ uplink-იან ქსელს ASN არ სჭირდება და ამას გეტყვიან.

მისამართების სივრცე ორად იყოფა, და ეს განსხვავება უფრო მნიშვნელოვანია, ვიდრე ჩვეულებრივ ჰგონიათ:

• PA (Provider Aggregatable) გამოეყოფა LIR-ს. LIR ქვებლოკებს ანაწილებს კლიენტებზე, და ეს განაწილებები ბრუნდება, როცა კლიენტი მიდის. ISP ჩვეულებრივ სწორედ ამას ფლობს.
• PI (Provider Independent) ენიჭება საბოლოო მომხმარებელს და რჩება მასთან პროვაიდერის შეცვლისასაც. მას სჭირდება სპონსორი LIR ურთიერთობის შესანარჩუნებლად და უფრო მკაცრი წესები აქვს გამოყენებასა და გადაცემაზე.

IPv4 RIR-ის დონეზე ფაქტობრივად ამოწურულია; ახალი გამოყოფები ხდება დაბრუნებული მისამართების ფონდიდან, მოლოდინის სიის პოლიტიკით, და მცირეა. დაგეგმეთ IPv6 ზრდის გზად და IPv4 — დეფიციტურ რესურსად, რომელიც უნდა დაზოგოთ. ეს იდეალიზმი არ არის, ეს ის რეალობაა, რომელსაც განაწილების პოლიტიკა ქმნის. ზომებსა და ვადებზე დაშვებამდე წაიკითხეთ პოლიტიკის მიმდინარე ტექსტი — ის იცვლება.

ობიექტები, რომლებიც თქვენს მარშრუტიზაციას განაგებს#

mntner#

დანარჩენ ყველაფერს იცავს maintainer ობიექტი. მისი ავთენტიფიკაცია არის ის, რაც მესამე პირს თქვენი ჩანაწერების რედაქტირებას უშლის — ხოლო მისი მიტოვება არის მიზეზი, რის გამოც უპატრონო ობიექტები წლობით რჩება. გამოიყენეთ ძლიერი ავთენტიფიკაცია და დარწმუნდით, რომ ორგანიზაციაში ერთზე მეტ ადამიანს შეუძლია მისი გამოყენება: maintainer, რომლითაც ვერავინ ავთენტიფიცირდება, არის რესურსი, რომელსაც ვერავინ ასწორებს.

aut-num#

აღწერს AS-ს და მის მარშრუტიზაციის პოლიტიკას RPSL-ში:

aut-num:        AS203136
as-name:        EXAMPLE-AS
import:         from AS65001 accept ANY
export:         to AS65001 announce AS-EXAMPLE
import:         from AS65002 accept ANY
export:         to AS65002 announce AS-EXAMPLE
admin-c:        EXPL-RIPE
tech-c:         EXPL-RIPE
mnt-by:         EXAMPLE-MNT
source:         RIPE

ზოგი uplink კითხულობს ამას; ბევრი — არა. მაინც შეინახეთ სწორად: ეს არის ოფიციალური დოკუმენტაცია მაშინ, როცა ვინმე არკვევს, რატომ მიდის თქვენი ტრაფიკი იქ, სადაც მიდის.

route და route6#

ეს არის ის ობიექტი, რომელსაც ყოველდღიური მნიშვნელობა აქვს. ის აძლევს origin AS-ს პრეფიქსის გამოცხადების უფლებას და სწორედ მისგან შენდება IRR-ზე დაფუძნებული prefix ფილტრები:

route:          185.143.176.0/22
descr:          EXAMPLE network
origin:         AS203136
mnt-by:         EXAMPLE-MNT
source:         RIPE

თუ route ობიექტი არ არის, uplink-ის გენერირებულ ფილტრში ჩანაწერი არ იქნება, ანუ თქვენი ანონსი გაიყრება. ეს არის ყველაზე ხშირი მიზეზი იმისა, რომ ახლად გამოცხადებული პრეფიქსი ინტერნეტის ნახევრიდან უხილავია, ხოლო თავად BGP სესია სრულიად ჯანსაღად გამოიყურება.

as-set#

თუ გყავთ საკუთარი ASN-ების მქონე კლიენტები, uplink-ები თქვენ as-set-ით გფილტრავენ და არა ერთი AS-ით:

as-set:         AS203136:AS-CUSTOMERS
descr:          Customers of AS203136
members:        AS203136
members:        AS64500
mnt-by:         EXAMPLE-MNT
source:         RIPE

გამოიყენეთ იერარქიული ფორმა (AS203136:AS-CUSTOMERS) და არა ბრტყელი სახელი. იერარქიულ სახელს ფლობს ის ASN, რომელიც პრეფიქსად უდგას, რაც აქრობს როგორც ორაზროვნებას, ისე ბრტყელი სახელების „ვინც პირველი დაიკავა“ პრობლემას.

uplink-ები ამ ყველაფერს ფილტრებად აქცევენ, ჩვეულებრივ bgpq4-ით:

# IPv4 prefix ფილტრი კლიენტისთვის, Junos ფორმატში
bgpq4 -Jl CUSTOMER-V4 AS203136:AS-CUSTOMERS

# IPv6, Cisco ფორმატში
bgpq4 -6 -l CUSTOMER-V6 AS203136:AS-CUSTOMERS

გაუშვით ეს ბრძანება თქვენივე as-set-ზე. რაც გამოვა, სწორედ ის არის, რასაც თქვენი uplink მიიღებს — და თუ პრეფიქსი ამ გამონატანში არ არის, მას ვერანაირი BGP კონფიგურაცია ვერ ამუშავებს.

IRR-იდან RPKI-მდე#

IRR ობიექტი ამბობს: „ეს origin აცხადებს ამ პრეფიქსს“. RPKI ამბობს: „რესურსის მფლობელმა კრიპტოგრაფიულად უფლება მისცა ამ origin-ს ამ პრეფიქსზე“. მეორე გადამოწმებადია ბაზის წვდომის კონტროლისადმი ნდობის გარეშე, სწორედ ამიტომ ვალიდაცია სულ უფრო მკაცრად ინერგება.

ROA-ს სამი ველი აქვს: პრეფიქსი, origin ASN და maxLength. ის ნებისმიერ ანონსს სამიდან ერთ მდგომარეობას ანიჭებს:

• Valid — ROA ფარავს პრეფიქსს, origin ემთხვევა და სიგრძე maxLength-ის ფარგლებშია.
• Invalid — ROA ფარავს პრეფიქსს, მაგრამ origin ან სიგრძე არ ემთხვევა. ეს საშიში მდგომარეობაა: Invalid აქტიურად იჭრება ვალიდაციის მატარებელი ქსელების მიერ.
• NotFound — პრეფიქსს ROA არ ფარავს. ჯერჯერობით თითქმის ყველგან მიიღება, მაგრამ ეს ნელა იცვლება.

maxLength-ის გადაწყვეტილება#

maxLength ამბობს, რამდენად კონკრეტული შეიძლება იყოს ანონსი Valid-ად დარჩენისას. ეს ის ველია, რომელსაც ორივე მიმართულებით უშვებენ შეცდომით:

• ზედმეტად თავისუფალი (მაგალითად maxLength /24 იმ /22-ზე, რომელსაც არასოდეს დეაგრეგირებთ) უფლებას აძლევს ექვს more-specific ანონსს, რომელსაც არასოდეს აკეთებთ — ორ /23-ს და ოთხ /24-ს. თავდამსხმელი, რომელიც მათგან ერთს თქვენი ASN-ით გამოაცხადებს, იღებს Valid hijack-ს, რომელიც longest-prefix-match-ით თქვენს აგრეგატს ჯობნის.
• ზედმეტად მკაცრი კეტავს ლეგიტიმურ საოპერაციო დეაგრეგაციას. ჯგუფის ROA 185.143.176.0/22-ისთვის იყენებს maxLength /22-ს — კონსერვატიულ არჩევანს. ეს ნიშნავს, რომ ნებისმიერი more-specific ანონსი Invalid იქნება, სანამ ჯერ ROA არ შეიცვლება.

ROA-ებს ქმნით RIPE NCC-ის პორტალში, სადაც NCC თქვენი სახელით მართავს სასერტიფიკატო ცენტრს. მიეცით relying party-ებს დრო ახალი ნაკრების წამოსაღებად, სანამ მასზე დაიწყებთ დაყრდნობას: ვალიდატორები განრიგით განახლდებიან და არა მყისიერად.

Route Origin Validation-ის ჩართვა#

ROA-ების გამოქვეყნება სხვებს იცავს თქვენს პრეფიქსებზე შეცდომებისგან. ვალიდაცია თქვენ გიცავთ სხვისი პრეფიქსების შესახებ შეცდომებისგან. საჭიროა relying-party ვალიდატორი — Routinator, rpki-client, Fort ან OctoRPKI — რომელიც როუტერებს კვებავს RTR-ით (RFC 8210).

FRR:

rpki
 rpki polling_period 300
 rpki cache 10.0.0.10 3323 preference 1
 exit
!
route-map UPSTREAM-IN deny 5
 match rpki invalid
!
route-map UPSTREAM-IN permit 10
 set local-preference 100

Junos:

routing-options {
    validation {
        group RPKI {
            session 10.0.0.10 {
                port 3323;
                local-address 10.0.0.1;
            }
        }
    }
}
policy-options {
    policy-statement rpki-validation {
        term invalid {
            from {
                protocol bgp;
                validation-database invalid;
            }
            then reject;
        }
        term valid {
            from {
                protocol bgp;
                validation-database valid;
            }
            then {
                validation-state valid;
                accept;
            }
        }
    }
}

გაუშვით სულ მცირე ორი ვალიდატორი. როუტერი, რომელსაც ერთადერთი RTR სესია აქვს და ის ჩავარდა, ყველაფერს NotFound-ად დაიწყებს აღქმას — ეს fail-open ქცევაა, რომელიც შეგნებულად უნდა აირჩიოთ და არა შემთხვევით აღმოაჩინოთ.

შემოწმება გარედან#

არასოდეს ჩათვალოთ საკუთარი კონფიგურაცია მტკიცებულებად. შეამოწმეთ, რას ხედავს დანარჩენი მსოფლიო:

# არსებობს თუ არა route ობიექტი და რომელი origin-ით?
whois -h whois.ripe.net -- '-T route 185.143.176.0/22'

# aut-num და მისი პოლიტიკა
whois -h whois.ripe.net AS203136

# რას ინახავს რეალურად თქვენი ვალიდატორი
routinator vrps | grep 185.143.176.0

# რა ფილტრს დააგენერირებს თქვენთვის uplink
bgpq4 -Jl TEST AS203136:AS-CUSTOMERS

დაამატეთ RIPEstat სარეგისტრაციო და RPKI ვალიდაციის ხედისთვის, RIPE RIS და საჯარო looking glass-ები იმისთვის, რაც რეალურად ვრცელდება, და route collector-ის ხედი იმის დასადასტურებლად, რომ გარეთ დანახული origin AS სწორედ ის არის, რომელიც თქვენს ROA-შია.

შეცდომები, რომლებიც პრეფიქსს ინტერნეტიდან ხსნის#

• route ობიექტი არ არსებობს. uplink-ის ფილტრი პრეფიქსს ჭრის; BGP სესია აწეულია და თქვენს მხარეს ყველაფერი წესრიგშია.
• route ობიექტი მოძველებული origin-ით. ASN-ის შეცვლის ან კლიენტის მიგრაციის შემდეგ ობიექტში ძველი AS რჩება. IRR ფილტრი მას უხმაუროდ გამორიცხავს.
• ROA შექმნილია, ანონსი განუახლებელი. ან პირიქით: more-specific-ის გამოცხადება maxLength-ის გაფართოებამდე, რაც იძლევა Invalid-ს და ვალიდაციის მატარებელი ქსელები მას ჭრიან. ეს ყველაზე ხშირად ნანახი შეცდომაა და ზუსტად ნაწილობრივ ავარიას ჰგავს.
• ბრტყელი as-set სახელები. ორი ორგანიზაცია ერთსა და იმავე დაუზუსტებელ სახელს იყენებს და ფილტრში ხვდება პრეფიქსები, რომლებიც არცერთს არ უგულისხმია.
• უმართავი mntner. კომპანიაში აღარავინაა, ვისაც მისი ავთენტიფიკაცია შეუძლია, ანუ საჭიროების შემთხვევაში ვერცერთ ობიექტს ვერ ასწორებთ — ეს ჩვეულებრივ ინციდენტის დროს აღმოჩნდება ხოლმე.
• აქვეყნებ, მაგრამ არ ამოწმებ. ROA-ები არსებობს, როუტერები ROV-ს არ ატარებენ, და ქსელი არაფრისგან არაა დაცული.

როცა სარეგისტრაციო მხარე წესრიგშია, საოპერაციო მხარე — ტრაფიკის გადანაწილება ამ uplink-ებს შორის — აღწერილია სტატიაში BGP traffic engineering flow მონაცემებით.