On 2013-04-01 20:31, John Curran wrote:
Indeed, there will be some that see RPKI as a possible new approach
for such matters. The registry needs to be consistent (i.e. across
registration data, Whois publication, and RPKI publication) and we'll
certainly seek to prevent RPKI-specific actions
On Apr 2, 2013, at 9:53 AM, Danny McPherson da...@tcb.net wrote:
Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's status on
getting to a single trust anchor?
I believe that ICANN and the RIR technical staffs are busy trying to
document a proposed structure and operation to
John,
See below.
On Apr 2, 2013, at 8:26 AM, John Curran jcur...@arin.net wrote:
On Apr 2, 2013, at 9:53 AM, Danny McPherson da...@tcb.net wrote:
[--snip--]
Yeah, they were nonsensical in the past and present role of ARIN, not in an
RPKI-enabled world where revocation or transfer or
On Apr 2, 2013, at 10:53 AM, Shane Amante sh...@castlepoint.net
wrote:
You keep repeating that assertion, but note that even in today's world
we could be ordered to reclaim and reassign a block with similar effect.
It may not be real time but there are plenty of folks who follow both
the
On 2013-04-02 09:30, John Curran wrote:
Indeed. Of course, that same outcome can effectively be had today
(for any
given IP address block) via one handful of court orders directed to
the larger
ISP backbones.
Assuming those backbones operate within jurisdictional or MLAT reach,
as
On 2013-04-02 08:26, John Curran wrote:
On Apr 2, 2013, at 9:53 AM, Danny McPherson da...@tcb.net wrote:
Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's
status on getting to a single trust anchor?
I believe that ICANN and the RIR technical staffs are busy trying to
On Apr 2, 2013, at 9:58 AM, Danny McPherson da...@tcb.net wrote:
On 2013-04-02 09:30, John Curran wrote:
Indeed. Of course, that same outcome can effectively be had today (for any
given IP address block) via one handful of court orders directed to the
larger
ISP backbones.
Assuming
On Apr 2, 2013, at 12:27 PM, Shane Amante sh...@castlepoint.net wrote:
IMO, there is still one key difference. ISP's are _directly_ involved in
receiving such orders, evaluating them for validity, applicability and then
carrying them out. This can also include providing a heads-up to
Danny,
The architecture permits overlapping allocations to accommodate
transfers that involve address space that
is in use. I've been told by several operators that, for this sort of
transfer, such overlap
is required.
Steve
On 4/2/13 12:02 PM, Danny McPherson wrote:
...
As for today, the
Shane,
As one operator whose worldwide routing/operations could be negatively
impacted by the above, it would be nice to have a concise statement
about what is/was the original intent of the design of the RPKI with
respect to the above. In addition, it would be useful to see if any
potential
On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent k...@bbn.com wrote:
Danny,
The architecture permits overlapping allocations to accommodate transfers
that involve address space that
is in use. I've been told by several operators that, for this sort of
transfer, such overlap
is required.
Shane,
IMO, there is still one key difference. ISP's are _directly_ involved in receiving such orders,
evaluating them for validity, applicability and then carrying them out. This can also include
providing a heads-up to operations teams, in that SP, that a change in configuration to effect
Sharon,
...
Nonetheless, all of the methods for whacking a ROA described in the
paper
are detectable by anyone who monitors the RPKI. One might argue that
each
resource holder should monitor his/her RPKI pub point to detect any
action
that causes one's ROA to become unverifiable.
We
Chris,
Yes, the example you provided matches what I had in mind.
Steve
-
On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent k...@bbn.com
mailto:k...@bbn.com wrote:
Danny,
The architecture permits overlapping allocations to accommodate
transfers that involve address space that
is
John,
On Apr 2, 2013, at 11:22 AM, John Curran jcur...@arin.net wrote:
On Apr 2, 2013, at 12:27 PM, Shane Amante sh...@castlepoint.net wrote:
IMO, there is still one key difference. ISP's are _directly_ involved in
receiving such orders, evaluating them for validity, applicability and then
Danny,
No, I didn't realize you were referring to the current multi-TA environment.
I thought that John Curran was alluding to plans to create an ICANN-managed
global TA, which is why I didn't realize the context you had in mind.
Steve
--
On 4/2/13 3:20 PM, Danny McPherson wrote:
On
On Apr 2, 2013, at 2:59 PM, Shane Amante sh...@castlepoint.net wrote:
So, in the future of the RPKI, as a resource holder, how am I able to shop
around as per the above, to mitigate one or more of the concerns that I've
illustrated above? Hint: given the, at present, limited number of RIR's
Steve,
Thanks for your careful reading of our report. We have some questions for
you inline:
-- We show that it is possible to revoke a ROA surreptitiously,
through methods other than (the obvious) revocation lists. See Section
2.2.1 of the report.
The terminology above is not quite
On 2013-04-01 10:17, Sharon Goldberg wrote:
So, if we suppose that prefixes directly allocated by the RIRs are
given their own resource certs, we see that these resource certs can
whack ROAs for ASes in multiple countries. (Look at 8/8 or 12/8, for
example.) How would takedowns play out if
On Apr 1, 2013, at 12:17 PM, Sharon Goldberg gol...@cs.bu.edu wrote:
snip
Nonetheless, all of the methods for whacking a ROA described in the paper
are detectable by anyone who monitors the RPKI. One might argue that each
resource holder should monitor his/her RPKI pub point to detect
On Apr 1, 2013, at 2:03 PM, Danny McPherson da...@tcb.net wrote:
On 2013-04-01 10:17, Sharon Goldberg wrote:
So, if we suppose that prefixes directly allocated by the RIRs are
given their own resource certs, we see that these resource certs can
whack ROAs for ASes in multiple countries.
On 2013-04-01 14:37, John Curran wrote:
The present equivalent for the RIRs would be LEO's engaging in orders
to change the address holder associated with an IP block, and I am
happy to say that (at least in ARIN's case) that we have not seen any
such requests to date.
That's intuitive given
On Apr 1, 2013, at 7:24 PM, Danny McPherson da...@tcb.net wrote:
On 2013-04-01 14:37, John Curran wrote:
The present equivalent for the RIRs would be LEO's engaging in orders
to change the address holder associated with an IP block, and I am
happy to say that (at least in ARIN's case) that
On Apr 1, 2013, at 10:17 AM, Sharon Goldberg gol...@cs.bu.edu wrote:
[--snip--]
As above, the actions described in these sections are all easily detectable
by the targeted entity. So, the question is what that entity would/could do
if
it detects this sort of activity by its parent (or
Sharon,
-- We show that it is possible to revoke a ROA surreptitiously,
through methods other than (the obvious) revocation lists. See Section
2.2.1 of the report.
The terminology above is not quite correct, since only one of the five
methods results in revocation per se. I suggest using the
Nonetheless, all of the methods for whacking a ROA described in the
paper are detectable by anyone who monitors the RPKI. One might argue
that each resource holder should monitor his/her RPKI pub point to
detect any action that causes one's ROA to become unverifiable.
thanks to shane for
On Mar 20, 2013, at 7:32 PM, Arturo Servin arturo.ser...@gmail.com wrote:
On 20/03/2013 20:00, Borchert, Oliver wrote:
snip
But what does the alert tell me?
What if one is multi homed, uses two ROAs then switches to be single homed
and revokes the second ROA. In this case the owner
On Mar 20, 2013, at 2:35 PM, Murphy, Sandra sandra.mur...@sparta.com wrote:
Speaking as regular ol' member
That all depends on the policy undertaken by each specific provider,
doesn't it? How can you tell the difference between a route with no ROA
because the registry has decertified, and a
On Mar 21, 2013, at 8:36 AM, Randy Bush ra...@psg.com wrote:
randy, who is not learning anything else new from this rinse repeat
So, you're stating that operator input wrt impacts the RPKI will have on their
networks is not useful to SIDR? OK, got it.
-shane
randy, who is not learning anything else new from this rinse repeat
So, you're stating that operator input wrt impacts the RPKI will have
on their networks is not useful to SIDR? OK, got it.
no. i am saying nobody seems to be saying anything that has not already
been said.
but if you're
randy, who is not learning anything else new from this rinse repeat
So, you're stating that operator input wrt impacts the RPKI will have on their
networks is not useful to
SIDR? OK, got it.
Randy said nothing new, not nothing.
--Sandy, speaking as regular ol' member.
Thanks for the interest in our work. We wanted to clarify a few points:
-- We have a technical report, which contains motivation and details
that the slide deck does not. See
http://www.cs.bu.edu/~goldbe/papers/RPKImanip.pdf
-- As we point out in the paper (and as John Curran, Carlos, and
others
Interesting presentation here:
http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf
The RPKI (Resource Public Key Infrastructure) is a new infrastructure
to secure Internet routing
It’s been in deployment since ~2011 But, it also creates new risks
(misconfigurations and takedowns)
that
On Mar 20, 2013, at 6:50 AM, Danny McPherson da...@tcb.net wrote:
Interesting presentation here:
http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf
The RPKI (Resource Public Key Infrastructure) is a new infrastructure to
secure Internet routing
It’s been in deployment since ~2011
And THE organization can also take down bgp-peers, shutdown interfaces,
etc.
At the end, it is its space, they can revoke certs.
Cheers,
as
On 3/20/13 9:50 AM, Danny McPherson wrote:
Interesting presentation here:
http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf
Danny - Is there really a tight coupling if providers are
following the recommend BGP origin validation best practices?
I said BGPSEC...
-danny
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
On Mar 20, 2013, at 7:21 AM, Danny McPherson da...@tcb.net wrote:
Danny - Is there really a tight coupling if providers are
following the recommend BGP origin validation best practices?
I said BGPSEC...
Got it - the presentation suggests that RPKI poses risks to network
reachability due
disclaimer: i haven't read the paper in full, i've started and so far
it seems more solid than the slide deck
I agree with John's observations. We need to stop making the statement
no roa == no route, because it's simply not true.
So far in my reading of the full paper, many of the
Danny,
Thanks for the link. I read the doc.
I do not believe the work has been peer-reviewed and I detected a couple of
bizarre statements (such as deleting an object = revocation or the idea of
overwriting a ROA to replace an existing one).
What I believe it adds to our work are a number of
On 2013-03-20 09:15, Richard Barnes wrote:
One other thing to note is that manipulation is indistinguishable
from legitimate revocation, at a technical level. So the only
solution here is at the human layer, for RPKI relying party software
to have operator overrides. Randy stated this better
I agree with John's observations. We need to stop making the statement
no roa == no route, because it's simply not true.
There's something I probably don't understand here...
1. SIDR's ROA/RPKI infrastructure is designed to provide security for
route origination.
2. Security for route
There is a difference.
Invalid: someone is certified to own it and someone ELSE is originating.
Unknown: No one is certified owner.
Yes, I know that --but when someone says this:
I agree with John's observations. We need to stop making the
statement no roa == no route, because it's simply
On Mar 20, 2013, at 1:10 PM, Russ White ru...@riw.us wrote:
In response to a paper that says removing ROAs is a form of DoS, or that
there are potential problems in the space of the relationship between
the registry and the address owner, then we've moved from unknown, to
contested. The
Loss of a ROA (e.g. due to an attack on the RPKI system) does not
cause a _reachability event_ if folks are using best practices for
route precedence; that's what was implied in the paper and is wrong.
Successful attacks against the RPKI system do have an impact, but it
is simply that
That could be attacked as well. Then we will have something to tell
that an entry exists for the table that tells that roas exists.
:)
What we probably need need is something that flags that a Certificate
or a ROA has disappeared in the last X time. Then as operator we could
Speaking as regular ol' member
That all depends on the policy undertaken by each specific provider,
doesn't it? How can you tell the difference between a route with no ROA
because the registry has decertified, and a route with no ROA simply
because one hasn't ever been created?
To an ISP who
What we probably need need is something that flags that a Certificate
or a ROA has disappeared in the last X time. Then as operator we could
take the action to decide if this was an attack or a valid revocation.
That is probably a good idea... But since the ROAs are time based
On 3/20/13 4:41 PM, Russ White ru...@riw.us wrote:
What we probably need need is something that flags that a Certificate
or a ROA has disappeared in the last X time. Then as operator we could
take the action to decide if this was an attack or a valid revocation.
That is probably a good
On Mar 20, 2013, at 2:26 PM, Russ White ru...@riw.us wrote:
I never argued with addressing the risks that might be posed; I was pointing
out that the risk does not equate (on its own) with a reachability event, as
alluded to by the paper.
That all depends on the policy undertaken by each
On 20/03/2013 17:41, Russ White wrote:
What we probably need need is something that flags that a Certificate
or a ROA has disappeared in the last X time. Then as operator we could
take the action to decide if this was an attack or a valid revocation.
That is probably a good idea...
On 20/03/2013 17:41, Russ White wrote:
What we probably need need is something that flags that a
Certificate or a ROA has disappeared in the last X time. Then as
operator we could take the action to decide if this was an attack or a
valid
revocation.
That is probably a good
On 20/03/2013 20:00, Borchert, Oliver wrote:
On 20/03/2013 17:41, Russ White wrote:
What we probably need need is something that flags that a
Certificate or a ROA has disappeared in the last X time. Then as
operator we could take the action to decide if this was an attack or a
valid
52 matches
Mail list logo
