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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 19 January 2022 17:12 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370DF3A1409; Wed, 19 Jan 2022 09:12:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZNYMacrke5d; Wed, 19 Jan 2022 09:12:36 -0800 (PST)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A9D3A13C1; Wed, 19 Jan 2022 09:12:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 20JHCYlG014682; Wed, 19 Jan 2022 12:12:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1642612354; bh=vRSat6ZZ1u64DyYm/69uNLXDoXtbczN5snRx+ba35Ok=; h=From:To:CC:Subject:Date:From; b=MeKGSB1s1uLiZ8bxrgoeB+d9t/5Ks3TquP+JSmZKtJA29gVm9IxwkfPiZ3LPQcGXp +NJwSq30PbADoPk1fBlkpSKjfKssx3dtxHcJNkbGwyAtlROZUB2s0T4hk0lRtpLlnl aQ/MjK95PDs5RPyHH4q/O+RC6ayRG92NrnjFBgDBEHFsUrMKHo8lGc7eUZaxromCmR vEQ03jwcPaa40xa1VXv3jkRApjLWiKy2ezvPdGHayvJaftKNk3f6Qzk7OIdQ3GRPE3 bVG7mlY9HAATc4N1bUqcIv5EwfyFOWQrGLaYqv5oR02M9iKRd23vaS59+Cw8kW3YZu VLZIOcP/tkNVA==
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 20JHCRj1014584 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Jan 2022 12:12:27 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Wed, 19 Jan 2022 09:12:26 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2375.012; Wed, 19 Jan 2022 09:12:26 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Russ Housley <housley@vigilsec.com>
CC: IETF SecDir <secdir@ietf.org>, "draft-ietf-rtgwg-atn-bgp.all@ietf.org" <draft-ietf-rtgwg-atn-bgp.all@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: Secdir early review of draft-ietf-rtgwg-atn-bgp-12
Thread-Topic: Secdir early review of draft-ietf-rtgwg-atn-bgp-12
Thread-Index: AdgNV7pAFob7JpUjROSHMPSnLTWArA==
Date: Wed, 19 Jan 2022 17:12:26 +0000
Message-ID: <528f2aa32e464085955051c8eea33f8b@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: AEC1C4E56FA48C8DF7E1843712116F4CAC1BC08157693236AD8A39F7E905137A2000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/5VwpPHST2cm2Nk5gN0XcKN4OAFQ>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jan 2022 17:12:41 -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:housley@vigilsec.com]
> Sent: Wednesday, January 19, 2022 8:59 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: IETF SecDir <secdir@ietf.org>; draft-ietf-rtgwg-atn-bgp.all@ietf.org; rtgwg@ietf.org
> 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 <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
> >