Hello again, Alvaro.
> > 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
Thanks
> 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.
So, to be clear, you are worried about what happens to the routing
infrastructure if one node gets subverted, and you believe that a combination
of something akin to route origin validation and ingress filtering would help.
Obviously (?) it is intended (and even stated) that SFPRs are originated only
by controllers, and as we say, "We assume that the Controllers have BGP
connectivity to all SFFs and all Classifiers within each service function
overlay network." That means that we are not relying on BGP peer-to-peer relay
of SFPR advertisements, but they are injected to the SFFs direct. Thus, your
concern is mitigated by making sure that the SFF/controller relationship is
known and authenticated, except for the case when the controller has been
subverted.
I don't, in this case, see how route origin validation or ingress filtering
would help us. A subverted controller in this case is like having two NMSes (or
two SDN controllers) in a network with both intended to be able to manage the
network in parallel: what do you do if one is subverted?
I think, here, we are discussing the wrong approach to a solution. A protocol
solution cannot protect against the subversion of a component that is otherwise
authorised to act.
We can, however, make sure that only nodes that are authorised to be
controllers are allowed to speak as controllers. An approach here would be to
configure each SFF with the identities of the controllers that it accepts.
(This, for example, is what is usually done with NMSes. Note that in the PCE
world, a PCC can be configured with the identities of he PCEs or it can
discover them). I think we might add...
"In an environment where there is concern that rogue Controllers might be
introduced to the network and inject false SFPRs or take over and change
existing SFPRs, it is RECOMMENDED that each SFF and Classifier be configured
with the identities of authorised Controllers. Thus, the announcement of an
SFPR by any other BGP peer would be rejected."
Would that be good?
>>> (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.
OK, we can work something out.
How about:
Note that implementation of this section of this specification will be
Controllers or Classifiers communicating with each other directly for
the purpose of instructing the
Classifier how to place packets onto an SFP. In order that the
implementation of Classifiers can be
kept simple and to avoid the confusion between the purpose of
different extended communities, a
Controller MUST NOT include other action extended communities at the
same time as a "Flow Specification
for SFC Classifiers" extended community: the inclusion of the "Flow
Specification for SFC Classifiers"
action extended community along with any other action MUST be treated
by an implementation of this
specification as an error which SHOULD result in the Flow
Specification UPDATE message being handled
as Treat-as-withdraw according to <xref target="RFC7606" /> Section 2.
> 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.
Yeah, time flies and rfc5575bis has overtaken us. That's good and I'll do the
update.
>>> (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.
OK, can do that. Slightly worried that the IANA section is not supposed to be a
place to include references for information, but doing it anyway.
>> -
>> 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.
Not sure you're right. That draft defines "Service Type" in a section called
"BGP-LS Extensions for Service Chaining" and includes them in the Service
Chaining TLV.
> 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.
Since this part of the Discuss is not actionable by the authors, I leave you to
talk to the AD/SFC chairs direct. All I can do is point you to the discussions
that happened on the SFC list.
>>> 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, you made me notice that I didn't tell IANA what the size of the
registry is.
Adrian
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
