Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

On May 31, 2020 at 4:10:35 PM, Adrian Farrel wrote:


Adrian:

Hi!


> > DISCUSS:
> > -------------------------------------------------------------
> >
> > (1) Controllers and other nodes.
...
> So, you are right and we are highlighting it in the security section, and
> we can note the existing mitigations in a BGP-based routing system against
> rogue players.

You didn't explicitly say so, but it looks like this may be the added text:

   Similarly, there is a vulnerablity if a rogue or subverted controller
   announces SFPs especially if that controller "takes over" an existing
   SFP and changes its contents.  This is corresponds to a rogue BGP
   speaker entering a routing system, or even to a Route Reflector
   becoming subverted.  Protection mechanisms, as above, include
   securing BGP sessions and protecting software loads on the
   controllers.

[nit] s/vulnerablity/vulnerability

Authentication helps, but it doesn't stop an authenticated subverted
node from taking over control of an SFP.

Maybe I haven't been clear with my concern.  I am concerned about
authorization of the BGP speaker to even act as a controller -- this
is akin to route origin validation: should a BGP speaker even be
generating SFPRs?  In "normal" BGP a mitigation against invalid
origination is ingress filtering -- in this case, a mitigation might
be for the operator to receive (using an access list, for example)
SFPRs originated by only some nodes.




> > (2) New Flow Specification Traffic Filtering Action
...
> I said:
> : Hmmm, we don't tent to explain why "MUST NOT" in our specifications.
> : The reasoning here is that it would be highly confusing to mix and match
> : SFC Classification with BGP routing. Perhaps I am wrong about that
> : confusion.
> : I think that when you program an SFC classifier, that is a single peer-to-
> : peer communication targeted at an SFC Classifier.
> : A 5575-only node will not be a classifier.
>
> You responded:
> | I raised this point as a DISCUSS because the text is at odds with other
> | standards track documents. That is the reason I'm asking for an
> | explanation.

You missed the second part of my response (to the last couple of sentences):

You>
   I think that when you program an SFC classifier, that is a single
   peer-to-peer communication targeted at an SFC Classifier.
   A 5575-only node will not be a classifier.

Me>
   That is the type of operational considerations that I would like to see
   the document include.


That's all I'm looking for.  By "isolating" the communication from
potential rfc5575bis-only nodes you eliminate my concern.


BTW, I didn't mention this before...  You use both rfc5575 and
I-D.ietf-idr-rfc5575bis as Normative references.  rfc5575bis is
already in the RFC Editor's queue, so you really only need that one.


...
> > (3) Use of the Control Plane
...
> And you said...
>
> | Everywhere I look at (§3.2, §4.3, for example) seems to indicate to me
> | that an SFT is necessary in the definition of the SPF. I may of course be
> | wrong or have missed where it clearly isn't. An example of how to do
> | it would be very useful.
>
> We see a number of types discussed
> - in this document
> - RFC 7665

Ok...so you now added to the table in §10.5.  Some of the new values
are not defined in this document, please add references to where they
are described.


> - https://tools.ietf.org/html/draft-dawra-idr-bgp-ls-sr-service-segments-02#section-4.1
> - https://tools.ietf.org/html/draft-dawra-idr-bgp-ls-sr-service-segments-02#section-4.2
>
> We have decided to group these all together and request population of the
> registry in Section 10.5.
> We are discussing with the authors of
> draft-dawra-idr-bgp-ls-sr-service-segments precisely what we should include
> and what they will ask for in their own draft.


draft-dawra-idr-bgp-ls-sr-service-segments needs "service types" and
"function identifiers" for purposes other than implementing this SFC
control plane.

I would still like to hear from the AD/sfc-chairs about whether there
is interest in the sfc WG to take advantage of the control plane.




> > COMMENT:
> > ---------------------------------------------------------------
...
> > (4) §3.1.1/§3.1.2: The two new Extended Communities are defined as
> > different types. Is it really necessary to request two different types,
> > instead of one type with sub-types? The transitive space is not close to
> > exhaustion, but having a single type would make it easier for any future
> > SFC-related extended communities to be identified/grouped. Just a
> > thought...
>
> Yeah, that's an easy change.

You're creating the new SFC Extended Community Sub-Types Registry, so
you can go ahead and assign the TBD7/TBD8 values.


Thanks!

Alvaro.