AComP-5640 - специфікації Protected Core Networking для розгортаного середовища

Що це таке

AComP-5640 - це NATO Allied Communications Publication, який визначає специфікації сумісності для Protected Core Networking (PCN) у розгортаних місійних середовищах. Він існує, щоб окремо належні національні мережеві сегменти, Protected Core Segments (PCS), могли підключатися одне до одного та до спільного федеративного ядра без того, щоб кожна держава будувала або довіряла одній мережі. Документ зазначає, що його мета - «to define the Interoperability Specifications (ISpecS) of the PCN interfaces and PCS characteristics applicable to deployable mission environments». Він охоплює саме розгортані з'єднання, відокремлюючи власну сферу від «Deployable and Static environments», які охоплює ширша концепція PCN.

Документ зобов'язує через STANAG 5640: «The agreement of nations to use this publication is recorded in STANAG 5640.» Сам AComP-5640 не створює прямого зобов'язання для компанії. Він доходить до implementer, коли національна або програма НАТО вирішує, що мережевий сегмент має з'єднуватися через PCN-1 або PCN-2, чи то з місійної вимоги, зобов'язання Federated Mission Networking, чи з контракту, який називає документ. Держава також може ратифікувати з резерваціями, а не прийняти весь документ: Record of Specific Reservations цього видання показує, що Данія виключає два типи Traffic Flow Confidentiality для супутникових каналів «as current national systems don't have the necessary bandwidth yet».

Два інтерфейси: PCN-1 між сегментами, PCN-2 до споживачів

PCN-1 з'єднує два Protected Core Segment між собою. PCN-2 з'єднує Protected Core Service Consumer (національну або місійну мережу через її «P-functionality») з Protected Core Segment. Обидва інтерфейси слідують тій самій базовій схемі, коли з'єднуючі сутності не фізично колоковані: взаємна автентифікація через IKEv2 з сертифікатами X.509, GRE-тунель, захищений IPsec ESP у transport mode, і шифрування AES-256-GCM поверх 384-bit elliptic-curve key exchange. Коли сутності колоковані в одній точці з'єднання, дозволено простіший native IP-канал з неявною процедурною автентифікацією, і він вважається таким, що відповідає повному діапазону Traffic Flow Confidentiality завдяки фізичним засобам контролю навколо нього.

Одна різниця між двома інтерфейсами легко пропустити: PCN-1 використовує BGP-4 як обов'язковий протокол маршрутизації, але «the PCN-2 interface does not support dynamic routing protocols. Routing over the PCN-2 is based on static routing» - маршрут за замовчуванням від сторони споживача та конкретні анонсовані підмережі від ядра.

Traffic Flow Confidentiality: п'ять типів визначено, два вимагаються зараз

Документ визначає п'ять типів Traffic Flow Confidentiality (TFC): Per-Packet Authentication, Source/Destination Hiding, Precedence Hiding, TFC Padding і Traffic Volume Hiding. Лише два обов'язкові в цьому виданні: «Supported TFC types for this STANAG version are: Packet Authentication and Source/Destination Hiding.» Власники PCS декларують одноліткам, які типи TFC підтримує їхня інфраструктура, «via NMCD information exchange», а не через зовнішню оцінку. Traffic Volume Hiding явно ще не підтримується: документ зазначає, що механізм залишено для майбутньої версії.

Органи довіри, сертифікати та SLA

Кожна сутність PCN (E-nodes, P-functionalities, NMCDs) автентифікується сертифікатами X.509v3, виданими Infrastructure of Trust Authorities, з алгоритмом підпису RSA 4096 з SHA-384 або EC P384 (EC P521 опційно), і відкликанням сертифікатів через CRL, з OCSP як опцією. Оскільки PCN федеративний, навмисно немає єдиного органу довіри: кілька trust authorities видають сертифікати різним сегментам, і між ними має бути встановлено відносини довіри (як мінімум, trust lists), перш ніж сутності з різних сторін зможуть з'єднатися.

Кожне з'єднання потребує Service Level Agreement, що охоплює як мінімум маркування трафіку, мінімальну та максимальну смугу пропускання, максимальну затримку передачі та максимальну варіацію затримки, побудовану на класах трафіку та моделі QoS у STANAG 4711. Якщо з'єднання має запуститися до повного узгодження SLA, весь трафік за замовчуванням маркується Low-Priority Data, а не залишається некласифікованим.

Чого розгортане середовище не охоплює

Документ явно вказує сферу, яку навмисно залишає поза межами. Конфіденційність інформації фактичного payload - не робота PCN: Protected Core - «a non-classified network», яка «will not provide information confidentiality and integrity of the consumer data/payload», що залишається відповідальністю власних криптографічних блоків споживача. Так само для архітектури безпеки загалом: «offering a holistic cyber security architecture is out of the scope of PCN. PCS operators are responsible for developing and implementing a robust cyber security design in their PCS.» PCN вимагає border protection function, який дозволяє вузький набір протоколів (BGP, BFD, ICMP і RIPng, де використовується autoconfiguration) на кожному інтерфейсі, а не загальну програму безпеки. Network Address Translation заборонено всередині спільного ядра, але дозволено на краю, зверненому до споживача, і кожна сутність PCN має залишатися синхронізованою з UTC у межах 1200 мілісекунд - конкретні, перевірювані числа, а не загальні поради.

Як вас оцінюють

Немає акредитації, сертифікації чи схеми notified body для AComP-5640. Відповідність виражається як «PCN-compliant», і документ визначає це операційно, а не інституційно: сутність «shall implement PCN-1 interface, PCN-2 interface, or both» залежно від ролі, і те, чи вона фактично взаємодіє, це і є доказ, а не аудит. Єдине місце, де документ використовує слово «certify», - декларація можливостей TFC, яку власники PCS обмінюють з однолітками через NMCD; це технічна самодекларація, а не сертифікат відповідності від будь-якого органу.

Стандарти, на які він посилається

AComP-5640 спирається на невеликий набір інших публікацій НАТО і довгий перелік протокольних стандартів IETF. STANAG 5637 і його Allied Publication, AComP-5637 - Head STANAG PCN - несуть загальну архітектуру PCN, яку цей документ лише коротко підсумовує для повноти. STANAG 4711 / AComP-4711 дає класи трафіку та модель QoS, на яких побудовані вимоги SLA цього документа. STANAG 4290 / AComP-4290 дає тактичний стандарт роз'ємів, названий для польових розгортань Ethernet. Поза нашим каталогом документ неодноразово вказує на STANAG 5655 / AComP-5655, Network Management and Cyber Defence Specification, який ще «under development» і де має бути повністю визначений інтерфейс NMCD, який цей документ лише окреслює, а також на Standards Related Document для схеми адрес PCN STANAG 5637, теж «under development». Механіку протоколів беруть з IETF RFC: IKEv2 (RFC 7296, з профілем алгоритмів у RFC 8247), GRE (RFC 2784, розширений RFC 2890), ESP (RFC 4303), сертифікати X.509 і CRL (RFC 5280), OCSP (RFC 6960), BGP-4 і розширення (RFCs 4271, 4760, 2545, 6793, 1772), Bidirectional Forwarding Detection (RFC 5880, RFC 7419), Generalized TTL Security Mechanism (RFC 5082) і приватна адресація (RFC 1918, RFC 4193).

AComP-5640 опубліковано NATO Standardization Office і внесено до NATO Standardization Document Database, безкоштовно. Документи НАТО не продає ComplyTrain, і ми не розміщуємо копій.

Стандарти, на які він посилається

• STANAG 4711Обов'язкове
• STANAG 5637Довідково
• AComP-5637Довідково
• AComP-4711Довідково
• STANAG 4290Довідково
• AComP-4290Довідково

Інші стандарти в темі «Системи зв'язку та інформації»

• AComP-5639AComP-5639 - специфікації Protected Core Networking для статичного середовища
• ADatP-4774ADatP-4774 синтаксис міток конфіденційності в метаданих
• ADatP-4778Механізм прив'язки метаданих ADatP-4778
• ADatP-5636Специфікація базових метаданих NATO ADatP-5636
• ADatP-5644Профіль обміну повідомленнями через вебсервіси ADatP-5644
• ADatP-5656Інтерфейс федеративного управління сервісами та контролю ADatP-5656