Re: [secdir] Secdir early review of draft-ietf-rtgwg-atn-bgp-12

["Templin (US), Fred L" <[e-mail]>]

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 <[e-mail]>; Templin (US), Fred L <[e-mail]>
> Cc: IETF SecDir <[e-mail]>; [e-mail]; [e-mail]
> 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 <[e-mail]>
> Sent: Wednesday, January 19, 2022 9:18 AM
> To: Templin (US), Fred L <[e-mail]>
> Cc: IETF SecDir <[e-mail]>; [e-mail]; [e-mail]
> 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 <[e-mail]> 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:[e-mail]]
> >> Sent: Wednesday, January 19, 2022 8:59 AM
> >> To: Templin (US), Fred L <[e-mail]>
> >> Cc: IETF SecDir <[e-mail]>;
> >> [e-mail]; [e-mail]
> >> 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 <[e-mail]> wrote:
> >>>
> >>> Russ, thank you for this Secdir review, and see below for responses:
> >>>
> >>>> -----Original Message-----
> >>>> From: rtgwg [mailto:[e-mail]] On Behalf Of Russ
> >>>> Housley via Datatracker
> >>>> Sent: Tuesday, January 18, 2022 2:22 PM
> >>>> To: [e-mail]
> >>>> Cc: [e-mail]; [e-mail]
> >>>> 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/rtgwg
> >>>
> >