Subject: [Sidr] SIDR Confusion

From: Danny McPherson <[email-masked]>
Date: Tue, 11 Mar 2008 07:57:13 -0600

So, one of my concerns with SIDR and it's current scope
is this, which I'd very much like some clue about...

Today RIRs allocate address space and AS numbers but
have NO controls over the routing system.  IRRs are used
for routing policy specification, and ideally, data in IRRs is
used to derive router configuration elements.

If SIDR is deployed in some manner, RIRs (and possibly
IANA) would have the ability to control what gets routed, and
that's a capability that's never existed before, and one that I
would suspect operators take considerable issue with.

For example, if operators subscribe to a SIDR model and an
RIR gets owned and an allocation revoked, or if they happen
to make a mistake that results in the same, or some bill non-
payment issue arises, or can't publish an update and one
expires, or whatever, then the result would be that the
associated routing for the concerned prefixes would break.
That's never been a threat vector before for ISPs.  They
wholly control and authorize what they announce.

What's worse is regarding who holds those keys.  If some
country holding the keys (TA) goes to war with another and
decides they want to revoke all of their allocations, then ISPs
would have zero control over this outside of their own routing
domain.

One might argue this is part of the reason why DNSSEC
raises deployment concerns for some, and has driven folks
like .cn to deploy their own root.

In my mind, a web of trust model for the routing system better
mirrors what we've got today.  Allocation authentication is
necessary, but just that.  IRRs and RPSL or even some back
end route server type functions down the road, else we'll
never get deployment of this.

So, I'm sure suspect I'm missing something here, could folks
please help me better understand both incremental deployment
models and how the above isn't an issue?

Thanks!

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 Mar 2008 10:10:46 -0400

> models and how the above isn't an issue?

Multiple trust anchors and multiple ROAs.

The current ROA model, presuming I'm not misinterpreting the PKI in the
drafts, only lets you trace your trust path up one chain.  While it'd be
nice to trace the trust path to multiple trust anchors from a single
ROA, I suspect that the way these ROAs are built wouldn't permit this.

See sec 2.4 of the architecture document.

-- Jeff

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Mar 2008 16:19:06 +0200 (EET)

> See sec 2.4 of the architecture document.

So, instead of using just RIRs as trust anchors, you add every other 
ISP on the planet as a trust anchor as well (or at least tier1 ISPs 
and those tier2's which connect to tier1's that don't support RPKI)?

Or are you proposing a model where other RIRs or some (currently 
non-existing from IP addressing perspecive) third parties would be 
doing additional ROA signing to get this single point of failure?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Mar 2008 11:07:59 -0400

Danny,

The response from Pekka is essentially correct.

SIDR decided to issue certs based on the resource allocation 
hierarchy, because that hierarchy is authoritative for resource 
allocation, and it requires no introduction of new trust points re 
attesting to resource allocations (consistent with the RPSEC 
requirements doc).  Each ISP is a relying party in this PKI and, as 
in every PKI, each RP is empowered to select it own set of trust 
anchors. Thus ISPs can choose to recognize one another as TAs, in 
lieu of the default TAs. You can approximate a web of trust model in 
this fashion, though it is not an exact mapping since X.509 certs do 
not accommodate multiple signatures. The technical term for the PKI 
structure you can achieve is a "mesh."

The proposal for dealing with stale data (as reflected in the 
manifest I-D) is to continue to use what you have. Thus the concerns 
you cite about what happens if anyone (IR or ISP) fails to publish 
data are not all valid ones. It is fair to note that new or changed 
data that is not published, or that is not fetched in a timely 
fashion, could cause ISPs to reject routes based on such changes. 
Unfortunately, without making change to BGP to carry such data, or 
providing some parallel distribution mechanism that is similarly 
timely, ...

Steve

---

From: Danny McPherson <[email-masked]>
Date: Tue, 11 Mar 2008 11:29:15 -0600

> providing some parallel distribution mechanism that is similarly  

So to be clear, I didn't intend to propose a web of trust model,  
although
after rereading my text from earlier, my point wasn't clear.  I  was  
simply
pointing out that with a model such as what's currently proposed RIRs
would have a VERY operational role and some authority about what gets
routed and what does not.  This is a fundamental change from how things
work today, where things more approximate a web of trust model - if
any.

-danny

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 11 Mar 2008 14:00:27 -0400 (Eastern Daylight Time)

> work today, where things more approximate a web of trust model - if

I understand that the effect of RIRs on routing will be more apparent, but 
I don't understand saying they have no impact today.

For RIRs whose database is a comingled resource and routing database 
(e.g., RIPE), a billing dispute can effect the RIPE IRR which many people 
use in routing operations.  And the whois is also frequently consulted in 
making routing decisions.

And in any RIR, problems at the RIR level could lead to retraction of your 
prefix allocation and assignment to someone else.  (Recall the social 
engineering prefix hijacking of a few years back.)  That sounds to me like 
a pretty severe impact on what gets routed.

So this might look new, but I don't see that the risk is larger.

Of course, there's always the "the relying parties choose what importance 
to place on the RPKI" caveat.

--Sandy

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 Mar 2008 14:19:57 -0400

> to place on the RPKI" caveat.

Not to mention it's influence on one's "security metric".

(Fake config to drive point.)

route-map set-security-pref 10
  match ta-map bad-rir
  set security-pref 1000
  exit
route-map set-security-pref 20
  # Default
  set security-pref 10
  exit

This stuff will undoubtedly influence route selection.  Just like
everything else that affects route selection, there will be knobs.  This
doesn't worry me.

-- Jeff

---

From: Danny McPherson <[email-masked]>
Date: Tue, 11 Mar 2008 12:32:29 -0600

> everything else that affects route selection, there will be knobs.   

I would note that today policies are only applied when a route is
processed upon receipt, not when the policy alone is modified.
Therefore, modification of such a policy would require the associated
route announcement to be re-advertised (either via BGP route refresh
or more memory consuming soft reconfiguration functions, or by reseting
a session or actually bouncing the route itself).  I.e., changes in  
status
from good to bad based on policy would require re-announcement of
the prefix in question if not performed by a security extension to BGP
itself.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Tue, 11 Mar 2008 12:39:27 -0600

On Mar 11, 2008, at 12:00 PM, Sandra Murphy wrote:

>
> I understand that the effect of RIRs on routing will be more  
> apparent, but I don't understand saying they have no impact today.

They don't actually 'route' anything.

> (e.g., RIPE),

That's different, that's IRRs, not RIRs.

> a billing dispute can effect the RIPE IRR which many people use in  
> routing operations.  And the whois is also frequently consulted in  

What?  Can you explain what you mean hear?  Do you mean someone
looks at whois before annoucning a route?  That's WAY different than an
RIR revoking an allocation and explicitly triggering a withdraw from the
routing system.

> And in any RIR, problems at the RIR level could lead to retraction  
> of your prefix allocation and assignment to someone else.  (Recall  
> the social engineering prefix hijacking of a few years back.)  That  
> sounds to me like a pretty severe impact on what gets routed.

Yeah, now imagine when operators have no control over this, the attack
surface just gained a new dimension.  But I would state that today that
system flow is not automated.

> So this might look new, but I don't see that the risk is larger.

Build a threat matrix and add an RIR that now has revocation  
capabilities
that explicitly impact global reachability of a given prefix.  That  
does NOT
exist today.

> Of course, there's always the "the relying parties choose what  
> importance to place on the RPKI" caveat.

Yes, but what's changed is that peers are now relying on it as well,
and therefore may not accept my routes.  That's never been in the
mix before.

-danny

---

From: Shane Amante <[email-masked]>
Date: Tue, 11 Mar 2008 12:48:19 -0600

Sandy,

> making routing decisions.

I think you may be confusing "registration services", (e.g.: acquiring & 
registering PI space and/or ASN's), vs. IRR -- Internet Routing 
Registries.  The IRR's directly affect routing policy on ISP networks, 
because SP's build prefix, etc. filters off them.  And, nearly all IRR's 
are *free* to the public, specifically: ARIN, RIPE (according to info 
publicly available on their Web sites) ... even Level 3.  Thus, 
non-payment for "registration services" (not IRR services) is going to 
have little to no impact on routing policy on provider's networks.

If my understanding is correct, the model being discussed here is 
dramatically different than the way that IRR's are operated & used today.

-shane

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Mar 2008 16:40:17 -0400

At 11:29 AM -0600 3/11/08, Danny McPherson wrote:
>>manifest I-D) is to continue to use what you have. Thus the 
>>concerns you cite about what happens if anyone (IR or ISP) fails to 
>>publish data are not all valid ones. It is fair to note that new or 
>>changed data that is not published, or that is not fetched in a 
>>timely fashion, could cause ISPs to reject routes based on such 
>>changes. Unfortunately, without making change to BGP to carry such 
>>data, or providing some parallel distribution mechanism that is 
>>similarly timely, ...
>
>So to be clear, I didn't intend to propose a web of trust model, although
>after rereading my text from earlier, my point wasn't clear.  I  was simply

Danny,

OK, thanks for the clarification.

if nobody checks announcements against any reference(s), then the 
system can be very responsive, but also vulnerable. I am told that 
some set of ISPs download IRR data from multiple sources, on a daily 
basis, and use that data in constructing router filters. For those 
ISPs, route object info changes that are missed in a periodic 
download can result in the sort of problems you cite. For the ISPs 
who adopt this model, this appears to be an acceptable, if imperfect, 
tradeoff. Nobody can mandate that all ISPs make use of ROA, BOA, and 
other data that will become available from the SIDR work. If enough 
folks find it useful, them presumably it will be used, otherwise not. 
Also, the static distribution of info via a repository system is not 
the ultimate goal of the SIDR work, just the starting point.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 11 Mar 2008 17:13:41 -0400 (Eastern Daylight Time)

On Tue, 11 Mar 2008, Shane Amante wrote:

>> For RIRs whose database is a comingled resource and routing database (e.g., 
>> RIPE), a billing dispute can effect the RIPE IRR which many people use in 
>> routing operations.  And the whois is also frequently consulted in making 
>> routing decisions.
>
> registering PI space and/or ASN's), vs. IRR -- Internet Routing Registries. 
> The IRR's directly affect routing policy on ISP networks, because SP's build 
> prefix, etc. filters off them.  And, nearly all IRR's are *free* to the 
> public, specifically: ARIN, RIPE (according to info publicly available on 
> their Web sites) ... even Level 3.  Thus, non-payment for "registration 
> services" (not IRR services) is going to have little to no impact on routing 
> policy on provider's networks.
>

I understand the difference.

However, ARIN looks to see if the registrant of a inetnum in their IRR is 
the same person as the POC for the allocated resource, as the 
authorization to register the inetnum.  So I have extrapolated from there 
to the belief that if they yank your resource they would yank the 
associated inetnum.  (If they didn't, it would be a bad thing that should 
be fixed.)

And RIPE has a co-mingled registry/routing policy database.  Their 
representation of a registry allocation of space is the inetnum (as I 
understand their database).  So yanking an address means the inetnum 
disappears in RIPE as well.  (Again, if they didn't, it would be a bad 
thing that you would want them to fix, yes?)

And that has got to effect routing policies somewhere.

Of course, there are the individual ISP's IRRs and the RADB etc.  Which 
have no authentication/authorization model at all much less one based on 
the registry allocation of resources.  And yet people use them, go figure.

--Sandy