Subject: [sidr] Injecting idea of "freshness of repository data" into BGP

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Mar 2012 04:19:39 -0400

Per my mic comment at IETF 83:
During the San Diego interim session we had discussed potentially signaling
in BGP the idea that a given AS may have fresher data available in its
repository. 

My original thought had been something along the lines of a new AFI/SAFI
that contains this data.  Matt L., in discussing this point at the mic with
me, suggested something that has resemblence to the serial number field in
DNS.  For example, this field could go into the "reserved" field that a
route originator puts into the signature.  If the serial number increases,
this could suggest that fresher information is present in that originator's
repository.

Discussion around this mechanism:
- If this is part of a given route's signature block, the issue is that a
  given origin may be seen with a number of serial numbers  depending on
  propagation of BGP routes.
- Such a serial number is important not only for the originator of a route,
  but also all parties participating in the signature.
  This particular details suggests to me that such signaling probably should
  be separate from the signatures.
- By being part of the signature, we get some level of freshness in things
  in a route-by-route basis and less likely that a completely separate
  "route" that is repository freshness is dropped.

-- Jeff

---

From: Terry Manderson <[email-masked]>
Date: Wed, 28 Mar 2012 01:30:03 -0700

Jeff,

> this could suggest that fresher information is present in that originator's

I think this is interesting. I think I would further like an
assessment/disussion of this "serial number" being consistent between the
BGP information, the RPKI repository, and this through the validated cache
and presented to the router via rpki-rtr.

It may well present far too many error situations by doing that, but may
also provide a brilliant statement of a consistent view matching origination
intent in a time and space perspective.

0.02c

---

From: DougM lists <[email-masked]>
Date: Wed, 28 Mar 2012 04:54:11 -0400

I thought John Scudder's belt and suspenders comment was a good one.   
We have looked at some level of detail at both explicit expire times in 
updates and key roll techniques to manage freshness of BGP updates.   
Neither approach is a silver bullet and both have the potential to swamp 
the system with either updates or updates and RPKI data.

Ideas discussed to date of bounding the potential load imposed by either 
single mechanism are imperfect.   Without bounds, either mechanism could 
be abused at the expense of the entire net.

Sandy has called previously for a discussion of the general requirements 
for "the freshness/replay problem".    Assuming we don't want to leave 
the problem half solved (e.g., deal with withdraw suppression as well as 
explicit replay and peering topology changes), the idea of combining 
mechanisms seems to offer an opportunity.

Combining John and Randy's comments  during the discussion .....

Assume we bound the units of expire time to days (for example, choose 
your acceptable background granularity) past epoc.    Assume we express 
bounds that components MUST support at least two pre-published keys per  
router/AS.

Emergency or topology driven key roll at the router, works at speed of 
BGP convergence.   Day based expire times catch those freshness problems 
that can't be addressed by router key roll.

Some bounds are necessary to prevent / discourage me from pre-publishing 
vast number of router keys signed with very short lived certificates 
..... i.e., I can churn the system just as bad with frequent key rolls 
on routers.

Anyway, combining the two mechanisms would give us a reactive system 
(router key roll) along with a background system that covers the rest of 
the threat space.

I think that was John's point.
dougm

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Mar 2012 04:57:03 -0400

> and presented to the router via rpki-rtr.

Would it be sufficient to put have the latest manifestNumber (from RFC 6486)
be distributed as a single "route" signed using the normal BGPSEC
procedures?

With my usual apologies, I'm less clear on whether it's likely there will be
more than one manifest on a per AS basis.

-- Jeff

---

From: Danny McPherson <[email-masked]>
Date: Wed, 28 Mar 2012 21:02:24 -0400

> in BGP the idea that a given AS may have fresher data available in its

Shouldn't this problem be solved in the resource certification infrastructure (i.e., RPKI) - signaling RPKI freshness in BGP and distributing to literally millions of routers seems like a REALLY bad idea to me.

-danny

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 29 Mar 2012 06:46:54 +0000

Speaking as regular ol' member.

Too bad you couldn't make the meeting, Danny.

This is in bgpsec path validation and the signalling would go no further than the bgpsec path validation would go.

A method of "signalling" that was mentioned was the validity periods on the router keys so all RPKI info needed would already be available.  Other means were also discussed, no decision made.

--Sandy, regular ol' member

________________________________________
From: [email-masked] [[email-masked]] on behalf of Danny McPherson [[email-masked]]
Sent: Wednesday, March 28, 2012 9:02 PM
To: sidr wg list
Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP

-danny

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Mar 2012 03:22:36 -0400

> Shouldn't this problem be solved in the resource certification infrastructure (i.e., RPKI) - signaling RPKI freshness in BGP and distributing to literally millions of routers seems like a REALLY ba…

One "route" per AS in the system which is a 20byte value max (per the cert)
hardly seems that scary. :-)

But that said, I don't object to some sort of mechanism used as part of the
RPKI infra would do such a "you may want to refresh" request.  My thought is
that since the certs in question are required for validation, the routing
system already has a strong interest in making sure downstreams can validate
(or invalidate!) routes.

-- Jeff

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 29 Mar 2012 03:51:10 -0400

Could we not put a freshness indication into the BGP update?
Then everyone that receives the new update would know to invalidate the less fresh paths.

Here is the key point:
The new update will reach everywhere that it needs to go.
Won't it?

No expiry time needed.

--
Jakob Heitz.

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 29 Mar 2012 03:58:38 -0400

Any place that does not receive a new BGP update can not be helped. Even with a beacon.
Therefore, a freshness indicator in the BGP update itself is enough to invalidate less fresh updates.

Only freshen the BGP update when you actually have a dispute with your old provider.

--
Jakob Heitz.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Mar 2012 04:16:25 -0400

Jakob,

> Then everyone that receives the new update would know to invalidate the less fresh paths.

Just to be clear, this is not a route freshness mechanism I am
recommending.  What I am recommending is a signal that a repository has
newer data that may be needed for validation.

Given such a mechanism, we may be able to reduce the work upon the
repository mirroring system (distributed or not) by not having to regularly
poll for new objects frequently unless the repository indicates there is new
data present.

-- Jeff

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Mar 2012 04:24:46 -0400

> newer data that may be needed for validation.

the comment at the mic from Mr Hoffman was interesting to me,
potentially signalling via something akin to RSS/Atom, something light
weight and simple.

-chris

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 29 Mar 2012 10:43:16 +0200

> potentially signalling via something akin to RSS/Atom, something light

update frequency is in either case the product of the polling interval.
if you want to not be dependant on a polling interval one could choose a
signaled rather than polled approach.

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Mar 2012 13:41:23 +0200

> recommending.  What I am recommending is a signal that a repository
> has newer data that may be needed for validation.

Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides such
a mechanism

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Mar 2012 07:57:14 -0400

Randy,

> Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides such

Not what I'm talking about.

What notifies a cache that it needs to fetch new objects from a RPKI
repository?  As best I understood, it's largely done on cron jobs now.

I could readily see a BGP signaled "This AS has a manifest with a newer
serial number" being passed back to rpki-rtr so that it could kick off
rsync (or whatever).

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Mar 2012 14:01:24 +0200

>> Serial Notify, sec 5.2 of draft-ietf-sidr-rpki-rtr-26.txt, provides
>> such a mechanism

ahh.  yes.  if we do a next-gen rpki flooding mechanism, that would be a
good addition.

> I could readily see a BGP signaled "This AS has a manifest with a
> newer serial number" being passed back to rpki-rtr so that it could
> kick off rsync (or whatever).

to a bgp hacker everything looks like a nail, eh?  how about a sip
notification?  :)

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 29 Mar 2012 08:18:24 -0400

> ahh.  yes.  if we do a next-gen rpki flooding mechanism, that would be a

Agreed.  It certainly belongs in there.

> to a bgp hacker everything looks like a nail, eh?  how about a sip

Just a minor correction: To a BGP hacker, every solution looks like a baby
seal.

If you'd like to do the distribution of bgp path security state in SIP, I'm
happy to review the document.  There's at least 2 days before it'd need to
be published.

-- Jeff

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Mar 2012 16:06:08 +0200

just a note at the high level

  o anyone who thinks rsync is not gonna do well for the scaling we are
    likely to see in the next year+ is smoking some strong optimism.
    we're only at 5k objects today, three months into the game.

  o but we do not know the long term scaling characteristics of the
    current rsync scheme.  http etc are not likely to scale any better.

  o we could get much better rsync performance with a trivial change at
    the rirs.

  o we are currently constructing some measurement experiments.  on the
    order of 500k to 1m roas.  we need some points on the curve not bs
    and fud in powerpoint.

  o we are already playing with a bittorrent experiment for a number of
    reasons, mainly because its model is so different.  you have seen
    the initial results.  the code is open.

  o but we are suspicions and curious creatures, so folk are already
    discussing mechanisms for v2, mechanism agility, ...  to be deployed
    in a year or three.

we now return you to the ppt and fud channel of your choice.  but i am
sure the channel will be transported over dns and bgp. :)

randy

---

From: Andrew Lange <[email-masked]>
Date: Thu, 29 Mar 2012 07:14:49 -0700

> ahh.  yes.  if we do a next-gen rpki flooding mechanism, that would be a

What about an XMPP-based PUSH service?  The local cache can subscribe, and get info pushed when it comes out (modulo a small delay). 

Andrew

---

From: "Danny McPherson" <[email-masked]>
Date: Thu, 29 Mar 2012 10:23:54 -0400 (EDT)

>     current rsync scheme.

While we may not know the scaling characteristics of the solution, do we
at least know what would be a desirable objective target for sustainable
deployment?

>     the rids.

Does "much better" accommodate our desired engineering targets for
long-term?  What are those?

>     the initial results.  the code is open.

Twitter may be more real-time (only half kidding :-)

>     discussing mechanisms for v2, mechanism agility, ...  to be deployed

Again, if we're engineering here for the future and stable standards then
what are the desirable long-term system scale objectives for the RPKI?  I
think this is a pretty reasonable question - when this is fully deployed
in n years, whatever the timeline is, what do you believe will be the
number of objects (CRLs, EEs, ROAs, Manifests, size, etc..), RPs,
frequency of updates, etc.., given the operational and design experience
you have thus far?

While I suspect some clever response here, I'm being sincere with these
questions, particularly if we're baking this stuff into standards track
protocols.

Thanks,

-danny

---

From: DougM lists <[email-masked]>
Date: Thu, 29 Mar 2012 11:08:03 -0400

>  Any place that does not receive a new BGP update can not be helped.

Just to be clear, the explicit expire time approach to freshness does 
work to age-out updates along a update path that is no longer 
bgp-reachable from the origin.    It is the only technique that will 
help all withdrawl suppression, etc scenarios.

That is a slightly different point than this thread (how to indicate 
that a router has updated RPKI state).  But if you were doing origin 
beacons like the -01 draft, you may not need to do this.

Actually from the belt-and-suspenders approach discussed yesterday 
(combining coarse beaconing with pre-staging two rtr keys and doing 
faster paced roll) ... what we need to do is expedite / trigger CRL 
retrievalal / processing (of router old key).

The important part of a key roll, is invalidating the old key.   We 
can't pre-stage the CRL, so while we can move to the new key at the 
speed of BGP convergence, we can only revoke the old key at the speed of 
RPKI publication, data distribution, and cache-to-rtr.

Frankly if we limited the granularity of the beacon to days, I suspect 
that will be faster than the global CRL pipeline.

dougm

>  -- Jakob Heitz.
> > Could we not put a freshness indication into the BGP update? Then
> > everyone that receives the new update would know to invalidate the
> > less fresh paths.
> >
> > Here is the key point: The new update will reach everywhere that it
> > needs to go. Won't it?
> >
> > No expiry time needed.
> >
> > -- Jakob Heitz. _______________________________________________
> > sidr mailing list [email-masked]
>  _______________________________________________ sidr mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/sidr

---

From: Andy Newton <[email-masked]>
Date: Fri, 30 Mar 2012 08:53:49 +0000

>  o we could get much better rsync performance with a trivial change at

I've learned that little related to the RPKI is trivial.

Is the actual issue observed with rsync documented anywhere, along with a more descriptive solution? I think I understand what is being asked, but it would be best to have clarity before making changes.

Also, the presentation given at SIDR and IEPG indicated the study was done with only one RPKI validator. We have all three running in our lab and have noticed differences in speed over a local network with the same repository. Before declaring the problem a universal issue with rsync, wouldn't a test with the other validators provide helpful data points?

-andy

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 30 Mar 2012 05:44:21 -0400

> Also, the presentation given at SIDR and IEPG indicated the study was done with only one RPKI validator. We have all three running in our lab and have noticed differences in speed over a local netw…

is there a way to run all three from many points on the network and
gather useful stats to graph/history/etc? (is this sort of thing a
good idea? watching/storing/analyzing performance over history I mean)

---

From: Arturo Servin <[email-masked]>
Date: Fri, 30 Mar 2012 12:14:21 +0200

> good idea? watching/storing/analyzing performance over history I mean)

	I think there is a way and it is a very good idea. We just need some CPU donations.

	I think some RIRs are willing to support the idea and to do some cross monitoring (but just speaking for myself). 

Regards,
.as

---

From: Matthias Waehlisch <[email-masked]>
Date: Fri, 30 Mar 2012 12:53:14 +0200

On Fri, 30 Mar 2012, Arturo Servin wrote:

> >> Also, the presentation given at SIDR and IEPG indicated the study 
> >> was done with only one RPKI validator. We have all three running in 
> >> our lab and have noticed differences in speed over a local network 
> >> with the same repository. Before declaring the problem a universal 
> >> issue with rsync, wouldn't a test with the other validators provide 
> >> helpful data points?
> >> 
> 	I think some RIRs are willing to support the idea and to do some 
> cross monitoring (but just speaking for myself).
> 
  we already run Rob's validator and RIPE NCC Validator (located in 
Germany, connected via German NREN); BBN for testing purposes. We are 
open to activate performance stats. Let me know.

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Danny McPherson <[email-masked]>
Date: Fri, 30 Mar 2012 11:26:47 -0400

> poll for new objects frequently unless the repository indicates there is new

And again, why would this not be done in the repository system (RPKI)?  It does NOT belong in the routing system.

-danny