On December 19, 2019 at 6:23:43 AM, Adrian Farrel wrote: Adrian:
Hi! > I'll think about this a little more when not on vacation... Enjoy your vacation! I'm replying now so I don't have to think about this when I go on vacation. :-) > > (1) Controllers and other nodes. ... > 2. The challenges and concerns that you raise are not dissimilar to the > general attack vectors in a routing system, and should be thought of in the > same way. What happens if a "rogue" router starts issuing bogus routes? > > So, you are right that this can be highlighted in the security section, and > we can note the existing mitigations in a BGP-based routing system against > rogue players. But I doubt that anything "special" is needed. Yes, the same/similar problems exist in "normal" BGP, all the way from the ability of having a rogue router, to invalid route origination and understanding route type support inside a specific AFI/SAFI pair. This document introduces new functionality in the ability of the Controller to, well, control the SFP in a network. *Specific to the new functionality*, what I'm looking for is: (1) a statement that says: "the new functionality introduces this new risk...", which even if it is the same type as "normal" BGP, it is new, and I would even call "special". (2) guidance to operators who might want to deploy this control plane. > > (2) New Flow Specification Traffic Filtering Action > > Hmmm, we don't tent to explain why "MUST NOT" in our specifications. 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. > 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. That is the type of operational considerations that I would like to see the document include. > > (3) Use of the Control Plane > > > > This last point is not specifically for the authors, but for the > > Responsible AD and the Chairs for the sfc WG (cc'd). > > Nevertheless, one of the authors will answer. > > I do not agree that knowledge of SFTs is essential to the construction of > SFPs. I think it is very helpful, but I note that an initial system would > have good knowledge of the location and capabilities of SFIs in the network, > specifically because the "orchestrator" has created and located them. Thus, > the creator of the SFP also knows the locations and types of the SFIs. 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. Thanks!! Alvaro. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
