Subject: Re: [Last-Call] [secdir] Secdir last call review of draft-ietf-bess-datacenter-gateway-10

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 May 2021 23:27:18 +0100

Hi Ben,

Apologies and especially to Daniel.

> I don't see any responses to this review in the mailarchive.  It looks
like
> it was even sent before the end of the IETF LC, so I'm pretty surprised
> that there was no response.  (I'm particularly interested in the last
> question about the security considerations.)

I think I read as far as...

> Reviewer: Daniel Migault
> Review result: Ready
> Hi,
> Review result: Ready

...and stopped. No issues, no nits, come back to the clarifications later.
Sigh. Well, it is "later" so I'm on target.

> 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.
 However, in
> this case these comments mostly reflect some question to clarify my own
> understanding. Document authors, document editors, and WG chairs should
treat
> these comments just like any other IETF Last Call comments.
> 
> Yours,
> Daniel
> 
> Just to clarify my understanding of Fig 1. BGP usually selects the best
route,
> so if AS1-AS2 is the best, none of the traffic will go through AS3.
However
> even in this configuration AS2 will select one of the GW and all traffic
will
> go only to one of the GW1 or GW2. The Add-Path might be able to
distinguishes
> between AS1-AS2 and AS3 but AS1-AS2 cannot be subdivided between two paths
one
> that would terminates in GW1 and another that would terminates at GW2.

Right. 
What you stated is exactly the problem that we needed to resolve with this
document. The document explains the problem.
And, as you note (and the draft notes) Add-Path is only a solution in some
cases, but not in general.

> I am not sure following acronyms may be expanded as well as AFI/SAFI being
> described with text as opposed to their values. I let you decide whether
that
> is needed or not.

You're right. Mysteriously, AFI/SAFI are not listed as well-known at
https://www.rfc-editor.org/materials/abbrev.expansion.txt

1. I'll update the draft
2. I'll ping the RPC

> OLD:
>  An IPv4 or IPv6 NLRI containing one of the GW's loopback addresses
>       (that is, with an AFI/SAFI pair that is one of 1/1, 2/1, 1/4, or
>       2/4).
> 
> NEW
>  An IPv4 or IPv6 Network Layer Reachability Information (NLRI) [RFC4760]
>  containing one of the GW's loopback addresses (that is, with an Address
Family
>  Number (AFI)/ Subsequent Address Family (SAFI) pair that is one of
IPv4/NLRI
>  used for unicast forwarding (1/1), IPv6/NLRI used for unicast forwarding
>  (2/1), IPv4/NLRI with MPLS Labels (1/4), or IPv6/NLRI with MPLS Labels
(2/4)).

OK. Something like that will go in.

> Security consideration:
> 
> When the information is shared between the domains, I am wondering if the
> information is encrypted or if the communication appears in clear text. If
no
> encryption is used, that information is actually not limited to the two
domains
> but to anyone on path can read it. If that is the case, information
provided by
> the Egress SR domain to the Ingress SR Domain seems to me transiting
through
> the backbone which makes the information pretty much public. I am
wondering if
> I am missing something.

Maybe the current text in Section 8 is not clear enough on this point. Or
rather, it in oblique in its approach to this issue.
You are right on exactly this. It is the same problem as in a VPN -
information about the sites at the edge of the network is carried across the
network in BGP messages. Those messages could reveal the information unless
they are protected.

BGP is (of course) carried over TCP, and TCP can be protected. This is being
clarified in answer to one of the points John Scudder raised in his review.

Thanks,
Adrian