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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 5 Jul 2020 18:10:03 +0100

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

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 10 Jul 2020 14:21:55 -0400

On July 5, 2020 at 1:10:06 PM, Adrian Farrel wrote:

Adrian:

Hi!

...
> 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?

I don't think that the initial qualification ("in an environment...")
is needed; the action is RECOMMENDED, so the operator can decide
when/if they want to follow it.  Otherwise it looks good to me.

...
> 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
> Section 2.

s/action extended communities/Traffic Filtering Action Extended Communities

I'm not too keen on the use of treat-as-withdraw, specially because
the sender doesn't know that something happened.  Knowing that the
communication is direct between the controller/classifier, I would
like to propose thinking of multiple communities as interfering with
the new one (see §7.7/rfc5575bis).  This would result in this document
specifying something like this:

OLD>
   ...: 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 Section 2.

NEW>
   ....  The "Flow Specification for SFC Classifiers" extended community
   interferes with all other Traffic Filtering Actions.  Only the SFC
   Classifiers action MUST be considered and all others ignored.

If you *really* want to treat-as-withdraw, then here's my suggested
text to be in line with rfc5575bis:

NEW>
   ...: a "Flow Specification for SFC Classifiers" Traffic Filtering Action
   Extended Community advertised with any other Traffic Filtering Action
   Extended Community MUST be treated as malformed.

Thanks!

Alvaro.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Jul 2020 20:56:41 +0100

Thanks Alvaro!

> when/if they want to follow it.  Otherwise it looks good to me.

OK

"Where there is concern..."

> s/action extended communities/Traffic Filtering Action Extended Communities

Ack

>   Extended Community MUST be treated as malformed.

Thanks. I can accept either of your suggestions. I'm going to do some archaeology to remind myself where the treat-as-withdraw came from. I have some memory that it was IDR that pushed us to have this (and other) error actions, but I may well be misremembering. Depending on what I discover, I will pick one or the other of the suggestions and re-post.

Cheers,
Adrian

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 10 Jul 2020 16:06:24 -0400

rfc5575bis, when it came out of the WG had a section about error handling
including treat-as-withdraw.  As we processed and cleaned the document up
we ended up not defining specific effort handling for FS, but relying on
the behavior for Extended communities already specified somewhere else.

Just some digging help. :-)

Alvaro.

On July 10, 2020 at 3:56:44 PM, Adrian Farrel ([email-masked]) wrote:

Thanks. I can accept either of your suggestions. I'm going to do some
archaeology to remind myself where the treat-as-withdraw came from. I have
some memory that it was IDR that pushed us to have this (and other) error
actions, but I may well be misremembering. Depending on what I discover, I
will pick one or the other of the suggestions and re-post.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Jul 2020 22:08:31 +0100

Thanks!

That may explain why we have what we have.

A

From: Alvaro Retana <[email-masked]> 
Sent: 10 July 2020 21:06
To: [email-masked]; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Alvaro Retana's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

rfc5575bis, when it came out of the WG had a section about error handling including treat-as-withdraw.  As we processed and cleaned the document up we ended up not defining specific effort handling for FS, but relying on the behavior for Extended communities already specified somewhere else.

Alvaro.

On July 10, 2020 at 3:56:44 PM, Adrian Farrel ([email-masked] <mailto:[email-masked]> ) wrote: