• 1

Article on Spam from an INRM Perspective

By: Amreesh Phokeer
Contributors: Alain Aina and Loganaden Velvindron

During the AIS'15 Meeting in Tunis, AFRINIC was invited to speak on anti-spam measures from AFRINIC's perspective. With the objective of  sensitising the AFRINIC community on spam, Amreesh Phokeer from  AFRINIC's Research and Innovation team wrote this article which also critically analyses existing anti-spam mechanisms and their utilisation.

Abstract

The concept of 'spam' on the Internet is known to virtually every Internet user. The fight against spam is a worldwide issue. Spam has a broad negative effect on the Internet causing technical and operational problems to network operators and users. It is a nuisance and is also regularly used in criminal activities such as phishing and other fraud.

While the issue of spam is multidimensional and needs be tackled at different levels, AFRINIC plays an important role as a provider of information on Internet number resources. AFRINIC itself is not mandated to fight spam but it maintains a registry that is of paramount importance for traceability of Internet Number Resources ownership information.

This paper specifically deals with the different policies and technical frameworks at AFRINIC, that are basically part of the RIR toolkit for Internet Number Resources Management, but which are important in the fight against spam.

The statistics however shows that those mechanisms, whether policy-related or technical, are mostly under-utilised. 

Introduction

Spam is global issue that is not recent. It started back in the days where email actually started and it initially took the form of chain letters. Spamming techniques and medium have greatly evolved with the advent of cloud-based email and social media platforms. A study from Symantec on the state of spam, shows that spam made up of more that 92% of all email messages [1]. This goes to show the severity of the issue.

This is why, after so many years, the fight against spam still remains a topic of great interest for both the technical community and policy-makers. Many stakeholders in the digital sphere have pulled hands together and came with joint-effort to fight spam, namely ITU and ISOC [21]. The private sector also came up with the M3AAWG (Messaging Malware Mobile Anti-Abuse Working Group) [25]. The aim of this Working Group is to focus on operational issues of Internet abuse to fight botnets, malware, spam, viruses, DoS attacks through technology, industry collaboration and public policy. 

As a registry of Internet resources, an RIR operates at the network layer of the OSI model or more commonly at the Internet layer of the TCP/IP model. By virtue of its function, which is the allocation of Internet resources (IP addresses and AS number), RIRs have a direct link to operators at the network-level, which are the LIRs (Local Internet Registries) or End-users. They all operate a network and can therefore potentially be a source of spam, as well as, victim of spammers.

What is a spam?

The exact definition of spam is something that has been subject to endless debates on many forums. Some feel that the implicit right to freedom of speech allows them to send any mails they wish. This however must be weighed up against the rights of the recipients. RFC2635 defines Spam as "transmission of bulk unsolicited emails"[2] .

The definition of spam should largely be considered from the point of view of the recipient. Any mail that a recipient does not wish to receive can in many cases be considered as spam but there are some generally accepted characteristics of spam:

  • Bulk volumes of messages sent to thousands of users who have never requested to be sent them.

  • Messages that raise security concerns: Mail Bombing, Viruses, Phishing, Scams, ID Theft.

  • Messages that negatively affect the operation of the networks in the methods that they are delivered.

  • Mostly consisting of commercial, offensive or harmful content

  • Sending of messages that are difficult to trace back to a sender

Challenges for network service providers

Most of the challenges that service providers face with regards to spam are the same around the world. Security concerns, bandwidth consumption, overloading of computing resources, dissatisfied customers are all problems that are affecting networks across the globe. African networks do sometimes feel the effect of these more strongly due to the bandwidth, computing and financial resource constraints on the continent and thus there is a requirement to be somewhat more careful with the approach to dealing with spam.

In addition, the methods of sending spam are continuously evolving and changing and the only way to combat this is to be continuously updating the spam fighting techniques. The knowledge about these techniques needs to be effectively shared between operators to ensure that their networks are able to continue to function and it is in their best interests to be collaborating with other operators within each country and across the continent.

Sources of Spam

There is a wide variety of spamming techniques ranging from botnets using infected computers, the exploitation of unsecured networks, spamming through social network platforms or exploiting open relays and proxies [19]. In this section we will provide some information on two specific spamming sources, which more or less relate to the function of a Regional Internet Registry.

Botnets and Zombies

It is believed that most of the spam today comes from botnets or infected computers connected to the Internet. Those could be either servers at the operator level but importantly, they are typically computers found in home networks. Examples of bonets are Bobax, Grum or Pushdo [3]. The fact that they are usually located within the ISP’s customer subnet, RIRs are usually used as an important source of information for abuse contact.

Direct spamming "419 scam"

One example of direct spamming is scam. Our region is well-known for the “419 Scam” also called the “Nigerian Scam”, where you receive an email saying that you won a lottery or you inherited a massive amount of money [4]. They usually request an up-front payment before releasing the sum. “419 Scams” not only use spoofed email addresses but make use of phising techniques to lure people to fake website that would collect credit card information or bank login details. 

Some IPs and scam formats:
82.128.1.75 - INTERLINK EXPRESS HAULAGE & STORAGE LLC (Andrew HALL, £500 82.128.1.87 - Great Fountain / ARITA WRIGHT 82.128.3.181 - UNIVERSAL SECURITY & FREIGHT UK / European Gaming Commission

For example, the IP address "82.128.1.75" was found to be sending scams from the following email addresses

Email Date/Time
2005-12-04 03:02:26 UTC This email address is being protected from spambots. You need JavaScript enabled to view it.
2005-12-04 03:02:26 UTC This email address is being protected from spambots. You need JavaScript enabled to view it.
2005-12-04 03:02:26 UTC This email address is being protected from spambots. You need JavaScript enabled to view it.
2005-12-04 03:02:26 UTC This email address is being protected from spambots. You need JavaScript enabled to view it.

To trace back the owner of this IP, a query is run against the WHOIS database of the issuing RIR.

inetnum: 82.128.0.0 - 82.128.31.255
netname: INET-MLTL
descr: Multi-Links Telecommunications Limited
country: NG
admin-c:DG26
tech-c: RIA27
status: ASSIGNED PA
mnt-by: MLTL-INT-MNT
remarks: data has been transferred from RIPE Whois Database
source: AFRINIC # Filtered
parent: 82.128.0.0 - 82.128.127.255

person: name removed
address: 231, Adeola Odeku Street Victoria Island Lagos, Nigeria
phone: +23417751039
e-mail: deep(at)multilinks.com

Furthermore, some ISPs are known to be lenient in the activities of its customers. Many customers therefore take advantage of ISPs being “spam friendly” to engage in this illicit activity. Usually those customers have obtained Provider-Independent space (ASSIGNED PI) from AFRINIC, which allows them to change from one ISP to another in case their spamming activities are unveiled.

However, AFRINIC has no means to determine in what type of activities a member is engaged into, as the type of contract between the ISP and its customer. There have been cases where email spammers will engage in a “pink contract” with their upstream provider, allowing them to host spam servers.

The example above shows the importance of having accurate data in the WHOIS database to allow traceability of information.

IP Address hijacking

IP space hijacking is not a new phenomenon and has been a recurring issue over the years. Spammers can hijack spaces that have not yet been allocated (still in IANA pool) or they can use free/reserved space from an RIR pool. Unallocated spaces not registered in an RIR database and being advertised in the global routing are referred as bogon space [5]. Some spam filters will use Bogons database to fight spam but it is not always very efficient. The problem is that sometimes mail headers legitimately contains Bogon IPs for example, in case internal mail servers use public IPs in a private fashion.

The history of the Internet is full of cases of IP hijacking, one very well known in the RIR community is the Pakistan Telecom-Youtube hijack [6]. Although the objective was not to do spamming but to rather blackhole traffic, the principle used was the same. The hijack was successful partly because of poor outbound BGP filtering but also because there were no hard security mechanisms deployed at a wide scale. Another aspect to consider is the fact that Internet routing is done “by rumour”, meaning that hijacked spaces can easily find their way on the global routing tables.

Combating spam through proper Internet Number Resources Management

Anti-spam techniques can broadly be classified in two categories which are either Content-based [16] or Reputation-based [17]. Examples of Content-based techniques are heuristic filtering, fingerprint based filtering or machine learning techniques. On the other hand, Reputation-based approaches would rather focus on parameters such as email origin, traffic flow and volume [18]. Depending on which side an email administrator is (End-user, sender or server side), different spam mitigation techniques apply. 

It is important to understand that as a registry, an RIR has the obligatory duty to maintain an up-to-date database of information. As per the ICP-2 document on the criteria for the establishment of new RIRs from ICANN, RIRs must keep proper records of all registry activities [7]. As such, AFRINIC does not specifically operate any anti-spam mechanism but maintains a set of frameworks (either technical or policy based) that can be used as mitigating factors. Those are for example the Abuse Contact Information policy [8], the Reverse DNS service and related policies, the Internet Routing Registry (IRR) [10] and the Resource Certification framework (RPKI) [11].

WHOIS Database

RIRs maintain a public database of Internet number allocation (ALLOCATED PA/ALLOCATED-BY-RIR) and end-user assignments (ASSIGNED-PI) and LIRs also need to declare their sub-allocation (SUB-ALLOCATED PA) and customer assignments (ASSIGNED-PA) in the WHOIS database. Besides Internet Numbers (inetnum, inet6num and aut-num), the WHOIS database holds many other data required for the operations of a network.

List of WHOIS objects

inetnum
inet6num
as-block
aut-num
as-set
domain
route
route6
route-set
inet-rtr
filter-set
peering-set
rtr-set
mntner
irt
keycert
organisation
role
person 

As such, each object in the WHOIS database has a contact information in the form of either a PERSON object, a notify email address, a maintainer object and if the object is tied to an organisation, the “org” attribute. Abuse contact information can also be inserted in the WHOIS objects, for example by using the “notify” or “remarks” attribute.

Example of an AS Number object

aut-num:
as-name:
descr:
admin-c:
tech-c:
org:
mnt-by:
mnt-lower:
mnt-routes:
mnt-irt:
source:

 

AS37708
AFRINIC-MAIN
AFRINIC MAIN AS
CA15-AFRINIC
IT7-AFRINIC
ORG-AFNC1-AFRINIC
AFRINIC-HM-MNT
AFRINIC-IT-MNT
AFRINIC-IT-MNT
IRT-AFRINIC-IT
AFRINIC

 


Before 2012, there were not a standard way to register an "abuse contact information". Some people used "notify", other used "remarks" while the rest were relying on the "email" attribute which was "optional". The community decided to come with a more efficient way to register abuse information with the "Abuse contact information" policy.

Registration of customer assignments (ASSIGNED PA)

Spam filters are built on information received from different sources such as Spamhaus [23]. Sometimes when a host or several hosts on a network are found to be spamming, the network gets blacklisted. The WHOIS database is used to retrieve information on those subnets, which are usually customer assignments (ASSIGNED PA). However, if an LIR fails to register its customer assignments in the RIR's WHOIS database, the only next information available would be the LIR network itself.

As a matter of best practice, it is therefore recommended for LIRs to register their end-user assignments, the reason being if a host in a non-registered subnet (for e.g a /28) is blocked because it is involved in spamming activities, the whole subnet of the parent (for e.g a /19) can be denied access.

AFRINIC therefore highly recommends its members to register their customer assignments as per this document. In 2014, there was a policy proposal through the AFRINIC Policy Development Process to make the registration of customer assignments mandatory [30]. Even though the policy was not implemented, it shows that the community must be made aware of the importance of properly registering LIR networks and customer IP assignments. However, LIRs sometimes refrain from providing information on customer assignments, even though the address spaces are in use, as a matter of privacy.

Abuse contact information Policy

AFRINIC has implemented an Abuse Contact Information policy in May 2012. The policy stipulates that there must be a dedicated object in the WHOIS database to cater for abuse contact information. As we have seen above, abuse contact information was usually put in the “remarks” field of different objects. 

Network owners increasingly operate dedicated abuse handling departments, distinct from the basic operations department. More and more network owners and other institutions are also starting to exchange data about abusive behavior with each other, to more quickly allow networks to identify internal abuse, external abuse, and other security problems. Earlier, the abuse reports were sent to e-mail address specified in the e-mail field. These addresses were used because the AFRINIC Whois Database currently did not have any specialised contact object for abuse departments. Instead, all abuse reports were sent to contacts that usually have broader responsibilities or different responsibilities.

If an IP address is found to be spamming, abuse reports are sent to e-mail address specified in the e-mail field of the inetnum object. AFRINIC therefore implemented a new object type called “irt” for Incidence Response Team. IRT objects provide information about a CSIRT (Computer Security Incident Response Team), which is basically a group of individuals responsible for handling network security incidents and reports for any given organization or entity.

IRT object template

 irt:  [mandatory]  [single] [primary/lookup key]
address: [mandatory]  [multiple] [ ]
phone: [optional]   [multiple] [ ]
fax-no: [optional]   [multiple] [ ]
e-mail: [mandatory]  [multiple] [lookup key]
abuse-mailbox: [mandatory]  [multiple] [inverse key]
signature: [optional]   [multiple] [ ]
encryption: [optional] [multiple] [ ]
org: [optional] [multiple]   [inverse key]
admin-c: [mandatory] [multiple]   [inverse key]
tech-c: [mandatory]  [multiple]   [inverse key]
auth: [mandatory]  [multiple]   [inverse key]
remarks: [optional]   [multiple]   [ ]
irt-nfy: [optional]   [multiple]   [inverse key]
notify: [optional]   [multiple]   [inverse key]
mnt-by: [mandatory]  [multiple]   [inverse key]
changed: [mandatory]  [multiple]   [ ]
source: [mandatory]  [single]     [ ]

 

The “irt” object is then referenced in by: inetnum (IPv4), inet6num (IPv6) and aut-num (AS number).

mnt-irt in an inetnum object 

inet6num: 2001:42d0::/32
netname: AfriNIC-ZA-Ops
descr: AfriNIC
descr: RIR
country: ZA
org: ORG-AFNC1-AFRINIC
admin-c: CA15-AFRINIC
tech-c: IT7-AFRINIC
tech-c: CA15-AFRINIC
status: ALLOCATED-BY-RIR
notify: This email address is being protected from spambots. You need JavaScript enabled to view it.
mnt-by: AFRINIC-HM-MNT
mnt-lower: AFRINIC-IT-MNT
mnt-domains: AFRINIC-IT-MNT
mnt-irt: IRT-AFRINIC-IT <===================
mnt-routes: AFRINIC-IT-MNT
changed: This email address is being protected from spambots. You need JavaScript enabled to view it. 20140915
source: AFRINIC
parent: 2001:4200::/23

  

The issue however, is that the "mnt-irt" is not mandatory. The policy does not force AFRINIC members to register an IRT object in their inetnum, inet6num and aut-num objects. The table below shows the number of IRT objects per object type in the WHOIS database (August 2015):
 Abuse contact information
(e.g. remarks: Please send abuse to This email address is being protected from spambots. You need JavaScript enabled to view it.
IRT object usage
(e.g. mnt-irt: IRT-AFRINIC-IT)
Object TypeTotal in database

Number of objects
with any abuse 
information

%
over total
in database
Number of objects
with mnt-irt attribute 

%
over total
in database 

inetnum 113111 12668 11.2 10 0.00
inet6num 1057 120 11.3 1 0.09
aut-num 1474 48 3.25 5 0.34
Total 115642 12836 11 16 0.01

Reverse DNS Service

AFRINIC manages reverse DNS for the IANA delegated zones which are the {196, 197, 154, 41, 102, 105}.in-addr.arpa for IPv4 and {0.c.2, 2.4.1.0.0.2, 3.4.1.0.0.2}.ip6.arpa for IPv6. For example, if a member was assigned a 196.1.5.0/24 network on which a mail server is running, the member needs to the delegation of the 5.1.196.in-addr.arpa zone from AFRINIC, who manages the parent 196.in-addr.arpa zone.

 

RFC2050 Section 5. IN-ADDR.ARPA Maintenance
The regional registries will be responsible for maintaining IN-ADDR.ARPA records only on the parent blocks of IP addresses issued directly to the ISPs or those CIDR blocks of less than /16.  Local IRs/ISPs with a prefix length of /16 or shorter will be responsible for maintaining all IN-ADDR.ARPA resource records for its customers. IN-ADDR.ARPA resource records for networks not associated with a
specific provider will continue to be maintained by the regional
registry.

 

Importance of PTR records

As a matter of best practice, even though RFC1033 and RFC1912 specify that "Every Internet-reachable host should have a name", rDNS has never become a protocol requirement for the operation of the DNS. Therefore, rDNS has always been considered as optional, explaining why not every host on the Internet today is mappable to a domain name. However, this technique is widely used by email servers to fight spam.

IP addresses assigned by AFRINIC are public IP address that will be used statically. Email operators that have used those static IPs need to properly configure the rDNS entries to make the match between the IP address and the domain name of the server. This also applies to home (dialup) users who are usually assigned dynamic IPs by their respective LIRs. Below are example of PTR records to "whois.afrinic.net".

 

Example of PTR records
20.2.216.196.in-addr.arpa domain name pointer whois.afrinic.net.
0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.2.0.0.0.0.0.0.d.2.4.1.0.0.2.ip6.arpa domain name pointer whois.afrinic.net.

 

rDNS check by mail servers

Reverse DNS (rDNS) is a mechanism used by mail servers to make the connection back the sender’s PTR record if it has one. When an email server sends an email to another server, the receiver will check whether the IP of the domain name in the SMTP Banner has a corresponding PTR record. The receiving server will use this IP to check that the sender has a reverse DNS entry [12].

The downfall is that is that not all email service administrators will configure rDNS for their server. Legitimate emails coming from those servers might get rejected if the receiver has activated rDNS check [13].

DNSSEC

In 2012, AFRINIC deployed DNSSEC [26] to sign the reverse zones it is managing, making the Reverse DNS service more secure against DNS-based vulnerabilities [14]. It allows the community to validate authoritative DNS data from AFRINIC's RDNS zones and members to publish DS records to build the chain of trust for their RDNS zones.

No reverse unless assigned policy

In 2014, AFRINIC implemented the "No Reverse Unless Assigned" policy [9] which requires members wishing to get delegation of their reverse zones from AFRINIC, to register at least one assignment. This is to encourage resource holders (ALLOCATED PA/ALLOCATED-BY-RIR) to register the subnets assigned to their customers (ASSIGNED PA).

Lame delegations

Even though members are registering their reverse DNS at AFRINIC, there are cases where the RDNS entries are "lame". A delegation is considered lame when the name server gives a non-authoritative answer for the zone or does not respond at all. Lame delegations can potentially have an impact on reverse DNS lookups of email servers receiving legitimate emails. The issue is that members do not maintain their reverse DNS entries in the WHOIS database. Information is therefore wrong from the source itself.

Resource Certification against Route Hijacking

Route hijacking is a complex issue that has been the headache of network operators for a long time. As mentioned earlier, routing on the Internet today is based on trust and mutual relationships between BGP peers. So far there has not been any largely accepted mechanism that uses hard security priniciples like digital signatures in order to make routing on the Internet more robust. RPKI (Resource Public key Infrastructure), together with BGPSEC [27] (still under development), are the frameworks being currently investigated as a global solution to secure the Internet Routing.

Internet Routing Registries (IRR) can also be used to mitigate the risk of route hijacking, though not really considered as a sustanaible solution. There are around 30 Routing registeries in the world [28], some of them operated by RIRs, others by private entitites. Network operators can publish their routing policies online allowing other BGP speakers to create filters based on those policies. Currently, there is no way to validate the information on IRRs making the system a bit brittle. That is why, eye balls are currently on the RPKI framework as the next big step in routing security.

Resource Certification [11] is a security framework with makes use of a Public Key Infrastructure to certify resources that have been assigned to a member, through the delivery of a Resource Certificate. It adds a verifiable form of resource holdership. A Resource Certificate is based on the X.509 certificate format (RFC 5280), extended by RFC3779 to include Internet number resources (IPv4, IPv6 and AS number).

 

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm:
sha256WithRSAEncryption     
Issuer: CN=AFRINIC/serialNumber=90A020F44F15B89D6FB15B5060D21067E43C0C0B
Validity Not Before: May 15 06:59:27 2015GMT
Not After : Mar 31 00:00:00 2016GMT
Subject: CN=F365CA10AF/serialNumber=B883D77155F7D67BA69663FE59AB8FCE04300394
sbgp-ipAddrBlock:critical
IPv4: 196.1.0.0/24
IPv6: 2001:43f8:92::/48

 

With a Resource Certificate, network operators can create crytographic objects called Route Origin Authorization (ROA), which are signed by the certificate to bind a prefix to an Origin AS. ROAs become therefore the mechanism “par excellence” to prevent route hijacking as only prefix owners can verifiably say which AS is allowed to advertise its network.

 

Example of a ROA
version: 0
    as_id: 37301
    prefixes:146.64.10.0/24-24
signing certificate:
serial: 7 (0x7)
not before: 2015-06-11T08:42:09
not after: 2015-06-26T08:42:09
subject: CN=557949f1-a786
ski: 2e4427450ad7ecf6ad6b3b257a29b6547adb79c2
g_ski: LkQnRQrX7Patazsleim2VHrbecI
sia:
signedObject:rsync://rpki.afrinic.net/repository/member_repository/F3634D22/24294C20FADD11E49BBA825D3BB695CA/CA8EB9AE101511E5B100220DD949923A.roa
issuer: CN=F3634D22AR, SN=FAFEBCF83FC94DF547DDAE1DF56495BDBCD2C192
aki: fafebcf83fc94df547ddae1df56495bdbcd2c192
g_aki:    -v68-D_JTfVH3a4d9WSVvbzSwZI
aia: caIssuers: rsync://rpki.afrinic.net/repository/afrinic/-v68-D_JTfVH3a4d9WSVvbzSwZI.cer

Relying party BGP speakers which are RPKI enabled, will create filters based on data received from RPKI Cache validator [15]. Then the router will tag every route announcement in its RIB as either validunknown or invalid. An announcement is:

  • Valid when it is covered by at least one ROA. (i.e AS in ROA matches Originating AS and prefix in ROA covers prefix announced)
  • Unknown when no covering ROA has been found for the announcement.
  • Invalid when a ROA covers the prefix announcement but the Originating AS does not match AS in ROA.

Below are some statistics about RPKI at AFRINIC as at August 2015:

Total number of
advertised prefixes 
Valid
Invalid
Unknown
RPKI Adoption Rate

AFRINIC
Members 

RPKI-Enabled
Members 
13203 (100%) 160 (1.21%) 36 (0.27%) 13007 (98.52%) 1.48% 1245 38 (3%)

The more our members will enroll for RPKI and cover their announcements with ROAs, the less easy it will be for spammers to advertise space not belonging to them.

Some statistics from Spamhaus

Spamhaus [29] maintains an "Extented/Don't Route Or Peer Lists" aka EDROP and DROP lists [23]. Those lists are advisory list of "hijacked networks" and being used by spammers or other cyber criminal to do illicit operations. These lists are mainly used by firewalls and routing equipments to drop traffic.

We used to EDROP list [24] to extract the number of subnets (/24) that are from AFRINIC region.

RIR
# of subnets
in EDROP 
list (/24)
%

Referenced
IRT objects

Subnets (/24)
Covered 
by ROA
AFRINIC 94 3.5 0 None
APNIC 2486 92.5 - None
ARIN 14 0.5 - None
LACNIC 3 0.1 - 1
RIPE 100 3.7 - 2
Total 2697      

The table above shows that 3.5% of hijacked space in the EDROP list is from AFRINIC. None of the space tagged as "hijacked" by Spamhaus have an IRT object referenced and none are covered by ROAs.

Conclusion

This paper gave an overview of the how AFRINIC, as an RIR, contributes to the fight against spam. As mentioned, spam is a multidimensional problem that cannot be tackled from one perspective only. The policy measures and technical frameworks made available to the Internet community are only part of a global endeavour to combat spam. Many international institutions are also involved in this battle like the Internet Engineering Task Force (IETF) [20], the International Telecommunication Union (ITU) [21] and the Internet Society (ISOC) [22].

ISPs and Network service providers need to correctly document their networks and publish their information in the WHOIS Database. AFRINIC members must be made aware of the purpose of the data that is stored in the whois database and the importance of its accuracy. Often when large blocks of IPs are blacklisted this is as a result of a failure to resolve the network abuse with the designated owner of the IP block. Network operators need to be made aware of their responsibilities for managing abuse of their networks by spammers (and other abusers). The consequences of failing to manage abuse of their networks can include blacklisting of their and others networks and they should take responsibility for when they negatively affect users. 

Apart from policy measures, AFRINIC maintains and manages different technical frameworks which are the Reverse DNS service, the Internet Routing Registry (IRR) and the Resource Certification (RPKI) system. While those frameworks should not be considered as the "ultimate anti-spam solutions", they must be viewed as migitating measures. Altogether, those frameworks help build a more robust Internet infrastructure and therefore contributed to reduce the attack surface of spammers.

The statistics available on usage shows that the systems in place at AFRINIC, are mostly under-utilised. Much effort has to be gathered to encourage members register their end-user assignments and create the corresponding IRT objects, keep their objects up-to-date, register and sign their reverse DNS and to prevent prefix hijacking, start making use of the AFRINIC IRR and RPKI system.

Glossary

ALLOCATED PA (IPv4)

ALLOCATED-BY RIR (IPv6)

Resources allocated to an LIR, which can be re-assigned (ASSIGNED PA) to end customers.
PA stands for Provider-Aggregatable 
SUB-ALLOCATED PA LIRs sometimes need to distribute part of their network to downstream providers. This allows the downstream
customers to make the sub-allocation, without having the parent (LIR) to intervene. 
ASSIGNED PI Resources allocated to End-users and who can choose their upstream providers. PI stands for Provider Independent
ASSIGNED PA Resources allocated to customers from LIR pool. Customers' upstream is the LIR itself.

References

[1] http://www.symantec.com/content/en/us/enterprise/other_resources/b-state_of_spam_and_phishing_report_09-2010.en-us.pdf

© 2017 AFRINIC. All Rights Reserved. Designed By AFRINIC