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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Wed, 19 January 2022 16:53 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 C800A3A1398; Wed, 19 Jan 2022 08:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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_HI=-5, 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 jQ8K1vUqTRwY; Wed, 19 Jan 2022 08:53:36 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 983A93A1394; Wed, 19 Jan 2022 08:53:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 20JGrPUH032415; Wed, 19 Jan 2022 11:53:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1642611209; bh=QCJBrGA1yWuZl1ZinEd69jAuU3uYlQdgnInBVZWWbP0=; h=From:To:CC:Subject:Date:From; b=a7Hv/VGPewHBezeD8P9LAWNnANiL2ZnG0U1+agdLu3exTN39O710OylXuOq5XrOSq 7Ws+xek2QfaUL/WSeailK0xuClCJchGKriL4Xzkw7sfQFGsejmWMo6dTKVOxkMMUUG xr+g6g8sYPqeJJeK+6Shl9uqitiEZmiHgml147rgA6dPMwzZu5HDG96XswNB/0mQtS kFuGOXDBopqV/QE0bDNl4RBYxmAnMctkrJURNd6TDK0SP1s/3sj8glLiib7Muqo/VM e6TZ3mesQtJW7on0B8V3dwiZh/iSuyF7chCADzE6TxIeQwl4nfflCI+kbaql5TuoBD rCla6o6XWQiNw==
Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 20JGrLxv032381 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Jan 2022 11:53:21 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.12; Wed, 19 Jan 2022 08:53:20 -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 08:53:20 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Russ Housley <housley@vigilsec.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "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: AdgNUUF0Fob7JpUjROSHMPSnLTWArA==
Date: Wed, 19 Jan 2022 16:53:20 +0000
Message-ID: <c10062dd0ac24e1f8a8e00175c54eee6@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: 3E6C6B5071E5DE84156FA7467C3D0BB230E75A90448127BE53DBEAAE3CC5B2AA2000: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/WbqamYwmO-mJ9q2DvnqZpluuQi8>
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 16:53:41 -0000

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