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
