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

From: Robert Raszuk <[email-masked]>
Date: Mon, 4 Nov 2019 18:50:29 +0100

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.

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Tue, 5 Nov 2019 08:11:12 +0000

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:[email-masked]]
Sent: Tuesday, November 5, 2019 1:50 AM
To: Wanghaibo (Rainsword) <[email-masked]>; [email-masked]; Zhuangshunwan <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Destination-IP-Origin-AS Filter for BGP Flow Specification

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:

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

   R1 as following:

     | IP Origin AS |              |                         |

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.

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.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 7 Nov 2019 12:37:33 -0500

Haibo,

>From a forwarding perspective, this is the detail that bothers me.

Flowspec right now is currently independent of FIB state.  It functions on
the firewall layer, which is typically implemented prior to FIB.

What this feature implies is something roughly like:
Packet comes in, hits rule to check dst-as.
dst-as lookup needs to happen as one of:
- communicate to BGP routing process. (not likely to scale)
- trigger a FIB lookup, check returned dst-as.  Violates pipelining in many
  architectures.
- Have the entire FIB's dst-as-map pushed into memory for firewall,
  implement as a longest-match lookup on that collection.

-- Jeff

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Fri, 8 Nov 2019 01:48:24 +0000

Hi Jeffrey,

	Flowspec is designed for security protection, but current usage is not limited to security protection, 
    but also to optimize traffic. Using Flowspec to optimize traffic is safer and more reliable than send routes to router.

    Our scenario here is for optimize traffic. The actions here are all performed on the routers. You need to perform a FIB lookup to get dest-as.

    This does violate some of the current rules and introduces a certain performance penalty,
    but it can reduce the demand for Flowspec entry space, so you can use this rule in the appropriate scenario.

Regards, 
Haibo

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Friday, November 8, 2019 1:38 AM
To: Wanghaibo (Rainsword) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; [email-masked]; Zhuangshunwan <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Haibo,

>From a forwarding perspective, this is the detail that bothers me.

Flowspec right now is currently independent of FIB state.  It functions on the firewall layer, which is typically implemented prior to FIB.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 8 Nov 2019 12:11:06 -0500

Haibo,

Thanks for the expected clarification.

To the chairs, as noted below the feature violates some fundamentals of flowspec architecture.  I'd strongly object to the feature being adopted without a new SAFI to get it out of the existing flowspec use cases.

-- Jeff

> On Nov 7, 2019, at 8:48 PM, Wanghaibo (Rainsword) <[email-masked]> wrote:
> 
> Hi Jeffrey,
>

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Mon, 11 Nov 2019 07:21:17 +0000

Hi Jeffrey,

	Thanks for your suggestion.

	Flowspec is intended to match only the message fields. 
	Our solution here is an enhancement to Flowspec, which can effectively reduce the space of the flowspec.

	The rules here are also used in conjunction with the existing Flowspec rules, so using the new SAFI to describe it is not appropriate.
	We can increase OPEN capability negotiation to enable when this feature is supported.

Regards,
Haibo

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Saturday, November 9, 2019 1:11 AM
To: Wanghaibo (Rainsword) <[email-masked]>; [email-masked]
Cc: Robert Raszuk <[email-masked]>; [email-masked]; Zhuangshunwan <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Haibo,

-- Jeff

> Cc: Robert Raszuk <[email-masked]>; [email-masked]; 
> Zhuangshunwan <[email-masked]>; idr@ietf. org <[email-masked]>
> - trigger a FIB lookup, check returned dst-as.  Violates pipelining in 
> many  architectures.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 11 Nov 2019 03:24:03 -0500

> 	We can increase OPEN capability negotiation to enable when this feature is supported.

BGP NLRI are transitive across a network.  If you want a feature that varies
on NLRI parsing or processing behavior, it needs to be uniformly supported
across all BGP speakers that receive it.  This cannot be a capability.  That
behavior is covered by afi/safis.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Nov 2019 12:50:20 +0100

Wanghaibo,

Flow spec 5575 and 5575bis limits to what can be used as match criteria to
IPv4/IPv6 IP layer and transport layer headers:

*"The following sections define component types and parameter encodings for
the IPv4 IP layer and transport layer headers."*

Your proposal can not proceed under FlowSpec umbrella as packet's target
ASN is not carried in any of the packet headers so it can not be applied as
a packet ACL.

If you want to continue with this extension let's use a different SAFI and
preferable a different name.

Thx,
R.

On Mon, Nov 11, 2019 at 8:21 AM Wanghaibo (Rainsword) <
[email-masked]> wrote:

>         Our solution here is an enhancement to Flowspec, which can
> effectively reduce the space of the flowspec.
>
>         The rules here are also used in conjunction with the existing
> Flowspec rules, so using the new SAFI to describe it is not appropriate.
> To the chairs, as noted below the feature violates some fundamentals of
> flowspec architecture.  I'd strongly object to the feature being adopted
> without a new SAFI to get it out of the existing flowspec use cases.
>
> -- Jeff
>
>
> >    but also to optimize traffic. Using Flowspec to optimize traffic is
> safer and more reliable than send routes to router.
> >
> >    Our scenario here is for optimize traffic. The actions here are all
> performed on the routers. You need to perform a FIB lookup to get dest-as.
> >
> >> 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.
> >
> > Flowspec right now is currently independent of FIB state.  It functions
> on the firewall layer, which is typically implemented prior to FIB.
> >
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 11 Nov 2019 12:40:44 +0000

Hi Robert,

The sentence you quoted simply says that the existing type can perform such behavior, and not “Must” or “Should”.

Thanks,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, November 11, 2019 7:50 PM
To: Wanghaibo (Rainsword) <[email-masked]>
Cc: [email-masked]; idr@ietf. org <[email-masked]>; [email-masked]
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Wanghaibo,

Flow spec 5575 and 5575bis limits to what can be used as match criteria to IPv4/IPv6 IP layer and transport layer headers:

"The following sections define component types and parameter encodings for the IPv4 IP layer and transport layer headers."

Your proposal can not proceed under FlowSpec umbrella as packet's target ASN is not carried in any of the packet headers so it can not be applied as a packet ACL.

If you want to continue with this extension let's use a different SAFI and preferable a different name.

Thx,
R.

On Mon, Nov 11, 2019 at 8:21 AM Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jeffrey,

Regards,
Haibo

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, November 9, 2019 1:11 AM
To: Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Zhuangshunwan <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Haibo,

-- Jeff

> On Nov 7, 2019, at 8:48 PM, Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Jeffrey,
>
> From: Jeffrey Haas [mailto:[email-masked]<mailto:[email-masked]>]
> To: Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>
> Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> Zhuangshunwan <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Zhuangshunwan <[email-masked]>
Date: Mon, 11 Nov 2019 13:02:10 +0000

Hi,

Per my understanding of the existing types defined in that section, it does not preclude the extensions of new types with new behaviors.

Thanks,
Shunwan

From: Idr [mailto:[email-masked]] On Behalf Of Zhuangshunwan
Sent: Monday, November 11, 2019 8:41 PM
To: Robert Raszuk <[email-masked]>; Wanghaibo (Rainsword) <[email-masked]>
Cc: [email-masked]; [email-masked]; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Hi Robert,

Thanks,
Shunwan

Cc: [email-masked]<mailto:[email-masked]>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Wanghaibo,

Thx,
R.

Regards,
Haibo

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, November 9, 2019 1:11 AM
To: Wanghaibo (Rainsword) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Zhuangshunwan <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Destination-IP-Origin-AS Filter for BGP Flow Specification

Haibo,

-- Jeff