Fred: That is one approach, but it seems like there needs to be a globally trusted trust anchor or set of trust anchors that understand the architecture to make sure that the certificates are providing the needed authentication and key management.
Russ > On Jan 19, 2022, at 12:12 PM, Templin (US), Fred L > <[email protected]> wrote: > > Russ, ICAO will be the top-level administrative authority for a hierarchy of > Air Navigation Service Providers such as ARINC, SITA, Inmarsat and others. > Different ANSPs will need to establish security peerings between neighboring > ASBRs even though they are from different organizations. So, I assume this > would mean that ICAO would need to be the ultimate authority for the > common PKI? > > Thanks - Fred > >> -----Original Message----- >> From: Russ Housley [mailto:[email protected]] >> Sent: Wednesday, January 19, 2022 8:59 AM >> To: Templin (US), Fred L <[email protected]> >> Cc: IETF SecDir <[email protected]>; [email protected]; >> [email protected] >> Subject: Re: Secdir early review of draft-ietf-rtgwg-atn-bgp-12 >> >> Fred: >> >> If a tunnel that provides confidentiality and integrity is used for all >> control plane traffic, that addresses several of the comments. This does >> raise a question about the approach that will be used to provide keys for >> the tunnel. Will ICAO or some delegated authority provide a PKI >> for this purpose? >> >> Russ >> >> >>> On Jan 19, 2022, at 11:53 AM, Templin (US), Fred L >>> <[email protected]> wrote: >>> >>> Russ, thank you for this Secdir review, and see below for responses: >>> >>>> -----Original Message----- >>>> From: rtgwg [mailto:[email protected]] On Behalf Of Russ Housley via >>>> Datatracker >>>> Sent: Tuesday, January 18, 2022 2:22 PM >>>> To: [email protected] >>>> Cc: [email protected]; [email protected] >>>> Subject: Secdir early review of draft-ietf-rtgwg-atn-bgp-12 >>>> >>>> Reviewer: Russ Housley >>>> Review result: Has Issues >>>> >>>> I reviewed this document as part of the Security Directorate's ongoing >>>> effort to review all IETF documents being processed by the IESG. These >>>> comments were written primarily for the benefit of the Security Area >>>> Directors. Document authors, document editors, and WG chairs should >>>> treat these comments just like any other IETF Last Call comments. >>> >>> I will respond to your points below as IETF Last Call comments. >>> >>>> Document: draft-ietf-rtgwg-atn-bgp-12 >>>> Reviewer: Russ Housley >>>> Review Date: 2022-01-18 >>>> Early Review Due: 2022-02-11 >>>> IETF LC End Date: Unknown >>>> IESG Telechat date: Unknown >>>> >>>> >>>> Summary: Has Issues >>>> >>>> >>>> Major Concerns: >>>> >>>> Section 3 says: >>>> >>>> The only requirement is that ASNs >>>> must not be duplicated within the ATN/IPS routing system itself. >>>> >>>> What party will administer these ASNs? I understand why it does not >>>> need to be IANA, but there does need to be a single authority, even >>>> if a hierarchy is used to delegate assignments. ASN collisions are >>>> extremely harmful. >>> >>> It is assumed that a centralized administrative authority for the ATN/IPS >>> routing system overlay will be responsible for assigning the ASNs. As you >>> note, this has nothing to do with IANA since the ATN/IPS routing system >>> does not interact with the Internet routing system, but most likely an >>> entity such as the International Civil Aviation Organization (ICAO) will >>> be responsible for overall administrative control. I gather from the point >>> you are raising that you would appreciate some additional text to this >>> effect, and I can certainly provide something more concrete. >>> >>>> Section 10 says: >>>> >>>> BGP protocol message exchanges and control message exchanges used for >>>> route optimization must be secured to ensure the integrity of the >>>> system-wide routing information base. >>>> >>>> I assume that "secured" means integrity protected. BGP runs over TCP. >>>> TCP-AO was defined primarily to provide integrity protection for BGP. >>>> Is the intent to use TCP-AO or something else. Please specify. >>> >>> Security is based on network layer security between BGP peers, where all >>> secured traffic between the peers is confidential, integrity-protected and >>> authenticated by a security tunnel. Since the tunnel extends the entire >>> length of the path between the BGP peers, I believe higher-layer security >>> protection such as the TCP-AO you mention should be seen as optional. >>> Again, if this satisfies the concern I could add some words to that effect. >>> >>>> Minor Concerns: >>>> >>>> Section 1 talks about IPsec and Wireguard as "secured encapsulations". >>>> Please say what you mean by security here. Are you expecting >>>> confidentiality, integrity, or both? Since this is an example, >>>> please drop "Wireguard" or provide a reference for it. >>> >>> I am expecting these network-layer securing functions to provide all of >>> confidentiality, integrity and authorization. I can add words to make this >>> more clear. About Wireguard, I would prefer to keep it and provide a >>> reference, but if you recommend dropping I would be willing to do that. >>> >>>> Section 1 goes on to say: >>>> >>>> In particular, tunneling must be used when >>>> neighboring ASBRs are separated by multiple INET hops. >>>> >>>> This seems to mean that tunnels are not used in some if there is a >>>> single INET hop. Can you add a sentence about that? >>> >>> Yes, actually this text is misleading to begin with because tunneling >>> will be used even if the ASBRs are connected by a common link. I >>> will look for better words to use here. >>> >>>> Section 5 says: "...tunnels packets directly between Proxys ...". >>>> Are these IPsec tunnels? I am trying to fully understand when the >>>> tunnels require IPsec (or some other security protocol) and when they >>>> do not. >>> >>> This is a good point. We want to establish an environment where security >>> tunneling is used to protect only control messages and BGP protocol >>> messages while unsecured tunneling is used to convey data plane packets >>> when higher-layer security is used end-to-end. Again, more words may >>> help clarify. >>> >>>> Section 10 lists IPsec, TLS, WireGuard, etc. This is the first >>>> reference to TLS. When do you see TLS being used? >>> >>> TLS and possibly also DTLS may be used to protect the data plane in >>> end-to-end security, but they do not really apply for protecting the >>> control plane which is what this document is about. I could resolve >>> this by either cutting TLS and remaining silent about data plane >>> security, or including one or two sentences such as the above to >>> explain the data plane considerations - do you have a preference? >>> >>> Thanks - Fred >>> >>> >>>> _______________________________________________ >>>> rtgwg mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/rtgwg >>> > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
