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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
