Hi Sandy, On 29/10/10 1:53 AM, "Sandra Murphy" <sandra.mur...@sparta.com> wrote:
> > 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. 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, > 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. I agree with that summary. > > 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? 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. > > 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. > 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 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
