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

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 19 Jan 2022 16:53:20 +0000

Russ, thank you for this Secdir review, and see below for responses:

> -----Original Message-----
> From: rtgwg [mailto:[email-masked]] On Behalf Of Russ Housley via Datatracker
> Sent: Tuesday, January 18, 2022 2:22 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Jan 2022 11:59:19 -0500

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 <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 22 Jan 2022 19:53:34 -0800

> > Subject: Secdir early review of draft-ietf-rtgwg-atn-bgp-12
[...]
> when higher-layer security is used end-to-end. Again, more words may

Without looking too hard at the specifics of this draft's situation, as a
general statement, knowing that higher-layer security is used end-to-end is
hard to 100% reliably determine, and the cost of getting it wrong can be
very high.  As a general design pattern, having multiple layers of crypto
that aim to protect different aspects of the traffic is perfectly fine, and
in some cases actually required in order to get the needed properties.
If the only tunnel available is a secure tunnel, then you don't have to
worry about getting the decision wrong.

Looking at the specific scenario in §5, it is not a direct analogue of the
scenario I describe, but I would caution against being too eager to discard
the certainty of always having a secure tunnel.

-Ben

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 24 Jan 2022 14:46:58 +0000

Hi Ben,

> From: Benjamin Kaduk [mailto:[email-masked]]
> Sent: Saturday, January 22, 2022 7:54 PM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Russ Housley <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
> Subject: [EXTERNAL] Re: [secdir] Secdir early review of draft-ietf-rtgwg-atn-bgp-12
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 

The security goal for lower layers is to protect routing information and control
plane messages that affect routing. For that, secured tunnels serve the purpose
well. In the data plane, it is no different than the way the public Internet works.
Secured transactions like online banking are conducted over the public Internet
all the time without requiring a secured tunnel at the network layer, since the
upper layers set up their own security associations. Requiring a secured tunnel
at the network layer even for data plane transactions would interfere with
route optimization and really defeat the purpose of what we are trying to
accomplish here.

Thanks - Fred