[bess] Meeting minutes uploaded, if any comment missing. Please send it to list as well.
All, I have uploaded initial version of minutes. Would be updating it over weekend if there is something missing . Mankamana ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)
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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Roman Danyliw's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)
Hi Roman,
Without delving deeper (yet), why is this document any different from any other
document in which BGP is used? Will you be placing a Discuss on every document
coming out of IDR and BESS until there is a clear statement of how to secure
BGP-based systems?
Thanks,
Adrian
-Original Message-
From: Roman Danyliw via Datatracker
Sent: 18 December 2019 19:15
To: The IESG
Cc: draft-ietf-bess-nsh-bgp-control-pl...@ietf.org; bess-cha...@ietf.org;
slitkows.i...@gmail.com; bess@ietf.org
Subject: Roman Danyliw's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13:
(with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for
draft-ietf-bess-nsh-bgp-control-plane-13: Discuss
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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/
--
DISCUSS:
--
* Section 9 cites a number of references (which cite additional references) on
BGP security. My summary of the highlights is:
(1) RFC4271 => TCP MD5 (RFC2385) is a MUST
(2) RFC4271 => consider RFC 3562 for key management guidance
(3) ietf-idr-tunnel-encaps => caution on Tunnel Encapsulation attribute
(4) rfc4364 => TCP MD5 is a non-rfc2119 “should”
(5) rfc4364 => don’t make connections with untrusted peers
(6) RFC7432 => references the utility of TCP-AO (RFC5925)
- Could the text articulate more clearly de-conflict (1), (4) and (6) – what is
the recommended approach?
- a discuss-discuss – Given the green field nature of this specification (the
shepherd’s report notes no implementation) and the assumed SFC deployment model
(not the internet; a single provider’s operational domain where key management
should be easier), could a more robust transport security option such as BGP
over IPSec be RECOMMENDED?
--
COMMENT:
--
* Section 2.2. Could you please clarify connect between these two statements
about the SFC architecture:
1. “The SFIR is advertised by the node hosting the service function instance”
2. “We assume BGP connectivity between the Controller and all SFFs within each
service function overlay network”
Is the node referenced in statement (1) the SFF. If not, it seems like they
need to be added to statement #2 as entities that have BGP connectivity.
* Section 2.2. Per Figure 1, where is the “Controller” in this reference model?
* Section 3.1. Per “If two SFIRs are originated from different administrative
domains …”, are these administrative domains still in a “within a single
provider's operational domain” per Section 2.2.?
* Section 3.1.1. Per the SFIR Pool Identifier Value being “globally unique”,
is that globally unique per Controller? Per overlay network?
* Section 4.3. Per the summary notation of “RT, {SFPR-RD, SPI}, m * {SI, {n *
{SFT, p * SFIR-RD} } }”, it isn’t clear to me what this expression is
summarizing. Also, what does the “*” mean?
* Section 4.5.1. Per “Therefore, while this document requires that the SI
values in an SFP are monotonic decreasing, it makes no assumption that the SI
values are sequential.”, should this “requires” be a RFC2119 MUST or REQUIRED?
* Section 6. Per “Therefore, the use of NSH metadata may be required in order
to prevent infinite loops”, what is this meta-data?
* Section 7.2. Per “In such cases it can be important or necessary that all
packets from a flow continue to traverse the same instance of a service
function so that the state can be leveraged and does not need to be
regenerated.”, how is this requirement signaled through the SFIRs for the
computation of SFPs?
* Editorial Nits:
- Section 2.2. s/channelled/channeled/
- Section 4.5.1. s/bevahior/behavior/
- Section 7.1. Per “As noted in Section 3.2.1.1 SFPRs reference each other one
SFPR advertisement will be received before the other.”, this sentence didn’t
parse for me.
- Section 8.9.1. Typo. s/is is/is/
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)
Hi Alvaro, I'll think about this a little more when not on vacation, but I want to draw your attention to two things: > (1) Controllers and other nodes. 1. The controllers are not SDN controllers. They are not single omnipotent, all-seeing god boxes. They are boxes that control. They could be dedicated devices, management systems, distributed servers, or network devices. They are, simply put, BGP speakers. 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. > (2) New Flow Specification Traffic Filtering Action 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. > (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. What this draft does is open the door for future more dynamic approaches. What might be surprising would be if the FCFS registry of SFT values had been populated prior to creation of the registry 😊 Best, Adrian === (1) Controllers and other nodes. Background: This document defines the new SFC NLRI, which has two distinct route types, originated by either a node hosting an SFI or a Controller. Each route type has a specific function and it is reasonable to expect that the originators represent different nodes in the network, with different functions, location, etc.. BGP Capabilities Advertisement doesn't have a route type granularity; instead, a BGP speaker known to support the SFC NLRI could originate any type of route. The facts above open the possibility that any node in the network can originate an SFPR and take over an SFP. §3.2.2 does a very good job of explaining the potential existence of multiple Controllers and even offers the appropriate tie breaker to take control of the SFP: "MUST use the SFPR with the numerically lowest SFPR-RD". The document proposes no mitigation to the possibility of any node (a rogue node, for example) issuing SFPRs. The assumption (§2.2) of "BGP connectivity between the Controllers and all SFFs" introduces also the ability to locate a rogue controller anywhere; I interpret "BGP connectivity" to include the presence of a router reflector (for example), which then allows distribution of SFPRs without going through a central policy point. On one hand I think this condition is a feature (the Controller can be anywhere), but the case of a rogue node that wants to act as a controller is not considered. To address this issue, I would like to see text that (1) acknowledges the issue (maybe in the security considerations section), and (2) discusses operational considerations for the placement, control, filtering, etc. of Controllers and the corresponding UPDATES from them and/or other nodes in the network. IOW, the considerations around proper initial setup of the system should be clear. (2) New Flow Specification Traffic Filtering Action §7.4 (Flow Spec for SFC Classifiers) defines a new Traffic Filtering Action to be used with the Flow Specification NLRI. rfc5775bis allows for any combination of Traffic Filtering Actions to be present, but this document says that "other action extended communities MUST NOT be present". I believe that specifying the use of treat-as-withdraw is ok as a case of Traffic Filtering Action Interference -- I just say "ok" because it is not clear to me (nor explained anywhere) why other Traffic Filtering Actions cannot be used; for example, I could imagine rate-limiting the traffic into an SFP. What concerns me more (and the reason for this DISCUSS point) is that rfc5575-only implementations will not consider the new Traffic Filtering Action, but could, depending on the components encoded in the NLRI, take actions based on other Traffic Filtering Actions. The result can then be an inconsistent application of Traffic Filtering Actions in the network -- for example, some nodes may want to d
