Subject: [sidr] Clarifying question ...

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Mar 2011 10:51:29 +0200

Hi,

If I am not mistaken there was a Randy's comment today at the mic 
indicating that an AS may consider a path origin validation as INVALID 
as compared to the peering AS just because the "RPKI may not be 
synchronized"

Is this at all possible ? Doesn't RPKI already have been enhanced 
sufficiently to avoid mis-detections even in the AS migration cases ?

Otherwise if this is a valid comment and if due to issues with RPKI sync 
ASes will even transiently be subject to wrong classifications of 
legitimate incoming paths I think there is a much bigger issue to worry 
about.

Many thx,
R.

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Mar 2011 10:56:25 +0200

> sufficiently to avoid mis-detections even in the AS migration cases ?

you may find the first para of section 6 of draft-ietf-sidr-origin-ops
useful.  to save you actually reading the draft

   Like the DNS, the global RPKI presents only a loosely consistent
   view, depending on timing, updating, fetching, etc.  Thus, one cache
   or router may have different data about a particular prefix than
   another cache or router.  There is no 'fix' for this, it is the
   nature of distributed data with distributed caches.

rany

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Mar 2011 11:02:07 +0200

Hi,

Having different data is obvious. I am not saying this is a problem.

Having data in one cache which will invalidate a valid prefix due to 
loose consistency is a problem. It has been pointed to Alvaro that he 
may indicate prefix as INVALID due to this reason.

Thx,
R..

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Mar 2011 11:09:29 +0200

> may indicate prefix as INVALID due to this reason.

which people at the mic tried to point out in response to the signaling
preso.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Mar 2011 11:11:02 +0200

> may indicate prefix as INVALID due to this reason.

or, to put it another way, this is what russ housley was trying to tell
you.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Mar 2011 11:20:49 +0200

It seems you are confirming that RPKI origin validation may very well 
turn Internet into a swiss cheese with transient short lived holes in it.

I am not sure if this is an expected and well known issue by all parties.

R.

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Mar 2011 11:33:50 +0200

> turn Internet into a swiss cheese with transient short lived holes in

no, it will maintain the bgp swiss cheese.  i have a tee shirt which
says "bgp never really converges."

and this is a slight to the swiss, who have many wonderful cheeses

randy

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 31 Mar 2011 11:43:20 +0200

> says "bgp never really converges."

this also seems (to me) to imply that 'invalid == drop' policy is
global, no? I suspect for a great long while 'invalid == lowered pref'
will predominate. Hopefully when we get more comfortable and more
reasonable with operations of the rPKI we'll have less cheese to deal
with.

-chris
(no chair clothing on)

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Mar 2011 11:49:00 +0200

> reasonable with operations of the rPKI we'll have less cheese to deal

this was my original position, but [other] operators whacked me out of
it.  essentially the argument is, if you're not gonna drop something
that is clearly invalid, then why the heck run it?

and the rpki having all the consistency problems of a widely distributed
database is not related to, or effected by, incremental deployment.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 31 Mar 2011 13:14:51 +0200

> that is clearly invalid, then why the heck run it?

I may have 2 routes, which one is better? given all things equal i'd
prefer 'valid' over 'invalid' origins. I'd even prefer a
longer-as-path-valid-origin over short-as-path-invalid.

I don't want to shut the door completely, I like having a choice.

> database is not related to, or effected by, incremental deployment.

ok

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Mar 2011 13:21:34 +0200

> I don't want to shut the door completely, I like having a choice.

you have the choice.  i hope all my customers accept invalid routes

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Mar 2011 13:22:27 +0200

[ let's try again ]

> I don't want to shut the door completely, I like having a choice.

you have the choice.  i hope all my competitors accept invalid routes

randy

---

From: Doug Montgomery <[email-masked]>
Date: Thu, 31 Mar 2011 07:46:31 -0400

On 3/31/11 4:51 AM, Robert Raszuk wrote:
> Otherwise if this is a valid comment and if due to issues with RPKI 
> sync ASes will even transiently be subject to wrong classifications of 
> legitimate incoming paths I think there is a much bigger issue to 
> worry about.
>
> Many thx,
> R.

If you think about the concatenated timing cycles of RPKI repository 
publication, polling intervals of validating caches, and notification 
intervals between caches and routers it is clear there will be 
(hopefully transient) incidents of RPKI state  skew across the global 
net ... and in particular in the context of this draft, two neighboring 
eBGP speakers.  Of course, beyond the timing effects of normal 
operations, reboots etc of routers/cache's/repositories could also cause 
these transients.

When A sends and announcement to B, that B thinks has an invalid origin, 
it is not clear if it is A or B who has a stale view of the global RPKI 
(maybe A has not rsync'ed a recent CRL) or maybe they have a consistent 
view, it is just the case  that A implements a policy that does not 
preclude selection of routes with invalid origins (e.g., it implements a 
preference for valid origins vs a policy that ignores invalid routes).

While I am very supportive of the need for new diagnostics for BGP 
routing w/ ROA/RPKI processing there are some details of the draft that 
need some clarification.

1. As was pointed out at the mic, there is no way in the protocol to 
know if your  peer has even tried to implement RPKI/ROA validation.  
While one could question if they would implement this new capability 
before they implemented ROA processing, you should address (a) if you 
will blindly send these messages to such a router, or (b) have some way 
of using the query feature to decide if you should bother your neighbor 
with these.

2. In the early days one might expect a few valid origins and ~300,000 
unknows.  While you note rate limiting these, one might recommend the 
ability to choose which validation codes you send diagnostics for.

3. The ROA validation drafts recognize 3 potential results - valid, 
invalid, unknown.  Seems like your Method 1  validity codes should 
follow this.

4. It is not clear that routers that follow the rpki/rtr model (i.e., 
don't have a full RPKI cache, but instead just a white list) will have 
enough information to emit the reason codes specified for method 1 
validity code 2 (i.e., invalid).

dougm

---

From: CAUCHIE Grégory <[email-masked]>
Date: Thu, 31 Mar 2011 13:49:55 +0200

> you have the choice.  i hope all my competitors accept invalid routes
As a provider I have the same point of view as Randy. But then when we 
talk about first deployments, it can be harmful to reject UPDATE 
messages because there is some problem with the signature of the prefix 
in a legitimate announcement.
That's where the draft on security state diagnostic message by Alvaro 
and Robert can be interesting in debugging such cases. However, I will 
tend to limit the scope of such messages only to information pertaining 
to the neighbouring AS (ie the prefixes it originates and maybe in the 
future the AS_PATH its has signed, and not the prefixes signed by a 
5-hop-far AS).

Greg

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Mar 2011 13:58:43 +0200

Hi Grégory,

 > tend to limit the scope of such messages only to information
 > pertaining to the neighbouring AS (ie the prefixes it originates
 > and maybe in the future the AS_PATH its has signed, and not the
 > prefixes signed by a 5-hop-far AS).

This is actually a very useful idea reg the scoping of what given peer 
should get as part of this diagnostic message.

We will incorporate this to make sure that implementations do allow to 
configure such scope.

Many thx,
R.

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