Subject: [sidr] about reserved address space, anycast addresses and such

From: Sandra Murphy <[email-masked]>
Date: Thu, 28 Oct 2010 11:53:58 -0400 (Eastern Daylight Time)

This message is about a technical question, not a wg process question.  I 
send this message as a typical wg member, with no special wg chairness 
involved, no special items of wg ceremonial vestments donned, etc.

I came across a couple of special address space cases recently.

There are some special addresses that are reserved by/to IANA.  We've 
discussed a few of the more well known, e.g. the private address space 
(10/8, etc) and local addresses (127/8, etc).

For the most part, these addressees are not intended to be globally 
routed, so ROAs for these spaces are not meaningful.  In full deployment, 
the prefix holder (IANA) might omit producing a ROA for such address 
space.  In incremental deployment, that would allow anyone to originate a 
route to the prefix.  For address space that is not supposed to be 
announced, we've discussed things like producing a ROA to AS 0 (and BOAs) 
to cause mis-originations to be evaluated as "invalid" rather than 
"unkown".  That works for these not-globally-routed cases as well, with 
IANA signing the ROA.

But not all reserved address space is private.  In particular, there is a 
IANA reserved space for 6to4 routers, the 192.88.99.0/24 prefix. It is 
intended to be carried in BGP updates between ASs, if I read RFC3068 
correctly.

This space is also a special case in that is supposed to be an anycasted 
address.  Anycasted addresses that have specific individual prefix holders 
present little problem to the RPKI.  The prefix holder creates a ROA for 
each AS that could originate the prefix.  But in the 6to4 address case (if 
I read correctly), any AS is allowed to use that address space.  Would 
IANA sign ROAs for that space?  What ASs would be in the ROA for that 
address space?  Every AS?  How would that prevent hijacking?

The security considerations section in RFC3068 is nifty keen, especially 
the last sentence:

    The generic security risks of 6to4 tunneling and the appropriate
    protections are discussed in [RFC3056].  The anycast technique
    introduces an additional risk, that a rogue router or a rogue AS
    would introduce a bogus route to the 6to4 anycast prefix, and thus
    divert the traffic.  IPv4 network managers have to guarantee the
    integrity of their routing to the 6to4 anycast prefix in much the
    same way that they guarantee the integrity of the generic v4 routing.

[There is another range of addresses that has no defined semantics as yet 
and so might prove problematic to RPKI protections - the special use range 
of RFC5736/5735
        192.0.0.0/24 - This block is reserved for IETF protocol
       assignments.

We won't know until someone attempts to register something in this range 
(currently the registry is empty) whether it will fit nicely with the RPKI 
model.  Cross that bridge when we come to it.]

--Sandy, garden variety wg member

---

From: Terry Manderson <[email-masked]>
Date: Thu, 28 Oct 2010 16:50:23 -0700

Hi Sandy,

On 29/10/10 1:53 AM, "Sandra Murphy" <[email-masked]> wrote:

> routed, so ROAs for these spaces are not meaningful.

A ROA can only exist publically if the resource has been allocated to the
entity, setting aside discussion of the local TA for a moment. So really the
only place a reserved or special ROA (AS0 or otherwise) would be publically
created is the IANA.

> In full deployment,

I agree with that summary.

> address space?  Every AS?  How would that prevent hijacking?

Personally, and speaking only for myself, I would rather not see a ROA of
any type created for such prefixes as the 6to4 allocation. I would much
rather have it flagged as "unknown" over "Valid from 'ANY AS'". The relying
party then has a visible and conscious decision to make.

>     same way that they guarantee the integrity of the generic v4 routing.

Right, its really passing the decision and responsibility to the relying
party (IPv4 network managers).

So at some point in the near future it would be worth cataloging the
expected IANA issued RPKI objects for the internet number resources IANA
retains (as opposed to the numbers the IANA  allocated to the RIRs through
certification). Some would be candidates for a ROA with AS0, others might be
best handled by leaving them in the unknown state.

Cheers
Terry