Subject: [sidr] Resolving the issues in the roa-format draft

From: Geoff Huston <[email-masked]>
Date: Sat, 4 Oct 2008 14:45:50 +1000

WG-Chair hat hurled into the corner for this posting....

I note that there are two residual open issues in the ROA draft that  
should be resolved. From the minutes of IETF 72 it was reported that  
from this draft:

    o Open issues:
         * Should a canonical format for IP addresses in ROAs be
           specified?
           - What does equivalence of ROA mean if there is no canonical
             format?
           - Should we mandate canonical format to make comparison as
             easy as possible?
           - Is a useful canonical format feasible, and is the transform
             to any such format of benefit to the ROA creator or ROA
             relying party?
           - How do we apply the validation test of a precise match
             between the resources in the EE cert and the prefixes in
             the ROA, as described in step 3 of the draft
           - Further consideration of this topic is required by the WG

         * Should the ROA format permit multiple EE certs?
           - If an ISP has two CA certs from different CAs for adjacent
             addresses where the ISP wishes to advertise the aggregate,
             that this cannot be expressed in a ROA.
           - Is this something that the specification should address?
           - There was no clear outcome from the discussion, and further
             consideration of the matter is required by the WG.

I'd like to propose a resolution to these issues by proposing that:

a)  NO canonical ROA format be specified.

The reason for this is that origination validation is reliant on the  
presence of a valid ROA that matches the prefix. The presence of  
additional ROAs, valid or invalid, that also match the prefix does not  
alter the reliance that can be given to the route object once one  
valid ROA is detected. Therefore, as long as a relying party can use  
as a lookup key a given prefix and retrieve all ROAs that match the  
prefix then the validation operation can be undertaken. Comparison of  
2 or more ROAs for equivalence is not necessary. in order to allow  
this document to proceed I propose that NO text be added regarding a  
description of a canonical ordering of prefixes in a ROA.

b) a ROA BE ALLOWED to use multiple signatures

This would use the CMS option of multiple EE certs to describe those  
aggregate prefixes that are not certified within a single validation  
path. This is a situation akin to proxy aggregation, where a route  
object is being constructed from multiple components and the  
associated ROA therefore contains a route object that cannot be  
described in a single EE certificate.

The draft would need to specify that:
- all EE certificates are to be included
- all signatures MUST validate for the CMS object to be considered valid
- the union of the address prefixes in the EE certificates MUST  
encompass the prefixes specified in the ROA.

In favor of this approach I note that RFC 3852 and RFC4853 permit  
multiple signatures and EE certs in CMS, so the basic format of the  
ROA is not altered.

The comment has been raised that this is an unlikely situation and  
there is no need to make the specification more complex for unlikely  
cases. In response I would argue that the specification should be  
complete and provide appropriate guidance to implementors for all  
situations where interoperability is required, and this case, although  
not common, has visible in the routing table already and will likely  
be visible in the routing table in future. Given that this does not  
define a new signature standard for CMS, nor a major change in the  
logic of ROA processing I do not see that this adds any undue  
complexity to implementations and has the benefit of covering the full  
range of anticipated use cases for ROAs in their application to  
signing route origination.

Are there any comments from other folk on this proposed form of  
resolution?

Geoff

_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Matt Lepinski <[email-masked]>
Date: Mon, 06 Oct 2008 10:27:16 -0400

Geoff,

On the issue of canonicalization -- To the best of my knowledge no one 
has put forward a use-case, on this mailing list or at the Dublin 
meeting, in which efficient comparison of ROAs is necessary. Therefore, 
the only reason to define some sort of 'canonicalization' is to simplify 
comparison between the addresses in a ROA and an EE cert. It is possible 
that requiring prefixes to be lexiographically sorted makes it easier 
for relying parties to compare a ROA with its coresponding EE 
certificate [at the cost of slightly more work for the relying party]. 
Therefore, I have a weak preference for requiring ROA prefixes to be 
lexiographically sorted. However, I have a strong preference for 
finishing the document, so I'm willing to go along with Geoff's proposal 
(i.e. No canonical ordering).

While we're on the topic of comparing ROA prefixes to those in EE 
certificates: Currently, the ROA format draft specifies an exact match 
between the prefixes in a ROA and the prefixes in the EE cert, and this 
text is a bit ambigous as written (for which I am to blame). As was 
pointed out at IETF 72 we have the following issue:

One might reasonably create a ROA containing 10.0/16 and 10.1/16.
However, RFC 3779 specifies that if one were to create an EE cert 
covering these addresses that the IP address extension would contain the 
single prefix 10.0/15.
So if by "exact match" we mean a simple bit-wise comparison, then 
10.0/16 and 10.1/16 cannot be present in the same ROA (they would need 
to be split into two separate ROAs, which is clearly inefficient) and if 
by "exact match" we mean 'logically the same set of addresses' then it's 
not clear what the "exact match" requirement is buying us.

At IETF 72, George Michaelson suggested that the proper requirement is 
that each prefix in the ROA is a logical subset of a prefix in the EE 
certificate. This is at least as easy to implement as testing whether 
the ROA and EE cert contain the same 'logical set of addresses' and 
nicely resolves the issue of needing to break apart authorizations into 
a (potentially) large number of ROAs.

- Matt Lepinski

Geoff Huston wrote:

> additional ROAs, valid or invalid, that also match the prefix does 
> not  alter the reliance that can be given to the route object once 
> one  valid ROA is detected. Therefore, as long as a relying party can 
> use  as a lookup key a given prefix and retrieve all ROAs that match 
> the  prefix then the validation operation can be undertaken. 
> Comparison of  2 or more ROAs for equivalence is not necessary. in 
> order to allow  this document to proceed I propose that NO text be 
> added regarding a  description of a canonical ordering of prefixes in 
> a ROA.
>
> situations where interoperability is required, and this case, 
> although  not common, has visible in the routing table already and 
> will likely  be visible in the routing table in future. Given that 
> this does not  define a new signature standard for CMS, nor a major 
> change in the  logic of ROA processing I do not see that this adds any 
> undue  complexity to implementations and has the benefit of covering 
> the full  range of anticipated use cases for ROAs in their application 
> to  signing route origination.
>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 7 Oct 2008 10:07:12 +1100

On 07/10/2008, at 1:27 AM, Matt Lepinski wrote:

> Geoff,
>
> On the issue of canonicalization -- To the best of my knowledge no  
> one has put forward a use-case, on this mailing list or at the  
> Dublin meeting, in which efficient comparison of ROAs is necessary.  
> Therefore, the only reason to define some sort of 'canonicalization'  
> is to simplify comparison between the addresses in a ROA and an EE  
> cert. It is possible that requiring prefixes to be lexiographically  
> sorted makes it easier for relying parties to compare a ROA with its  
> coresponding EE certificate [at the cost of slightly more work for  
> the relying party]. Therefore, I have a weak preference for  
> requiring ROA prefixes to be lexiographically sorted. However, I  
> have a strong preference for finishing the document, so I'm willing  
> to go along with Geoff's proposal (i.e. No canonical ordering).
>
> certificates: Currently, the ROA format draft specifies an exact  
> match between the prefixes in a ROA and the prefixes in the EE cert,  
> and this text is a bit ambigous as written (for which I am to  
> blame). As was pointed out at IETF 72 we have the following issue:
>
> covering these addresses that the IP address extension would contain  
> the single prefix 10.0/15.
> 10.0/16 and 10.1/16 cannot be present in the same ROA (they would  
> need to be split into two separate ROAs, which is clearly  
> inefficient) and if by "exact match" we mean 'logically the same set  
> of addresses' then it's not clear what the "exact match" requirement  
> is buying us.
>
> At IETF 72, George Michaelson suggested that the proper requirement  
> is that each prefix in the ROA is a logical subset of a prefix in  
> the EE certificate. This is at least as easy to implement as testing  
> whether the ROA and EE cert contain the same 'logical set of  
> addresses' and nicely resolves the issue of needing to break apart  
> authorizations into a (potentially) large number of ROAs.

WG chair hat off once more:

Yes, if the text in section 3, step 3 of the draft was altered to use  
the term "encompass" such that the IP addresses prefixes in that  
extension encompasses the IP prefix(es) in the ROA I would agree that  
would be a suitable resolution.

regards,

Geoff

---

From: Brian Dickson <[email-masked]>
Date: Mon, 06 Oct 2008 19:41:51 -0400

>           - Further consideration of this topic is required by the WG
(see below, please)
> description of a canonical ordering of prefixes in a ROA.

(See below)

> Are there any comments from other folk on this proposed form of

I hope it isn't too late to voice an opinion on ROA prefix and
prefix-range semantics, and how those may better be represented with a
slight change in the ROA fields needed to achieve that degree of subtlety.

I believe that this may in fact inform a canonical format and sort
order, for facilitating comparisons between ROAs and for matching
prefixes against ROAs.

Here's the gist of the issue - there are two things represented in the
ROA which a prefix must match.
One is, the "range" of the ROA, i.e. the CIDR block within which the
matching prefix must fall.
The second is the "size" of prefixes that the ROA is valid for, i.e. the
range of valid prefix-lengths that a matching prefix's prefix-length
must fall within.

As it currently stands, an ROA has an implicit, rather than explicit,
lower value for the range of prefix-lengths, which equals the
prefix-length of the CIDR block that the ROA describes.

I believe that there may be situations where the "semantics" of the ROA
as it stands, would require multiple ROAs (where "multiple" could
conceivably be any power of 2!!), to accurately represent a desired ROA
assignment set.
And, that a more "flexible" ROA with *explicit* lower value for range of
prefix-lengths, would be all that is required to permit expressing such
ROA sets.

Rather than having:

    IP_address / length le maxLength (length <= maxLength <=
address-family-max-length)

this would be

    IP_address / length ge minLength le maxLength (length <= minLength
<= maxLength <= address-family-max-length)

One example I've seen discussed (not sure of the context, either in ROA
format discussions, or in multiple-signature context), is 10.0/16 and
10.1/16.
In this new syntax, this would be represented as "10.0/15 ge 16 le 16".

A prefix/length would match an ROA, iff prefix is covered by ROA
(ip_address/length) AND minLength <= length <= maxLength.

Sort order would be:
prefix (ascending)
length (descending)
minLength (descending)
maxLength (descending)

Search order semantics would be (and could be extended to tree-based
searching):
key_prefix >= prefix
key_prefix < prefix + 2^(addr-family-max-length - length)
key_length >= minLength
key_length <= maxLength

(NB - with this sort order and search order, the presence of "moot" ROAs
who are entirely covered by another ROA (subnet of the prefix, range
entirely within the other's range), won't break the matching process.)

I don't think this change drastically affects the ROA, and in most cases
I would expect length == minLength to be the case.

However, in the few instances where it doesn't hold true, this would be
a saving grace, and valuable enough (IMHO) to warrant discussion.

Brian Dickson

---

From: Geoff Huston <[email-masked]>
Date: Tue, 7 Oct 2008 16:33:17 +1100

WG Chair hat _OFF_

> <= maxLength <= address-family-max-length)

Its isomorphic in one sense isn't it? The described representation  
lists the prefixes in the maximally permitted aggregate format and by  
the optional MaxLength parameter which specifies the finest level of  
more specifics that could be originated from this ROA. Your suggested  
representation allows a  number of aggregatable prefixes to be  
aggregated as a described prefix, as long as they share a common  
minLength value.

_personally_ I'm unsure that this alternate representation would offer  
any superior flexibility in the representation of ROAs.

  Geoff

---

From: Brian Dickson <[email-masked]>
Date: Tue, 07 Oct 2008 02:33:16 -0400

> any superior flexibility in the representation of ROAs.

I'm not sure if any or all of these kinds of use cases are appropriate,
but if any of them are, they may serve to demonstrate the compactness
achievable with this representation.

Examples:
RIR->LIR, RIR has certain specific policies it wishes to enforce
regarding LIR assignments to end-users -- anything bigger than /X
requires justification (i.e. approval) and registration (i.e. ROA).
Either RIR has to create a large swath of ROAs, each of size /X, or it
can create one ROA with minLength=X. (In this example, maxLength is
irrelevant and presumed identical.)
Exceptions are needed, of course, for /Y (Y < X), but each of these can
be done with separate ROAs.
Even as a worst case scenario, no *more* ROAs are needed than in the
original case.
In a best case scenario, many orders of magnitude quantity of ROAs need
never be created, and RIR's policies are enforced directly via ROAs.

LIR->PA customers, LIR wants to aggregate but also wants to ensure no
customers are able to punch holes in the PA space.
LIR restricts the minLength to something not globally routable (e.g. /25
in IPv4, /49 in IPv6).
This ties the customer to the LIR, by preventing PA blocks being
announced via third parties (hole punching).
One ROA can be assigned, whether the amount of space is small or large.
Internal aggregation by the PA customer is limited, of course, but that
is the intention of the LIR.

There may be other cases that I'm missing, but which others may see,
based on the above examples.
Things related to IPv6 nibble boundaries (for ip6.arpa reasons) but
where the current use is only a portion of the larger (reserved) block;
ROAs with differing minLength can be created as the customer grows,
providing a viable path with no "flag day" needed.

It is certainly no worse than the previous representation, as it is
strictly a superset.

The main question, IMHO, is, does it add sufficient value to justify
making the change?
(I think it's the only question, actually.)

Brian

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 07 Oct 2008 10:09:19 -0400

Brian,

Two comments:

1) In your first example, the use of the term "registration" indicates 
that we might have some confusion on the semantics of a ROA. We envision 
that certificates will be issued in conjunction with the registration of 
IP resources (e.g. The RIR issues a certicate to the LIR when the LIR 
obtains resources from the RIR). ROAs are not intended to reflect 
registration but are merely a statement by the holder of IP resources 
(i.e. the party to whom the resources are registered) that a particular 
AS is permitted to originate routes to particular IP prefixes. If this 
was not your understanding, then I'd like your help in finding places in 
the ROA document where wording can changed to make these semantics 
clear. (If this was your understanding, then I apologize for 
mis-understanding your example.)

In any case, I personally believe that the SIDR Resource PKI is an 
inefficient way for the RIRs to enforce policy upon the LIRs. So I'm 
personally not inclined to make changes in an attempt to make the R-PKI 
suitable for that purpose. With regards to your second example, if the 
LIR wants to prohibit a an end-user from announcing prefixes through 
another provider (hole punching), then I think the right answer is for 
the LIR NOT to issue a certificate to the end-user (this prevents the 
end-user from issuing ROAs that grant permissions to other providers) 
and instead to issue an appropriate ROA for the aggregate prefix (which 
persumably names the LIR's own AS number).

2) With regards to format, there was discussion in March in Philidelphia 
which led to the addition of the max-length field. At that time, the 
question was raised as to whether there should also be a min-length 
field and at the time there seemed to be no operator requirement for 
such a field. In particular, to justify a min-length field one would 
need a use-case where a registered holder of IP resources wishes to give 
an AS permission to advertise many long prefixes, but expressly forbid 
the AS from advertising the aggregate prefix. Such a use-case seems 
unlikely because in most cases advertising the aggregate prefix does no 
harm (and indeed will be ignored in the presence of advertisements for 
longer prefixes) although I could be missing something.

- Matt Lepinski

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Oct 2008 11:19:41 -0400

At 2:33 AM -0400 10/7/08, Brian Dickson wrote:
>G...

When I got to this statement, I became very concerned.  A ROA is 
generated by a prefix holder to specify an AS that the prefix holder 
authorizes to originate a route to the prefix in question. Thus, an 
RIR (or NIR) should never be signing a ROA. Only ISPs and subscribers 
who are multi-homed or who have PI address space should be generating 
ROAs.

I didn't read the rest of your message to validate the other examples 
you offered, but this one seems seriously out of whack.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 7 Oct 2008 11:27:54 -0400 (Eastern Daylight Time)

On Tue, 7 Oct 2008, Stephen Kent wrote:

> When I got to this statement, I became very concerned.  A ROA is generated by 
> a prefix holder to specify an AS that the prefix holder authorizes to 
> originate a route to the prefix in question. Thus, an RIR (or NIR) should 
> never be signing a ROA. Only ISPs and subscribers who are multi-homed or who 
> have PI address space should be generating ROAs.

Any chance Brian meant RSA, not ROA?  Seems to fit the context better.

--Sandy

>
> I didn't read the rest of your message to validate the other examples you 
> offered, but this one seems seriously out of whack.
>
> Steve

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 7 Oct 2008 11:30:09 -0400 (Eastern Daylight Time)

On Tue, 7 Oct 2008, Sandra Murphy wrote:

>> When I got to this statement, I became very concerned.  A ROA is generated 
>> by a prefix holder to specify an AS that the prefix holder authorizes to 
>> never be signing a ROA. Only ISPs and subscribers who are multi-homed or 
>> who have PI address space should be generating ROAs.
>

On second thought, no it doesn't.  sorry.

--Sandy

---

From: Brian Dickson <[email-masked]>
Date: Tue, 07 Oct 2008 16:05:43 -0400

(Sorry in advance - long post ahead. Please read, however, when you have
time, everyone. There's some valuable operator input here.)

Matt Lepinski wrote:
> that we might have some confusion on the semantics of a ROA. We
> envision that certificates will be issued in conjunction with the
> registration of IP resources (e.g. The RIR issues a certicate to the
> LIR when the LIR obtains resources from the RIR). ROAs are not
> intended to reflect registration but are merely a statement by the
> holder of IP resources (i.e. the party to whom the resources are
> registered) that a particular AS is permitted to originate routes to
> particular IP prefixes. If this was not your understanding, then I'd
> like your help in finding places in the ROA document where wording can
> changed to make these semantics clear. (If this was your
> understanding, then I apologize for mis-understanding your example.)

I think I understand what you're saying.

However, I am trying to reconcile several things, and am having
difficulty in figuring out what EE/ROA things need to be issued, by
whom, and what the validation methodology is.

I'm specifically considering the BGP default-free zone, and prefixes
seen globally.

Here's how filters can be built today:

    * IP allocations are done
          o either entire PA blocks to ISPs for reassignment to their
            customers, and aggregation to the whole block before global
            announcement (at least in theory)
          o or PI blocks to end sites who are multi-homed
    * IRR registration is made by the originating AS (the ISP or
      multi-homed entity, using its own ASN as Origin: attribute for
      Route: objects, plus its Aut-num: object)
    * IRR registration is made for as-sets (hierarchically, too, to
      arbitrary depth) reflecting customer/transit relationships
    * IRR registration of peering announcements (who announces what to
      whom, in RPSL) is done
    * Expansion of IRR contents on a per-peer or per-customer basis is
      done, expanding into permitted AS_PATH and PREFIX lists (not
      necessarily tied together, unfortunately, and not necessarily as
      complete as we would like)

In the "-roa-" drafts, the term "originate" is used consistently, but I
am unclear if that maps 1:1 with "Origin:" in the IRR. Does it mean,
strictly, originate, or does it also mean "announce to a peer", where
the announcer heard it from some third party, i.e. the announcer has the
prefix with a non-empty as-path?

I can see how the first recipient of such an announcement could validate
the prefix based on ROA.
How does someone more than one AS away validate using ROAs, if he/she is
not able to know for certain that the sender is also authorized to send
all prefixes for the remote AS (the alleged originator)?
And/or, presumably, there is the ability to authorize an upstream AS to
announce all of one's AS, and that that is a transitive property.
Is the ROA used for this, or is there some other "thing" that is used
for signing/validating?

Now, for a use case:

There are classes of allocations which are made in a very particular
method, which I believe the RIRs would like to have means for
restricting their use.

These are "critical infrastructure" assignments, typically /24's to be
used in a PI fashion, which may be assigned en mass, e.g. from larger
ranges of contiguous space (perhaps by coincidence, but contiguous
nonetheless).
These could show up as a sequence of /23,/22,/23,/24 (for a set of 9
prefixes).
Operators of DNS infrastructure, among others, are critically dependent
on the availability and use of these, and having the ability to trust
routing announcements of these prefixes is of first-order importance to
SIDR, IMNSHO.

In these cases, I believe the RIR would want to issue the ROA itself,
and do so in such a way as to only permit /24's to be announced, and
only by a specific ASN originator. I do not believe the RIR would want
to cede control of the larger blocks, only (at best) the individual /24's.

And, in particular, the RIR would not want the recipient ASN to be able
to "glue together" the contiguous pieces, and certainly not to be able
to assign the glued bits to some third party, especially for money.

If it were technically feasible for a large chunk of "critical
infrastructure" space to be (a) aggregated, and (b) sold on the black
market, it would be bad all-around, for operators of critical
infrastructure, for the RIR, and for the processes involved.

That is one use case. However unlikely the scenarios described, they are
of enough concern for me to document. That at a minimum, I would hope,
is sufficient for the WG to give consideration to the security
considerations involved, and to view the minLength issue from that
perspective.

> personally not inclined to make changes in an attempt to make the
> R-PKI suitable for that purpose. With regards to your second example,
> if the LIR wants to prohibit a an end-user from announcing prefixes
> through another provider (hole punching), then I think the right
> answer is for the LIR NOT to issue a certificate to the end-user (this
> prevents the end-user from issuing ROAs that grant permissions to
> other providers) and instead to issue an appropriate ROA for the
> aggregate prefix (which persumably names the LIR's own AS number).

What about BGP MPLS VPNs? If an ISP gives a chunk of space to a customer
to use on the customer's VPN, and wants to run BGP to the customer for
PE-CE routing, and wants to ensure that the customer only announces
prefixes it is supposed to, and to do the filtering per site, the ISP
would ideally want to issue an ROA, with a longer minLength than the
block itself, but not announce the more-specific to the world. The ISP
would not want to have the customer announce any other prefixes. The ISP
would also want to enforce BCP 38, and would want to filter *packets*
based on RPKI (sidr). How else, other than ROA(s) is this possible?

And what if the customer is so big, that they are the only recipient of
an ROA from a large CIDR block? (Hint - think about large global
organizations like IATA, or various DOD departments).

>
> 2) With regards to format, there was discussion in March in
> Philidelphia which led to the addition of the max-length field. At
> that time, the question was raised as to whether there should also be
> a min-length field and at the time there seemed to be no operator
> requirement for such a field. In particular, to justify a min-length
> field one would need a use-case where a registered holder of IP
> resources wishes to give an AS permission to advertise many long
> prefixes, but expressly forbid the AS from advertising the aggregate
> prefix. Such a use-case seems unlikely because in most cases
> advertising the aggregate prefix does no harm (and indeed will be
> ignored in the presence of advertisements for longer prefixes)
> although I could be missing something.

Not to be too pedantic, but:
The IETF policy is that the mailing list is where things get decided.
Meetings are for useful discussions, and for getting "the sense of the
room".
However, the absence of voices of concern, at a meeting, is not
sufficient reason to discount discussion on technical issues and merits,
on the mailing list.

There are *definitely* cases where advertising the aggregate prefix can
and will do harm.

Consider Bill Manning's /16 for ep.net (exchange point allocations).
Each of those is used as a /24 (or /23 or /22 for big exchanges).
Announcing the aggregate, or any portion thereof, would likely cause
harm, and at a minimum facilitate wide-scale abuse, like pointing
default at peers on an exchange.
It's one example, but far from the only example.

I'd suggest that however unlikely, the presence of a single extra field,
may save someone's bacon somewhere down the road.

I wouldn't want to be counted among those opposing its inclusion, if not
having it caused someone a real operational problem, just because we
couldn't come up with a big enough example at the time.

I'd rather have it included and never get used, than exclude it and
cause a headache for someone.

It's analogous to free speech. I may disagree vehemently with you, but I
will always fight for your ability to express those insipid comments :-)

Brian

---

From: Geoff Huston <[email-masked]>
Date: Wed, 8 Oct 2008 07:41:19 +1100

WG Chair Hat Off

> time, everyone. There's some valuable operator input here.)

Brian when I read your post I was reading it with the following  
example in mind

ROA1
10.0.0.0/16, maxlength=18, 10.1.0.0/16, maxlength=18, EE  
Cert=10.0.0.0/15

and

ROA2
10.0.0.0/15 minlength=16, maxlength=18, EE Cert=10.0.0.0/15

Now as far as I can tell these are equivalent ROAs, yes?

Now what, in your examples could be expressed using ROA1 that chould  
not be expressed using ROA2, and vice versa? The reason why I ask the  
question was that in my readon of your post I saw nothing that helped  
me distinguish between these cases.

regards,

Geoff

---

From: Brian Dickson <[email-masked]>
Date: Tue, 07 Oct 2008 17:02:19 -0400

Geoff Huston wrote:
> 10.0.0.0/16, maxlength=18, 10.1.0.0/16, maxlength=18, EE Cert=10.0.0.0/15
>
> and
>
> ROA2

Yeeeeeees. However, my reading of the drafts suggest that the EE Cert
needs to exactly match the ROA.
Is that the case for ROA1?

> me distinguish between these cases.

For the small example above, there is no difference. But that example
is, in some respects, a "straw man"...

The problem is when you get into things like:

10.0.0.0/16, minlength=24, maxlength=24

or

10.0.0.0/12, minlength=21, maxlength=29

or

2001:foo::/48 minlength=56, maxlength=126

(Enumeration in binary systems doesn't scale well.)

I can think of environments where this kind of thing might be desired,
if not outright required.
MPLS BGP VPNs, or virtual machine environments (EC2), among others.

Even if we're not necessarily designing this for use in anything other
than the DFZ Internet, I don't see strong disincentive to designing
flexibility into the system, to support other uses.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Tue, 07 Oct 2008 17:14:51 -0400

> you offered, but this one seems seriously out of whack. 

I think there are definitely boundary issues on "who owns IP space" that
are very relevant, and very timely.

Yes, I understand that "who owns" the space is "who generates the ROA".

My question is, if the RIR's policy is that the RIR owns the space, not
the ISP, what then?
Nothing in the framework can or should mandate what an RIR does.
(RIRs may take guidance, but are ultimately responsive to their
membership, not the IETF.)

Case in point - the "IP Transfer Policy for IPv4" issue, in the ARIN
region (and likely mirrored in the other RIR regions)...
(You may want to take a look at the ARIN public policy mailing list
archives, if you aren't already on that list.)

The main issue is, if IP space is *fully* under the control of the ISP,
then that ISP can assign the whole block to some third party, e.g. for
money (aka, "sell" or "rent" the block).

Compare that to the model where the RIR *never* gives full control of
the block, but instead signs an ROA with the ISP's ASN listed as being
allowed to originate it, possibly with more-specifics.

It differs from the current model, but then, everything about ROAs
differs from the current model.

So, I don't believe my example is "out of whack" at all, and is
something that might not have been considered, but is definitely an
unresolved and important issue.

Brian

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 07 Oct 2008 17:33:30 -0400

Brian,

Thank you for the feedback, comments are in-line below

>time, everyone. There's some valuable operator input here.)
<snip>

>Is the ROA used for this, or is there some other "thing" that is used
[MBL]: It seems that our documents need to define "originate" more 
clearly. The intended meaning is that the "originating" AS is the one 
who initially injects an advertisement into the routing system (i.e. as 
the term is used in Section 5.1.2 of RFC 4271), and does not refer to an 
AS that receives an advertisement from a peer and forwards the 
advertisement to other peers. I believe this corresponds to the use of 
the "Origin:" attribute in the IRR.

[MBL]: Also let me attempt to be clear as to the problem that ROAs are 
attempting to solve. The use of validated ROAs as an (additional) input 
to the filter generation process allows the prevention of the following 
limited class of attacks: Consider an AS who (perhaps accidently due to 
mis-configuration)  emits a BGP UPDATE message originating a route to a 
prefix to which he is not authorized to originate routes (e.g. an ISP 
operator in Pakistan mistakenly announces a route to a prefix owned by 
youtube.com). Any ISP that receives such an invalid advertisement 
(either directly or by way of a peer who propagates the invalid 
announcement) can use data from validated ROAs to determine that the 
advertisement is invalid.

[MBL]: Note that no one is claiming that the current SIDR work is 
sufficient to prevent all attacks on the routing system. Indeed, as you 
indicate, ROAs alone are insufficient to detect cases where an 
intermediate ISP receives a valid announcement that the ISP is not 
permitted to propagate, but (either maliciously or accidently) prorates 
the announcement anyway. However, the infrastructure being developed by 
SIDR is a necessary first step in creating more comprehensive routing 
security solutions (such as S-BGP or SO-BGP)  which could be used to 
prevent such attacks by intermediaries.

>considerations involved, and to view the minLength issue from that
[MBL]: Thank you for the use case. The problem you raise above is not 
one that I had envisioned that SIDR would solve, however, is there is a 
simple way for the SIDR architecture to be modified to meet additional 
RIR requirements then we should certainly consider such modification. 
What confuses me in this example, however, is how the aggregation of 
"critical infrastructure" space is the problem. If an RIR wishes to 
prevent a party receiving IP resources from transferring those resources 
to another party (e.g. on the black market) then the RIR could in theory 
issue the ROA itself (and not issue a certificate to the party receiving 
the addresses) which allows the RIR to maintain control over which AS's 
can originate routes to the given address space. (Personally, I don't 
know if any RIRs are planning to do this, but it is certainly 
technically possible). On the other hand, if an RIR chooses to issue a 
certificate to a party receiving IP resources then the mechanisms 
specified in SIDR are completely in-capable of preventing the receiving 
party from transferring the resources without the RIR's consent (e.g. on 
the black market) --- And this seems true regardless of whether there is 
a minLength field in a ROA.

>organizations like IATA, or various DOD departments).
[MBL]: This seems like a good example (which hasn't come up in past 
discussions) for us to keep in mind. I don't know whether we can make 
the R-PKI work for MPLS VPNs, but I'd certainly like to do so if it can 
be done with only minor changes to the architecture (e.g. the addition 
of an extra ROA field). I apologize for my ignorance, but f you could be 
a little more specific here, it would help me. In particular, I'm 
confused here as to what is "the block itself" as compared to the 
prefixes that the customer should be advertising.

>sufficient reason to discount discussion on technical issues and merits,
[MBL]: My apologies, I did not mean to say that we should discount 
further discussion of the issue based on what had been said at IETF 72, 
I am only saying that the discussion at IETF 72 led me to personally 
believe that the existence of use-cases necessitating a minLength field 
was unlikely. But I'm happy to continue discussing this issue on the 
list, and it may very well turn out that I was mistaken.

>It's one example, but far from the only example.
[MBL]: It seems to me that in order for minLength to be needed, we'd 
require a case in which an AS was authorized to originate routes to two 
adjacent /24's but it would be harmful if the AS instead initiated a 
route to the aggregate /23. Is this such a case?

>will always fight for your ability to express those insipid comments :-)
[MBL]: Weighing the potential for future operational problems versus the 
added implementation complexity of adding rarely-used features to a 
specification is always challenging (see for example, the other current 
SIDR thread regarding multiple signatures on a ROA). I'm personally 
hesitant to include a feature without understanding the use-cases that 
necessitate such a feature, but others in the working group may 
disagree. Finally, I very much appreciate your feedback, and please do 
not take my response as arguing vehemently against inclusion of a 
minLength field (I'm really just trying to better understand the 
underlying use-cases).

---

From: Geoff Huston <[email-masked]>
Date: Wed, 8 Oct 2008 08:54:58 +1100

WG Chair hat off

> Is that the case for ROA1?

My apologies for the misunderstanging here - in the flurry of mail  
traffic on this list there was the proposal to change the "exactly  
match" text to "encompass"

"Yes, if the text in section 3, step 3 of the draft was altered to use  
the term "encompass" such that the IP addresses prefixes in that  
extension encompasses the IP prefix(es) in the ROA I would agree that  
would be a suitable resolution."

In my head in working through your example I had assumed that this was  
already the case.

(The reasoning here is that EE certs DO have a canonical  
representation, and 10.0.0.0/16, 10.1.0.0/16 must be expressed in a  
canonical form in the cert as 10.0.0.0/15 - for this reason  
"encompass" is a reasonable resolution

> (Enumeration in binary systems doesn't scale well.)

Again, however this is an enumeration issue rather than a difference  
in semantics.

> flexibility into the system, to support other uses.

I'm not arguing for or against this - I'm attempting to understand the  
precise nature of the difference.

Its my understanding so far that the two representations are  
isomorphic - nothing expressible in one notation is inexpressible in  
the other. The only difference _as far as I can see_ lies in the size  
of the ROA in expressing sets of prefixes, and as far as I can see a  
set of conjoined prefixes with the same maximal length constraint  
would have a more compact representation with a min length parameter.  
Or am I missing something still in my understanding of this?

regards,

    Geoff

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Oct 2008 19:00:31 -0400

Brian,

I believe the collection of SIDR documents do a reasonable job 
explaining the underlying assumptions and motivations for the SIDR 
work. Still, we'll revisit them to try to minimize the ambiguities 
you perceive. Nonethelsss, let me summarize:

The RPKI is intended to parallel the address space (and AS #) 
allocation hierarchy, from IANA, to RIRs, to NIRs (where applicable) 
to ISPs (aka LIRs) and PI subscribers, ...

We never talk about "owning" address space, because IANA and the RIRs 
do not use that term. We use the term "resource holder"  to refer to 
an entity who holds address space or AS numbers. The term refers to 
the entity that is recorded in the applicable RIR (or IANA) database 
as the holder of the resource in question.

Thus the resource certificates issued by registries are alternative 
representations of the registry database records, pared down to the 
essential data for the routing security goals of interest. They are 
only part of the overall set of data needed to help improve routing 
security, but they are a critical first step.

Given this model, a ROA is generated by the entity listed as the 
resource holder, because that entity is the one who chooses the 
ISP(s) that originate the route (i.e., is the origin AS in BGP terms) 
for the prefix (ignoring for the moment the issue of route 
aggregation).

A resource holder might ask the RIR (or NIR or ISP) from which a 
resource was allocated to manage the RPKI data on its behalf, but 
that should be done in a fashion that does not make such 
"outsourcing" visible to the relying parties processing RPKI data. 
(Such outsourcing is common for commercial, TTP PKIs as well.) I 
believe that the folks at APNIC and RIPE have indicated that they are 
prepared to provide such services for their members.

There is not an intent that ROAs represent a substantial departure 
from the current model, as you suggest.  The intent is for a resource 
holder be able to use a ROA to identify, in a secure, independently 
verifiable fashion, the identity (in the form of an AS #) of entities 
authorized to originate routes for the prefix. The IRR databases try 
to do this, and more, via RPSL entries, but the security there is not 
as good as what can be achieved via deployment of the RPKI.

Hope this helps.

Steve

---

From: Brian Dickson <[email-masked]>
Date: Tue, 07 Oct 2008 20:05:18 -0400

> Or am I missing something still in my understanding of this?

No, that is it.

(Other than the intrinsic self-documenting nature of the compact
representation, vs the expansion thereof.)

There are subtleties lost when enumeration is the only solution.

My favorite example of succinct and subtle was in Terminator 2:
  "How many cops are there?"
  "All of them, I think."

Brian