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

[Adrian Farrel <[e-mail]>]

Hi again,

> 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.

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

> 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)"?

Yeh, that was garbled.

>   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'.

Ack

>   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.

Hmmm. Yes.

New version when I'm allowed to post it.

Cheers,
Adrian