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 <Fred.L.Templin@boeing.com> wrote:
> 
> Russ, thank you for this Secdir review, and see below for responses:
> 
>> -----Original Message-----
>> From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Russ Housley via Datatracker
>> Sent: Tuesday, January 18, 2022 2:22 PM
>> To: secdir@ietf.org
>> Cc: draft-ietf-rtgwg-atn-bgp.all@ietf.org; rtgwg@ietf.org
>> 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
>> rtgwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtgwg
> 