nds for ISPs to take mitigation actions (e.g., filtering the traffic, guaranteeing bandwidth or rerouting). End networks have every incentive to use SENSS, since they receive much needed help and they pay only when they use the service. SENSS is economically appealing for ISPs because they can charge the victims for the services they provide. Our service is not a panacea but a long-missing piece in a set of secu- rity solutions. It is coarser grained and simpler than many single-point solutions; in fact, it is complementary to them and meant to be invoked when single-point solutions cannot handle the attack. 4.5.1 SENSS Architecture The SENSS service exposes an interface at each deploying ISP that enables remote victim networks to query this ISP about their mission traffic - traffic that carries either source or destination IPs from the victim's prefixes - and to request filtering services, bandwidth 4.5 SDN Security Attack Prevention guarantees, or route modifications. The ISP authenticates these requests, processes them, and implements them by setting up rules in its OpenFlow switches. In case of queries, the ISP returns the requested information to the remote customer network. This reply is also protected through cryptographic means to ensure authenticity and freshness. Let us denote by SENSS ISP an ISP that deploys SENSS. We use the same definition of flow as does OpenFlow and we define a tag to be a unique identifier of an AS that neighbors an ISP that deploys SENSS. A traffic aggregate is a combination of flow, tag, and direction (IN or OUT) fields. Table 4.1 defines SENSS messages from the customer (victim net- work) to the provider (SENSS ISP) and replies or actions taken by the provider. A traffic query asks about the distribution of traffic across ASes that neighbor with a SENSS ISP. It specifies the traffic aggre- gate of interest and the duration of observation. The ISP returns the list of packets or bytes sent by or sent to each neighbor. This helps SENSS customer trace back its traffic and identify 