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

[Robert Raszuk <[e-mail]>]

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