Subject: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-datacenter-gateway-12: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 21 Jul 2021 10:22:12 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-datacenter-gateway-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The -12 does address the discuss point that I raised, thank you!

In re-reading the draft so as to clear my discuss position, one thing
that occurred to me is that a reader might wonder what mechanisms are in
place to prevent an attacker outside of a site from spoofing an
auto-discovery route with a given site's site identifier.  (The security
considerations already dutifully considers the case of a node in the
site that is not a gateway being able to falsify an auto-discovery
route.)  As far as I can tell this is not an issue because nodes in the
site will not accept auto-discovery routes that initiate from outside
the site, based on configured knowledge of whether a given BGP peering
is internal or external.  The document already makes some allusions to
this by specifying that the actual tunnel encapsulation with the union
of all GWs' data is only included in "every route advertised externally
to that site", implying that the auto-discovery routes are on the
non-external (i.e., internal) advertisements.  It might (or might not)
be worth being more explicit about auto-discovery only occuring
internally within a site, to clarify this mechanism of action.

NITS

Section 1

   Data centers (DCs) are critical components of the infrastructure used
   by network operators to provide services to their customers.  DCs
   (sites) are interconnected by a backbone network, which consists of
   any number of private networks and/or the Internet, by gateway
   routers (GWs).  [...]

This currently looks like "interconnected by <X> (...), by <Y>" which
doesn't seem right.  Maybe end the sentence after "and/or the Internet"
and finish with "Each DC is connected to the backbone by one or more
gateway routers (GWs)"?

   The solution described in this document is agnostic as to whether the
   transit ASes do or do not have SR capabilities.  the solution uses SR
   to stitch together path segments between GWs and through the ASBRs.

Start the sentence with a majuscule 'T'.

   technique will experience scaling issues.  This all means that the
   Add-Paths approach is limited to sites connected over a single AS.

I'd consider "effectively limited"; we know that some groups/individuals
have a high capacity for hitting themselves in the way that recursive
Add-Path would entail.

---

From: John E Drake <[email-masked]>
Date: Wed, 21 Jul 2021 20:10:45 +0000

Ben,

Thanks for your thorough review and discussion.

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: BESS <[email-masked]> On Behalf Of Benjamin Kaduk via
> Datatracker
> Sent: Wednesday, July 21, 2021 1:22 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-datacenter-
> gateway-12: (with COMMENT)
> 
> [External Email. Be cautious of content]
> 
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to
> https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-
> criteria.html__;!!NEt6yMaO-gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-
> 8g0fltDGASgWWcsQJ-toZT_lgRJk$
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-
> datacenter-gateway/__;!!NEt6yMaO-
> gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-8g0fltDGASgWWcsQJ-
> toZ_kua3SE$
> 
> 
> 
> In re-reading the draft so as to clear my discuss position, one thing that occurred
> to me is that a reader might wonder what mechanisms are in place to prevent an
> attacker outside of a site from spoofing an auto-discovery route with a given
> site's site identifier.  (The security considerations already dutifully considers the
> case of a node in the site that is not a gateway being able to falsify an auto-
> discovery
> route.)  As far as I can tell this is not an issue because nodes in the site will not
> accept auto-discovery routes that initiate from outside the site, based on
> configured knowledge of whether a given BGP peering is internal or external.
> The document already makes some allusions to this by specifying that the actual
> tunnel encapsulation with the union of all GWs' data is only included in "every
> route advertised externally to that site", implying that the auto-discovery routes
> are on the non-external (i.e., internal) advertisements.  It might (or might not) be
> worth being more explicit about auto-discovery only occuring internally within a
> site, to clarify this mechanism of action.
> 
> NITS
> 
> Section 1
> 
> This currently looks like "interconnected by <X> (...), by <Y>" which doesn't seem
> right.  Maybe end the sentence after "and/or the Internet"
> and finish with "Each DC is connected to the backbone by one or more gateway
> routers (GWs)"?
> 
> I'd consider "effectively limited"; we know that some groups/individuals have a
> high capacity for hitting themselves in the way that recursive Add-Path would
> entail.
> 
> 
> 
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!N
> Et6yMaO-gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-8g0fltDGASgWWcsQJ-
> toZF8-VjNc$

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Jul 2021 19:36:56 +0100

Hi again,

> COMMENT:
> ----------------------------------------------------------------
>

Per other email. Since I have suggested text I'll make the change.

> and finish with "Each DC is connected to the backbone by one or more

Yeh, that was garbled.

> Start the sentence with a majuscule 'T'.

Ack

> have a high capacity for hitting themselves in the way that recursive

Hmmm. Yes.

New version when I'm allowed to post it.

Cheers,
Adrian