The configuration snippets provided for conformance check only, they are not intended as the implementation guidance. Specific set of features depend on the specific platform that is being used. Not all the products may support these features.

Description for Scenarios

ScenarioProgrammeAction

Scenario 1 Filtering

Network Operators

Action1. Prevent propagation of incorrect routing information

CDN & Cloud Providers

Scenario 2 Anti-spoofing

Network Operators

Action 2: Prevent traffic with spoofed source IP addresses

CDN & Cloud Providers

Action 2. Prevent traffic with illegitimate source IP addresses

Scenario 3 Filtering (IXP)

IXPs

Action 1. Prevent propagation of incorrect routing information. (Route Server)

Scenario 4 Protect L2 (IXP)

IXPs

Action 3. Protect the peering platform (layer 2)

Implementation of MANRS Action 1

Scenario 1 Filtering

Creating filters based on prefix lists: 
set policy-options policy-statement reject term unwanted from prefix-list-filter bogons orlonger
set policy-options policy-statement reject term unwanted then reject

set policy-options prefix-list bogons 100.64.0.0/10
set policy-options prefix-list bogons 101.10.0.0/19
set policy-options prefix-list bogons 127.0.0.0/8
set policy-options prefix-list bogons 169.254.0.0/16
set policy-options prefix-list bogons 192.0.0.0/24
set policy-options prefix-list bogons 192.0.2.0/24
set policy-options prefix-list bogons 198.18.0.0/15
set policy-options prefix-list bogons 198.51.100.0/24
set policy-options prefix-list bogons 203.0.113.0/24
set policy-options prefix-list bogons 224.0.0.0/4
set policy-options prefix-list bogons 10.0.0.0/8
set policy-options prefix-list bogons 172.16.0.0/12
set policy-options prefix-list bogons 192.168.0.0/16
Creating filters based on as-path: 
policy-options {
    policy-statement block-very-long-paths {
        from as-path too-many-hops;
        then reject;
    }

    as-path too-many-hops ".{50,}";
}
Creating filters based on RPKI: 
routing-options {
  validation {
    group rpki-validator {
      session 10.1.1.6
    }
  }
}

policy-statement rpki {
  term reject_invalid {
    from {
      protocol bgp;
        validation-database invalid;
    }
    then {
      validation-state invalid;
      reject;
    }
  }
  term mark_valid {
    from {
      protocol bgp;
      validation-database valid;
    }
    then {
      validation-state valid;
      next policy;
    }
  }
  then {
    validation-state unknown;
    next policy;
  }
}
Applicability: 
OS/Product line: Junos OS

Scenario 2 Anti-spoofing

Creating filters based on prefix lists: 
Configure unicast RPF strict mode, and apply the optional fail filter:
set interfaces ge-1/2/0 unit 2 family inet rpf-check fail-filter rpf-special-case-dhcp

(Optional) Configure only active paths to be considered in the RPF check.
(This is the default behavior):
set routing-options forwarding-table unicast-reverse-path active-paths

(Optional) Configure the fail filter that gets evaluated if a packet fails the RPF check:
set firewall filter rpf-special-case-dhcp term allow-dhcp from source-address 0.0.0.0/32 
set firewall filter rpf-special-case-dhcp term allow-dhcp from destination-address 255.255.255.255/32
set firewall filter rpf-special-case-dhcp term allow-dhcp then count rpf-dhcp-traffic 
set firewall filter rpf-special-case-dhcp term allow-dhcp then accept 
set firewall filter rpf-special-case-dhcp term default then log 
set firewall filter rpf-special-case-dhcp term default then reject

To configure unicast RPF loose mode, include the mode:
[edit] 
interfaces {
    so-0/0/0 {
        unit 0 {
            family inet {
                rpf-check fail-filter rpf-special-case-dhcp-bootp;
                mode loose;
            }
        }
    }
}
Implementing source address validation using access lists: 
firewall {
    filter SOURCE_FILTER {
        term MATCH_SOURCE {
            from {
                source-address {
                    10.194.0.14/32;
            }
            then accept;
        }
    }
}

set interface xe-0/0/1 unit 0 family inet filter input SOURCE_FILTER
Applicability: 
OS/Product line: Junos OS
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/unicast-rpf.html

Scenario 3 Filtering (IXP)

Creating filters based on prefix lists: 
set policy-options policy-statement reject term unwanted from prefix-list-filter bogons orlonger
set policy-options policy-statement reject term unwanted then reject

set policy-options prefix-list bogons 100.64.0.0/10
set policy-options prefix-list bogons 101.10.0.0/19
set policy-options prefix-list bogons 127.0.0.0/8
set policy-options prefix-list bogons 169.254.0.0/16
set policy-options prefix-list bogons 192.0.0.0/24
set policy-options prefix-list bogons 192.0.2.0/24
set policy-options prefix-list bogons 198.18.0.0/15
set policy-options prefix-list bogons 198.51.100.0/24
set policy-options prefix-list bogons 203.0.113.0/24
set policy-options prefix-list bogons 224.0.0.0/4
set policy-options prefix-list bogons 10.0.0.0/8
set policy-options prefix-list bogons 172.16.0.0/12
set policy-options prefix-list bogons 192.168.0.0/16
Creating filters based on as-path: 
policy-options {
    policy-statement block-very-long-paths {
        from as-path too-many-hops;
        then reject;
    }

    as-path too-many-hops ".{50,}";
}
Creating filters based on RPKI: 
routing-options {
  validation {
    group rpki-validator {
      session 10.1.1.6
    }
  }
}

policy-statement rpki {
  term reject_invalid {
    from {
      protocol bgp;
        validation-database invalid;
    }
    then {
      validation-state invalid;
      reject;
    }
  }
  term mark_valid {
    from {
      protocol bgp;
      validation-database valid;
    }
    then {
      validation-state valid;
      next policy;
    }
  }
  then {
    validation-state unknown;
    next policy;
  }
}
Applicability: 
OS/Product line: Junos OS

Scenario 4 Protect L2 (IXP)

Creating controls preventing unwanted traffic: 
Create a storm control profile and apply to interface:
set forwarding-options storm-control-profiles STORM-CONTROL all bandwidth-percentage 6
set interfaces ae11 unit 0 family ethernet-switching storm-control STORM-CONTROL

Configure MAC filter and apply to interface:
set firewall family ethernet-switching filter L2-INGRESS term ARP-REQ from source-mac-address be:ef:a2:01:00:0a/48
set firewall family ethernet-switching filter L2-INGRESS term ARP-REQ from destination-mac-address ff:ff:ff:ff:ff:ff/48
set firewall family ethernet-switching filter L2-INGRESS term V4-BROADCAST from source-mac-address be:ef:a2:01:00:0a/48
set firewall family ethernet-switching filter L2-INGRESS term ARP-REQ from ether-type arp
set firewall family ethernet-switching filter L2-INGRESS term ARP-REQ from user-vlan-id 10
set firewall family ethernet-switching filter L2-INGRESS term ARP-REQ then accept
set firewall family ethernet-switching filter L2-INGRESS term ARP-REQ then count ARP-REQ-CNT
set firewall family ethernet-switching filter L2-INGRESS term V4-BROADCAST from source-mac-address be:ef:a2:01:00:0a/48
set firewall family ethernet-switching filter L2-INGRESS term V4-BROADCAST from destination-mac-address ff:ff:ff:ff:ff:ff/48
set firewall family ethernet-switching filter L2-INGRESS term V4-BROADCAST from ether-type ipv4
set firewall family ethernet-switching filter L2-INGRESS term V4-BROADCAST from user-vlan-id 10
set firewall family ethernet-switching filter L2-INGRESS term V4-BROADCAST then accept
set firewall family ethernet-switching filter L2-INGRESS term V4-BROADCAST then count V4-BROADCAST-CNT-IN
set firewall family ethernet-switching filter L2-INGRESS term V6-BROADCAST from source-mac-address be:ef:a2:01:00:0a/48
set firewall family ethernet-switching filter L2-INGRESS term V6-BROADCAST from destination-mac-address ff:ff:ff:ff:ff:ff/48
set firewall family ethernet-switching filter L2-INGRESS term V6-BROADCAST from ether-type ipv6
set firewall family ethernet-switching filter L2-INGRESS term V6-BROADCAST from user-vlan-id 10
set firewall family ethernet-switching filter L2-INGRESS term V6-BROADCAST then accept
set firewall family ethernet-switching filter L2-INGRESS term V6-BROADCAST then count V6-BROADCAST-CNT-IN
set firewall family ethernet-switching filter L2-INGRESS term PKT_IN_V4 from source-mac-address be:ef:a2:01:00:0a/48
set firewall family ethernet-switching filter L2-INGRESS term PKT_IN_V4 from destination-mac-address 00:00:5e:00:00:04/48
set firewall family ethernet-switching filter L2-INGRESS term PKT_IN_V4 from source-port 1020
set firewall family ethernet-switching filter L2-INGRESS term PKT_IN_V4 from destination-port 1024
set firewall family ethernet-switching filter L2-INGRESS term PKT_IN_V4 from ip-source-address 10.0.10.201/32
set firewall family ethernet-switching filter L2-INGRESS term PKT_IN_V4 from ip-destination-address 10.0.12.201/32
set firewall family ethernet-switching filter L2-INGRESS term PKT_IN_V4 from ip-protocol tcp
set firewall family ethernet-switching filter L2-INGRESS term PKT_IN_V4 from user-vlan-id 10
set firewall family ethernet-switching filter L2-INGRESS term PKT_IN_V4 then accept
set firewall family ethernet-switching filter L2-INGRESS term PKT_IN_V4 then count V4-PKT-CNT-IN-TCP-FLAG-0x90
set firewall family ethernet-switching filter L2-INGRESS term DEF then accept
set firewall family ethernet-switching filter L2-INGRESS term DEF then count DEF_CNT_IN
set interfaces ae11 unit 0 family ethernet-switching filter input L2-INGRESS

Enabling BPDU Protection per interface:
set protocols layer2-control bpdu-block interface ae11.0
Applicability: 
OS/Product line: Junos OS (17.4 and newer)

Changes to normal EBGP behavior are controlled by the route-server-client CLI configuration. The route-server-client CLI configuration at the [edit protocols bgp group group-name] hierarchy level implements route server BGP attribute transparency behavior.

Route Server configuration:

set protocols bgp group  route-server-client
set protocols bgp group  type external
set protocols bgp group  neighbor

Implementation of MANRS Action 2

Describe your implementation of Action 2-1:

Action 2-1 status: Planned

Describe your implementation of Action 2-2:

Action 2-1 status: Implemented

Describe your implementation of Action 2-3:

Action 2-1 status: Implemented

Describe your implementation of Action 2-4:

Action 2-1 status: Planned

Why Juniper Networks Supports MANRS

With a greater reliance on the internet now more than ever, it is crucial that the internet is stable and offers secure and trusted methods to connect users. It is the responsibility of the global community to work together to ensure that the whole ecosystem forming the internet works well and is protected against threat actors. Juniper Networks is a proud supporter of the MANRS program and will continue to strive for a better internet in today’s connected world.

Melchior Aelmans Consulting Engineer, Juniper Networks