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
