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. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
