A quick glance at longer than /24 IPv4 prefixes

Distribution of probes which reached the /25 prefix with registered route object

Yesterday RIPE Labs announced a new test to measure propagation of longer than /24 IPv4 prefixes. The scope of these prefixes is to allow small allocations from the 23.128/10 net block that ARIN reserved to facilitate IPv6 deployment, but it could be impaired by filters and routing policies commonly deployed all around the net.

While looking forward to the RIPE results I couldn’t help glancing at the current situation as seen by a bunch of RIPE Atlas probes, so I performed some small tests on my own.

Measurements

The measurements I created are based on 500 random probes from the world wide area and have been used to ping the IP addresses announced by RIPE RIS (AS12654); these IP addresses are split in 2 main groups: one group has 3 addresses each one from a prefix (/24, /25 and /28) with a registered route object, the other group has similar addresses but from prefixes without a registered route object.

Prefix            Pingable IP	 Route object?	My Atlas measurement ID
23.128.24.0/24	  23.128.24.1    yes            1767799
23.128.25.0/25	  23.128.25.1    yes            1767800
23.128.25.240/28  23.128.25.241  yes            1767801
23.128.124.0/24   23.128.124.1   no             1767802
23.128.125.0/25   23.128.125.1   no             1767803
23.128.125.240/28 23.128.125.241 no             1767804

All measurements use the same set of probes, taken from the first measurement (the /24 prefix with registered route object).

Of course, mine is only a partial view (500 probes) taken from a bigger partial view (all the RIPE Atlas probes) of the global Internet; please take my results with regard of this.

Results

Data collected by RIPE Atlas have been parsed with a small python script that I used to match the results. It uses the RIPE Atlas Sagan library.

Reachability

From the first 3 measurements, 497 probes received at least one response from the /24 prefix with the registered route object; of those, only 57 received responses from the /25 prefix and 41 from the /28 prefix too.

Also 497 probes received responses from the /24 prefix without the registered route object; of those, 52 received responses from the /25 prefix and 38 from the /28 prefix too.

Longer than 24 prefixes reachability

Performances

For those probes which reach the /25 and the /28 prefix the average RTT seems to be pretty stable regardless of the prefix size.

Longer than 24 prefixes with route object  RTT avg

Longer than 24 prefixes without route object  RTT avg

Probes distribution

Here it is:

Distribution of probes which reached the /25 prefix with registered route object

Distribution of probes which reached the /25 prefix with registered route object – Click to enlarge

More and deeper tests may be useful to reveal AS paths and peering/transit relationships impacts on these measurements; maybe I’ll blog another post as soon as possible, or – better yet – maybe RIPE Labs folks will write about them in their results.

Conclusions

As far as I can see from the measurements I run (based on a small sample of probes), reachability of smaller than /24 prefixes is almost unaffected by the presence of registered route objects; who receives the registered net also receives the unregistered one. From the performances point of view, when the smaller prefixes are reached, RTTs are not better nor worse than /24 prefixes.

The real question is: what’s the portion of Internet that right now succeed to reach these prefixes?

I guess that some efforts will be needed in order to have ISPs to review their routing policies and accept the new small prefixes from the reserved pool.

References

RIPE Labs, Propagation of Longer-than-/24 IPv4 Prefixes – https://labs.ripe.net/Members/emileaben/propagation-of-longer-than-24-ipv4-prefixes

ARIN, Policy Proposal 2008-5 – Dedicated IPv4 block to facilitate IPv6 deployment- https://www.arin.net/policy/proposals/2008_5.html

ARIN, Number Resource Policy Manual (NRPM), adoption of Dedicated IPv4 block to facilitate IPv6 Deployment – https://www.arin.net/policy/nrpm.html#four10

ARIN, announcement of 23.128.0.0/10 reservation – https://www.arin.net/announcements/2014/20140130.html

RIPE Atlas: a script to show ASes traversed in traceroute

I released a small Python script which reads results from RIPE Atlas traceroute measurements and shows Autonomous Systems traversed by probes to reach the target: ripeatlastracepath.

It uses a library that I wrote to cache RIPEstat results about IP addresses details (ASN, prefix, …), in order to improve performance and to avoid a flood of requests: ipdetailscache.

More details can be found on my GitHub profile page.

A demo can be found here. It can’t be used to process other measurements, it only shows results from measurement ID 1674977, a traceroute from 50 probes all over the world toward www.ripe.net. You can drag&drop ASes to build the layout that best describes your scenario and, once done, you can “save” the graph for later usage. In this demo the “Load graph” button gives a preset of JSON data representing the example graph below:

Graph of traceroute to www.ripe.net

These scripts are not so elegant, but do the job! ;) They are on GitHub.com, feel free to use/edit/fork/improve them as you whish!

Avoid Cisco FIB/TCAM exhaustion on full BGP table feed

The number of IPv4 prefixes in the global BGP table is approaching the limit of many Cisco products, such as 7600/6500 RSP720/Sup720 and some ASR1000, which may hold a maximum of ~500K routes in their FIB (the Forwarding Information Base, where only best paths are stored).

These routers can usually handle a bigger load of prefixes, they can also be used to receive the full BGP table from many upstream providers concurrently, but they can’t manage more than 500/512K entries in their RIB or FIB.

Routing protocols to FIB

On 6500/7600 platforms, the default PFC3BXL/PFC3CXL TCAM configuration provides 512K entries for IPv4 and 256K for IPv6; the show mls cef maximum-routes command allows to show the running TCAM layout, that can be changed by entering mls cef maximum-routes ip … (it requires a reload).

7600(config)#mls cef maximum-routes ip 768
Maximum routes set to 786432. Configuration will be effective on reboot.

7600#show mls cef maximum-routes
FIB TCAM maximum routes :
=======================
Current :-
-------
 IPv4 + MPLS         - 512k (default)
 IPv6 + IP Multicast - 256k (default)

User configured :-
---------------
 IPv4                - 768k
 MPLS                - 16k (default)
 IPv6 + IP Multicast - 120k (default)

Upon reboot :-
-----------
 IPv4 + MPLS         - 512k (default)
 IPv6 + IP Multicast - 256k (default)

While this method allows to patch the immediate requirement for more IPv4 FIB space, it has the side effect of reducing the IPv6 resources, which are supposed to be more and more needed in the future.

Some ASR1000 platforms support up to 500K IPv4 routes and, as far as I know, they don’t allow RIB/FIB repartition.

In some scenarios, in order to continue using these routers while avoiding performance impairments, the BGP – Selective Route Download feature may help.

Routing protocols - table-map - FIB

The BGP—Selective Route Download feature allows a network administrator to selectively download some or none of the BGP routes into the Routing Information Base (RIB). (Cisco.com)

Sample scenario

Suppose to have a border router which receives 3 BGP feeds: some prefixes from a multihomed customer, some from an Internet exchange and the full table from a transit provider. This border router is also connected to a core router, where other border routers and the rest of the network is connected too. Configuring the table-map … filter option on the border router allows to prevent its FIB to be loaded with a lot of useless prefixes, which may be summarized with a default route toward the transit provider.

BGP prefixes filtering with table-map

Filtering may be based on many parameters; the one I used here is the next-hop address of each learned prefix. The final configuration looks like this:

router bgp xxx
 address-family ipv4
  table-map BGP-Table-IPv4 filter
!
route-map BGP-Table-IPv4 permit 10
 match ip next-hop BGP-NextHop-OK
route-map BGP-Table-IPv4 deny 10000
!
ip access-list standard BGP-NextHop-OK
 deny Transit_Provider_IP
 permit any

In order to minimize the changes to the standard configuration, an access-list is created which only denies the transit provider’s next-hop address.
Preferred prefixes learned from the Internet exchange and from the multihomed customer are permitted (not denied) by the access-list and, consequently, by the BGP-Table-IPv4 route-map referenced in the table-map command. Other prefixes are denied by the route-map and prevented from entering into the FIB, but they are anyway kept in the BGP database and announced toward the core router. Local-pref and other features may be configured on the routers to implement usual routing policies. Of course, in this example the core router must have a big enough FIB to handle the full BGP!

Please note that before configuring this feature, specific considerations are needed about local routing policies and traffic engineering mechanisms; special attention should be paid to locally generated prefixes announced to the border router by the rest of the network. As always, do it at your risk!

References

CIDR Report: Summary of total route table size for the past 7 days

Cisco.com: Cisco 7600 Series Route Switch Processor 720 Data Sheet

Cisco.com: Cisco ASR 1000 Series Embedded Services Processors Data Sheet

Cisco.com: BGP – Selective Route Download

RIPE68: Content blocking methods and their impacts

Today, in Warsaw, during the RIPE68 morning session reserved for the Cooperation Working Group, Olaf Kolkman kindly presented my work about Content blocking methods and their impacts.

Olaf’s presentation was the first in a series of 3, all about censorship and censorship circumvention.

Content Blocking Methods And Their Impacts

My work was born within a discussion on the RIPE Co-op Working Group mailing-list with the goal of depicting the impact of various content blocking mechanisms, in order to reach a final guide for policy makers and legislators called to solve social issues by using web filtering methods.

Unfurtunately, the time slot allocated to Olaf’s presentation was too small to allow him to give a full overview of impacts, side effects and hidden costs related to content blocking methods. More details can be found on the online resources:

– on the RIPE68 Cooperation Working Group Agenda you can find the slides and the video of the presentation;

– here on my blog I’m hosting the first version of the document A Technical Overview of Content Blocking Methods;

Download

– on the IETF website you can find the other document that Olaf talked about in his presentation, Technical Considerations for Internet Service Blocking and Filtering by IAB.

Verifying DKIM signatures on Thunderbird with DNSSEC

I’m happy to see that more and more tools are developed to increase the security level and trustworthiness of Internet applications. I already talked about DNSSEC and tools to check the validity of domain names, many others blogged about DANE and TLSA validation support in browsers; this time I would like to focus on DKIM and on a Thunderbird add-on to verify its signatures taking advantage of DNSSEC end-to-end validation.

DNSSEC+DKIM

DKIM

DKIM is a mechanism to build and verify a trust relationship between an email message and a domain name (usually the sender’s one). When an email message is sent, the sending mail server cryptographically signs its contents using the private part of an asymmetric key and adds a reference back to the public part of the key, that is published under the DNS zone of the sending domain.
Since message recipients base the validation on public keys published via DNS records, it’s important to be sure that data obtained through DNS queries is valid; here DNSSEC takes to the field.

Validation may occur both in the email server which holds the recipient’s mailbox or in the email client running on a user’s device: in the first case a local policy (or a DMARC policy, but this is off-topic for this post) defines what to do with the message (drop it, mark it as spam, …); in the second case the user’s client can show a warning if signature validation fails or a confirmation message if everything is fine. Here I’ll cover the second case.

Thunderbird DKIM Verifier add-on

I came across DKIM Verifier, an interesting add-on for Mozilla Thunderbird that checks DKIM signatures on the client-side and which supports a DNSSEC backend to ensure end-to-end DNS security. I tested the Windows version with good results.

The add-on can be configured to fetch DKIM DNS keys using two methods: a JavaScript DNS library, limited to simple TCP queries, or libunbound, a validating recursive DNSSEC library. To use the second method, the only one that gurantees end-to-end DNSSEC validation of DKIM keys, another add-on must be installed: DNSSEC Validator. At time of writing, only the 2.0.1 version includes libunbound, while the official one (1.1.5) does not.

Installation

Installation is built on two-steps: installing DNSSEC Validator (required to use libunbound) and then installing DKIM Verifier. Do it at your own risk.

After downloading the DNSSEC Validator 2.0.1 version, I installed it following the “Installing add-ons downloaded from outside Thunderbird” guide. As stated in the DKIM Verifier DNS Wiki page “the DNSSEC Validator add-on must only be installed, not enabled for this to work”, so I disabled it from the Thunderbird Tools / Add-ons interface.

Then I installed the DKIM Verifier from within Thunderbird, via the Tools / Add-ons interface.

Configuration

Since security and reliability of this solution rely on DNSSEC, we should verify that the trust anchor used by libunbound corresponds to the one used in the root zone: from the Thunderbird Config Editor search for the extensions.dkim_verifier.dns.dnssec.trustAnchor parameter and check that its value matches the one published at the root zone.

DKIM Verifier trustAnchor parameter (click to enlarge)

DKIM Verifier trustAnchor parameter (click to enlarge)

Then, from the Thunderbird Tools / Add-ons interface, open the DKIM Verifier options window and, in the DNS tab, select the libunbound option from the Resolver list. “Then set the path to libunbound to extensions/dnssec@nic.cz/plugins/ub_ds_windows-x86.dll and enable Path relative to profile directory” (more details on the DKIM Verifier DNS Wiki page). Many other settings are available in the options window, take a look at them to fully customise your configuration.

Finally, restart Thunderbird to ensure that new settings will be loaded.

Testing

Now, when you open a message that is signed using a DKIM header, Thunderbird will verify its signature and will show the results:

DKIM signed test message in Thunderbird with DKIM Verifier add-on

The add-on detects that the message is signed with a DKIM header, parses it and extracts the signing domain (d=nic.cz) and the selector (s=default):

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default;

Then, it uses libunbound to acquire the public DKIM key via DNS, sending a query of type TXT to selector._domainkey.domain (you can do it manually with dig default._domainkey.nic.cz TXT on a Linux shell or nslookup -querytype=TXT default._domainkey.nic.cz on Windows prompt).

This is what happens behind the scenes, as seen from Wireshark…

DKIM key validated using DNSSEC as seen by Wireshark

… and from the Thunderbird error console (Tools / Error console):

libunbound debug while verifying DKIM public key - from Thunderbird error console

The libunbound library takes care of DNS data lookup and possible DNSSEC end-to-end validation, from the root zone down to the domain level.
Of course, in order to have the “secure: true” output you must not only receive a message that is signed with DKIM headers, but it must be under a DNSSEC-secured domain also. In the example I used a message from the CZ domain registry, whose domain (nic.cz) is protected by DNSSEC. For example GMail, at time of writing, signs outgoing messages with DKIM but its domain is not protected by DNSSEC. The DKIM Verifier Options window, in the Advanced tab, offers some options on how to treat keys which are not signed by DNSSEC.

Please note that libunbound uses cache mechanisms to reduce network traffic: validations following the first one may not require DNS queries toward root zone or TLD if DNSSEC information have already been received.

More…

– DKIM official home-page: http://www.dkim.org/

– DKIM on WikiPedia: http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

– DKIM Verifier Thunderbird add-on on GitHub: https://github.com/lieser/dkim_verifier

– Unbound: http://www.unbound.net/