Subject: [Idr] 答复: New Version Notification for draft-liang-idr-flowspec-orf-00.txt

From: Liangqiandeng <[email-masked]>
Date: Tue, 2 Jun 2015 01:46:57 +0000

Thanks for your comments. My replies are as follows:

1. While disseminating FlowSpec rules among different provider's networks, it's reasonable to do some defensive policy to limit installing or
disseminating the injected FlowSpec rules for security consideration. Both dropping or transiting the illegal injected FlowSpec rules are acceptable choices.
 As in the Scenario 1 shown by Figure 1, if a customer hopes to disseminate a FlowSpec rule between its different sites, without any restriction of the provider network,
maybe it' better to establish BGP session between the ASBRs from different sites for disseminating their FlowSpec rules to each other.

2.Actually,our draft doesn't oppose the validation procedures as described in section 6 of RFC5575,
 the RFC checks whether a FlowSpec rule is valid for installing in the local FIB, while the FlowSpec-ORF only checks whether a FlowSpec rule should be disseminated to a specific BGP Peer.

In current FlowSpec deployment practice, there are only some small-scale deployments, single BGP router maybe supports no more than 64k FlowSpec rules. But the FlowSpec rule can be used as flow classifier and flow policy container for fine flow regulating, so there will be more than one million FlowSpec rules(for example flows described by source and destination ip prefix) that a single routing should support. In this case we think the FlowSpec-ORF is valuable.

发件人: Idr [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2015年5月30日 17:25
收件人: Haoweiguo; Qiandeng Liang
抄送: [email-masked]
主题: Re: [Idr] New Version Notification for draft-liang-idr-flowspec-orf-00.txt

Hello Weiguo,

Hi All,
A new draft of "BGP FlowSpec Outbound Route Filter" was proposed.
Your comments and suggestions are appreciated.

Thanks,
weiguo

​Let me provide few comments ​why I think this work should be rather abandoned right at its  -00 version:

section 3.1 Figure 1

   "Therefore, ASBR2 can send to ASBR1 a set of FlowSpec-ORF
   that can be used by ASBR1 to filter its outbound FlowSpec rules to
   ASBR2."

- The above would result in dropping part of the flow descriptions between ASBR 1 and ASBR 2 such that neither ASBR 3 nor ASBR 4 would be able to ever receive it. Note that ASBR 2 may act only as transit and may not be willing to enable foregin filtering in their data plane at all. However it should have not limit it to carry BGP control plane SAFI 133 or 134 to the legitimate peers. So pushing Flow Spec ORF from ASBR 2 to ASBR 1 would be counterproductive.

section 3.1 Figure 2

   "Furthermore, ASBR2 and ASBR3 will distribute the FlowSpec rules to
   ASBR1 and ASBR4 respectively."

- Sending FlowSpec information to ASBR1 would be acting against validation procedures as described in section 6 of RFC5575 which say:

"A flow specification NLRI must be validated such that it is
   considered feasible if and only if:

   a) The originator of the flow specification matches the originator of
      the best-match unicast route for the destination prefix embedded
      in the flow specification."

Summary:

I think we should not suppress propagation of filtering rules in BGP control plane provided they are legitimate (ie. pass validation procedure) just based on cherry picking on the match or actions criteria they contain.

Practically amount and  churn of the amount of flow spec information would be rather in white noise levels compared to what BGP should be ready to carry.

However if one would like to limit those other already available tools could be used: longer MRAI timer, dedicated BGP session for SAFI 133/134 with different input processing, FS NLRI dampening etc ...

​Regards,
r.​

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Jun 2015 11:18:49 +0200

>
> maybe it' better to establish BGP session between the ASBRs from different
> sites for disseminating their FlowSpec rules to each other.
>

​Maybe it is better though completely not practical to recommend web of
eBGP multihop sessions between peers ​which do not know each other and have
no peering agreements.

Moreover notice that in such case for validation purposes unicast traffic
would also need to be send over such direct peering what in turn means that
it would have to be encapsulated.

2.Actually,our draft doesn't oppose the validation procedures as described
> in section 6 of RFC5575,

​I commented on your example where you say that flow would go to ASBR1. It
would not if you validate it. ​

should support. In this case we think the FlowSpec-ORF is valuable.

​ORF in general is about pushing your inbound filter to a peer. Here we are
talking about installing inbound filters for flow spec routes and pushing
it to a peer.

How do you know what to reject if the flow information is dynamic by nature
.. created upon detection of DDoS ?

I am having problem envisioning a scenario that some of my peers push me
ORF stating

"I do not want to hear of flow spec routes from you which:

- contain match on port XX
- contain match on SRC/DST address x.x.x.x
- contain action drop
etc"

That way flow spec effectiveness for DDoS is reduced significantly.

Best,
r.

>
>
>
>
> *发件人:* Idr [mailto:[email-masked]] *代表 *Robert Raszuk
> *发送时间:* 2015年5月30日 17:25
> *收件人:* Haoweiguo; Qiandeng Liang
> *抄送:* [email-masked]
> *主题:* Re: [Idr] New Version Notification for
> draft-liang-idr-flowspec-orf-00.txt
>
>
>
> Hello Weiguo,
>
>
>
> Hi All,
> - The above would result in dropping part of the flow descriptions between
> ASBR 1 and ASBR 2 such that neither ASBR 3 nor ASBR 4 would be able to ever
> receive it. Note that ASBR 2 may act only as transit and may not be willing
> to enable foregin filtering in their data plane at all. However it should
> have not limit it to carry BGP control plane SAFI 133 or 134 to the
> legitimate peers. So pushing Flow Spec ORF from ASBR 2 to ASBR 1 would be
> counterproductive.
>
>
>
>
>
> section 3.1 Figure 2
>
>
>
> - Sending FlowSpec information to ASBR1 would be acting against validation
> procedures as described in section 6 of RFC5575 which say:
>
>
>
> I think we should not suppress propagation of filtering rules in BGP
> control plane provided they are legitimate (ie. pass validation procedure)
> just based on cherry picking on the match or actions criteria they contain.
>
>
>
> Practically amount and  churn of the amount of flow spec information would
> be rather in white noise levels compared to what BGP should be ready to
> carry.
>
>
>
> However if one would like to limit those other already available tools
> could be used: longer MRAI timer, dedicated BGP session for SAFI 133/134
> with different input processing, FS NLRI dampening etc ...
>
>
>
>
>
> ​Regards,
>
> r.​
>
>
>

---

From: Haoweiguo <[email-masked]>
Date: Wed, 3 Jun 2015 03:48:48 +0000

Thanks Robert for your good comments and suggestions. Pls see inline with [weiguo].

weiguo

________________________________
From: [email-masked] [[email-masked]] on behalf of Robert Raszuk [[email-masked]]
Sent: Tuesday, June 02, 2015 17:18
To: Liangqiandeng
Cc: [email-masked]; Haoweiguo; Youjianjie
Subject: Re: 答复: [Idr] New Version Notification for draft-liang-idr-flowspec-orf-00.txt

​Maybe it is better though completely not practical to recommend web of eBGP multihop sessions between peers ​which do not know each other and have no peering agreements.

Moreover notice that in such case for validation purposes unicast traffic would also need to be send over such direct peering what in turn means that it would have to be encapsulated.

​I commented on your example where you say that flow would go to ASBR1. It would not if you validate it. ​

​ORF in general is about pushing your inbound filter to a peer. Here we are talking about installing inbound filters for flow spec routes and pushing it to a peer.

How do you know what to reject if the flow information is dynamic by nature .. created upon detection of DDoS ?
[weiguo]: Yes, i agree. If the ingress PE doesn't know any flow information ahead of time, it can't generate any effective ORF.

I am having problem envisioning a scenario that some of my peers push me ORF stating

- contain match on port XX
- contain match on SRC/DST address x.x.x.x
- contain action drop
etc"
[weiguo]: Yes, these are useful cases for flowspec ORF. We can add these usecases in later version of this draft.

Best,
r.

发件人: Idr [mailto:[email-masked]<mailto:[email-masked]>] 代表 Robert Raszuk
发送时间: 2015年5月30日 17:25
收件人: Haoweiguo; Qiandeng Liang
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Idr] New Version Notification for draft-liang-idr-flowspec-orf-00.txt

Hello Weiguo,

Hi All,

Thanks,
weiguo

section 3.1 Figure 1

section 3.1 Figure 2

Summary:

​Regards,
r.​

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Jun 2015 14:55:27 -0400

> talking about installing inbound filters for flow spec routes and pushing

More importantly, in my opinion, flowspec already does rather well at
distributing its filtering behaviors without the need for the added
complexity of the ORF mechanism.  I don't believe ORF is a good fit and I
strongly suggest that this work be discontinued.

-- Jeff

---

From: Liangqiandeng <[email-masked]>
Date: Tue, 16 Jun 2015 02:29:20 +0000

Thanks for your interest in this draft and your comments.

Yes, as Robert has pointed out, flowspec-orf is unnecessary while there are not so many flowspec rules disseminated in the network, the router can filter the invalid flowspec rules locally.

But as flowspec is applied more and more popularly(e.g. draft-patel-raszuk-bgp-vector-routing-05, draft-liang-idr-bgp-flowspec-route-00), maybe the flowspec-orf will be more and more useful.

Please do me a favour, do you think whether the use cases of flowspec-orf are reasonable? Any comment is welcome.

-----邮件原件-----
发件人: Jeffrey Haas [mailto:[email-masked]] 
发送时间: 2015年6月16日 2:55
收件人: Robert Raszuk
抄送: Liangqiandeng; [email-masked]
主题: Re: [Idr] 答复: New Version Notification for draft-liang-idr-flowspec-orf-00.txt

On Tue, Jun 02, 2015 at 11:18:49AM +0200, Robert Raszuk wrote:
> ​ORF in general is about pushing your inbound filter to a peer. Here 
> we are talking about installing inbound filters for flow spec routes 
> and pushing it to a peer.

More importantly, in my opinion, flowspec already does rather well at distributing its filtering behaviors without the need for the added complexity of the ORF mechanism.  I don't believe ORF is a good fit and I strongly suggest that this work be discontinued.

-- Jeff