Services

About RPKI

What is RPKI?

Resource Public Key Infrastructure (RPKI) is a public key infrastructure framework designed to secure the Internet’s routing infrastructure, specifically the Border Gateway Protocol. RPKI provides a way to connect Internet number resource information (such as IP Addresses) to a trust anchor. Using RPKI, legitimate holders of number resources are able to control the operation of Internet routing protocols to prevent route hijacking and other attacks. More information.

Why do we need RPKI?

Routing protocols are potentially at risk of attacks that can harm individual users or network operations as a whole. RPKI was specified by the IETF to provide a secure means to certify the allocation of Internet number resources, as a step towards securing routing. The Internet Architecture Board considers a “properly designed and deployed RPKI an absolute prerequisite to having a secure global routing system, which is in turn a prerequisite to having a reliable worldwide Internet.”

What is ROA?

A ROA or Route Origin Authorization is an attestation of a BGP route announcement. It attests that the origin AS number is authorized to announce the prefix(es). The attestation can be verified cryptographically using RPKI.

How does SGIX validate IRR and RPKI?

Any routes that the peer announces will be RPKI validated and checked against Internet Routing Registry (IRR) data. The AS-SET that peer provides to us will be recursively resolved. Then filtering is executed as follows:

The origin ASN needs to be in the AS-SET that is well maintained and all downstream ASNs are included.
Is the route a blackhole?

if yes, the route undergoes loose RPKI validation filtering (origin only):

If the result is RPKI Valid, the route is accepted.
if the result is RPKI Invalid, the route is rejected.
If the result is RPKI NotFound/Unknown, router server checks if the route is resolvable for its origin ASN (check if a proper route object exists) and it might get accepted or rejected.

if no, the route undergoes strict RPKI validation filtering (origin and maxLength):

If the result is RPKI Valid, the route is accepted.
if the result is RPKI Invalid, the route is rejected.
If the result is RPKI NotFound/Unknown, router server checks if the route is resolvable for its origin ASN (check if a proper route object exists) and it might get accepted or rejected.

PEERING SERVICES

Members can connect to SGIX using one or more physical connections and reach many other peers on the peering fabric, thus optimizing the cost per peer when exchanging traffic between different networks. Port size available are 1G, 10G and 100G for traffic exchange. Subject to resource availability and operations approval, members may request for up to 2 IP addresses per ASN if connecting from 2 different locations and with both ports at 10G and above.

PEERING POLICY

Members can implement OPEN or SELECTIVE peering policy or a combination of both where different sets of prefixes are announced to OPEN and SELECTIVE peering group.

SELECTIVE Peering Policy
Also known as Bi-Lateral Peering (BLP) policy where member negotiate with other members in the Exchange to setup direct BGP peering according to their own requirements.

OPEN Peering Policy
Also known as Multi-Lateral Peering (MLP) policy. Instead of negotiating with individual member in the Exchange for direct BGP peering, member can setup a single BGP session with SGIX Route-Servers (RS1 & RS2) to announce and received prefixes from all other members with similar peering policy. Member can control their prefixes announcement to other members by tagging them with SGIX BGP communities. By default, SGIX Route-Servers will advertise your prefixes to all peers.

ROUTE SERVERS (RS)

SGIX operates two Route Servers (RS) in Singapore and filter based on AS-path and IP prefixes. BGP announcements that a route server receives from a peer are checked against the AS-SET the peer has provided and be RPKI validated.

Once peered with the RS, there is no need to maintain multiple BGP sessions with other members in the IX. RS provide AS-path, MED, Communities and Next-hop transparency so that peering at SGIX still appear to be directly connected. As a result, members traffic are exchanged directly within SGIX switching fabric without passing through RS.

Please note the following when peering with RS

Remove any private ASN in the prefix announcement.
Remove any IP v4v6 default route in the prefix announcement.
Prefixes stated in RFC 1918, RFC 2544, RFC 3927, RFC 5735, RFC 5737, RFC 6598 and RFC 6980 are not allowed.
Bogon ASNs in the AS-path are not allowed.
Disable check on first-ASN. This may be applicable to Huawei (“undo check-first-as”) and Cisco equipment (“no bgp enforce-first-as”).
The default BGP v4v6 max-prefix threshold is set to 100 but member can request for a different value during provisioning.

Conditions

Members are advised to peer with both RS for redundancy.
Members can choose to establish or maintain bi-lateral peering arrangement with other members.
Members agree not to hold SGIX responsible for any impact on traffic flow due to policies request configured at RS by other members.

BGP Announcement Filtering
Besides the well-known community like NO_EXPORT and NO_ADVERTISE, members can control their prefixes announcement to other members by tagging them with BGP standard community or large community. By default, RS will advertised all prefixes to all peers.

The following table shows BGP standard and large communities in top-down evaluation order. These communities are processed by RS and not propagated to any peers.

Standard Community	Descriptions
0:55518	Block announcement of prefixes to all ASN
0:$ASN	Block announcement of prefixes to this ASN only
55518:$ASN	Announce prefixes to this ASN only

Large Community	Descriptions
55518:0:0	Block announcement of prefixes to all ASN
55518:0:$ASN*	Block announcement of prefixes to this ASN only
55518:1:$ASN*	Announce prefixes to this ASN only

*For members having 4-byte ASN, you have to use for the BGP Large Communities.

AS PATH Prepending

The following table contains information about how to prepend your own ASN up to three times selectively to a certain ASN peer.

Standard Community	Descriptions
65001:$ASN	Prepend once to this ASN only
65002:$ASN	Prepend twice to this ASN only
65003:$ASN	Prepend thrice to this ASN only

Large Community	Descriptions
55518:101:$ASN*	Prepend once to this ASN only
55518:102:$ASN*	Prepend twice to this ASN only
55518:103:$ASN*	Prepend thrice to this ASN only

*For members having 4-byte ASN, you have to use for the BGP Large Communities.

Connecting using a Routed Port

Connecting to SGIX using a routed port is the preferred design and below is the recommended port configuration (Cisco IOS). Member need to adapt this configuration to their respective platform when connecting to SGIX fabric.

GigabitEthernet X/X/X
  description Facing SGIX Port
  ip address <your_allocated_ipv4_address>
  ipv6 address <your_allocated_ipv6_address> 
  no cdp enable
  no mop enable
  no ip mask-reply
  no ip proxy-arp
  no ip redirects
  no ip directed-broadcast
  no ip unreachables
  no keepalive
  no lldp transmit
  no lldp receive
  no udld enable
  ipv6 nd ra suppress all
  ipv6 nd prefix default no-advertise

Connecting via an Intermediate Switch

The intermediate switch connecting both the customer router and SGIX MUST have a dedicated vlan with no other additional devices in that vlan. SGIX only allow two MAC addresses per port. Below is the recommended switch port configuration facing SGIX. If bpdufilter feature is not available in your platform, we recommend that member disable spanning-tree on the dedicated vlan.

vlan XXX
  name SGIX

GigabitEthernet X/X/X
  description Facing SGIX Port
  switchport mode access
  switchport access vlan XXX
  switchport nonegotiate
  spanning-tree bpdufilter enable
  no keepalive
  no cdp enable
  no lldp receive
  no lldp transmit
  no udld enable

About Blackholing Service

To mitigate DDoS attack, SGIX provide a blackhole next-hop address for both IPv4 and IPv6 address-families. These next-hop addresses will resolves (via ARP/ND) to a predefined blackhole MAC address (de:ad:be:ef:66:66), which will be dropped by our switch port ingress filter where members are directly connected and thereby preventing DDoS traffic from reaching its destination. SGIX blackholing (BH) service is available on our Route Servers (RS) and members are encouraged to participate.

Below table contain SGIX blackhole next-hop address and BGP BLACKHOLE community information.

IPv4 Address	103.16.102.6
IPv6 Global Address	2001:DE8:12:100::6
IPv6 Link-Local Address	FE80::DEAD:BEEF:6666:6666
MAC Address	de:ad:be:ef:66:66
BLACKHOLE Community (RFC7999)	65535:666

Blackholing via Route Server (RS)

Below are guideline and restrictions when using blackholing service via RS:

To participate in SGIX blackholing service, members MUST allow IP v4v6 prefixes marked with BLACKHOLE community (65535:666) through their inbound filter. This blackholing inbound filter should be place above any existing inbound policies that you have to ensure it will not be bypass.

# Create BLACKHOLE community (RFC7999)
ip community-list standard BLACKHOLE-COMM permit 65535:666

# IPv4 Inbound policy snippet
route-map SGIX-IPv4-IN permit 10  # create new blackhole policy
  match community BLACKHOLE-COMM  # match BLACKHOLE community
route-map SGIX-IPv4-IN permit 20  # existing inbound policy
  <existing inbound policies>     # existing match statement

# IPv6 Inbound policy snippet
route-map SGIX-IPv6-IN permit 10  # create new blackhole policy
  match community BLACKHOLE-COMM  # match BLACKHOLE community
route-map SGIX-IPv6-IN permit 20  # existing inbound policy
  <existing inbound policies>     # existing match statement

# BGP Inbound Policy snippet
router bgp <your_ASN>
....
  address-family ipv4
    neighbor 103.16.102.12 route-map SGIX-IPv4-IN in  # RS1 IPv4 inbound policies
    neighbor 103.16.102.13 route-map SGIX-IPv4-IN in  # RS2 IPv4 inbound policies
  exit-address-family
....
  address-family ipv6
    neighbor 2001:DE8:12:100::12 route-map SGIX-IPv6-IN in  # RS1 IPv6 inbound policies
    neighbor 2001:DE8:12:100::13 route-map SGIX-IPv6-IN in  # RS2 IPv6 inbound policies
  exit-address-family

To ensure member’s inbound filter are configured correctly, SGIX provide a permanent test IP v4v6 blackhole prefixes. Member will need to verify they can receive this test prefix with correct next-hop address and BGP communities in their routing table.

Test IP v4v6 Blackhole Prefix	next-hop address	BGP Communities
202.3.78.3/32	103.16.102.6	65535:666 no-export
2001:df0:214::3/128	2001:DE8:12:100::6 (Global) FE80::DEAD:BEEF:6666:6666 (Link-Local)	65535:666 no-export

To signal an IP prefix for blackholing, marked the prefix with BLACKHOLE community (65535:666) before advertising to RS. RS will automatically rewrite this prefix’s next-hop address to SGIX blackhole next-hop address and append the NO_EXPORT community before announcing to the rest of RS clients.

# Create IP v4v6 static route for victim address
ip route X.X.X.X 255.255.255.255 <IPv4-next-hop-to-victim-address>
ipv6 route Y:Y:Y:Y::Y/128 <IPv6-next-hop-to-victim-address>

# Create IP v4v6 blackhole prefix-list for matching later
ip prefix-list RTBH-IPv4-LIST seq 5 permit X.X.X.X/32
ipv6 prefix-list RTBH-IPv6-LIST seq 5 permit Y:Y:Y:Y::Y/128

# IPv4 outbound policy snippet
route-map SGIX-IPv4-OUT permit 10              # create new blackhole policy
  match ip address prefix-list RTBH-IPv4-LIST  # match blackhole prefix-list
  set community 65535:666                      # set BLACKHOLE community
route-map SGIX-IPv4-OUT permit 20              # existing outbound policy
  <existing outbound policies>                 # existing match statement

# IPv6 outbound policy snippet
route-map SGIX-IPv6-OUT permit 10                # create new blackhole policy
  match ipv6 address prefix-list RTBH-IPv6-LIST  # match blackhole prefix-list
  set community 65535:666                        # set BLACKHOLE community
route-map SGIX-IPv6-OUT permit 20                # existing outbound policy
  <existing outbound policies>                   # existing match statement

# BGP configuration snippet
router bgp <your_ASN>
  address-family ipv4
    network X.X.X.X mask 255.255.255.255                # Advertise IPv4 blackhole prefix
    neighbor 103.16.102.12 route-map SGIX-IPv4-OUT out  # RS1 IPv4 outbound policy
    neighbor 103.16.102.13 route-map SGIX-IPv4-OUT out  # RS2 IPv4 outbound policy
  exit-address-family

  address-family ipv6
    network Y:Y:Y:Y::Y/128                                    # Advertise IPv6 blackhole prefix
    neighbor 2001:DE8:12:100::12 route-map SGIX-IPv6-OUT out  # RS1 IPv6 outbound policy
    neighbor 2001:DE8:12:100::13 route-map SGIX-IPv6-OUT out  # RS2 IPv6 outbound policy
  exit-address-family

Members MUST enable send-community for both BGP v4v6 address-family.
RS only allowed blackhole IP prefixes from below size:

/24 =< IPv4 prefix length =< /32
/64 =< IPv6 prefix length =< /128

Members can only advertise blackhole IP prefixes from their own address space.
Blackhole IP prefixes should not be advertise outside their local AS.
The maximum number of blackhole IP prefixes that can be advertised is limited by:

(blackhole + standard prefix) < max-prefix

Members can target blackhole IP prefixes to specific ASN by combining it with SGIX standard community and large community filtering (the default is announced to all ASN).

Standard Community	Descriptions
0:55518	Block announcement of prefixes to all ASN
0:$ASN	Block announcement of prefixes to this ASN only
55518:$ASN	Announce prefixes to this ASN only

Large Community	Descriptions
55518:0:0	Block announcement of prefixes to all ASN
55518:0:$ASN*	Block announcement of prefixes to this ASN only
55518:1:$ASN*	Announce prefixes to this ASN only

*Please note that ASN is a four byte AS number you have to use for the BGP Large Communities.


# Example 1
route-map SGIX-IPv4-OUT permit 10
  match ip address prefix-list RTBH-IPv4-LIST  # match IPv4 blackhole prefix-list
  set community 65535:666 0:1234 0:5678        # blackhole to all except ASN 1234 and 5678

# Example 2
route-map SGIX-IPv4-OUT permit 10
  match ip address prefix-list RTBH-IPv4-LIST    # match IPv4 blackhole prefix-list
  set community 65535:666 55518:1234 55518:5678  # blackhole to only ASN 1234 and 5678

Blackholing via Direct Peering

Below are some guideline and restrictions for blackholing via direct peering:

Members MUST enable send-community for both BGP v4v6 address-family.
Use of RFC7999 BLACKHOLE community for prefix marking and matching is optional but recommended.
Members must allow IP prefixes marked with blackhole community (either RFC7999 or custom community) through their inbound filter.
Blackhole IP prefix should include NO_EXPORT community to prevent it from leaking outside the local AS.
To signal an IP prefix for blackholing, manually set the respective address-family next-hop to SGIX blackhole next-hop address together with NO_EXPORT community before advertising to direct peer. For IPv6 address-family, both Global + Link-Local addresses MUST be included in the next-hop information.

# Create IP v4v6 static route for victim address
ip route X.X.X.X 255.255.255.255 <IPv4-next-hop-to-victim-address>
ipv6 route Y:Y:Y:Y::Y/128 <IPv6-next-hop-to-victim-address>

# Create IP v4v6 blackhole prefix-list for matching later
ip prefix-list RTBH-IPv4-LIST seq 5 permit X.X.X.X/32
ipv6 prefix-list RTBH-IPv6-LIST seq 5 permit Y:Y:Y:Y::Y/128

# IPv4 outbound policy snippet
route-map SGIX-IPv4-OUT permit 10               # create new blackhole policy
  match ip address prefix-list RTBH-IPv4-LIST   # match blackhole prefix-list
  set community 65535:666 no-export             # set BLACKHOLE & no-export community
  set ip next-hop 103.16.102.6                  # set SGIX blackhole next-hop address
route-map SGIX-IPv4-OUT permit 20               # existing outbound policy
  <existing outbound policies>                  # existing match statement

# IPv6 outbound policy snippet
route-map SGIX-IPv6-OUT permit 10                # create new blackhole policy
  match ipv6 address prefix-list RTBH-IPv6-LIST  # match blackhole prefix-list
  set community 65535:666 no-export              # set BLACKHOLE & no-export community
  set ipv6 next-hop 2001:DE8:12:100::6 FE80::DEAD:BEEF:6666:6666  # set SGIX blackhole next-hop address
route-map SGIX-IPv6-OUT permit 20                # existing outbound policy
  <existing outbound policies>                   # existing match statement

# BGP configuration snippet
router bgp <your_ASN>
  address-family ipv4
    network X.X.X.X mask 255.255.255.255                   # Advertise IPv4 blackhole prefix
    neighbor <peer_ipv4_addr> route-map SGIX-IPv4-OUT out  # Direct peer outbound policy
  exit-address-family

  address-family ipv6
    network Y:Y:Y:Y::Y/128                                 # Advertise IPv6 blackhole prefix
    neighbor <peer_ipv6_addr> route-map SGIX-IPv6-OUT out  # Direct peer outbound policy
  exit-address-family

INFRASTRUCTURE

SGIX operates a distributed peering network across major data centres in Singapore.

1-Net East / North
BDx SIN1
Digital Realty Singapore SIN10 / SIN11 / SIN12
Epsilon Global Hubs Singapore
Equinix SG1 / SG2 / SG3 / SG5
Global Switch (Tai Seng)
Iron Mountain DC Singapore (SIN-1)
Keppel Data Centre Singapore 1
Racks Central
Singtel DC West
STT Tai Seng 1
Telin-3 Data Centre

As SGIX operates a single VLAN, both IPv4 and IPv6 peering will take place in the same VLAN.

All switch ports are access/untagged port and permit only two MAC addresses per port by default. BPDU packets are being filtered and broadcast storm control implemented.

Only IPv4 (0x0800), IPv6 (0x86dd) and ARP (0x0806) packets are permitted. All vendor proprietary protocols (CDP, EDP, FDP, MNDP, LLDP, VTP, DTP, L2 Keepalive, BOOTP/DHCP), IGP routing protocols (RIP, OSPF, IS-IS, IGRP, EIGRP) and Multicast routing protocols (IGMP, PIM, MLD, DVMRP) are not allowed.

Port Price

Port Size	NRC/OTC	MRC in SGD	MRC in USD (Indicative)	Media Type
1G	*Fee applies	120	95	1x 1G-LX over SMF
10G	None	500	390	1x 10G-LR over SMF
20G	None	900	700	2x 10G-LR over SMF
30G	None	1300	1010	3x 10G-LR over SMF
40G	None	1700	1325	4x 10G-LR over SMF
100G	None	2900	2255	1x 100G-LR4 over SMF
200G	None	5400	4195	2x 100G-LR4 over SMF
300G	None	7700	5985	3x 100G-LR4 over SMF
400G	None	9800	7615	4x 100G-LR4 over SMF