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

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 19 Jan 2022 17:12:26 +0000

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Jan 2022 12:17:56 -0500

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-masked]> wrote:
>