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

[Haoweiguo <[e-mail]>]

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

weiguo

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


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

"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"
[weiguo]: Yes, these are useful cases for flowspec ORF. We can add these usecases in later version of this draft.


That way flow spec effectiveness for DDoS is reduced significantly.

Best,
r.




发件人: Idr [mailto:[e-mail]<mailto:[e-mail]>] 代表 Robert Raszuk
发送时间: 2015年5月30日 17:25
收件人: Haoweiguo; Qiandeng Liang
抄送: [e-mail]<mailto:[e-mail]>
主题: 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.​