Yes, that would be good. It is important to the security of the tunnels. Russ
> On Jan 19, 2022, at 12:26 PM, Templin (US), Fred L > <[email protected]> wrote: > > Thanks Greg - Russ, maybe you would like some words to this effect in the > draft? > > Fred > >> -----Original Message----- >> From: Saccone (US), Gregory T >> Sent: Wednesday, January 19, 2022 9:21 AM >> To: Russ Housley <[email protected]>; 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 >> >> Hi Russ- >> Fred is correct, ICAO has a Trusted Framework Study Group that is defining >> the PKI approach for ATN/IPS, and this is being done in >> conjunction with the various ATN/IPS industry groups as well. >> Thanks >> Greg >> >> -----Original Message----- >> From: Russ Housley <[email protected]> >> Sent: Wednesday, January 19, 2022 9:18 AM >> To: Templin (US), Fred L <[email protected]> >> Cc: IETF SecDir <[email protected]>; [email protected]; >> [email protected] >> Subject: [EXTERNAL] Re: Secdir early review of draft-ietf-rtgwg-atn-bgp-12 >> >> EXT email: be mindful of links/attachments. >> >> >> >> 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
