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

[John E Drake <[e-mail]>]

Ben,

Thanks for your thorough review and discussion.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: BESS <[e-mail]> On Behalf Of Benjamin Kaduk via
> Datatracker
> Sent: Wednesday, July 21, 2021 1:22 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-datacenter-
> gateway-12: (with COMMENT)
> 
> [External Email. Be cautious of content]
> 
> 
> 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-
> criteria.html__;!!NEt6yMaO-gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-
> 8g0fltDGASgWWcsQJ-toZT_lgRJk$
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bess-
> datacenter-gateway/__;!!NEt6yMaO-
> gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-8g0fltDGASgWWcsQJ-
> toZ_kua3SE$
> 
> 
> 
> ----------------------------------------------------------------------
> 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.
> 
> 
> 
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bess__;!!N
> Et6yMaO-gk!WM0wrcZUeK_Mcc3YdAxJJsDiUT_G1M-lAz-8g0fltDGASgWWcsQJ-
> toZF8-VjNc$