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

Internet Week Talk – The Japanese Net Community – an Outside View

At the ISP level, Japan is the most cooperative and communicative culture in the world. For example, a research study of BGP routing policy found all countries except Japan had 60-90% of ASs having some default routing. Japan had 36%. We believe this is due to coordination between Japanese ISPs and cooperation in sharing of technique.

JaNOG is a significant forum and a factor in coordination. Note that JaNOG meetings are as big, and sometimes bigger, as NANOG, the North American meeting.

I will never forget a JaNOG talk on hand tools, the tools we use when dealing with equipment in racks. Simple basic things such as powered screwdrivers, cable connectors, etc. This never happens outside of Japan, network operators in Europe and the United States are too self-important. Here, we share the techniques of our day-to-day lives. This attitude creates a harmony and consistency across the Japanese networking culture.

It is when we do not consult and coordinate openly that things go from amazingly good to varying shades of bad.

One example is the NTT NGN deployment, which was meant to encourage IPv6 deployment and to move the Internet forward technically. Unfortunately, though it was intended with very positive motives, it was done with insufficient technical consultation. It essentially made the *customer* IPv6 experience so bad, resulting in delays of one second, that Google, FaceBook, etc. have blacklisted Japan. This is unusually embarrassing as Japan was supposed to be a global leader in IPv6 deployment.

When it comes to coordination and cooperation above the engineering level, Japan is often a very negative point on the graph. When it comes to coordination with the government, it looks as if everything goes into a back room which accentuates all the disadvantages of the stereotyped Japanese isolation.

We have laws punishing Internet providers who host pornography which I am embarrassed to see as I walk down Book Street in Jimbocho. And it is right in front of children on the street. And it is right in front of me, and I am offended. At least on the Internet it can be avoided, since you have to hunt for it.

We now may put people in prison for downloading music. No other country in the world has such an extreme law. And who is being served by this? A back room deal between the media industry and the government with no public or Internet industry consultation.

The term “Internet Governance” is very dangerous. Our use of language constrains our thoughts. The Internet exploded and thrives because it is about cooperation and coordination, not hierarchy and control. And nowhere is this stronger than in the Japanese Internet technical community.

And we say that the Internet Wall of China is bad? We should look at ourselves first.

So there is the really good and the pretty bad. And of course it is not all black or white but has many colors in between. This leaves us with work to do. How do we create and maintain a more open dialog in the Japanese Internet culture

Comments off

Debbie Presented “Towards a Framework for Evaluating BGP Security” at CSET’12

Debbie Perouli presented our first AutoNetKit / RPKI Emulation paper at CSET’12

Olaf Maennel, Iain Phillips, Debbie Perouli, Randy Bush, Rob Austein, and Askar Jaboldinov, Towards a Framework for Evaluating BGP Security, CSET’12, 5th Workshop on Cyber Security Experimentation and Test.

From the abstract:

In this paper, our abstractions are specifically designed to evaluate the BGP security framework currently being documented by the IETF SIDR working group. We capture the relevant aspects of the SIDR security proposals, and allow experimenters to evaluate the technology in topologies of real router and server code. We believe such methods are also useful for teaching newcomers and operators, as it allows them to gain experience in a sand-box before deployment. It allows security experts to set up controlled experiments at various levels of complexity, and concentrate on discovering weaknesses, instead of having to spend time on tedious configuration tasks. Finally, it allows router vendors and implementers to test their code and to perform scalability evaluation.

Comments off

Resize a FreeBSD Disk Running Under VMware

I have a FreeBSD guest as a VM under VMware Fusion on my MacBook Air. It was built before my disk went from 250g to 500g, so was small. A research software build blew the 8g boundary. So, what worked was as follows

boot from a FreeBSD-9.0-RELEASE-amd64-bootonly.iso image
gpart delete -i 3 da0 (the swap)
gpart resize -i 2 -s 24g da0
gpart add -t freebsd-swap da0
growfs /da0p2

I see no reason this would not apply to vmware esxi on the servers

Comments off

DynaMIPS on FreeBSD on VMware ESXi

The simple approach to running DynaMIPS on FreeBSD guest under VMware did not work at all. No packets from the LAN reached the DynaMIPS ether interface.

24 hours later, and with the help of Iain and Rob, it was sorted.

It required two hacks as follows:

The first hack was running em1, the interface dynamips was using, through a custom vswitch that had promiscuous mode enabled.

The problem here was that this let packets through so well that it looped and multiplied them. Pings from the same ether LAN had TTLs as low as 220, delays of many seconds, and massive duplication of packets.

The second hack was running it through a bridge/tap interface on FreeBSD. In /etc/rc.conf lingo, that’s

   cloned_interfaces="bridge0 tap0"
   ifconfig_bridge0="addm em1 addm tap0"
   ifconfig_em1=up
   ifconfig_tap0=up

and then the dynagen conf file used

   fa0/0 = NIO_tap:/dev/tap0

Either hack alone did not work. It took both and one or more rubber chickens. The result looked like the following:

 
    .--------------------------.
    |                          |
    | .----------------------. |
    | |                      | |
    | | .------------------. | |
    | | |                  | | |
    | | |     DynaMIPS     | | |
    | | |                  | | |
    | | |                  | | |
    | | |           fa 0/0 | | |
    | | `--------------|---' | |
    | |                |     | |
    | |              tap0    | |
    | |  FreeBSD       |     | |
    | |             bridge0  | |
    | |                |     | |
    | |  em0          em1    | |
    | `---|------------|-----' |
    |     |            |       |
    |  vswitch      vswitch    |
    |     |            |       |
    |     `------------'       |
    |            |             |
    |  ESXi      |             |
    `------------|-------------'
                 |
        /--~~-----------~~--/
                LAN

The DynaGen configuration then looked like

  [localhost]
    [[7200]]
      model = 7200
      image = images/c7200-adventk9-mz-rpki26-v152_1_s_xe35_tr-bl30.unzip
      ram = 2048
      npe = npe-400
      idlepc = 0x6204bd2c
      ghostios = True
    [[router r0]]
      console = 2001
      aux = 3001
      fa0/0 = NIO_tap:/dev/tap0

Comments off

RFC 6493

        Title:      The Resource Public Key Infrastructure 
                    (RPKI) Ghostbusters Record 
        Author:     R. Bush
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2012
        Mailbox:    randy@psg.com
        Pages:      8
        Characters: 15491
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-sidr-ghostbusters-15.txt

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

In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc.  This document describes the RPKI Ghostbusters Record containing human contact information that may be verified (indirectly) by a Certification Authority (CA) certificate.  The data in the record are those of a severely profiled vCard.

Comments off

Freebsd-9 Configuration for Tunneling IPv6 to IIJ over IPv4 PPoE on B-Flets

With the generous help of Sato san, I managed to get IPv6 back working on my Tokyo home Soekris gateway to IIJ.

This is the simple view, pretty much focused on IPv4

               .-------------------------.
               |                         |
               |                b --wlan0|
               |                r        | 192.168.0.0/24
    WAN IIJ    |                i --- vr1| LAN hosts,
    PPP/NAT ---|vr0[PPPoE]tun0--d        | DHCP Clients
210.138.216.50 |                g --- vr2| ...
               |                e        |
               |                0 --- vr3|
               |                         |
               `-------------------------'

Here is the /etc/rc.conf

# User ppp configuration.
ppp_enable=YES
ppp_mode=dedicated
ppp_profile=iij

# IPv4 internal LAN
wlans_ath0=wlan0
create_args_wlan0="wlanmode ap mode 11g channel 11 up"
cloned_interfaces=bridge0
ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 up"
ifconfig_vr1=up
ifconfig_vr2=up
ifconfig_vr3=up

gateway_enable=YES
hostapd_enable=YES # Run hostap daemon.

# IPv6 internal LAN
ifconfig_bridge0_ipv6="inet6 fe80::0452:fdff:fe5d:b500/64"
ifconfig_bridge0_alias0="inet6 2001:240:6a8::1/64"

# IPv6 options
ipv6_activate_all_interfaces=YES
ipv6_gateway_enable=YES
route6d_enable=YES
route6d_flags="-A 2001:240:6a8::/48,gif0 -O 2001:240:6a8::/48,gif0"
rtsold_enable=YES
rtadvd_enable=YES
rtadvd_interfaces="vr0 bridge0"
gif_interfaces=gif0
gifconfig_gif0="210.138.216.50 210.138.77.245"
ipv6_static_routes=gif
ipv6_route_gif="default -interface gif0"

and the /etc/ppp/ppp.conf

default:
set log Phase Chat LCP IPCP CCP tun command
ident user-ppp VERSION (built 2008.04.01)
disable ipv6cp

iij:
set device PPPoE:vr0
set MRU 1454 # NTT suggests this value
set MTU 1454
accept CHAP
enable lqr
add default HISADDR
nat enable yes
set authname <user>@bnf1.iij.ad.jp
set authkey <password>

Comments off

Anti-CGN Presentation

At the 6th Slovene IPv6 Summit, I did the lead preso to a panel with Mark Townsley and Dan Wing on translation vs. encapsulation where I managed a serious anti-CGN rant. See my presentation.

Comments off

Estimating CPU Cost of BGPsec on a Router

My presentation, with Kotikalapudi Sriram, given at Cisco NAG of the first results from modeling the signing and validation processor costs of BGPsec.

My take-away:

  • You very well may be able to do initial deployment of path validation using current high end routers, and even some almost high end routers.
  • As we deploy, at least Cisco looks likely to be ahead of our CPU needs. The ISP W in my slides will have to move up if they intend to keep their current BGP peer density. But there will be something to which they can move.
  • Comments off

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