ICANN/GNSO GNSO Email List Archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

[ga] [Fwd: [sig-policy] Comments on prop-059-v001: Using the Resource PublicKey Infrastructure to construct validated IRR data]

  • To: Ga <ga@xxxxxxxxxxxxxx>
  • Subject: [ga] [Fwd: [sig-policy] Comments on prop-059-v001: Using the Resource PublicKey Infrastructure to construct validated IRR data]
  • From: "Jeffrey A. Williams" <jwkckid1@xxxxxxxxxxxxx>
  • Date: Mon, 11 Aug 2008 18:07:32 -0700

All,

  I thought this might/should be of interest to some of
you for obvious reasons...

-------- Original Message --------
Subject: [sig-policy] Comments on prop-059-v001: Using the Resource
PublicKey Infrastructure to construct validated IRR data
Date: Wed, 13 Aug 2008 06:21:54 +1000
From: Geoff Huston <gih@xxxxxxxxx>
To: APNIC Policy SIG List <sig-policy@xxxxxxxxx>

Comments on:

prop-059-v001: Using the Resource Public Key Infrastructure to
               construct validated IRR data

This is a proposal that proposes that APNIC use Route Origin
Attestations (ROAs) that are published in the Resource Public Key
Infrastructure (RPKI) to synthesize Route Objects in the Routing
Policy Specification Language (RPSL) framework, and publish these
synthetic Route Objects in a new Internet Route Registry (IRR)
operated by APNIC.

The proposal indicates that operators who use the IRR to generate
routing filters can choose to put this new IRR registry logically in
front of the other registries, and that operators can then give
preference to routing origin information that can be formally
validated.

The proposal text indicated that there are no disadvantages to this
proposal.

I would like to make the comment that I differ with this assessment,
and put forward the viewpoint that the proposal has some very serious
disadvantages.

The proposed approach to synthesise Route Objects from ROAS makes the
underlying assumption that Route Object and ROAs are semantically
equivalent, and that they encapsulate the same information in
different formats, so that the transformation by a third party (namely
APNIC in this case) would neither add nor remove any information, nor
alter any implied permissions or authorities. This is not the case
in my opinion.

Firstly, the semantics of the two objects differ. A ROA is an
"authority" granted by a prefix holder that nominates an AS as a
potential originating AS. The key observation here is that the AS
holder is not necessarily aware of this ROA, or even necessarily aware
that such an authority has been granted or published, let alone be
prepared to announce the prefix as originating from this AS. The AS
holder cannot cause such an authority to be removed or revoked. In
contrast, a Route Object is a statement by an AS holder to the effect
that the AS is currently, or may in the future, announce a
particular prefix as originating from this AS. The question is: "what
is the validity of rephrasing a ROA as a Route Object?" This is a
serious violation of the semantics of a Route Object, in that the ROA
is not necessarily generated with the knowledge and consent of the AS
holder, and the synthesised Route Object is also not necessarily
generated with the knowledge or intent of the AS holder, nor
can the AS holder withdraw the synthesised Route Object.

Secondly, the intended use of the two objects differ. ROAs can be
treated in isolation. By this it is meant that the the actions that
may be taken by a relying party in processing a routed prefix in the
presence of a ROA does not alter when other ROAS are present. Route
Objects, on the other hand, have an entirely different intended use
and cannot be treated in isolation and must be taken as a
collection. In the intended use context of an IRR, the collection of
Route Objects that have a common origin AS are used to construct a
route filter. The implication of this filter construction is that all
prefixes not described by a Route Object with this originating AS are
to be rejected by a relying party. In other words, a set of Route
Objects must form a complete set, and relying parties must assume that
the collection of Route Objects are a complete set.

The issues raised by these semantic differences are most serious in a
world of partial use of ROAs, where some prefixes are covered by ROAS
and some are not, matching the environment of IRRs where some AS's
publish their routing policy information in IRRs while other AS's do
not. For a set of ROAS that have a common originating AS, the critical
question is "Does the set of prefixes described by this set of ROAs
form the entire and complete set of prefixes that may be originated by
this AS?" In an environment of partial use of ROAs the only possible
answer is "I do not know, as it is possible that they do not." The
implication is that if this set of ROAs is used to construct a filter
for the originating AS, via the synthesised set of Route Objects that
would be constructed according to this proposal, then the filter may
be incomplete, causing otherwise legitimate routing advertisements to
be dropped becuase of this incomplete filter that was constructed from
ROAS that were transformed into synthetic Route Objects.

It is possible to conceive of an attack on the routing system where a
prefix owner targets an AS by generating a ROA with that victim AS as
the nominated originating AS. In and of itself this is not an improper
use of a ROA, and in terms of the interpretation of the ROA then
nothing inappropriate has taken place. In synthesising a Route Object
from the ROA, the problem is that if the originating AS does not
otherwise use the IRR to publish any routes it originates, then
parties who use this IRR to create routing filters, as noted in the
proposal as a valid use of this IRR, will then construct a route
filter for this victim AS that consists of the single prefix described
in the ROA and no others. The prefixes that were validly originated by
the victim AS will be dropped by this filter, and, in some cases, this
may result in effective isolation of the victim AS from the network.

It is my view that this is an extremely serious disadvantage of this
proposal.

regards,

   Geoff 

(speaking purely for myself, of source)



 



*              sig-policy:  APNIC SIG on resource management
policy           *
_______________________________________________
sig-policy mailing list
sig-policy@xxxxxxxxxxxxxxx
http://mailman.apnic.net/mailman/listinfo/sig-policy

Regards,

Spokesman for INEGroup LLA. - (Over 281k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
jwkckid1@xxxxxxxxxxxxx
My Phone: 214-244-4827



<<< Chronological Index >>>    <<< Thread Index >>>