Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

["Wanghaibo (Rainsword)" <[e-mail]>]

Hi Robert,

    Thanks for your comments.

1. Flowspec is mainly used inside an operator, so the risk is controllable unless the device that generate the Flowspec rule is compromised.
But if this happens, the existing Flowspec rules are enough for hackers to do anything.
Also we can control which peer can support this function.

2. Forwarding does not need to spread a rule into multiple rules.
When matching a rule, the packet needs to obtain its Origin-AS according to the Dest IP in the FIB table, and then use this Origin-AS to perform rule matching. Of course, this action will bring some performance loss.

PS: Netflow is already supporting statistical traffic based on Dest-IP-Origin-AS, it already download Dest-IP-Origin-AS to FIB entry, this prosess can be reused.


Regards,
Haibo

From: Robert Raszuk [mailto:[e-mail]]
Sent: Tuesday, November 5, 2019 1:50 AM
To: Wanghaibo (Rainsword) <[e-mail]>; [e-mail]; Zhuangshunwan <[e-mail]>
Cc: idr@ietf. org <[e-mail]>
Subject: Destination-IP-Origin-AS Filter for BGP Flow Specification


Dear Authors of draft-wang-idr-flowspec-dip-origin-as-filter

After reading this document with interest I am scared !

You have constructed a fantastic tool to hijack traffic to any AS or for that matter balckhole it completely with surgical precision.

Yet the draft does not say a word about validation of such filters. In fact it describes use cases where validation would not be done as no destination IP address would be present at all. Section 4 just illustrates DST ASN + SRC IP.

Technically you highlight the value of the proposal by stating that R1 needs to install only one rule in the data plane:


 Using the method defining in this draft, the ISP AS64597 needs to

   setup only one "Destination Origin AS + Source Prefix" rule in Router

   R1 as following:



     +--------------+--------------+-------------------------+

     | Destination  | Source Prefix| Redirect to IP Nexthop  |

     | IP Origin AS |              |                         |

     +--------------+--------------+-------------------------+

     |  64598       | IP Prefix 61 |       R3                |

     +--------------+--------------+-------------------------+



     Figure 3: Steering the Traffic Using Origin AS and Source Prefix

Well packets do not carry ASNs so that may be a bit tricky for the data plane.

I assume you mean that router will explode given Dst ASN into all atomic BGP destination announcements either by BGP AS_PATH match or by RIR/RPKI lookup. So effectively one such control plane rule may result in 100s of not 1000s of data plane match rules.

And at the end you state:

5.  Security Considerations

   No new security issues are introduced to the BGP protocol by this
   specification.

IMHO this proposal both on security and technical grounds should not proceed any further.

Many Thx,
Robert.