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

[Russ Housley <[e-mail]>]

Yes, that would be good.  It is important to the security of the tunnels.

Russ

> On Jan 19, 2022, at 12:26 PM, Templin (US), Fred L <[e-mail]> wrote:
> 
> 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
>>>>> 
>>> 
>