Archive for Routers & Routing

RFC 7353 Security Requirements for BGP Path Validation

RFC 7353

Title: Security Requirements for BGP Path
Validation
Author: S. Bellovin, R. Bush, D. Ward
Status: Informational
Stream: IETF
Date: August 2014
Mailbox: bellovin@acm.org,
randy@psg.com,
dward@cisco.com
Pages: 9
Characters: 18148
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-sidr-bgpsec-reqs-12.txt

URL: https://www.rfc-editor.org/rfc/rfc7353.txt

This document describes requirements for a BGP security protocol
design to provide cryptographic assurance that the origin Autonomous
System (AS) has the right to announce the prefix and to provide
assurance of the AS Path of the announcement.

Comments off

RFC 7196 – Making Route Flap Damping Usable

RFC 7196
Title: Making Route Flap Damping Usable
Author: C. Pelsser, R. Bush,
K. Patel, P. Mohapatra,
O. Maennel
Status: Standards Track
Stream: IETF
Date: May 2014
Mailbox: cristel@iij.ad.jp,
randy@psg.com,
keyupate@cisco.com,
mpradosh@yahoo.com,
o@maennel.net
Pages: 8
Characters: 15202
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-idr-rfd-usable-04.txt
URL: http://www.rfc-editor.org/rfc/rfc7196.txt

Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes’ normal convergence process.

Comments off

RFC 7128 – RPKI Router Implementation Report

RFC 7128

Title: Resource Public Key Infrastructure (RPKI) Router Implementation Report
Author: R. Bush, R. Austein,
K. Patel, H. Gredler,
M. Waehlisch
Status: Informational
Stream: IETF
Date: February 2014
Mailbox: randy@psg.com,
sra@hactrn.net,
keyupate@cisco.com,
hannes@juniper.net,
waehlisch@ieee.org
Pages: 11
Characters: 19348
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-sidr-rpki-rtr-impl-05.txt

URL: http://www.rfc-editor.org/rfc/rfc7128.txt

This document is an implementation report for the Resource Public Key Infrastructure (RPKI) Router protocol as defined in RFC 6810. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the “YES” answer if the feature had at least been tested in the lab.

Comments off

RFC 7115 Origin Validation Operation Based on the RPKI

Title: Origin Validation Operation Based on
the Resource Public Key Infrastructure (RPKI)
Author: R. Bush
Status: Best Current Practice
Stream: IETF
Date: January 2014
Mailbox: randy@psg.com
Pages: 11
Characters: 26033
See Also: BCP 185

I-D Tag: draft-ietf-sidr-origin-ops-23.txt

URL: http://www.rfc-editor.org/rfc/rfc7115.txt

Deployment of BGP origin validation that is based on the Resource
Public Key Infrastructure (RPKI) has many operational considerations.
This document attempts to collect and present those that are most
critical. It is expected to evolve as RPKI-based origin validation
continues to be deployed and the dynamics are better understood.

Comments off

Turning Comcast IPv6 Up on a NetGear 3800 with OpenWRT

The first problem was a pre-release kernel. I used LuCI, the web interface, to flash openwrt-ar71xx-generic-wndr3800-squashfs-sysupgrade.bin, and needed to be patient with 15 minutes of twirly. The flash lost my ssl package, so I also had to

opkg install uhttpd-mod-tls

Thanks for Chris Adams for all clue, and John Brzozowski for diagnostics and support, I loaded the necessary packages

opkg install ip6tables radvd wide-dhcpv6-client ip

Then I hacked /etc/config/dhcp6c

config 'dhcp6c' 'basic'
        option 'enabled' '1'                            # 1 = enabled; 0 = disabled
        option 'interface' 'wan'                        # This is the interface the DHCPv6 client will run on
        option 'dns' 'dnsmasq'                          # Which DNS server you run (only dnsmasq currently supported)
        option 'debug' '0'                              # 1 = enable debugging; 0 = disable debugging

        # Send options (1 = send; 0 = do not send)
        option 'pd' '1'                                 # Prefix Delegation
        option 'na' '1'                                 # Non-Temporary Address
        option 'rapid_commit' '1'                       # Rapid Commit

        # Request options (1 = request; 0 = do not request)
        option 'domain_name_servers' '1'
        option 'domain_name' '0'
        option 'ntp_servers' '0'
        option 'sip_server_address' '0'
        option 'sip_server_domain_name' '0'
        option 'nis_server_address' '0'
        option 'nis_domain_name' '0'
        option 'nisp_server_address' '0'
        option 'nisp_domain_name' '0'
        option 'bcmcs_server_address' '0'
        option 'bcmcs_server_domain_name' '0'

        # Override the used DUID, by default it is derived from the interface MAC
        # The given value must be uppercase and globally unique!
        #option 'duid' '00:03:00:06:D8:5D:4C:A5:03:F2'

        # Script to run when a reply is received
        option 'script' '/usr/bin/dhcp6c-state'

# Define one or more interfaces on which prefixes should be assigned
config 'interface' 'loopback'
        option 'enabled' '0'                            # 1 = enabled; 0 = disabled
        option 'sla_id' '1'                             # Site level aggregator identifier specified in decimal (subnet)
        option 'sla_len' '0'                            # Site level aggregator length (64 - size of prefix being delegated)
                                                        # e.g. /60 from ISP -> 64 - 60 = 4
config 'interface' 'lan'
        option 'enabled' '1'
        option 'sla_id' '1'
        option 'sla_len' '0'

Then /etc/init.d/dhcp6c start and see what you get. You should have an RA-assigned IP on your wan interface and a PD-assigned /64 on the LAN. If you configure radvd (just set it with no prefix listed), dhcp6c will automatically re-configure it to give out addresses from the /64.

Now get Router Advertisement working, hack /etc/config/radvd to

config interface
        option interface        lan
        option AdvSendAdvert    1
        option AdvManagedFlag   0
        option AdvOtherConfigFlag 0
        option ignore           0

config prefix
        option interface        lan
        # If not specified, a non-link-local prefix of the interface is used
        list prefix             ''
        option AdvOnLink        1
        option AdvAutonomous    1
        option AdvRouterAddr    0
        option ignore           0

config rdnss
        option interface        lan
        # If not specified, the link-local address of the interface is used
        list addr               ''
        option ignore           0

config dnssl
        option interface        lan
        list suffix             rg.net
        option ignore           0

Then
/etc/init.d/radvd start
/etc/init.d/dhcp6c start

At this point, we had the /128 on our WAN interface, and the /64 on the LAN interface. But, from the OpenWRT, we could not ping an external IPv6 address. Hours were spent chasing various ghosts, when we found the fix,

sysctl -w net.ipv6.conf.eth1.accept_ra=2

From a hint in New Zealand
, accept_ra=1 means “only accept RAs if forwarding is disabled”. Turns out to be documented in the 3.12.4 kernel source clue pages. Once you have forwarding enabled, you have to have accept_ra=2 to override that.

:~# ping6 psg.com
PING psg.com (2001:418:1::62): 56 data bytes
64 bytes from 2001:418:1::62: seq=2 ttl=52 time=70.286 ms
64 bytes from 2001:418:1::62: seq=3 ttl=52 time=70.090 ms
64 bytes from 2001:418:1::62: seq=4 ttl=52 time=71.169 ms
64 bytes from 2001:418:1::62: seq=5 ttl=52 time=77.020 ms

Comments off

An Automated System for Emulated Network Experimentation

Simon Knight presented our paper, An Automated System for Emulated Network Experimentation, at CoNEXT 2013 in Santa Barbara.

Emulated networks and systems, where router and server software are run in virtual environments, allow network op- erators and researchers to perform experiments at large scale more economically than in testbeds. Running real code pro- vides a greater level of realism than simulation.

However, large scale comes with a problem: running real software means each test needs at least as much configura- tion as a real network. To recognise the true value of emula- tion at scale, we need to reduce the complexity of building, configuring, deploying, and measuring emulated networks.

We present a system to facilitate emulation by provid- ing translation from a high-level network design into a con- crete set of configurations that are automatically deployed into one of several emulation platforms. Our system can be used to construct multi-domain networks in minutes, and is scalable to networks with over a thousand devices. It is modular, allowing support for different protocols, topology designs, and target platforms: Quagga, JunOS, IOS, etc. Users, from both the research community and industry, have already demonstrated its value in research and education.

Comments off

RFC 6945 – Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol

RFC 6945

Title: Definitions of Managed Objects for
the Resource Public Key Infrastructure (RPKI)
to Router Protocol
Author: R. Bush, B. Wijnen,
K. Patel, M. Baer
Status: Standards Track
Stream: IETF
Date: May 2013
Mailbox: randy@psg.com,
bertietf@bwijnen.net,
keyupate@cisco.com,
baerm@tislabs.com
Pages: 25
Characters: 52515
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-sidr-rpki-rtr-protocol-mib-07.txt

URL: http://www.rfc-editor.org/rfc/rfc6945.txt

This document defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for monitoring
the Resource Public Key Infrastructure (RPKI) to Router Protocol.

Comments off

RFC 6811 BGP Prefix Origin Validation

RFC 6811

Title: BGP Prefix Origin Validation
Author: P. Mohapatra, J. Scudder,
D. Ward, R. Bush,
R. Austein
Status: Standards Track
Stream: IETF
Date: January 2013
Mailbox: pmohapat@cisco.com,
jgs@juniper.net,
dward@cisco.com,
randy@psg.com,
sra@hactrn.net
Pages: 10
Characters: 20082
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-sidr-pfx-validate-10.txt

URL: http://www.rfc-editor.org/rfc/rfc6811.txt

To help reduce well-known threats against BGP including prefix mis-
announcing and monkey-in-the-middle attacks, one of the security
requirements is the ability to validate the origination Autonomous
System (AS) of BGP routes. More specifically, one needs to validate
that the AS number claiming to originate an address prefix (as
derived from the AS_PATH attribute of the BGP route) is in fact
authorized by the prefix holder to do so. This document describes a
simple validation mechanism to partially satisfy this requirement.
[STANDARDS-TRACK]

Comments off

RFC 6810 The Resource Public Key Infrastructure (RPKI) to Router Protocol

RFC 6810

Title: The Resource Public Key Infrastructure
(RPKI) to Router Protocol
Author: R. Bush, R. Austein
Status: Standards Track
Stream: IETF
Date: January 2013
Mailbox: randy@psg.com,
sra@hactrn.net
Pages: 27
Characters: 59714
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-sidr-rpki-rtr-26.txt

URL: http://www.rfc-editor.org/rfc/rfc6810.txt

In order to verifiably validate the origin Autonomous Systems of BGP
announcements, routers need a simple but reliable mechanism to
receive Resource Public Key Infrastructure (RFC 6480) prefix origin
data from a trusted cache. This document describes a protocol to
deliver validated prefix origin data to routers. [STANDARDS-TRACK]

Comments off

RIPE-580 – RIPE Routing Working Group Recommendations on Route Flap Damping

RIPE-580 – RIPE Routing Working Group Recommendations on Route Flap Damping has been published. As RIPE-178 was the start of Route Flap Damping, this is useful

Comments off

« Previous Page« Previous entries « Previous Page · Next Page » Next entries »Next Page »