On Mar 20, 2013, at 7:23 PM, "Sriram, Kotikalapudi"
wrote:
> The DDoS mitigation example was discussed before.
> It appeared there was a reasonable solution.
> Please see this post:
> http://www.ietf.org/mail-archive/web/sidr/current/msg05605.html
Might work for Joel, not me...
-danny
__
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
The DDoS mitigation example was discussed before.
It appeared there was a reasonable solution.
Please see this post:
http://www.ietf.org/mail-archive/web/sidr/current/msg05605.html
Sriram
>
>From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of
>Danny McPherson
>Sent: Wednesday
> 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
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 Mar 20, 2013, at 2:26 PM, Russ White 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 speci
On 3/20/13 4:41 PM, "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 i
> 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
themsel
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
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
take
>> 1. Removing the ROAs is a problem in terms of increased risk, which is a
>> problem which needs to be addressed.
>
> 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
>> It seems, to me, that if the RPKI can't be used to actually validate who
>> owns what route with certainty, we're going to a lot of trouble for
>> nothing... Or maybe folks are trying to have their cake and eat it to.
>> "We'll provide solid security which you can ignore if you like, no
>> prob
On Mar 20, 2013, at 1:51 PM, Russ White wrote:
> How often do you think an attacker would bother with taking out a ROA
> without taking out the route as well?
Invert the question... Of the thousands of entities that could today
inject (hostile) routes and do a hijack today, how many of them wil
Speaking as a regular ol' member
>It seems, to me, that if the RPKI can't be used to actually validate who
>owns what route with certainty, we're going to a lot of trouble for
>nothing... Or maybe folks are trying to have their cake and eat it to.
>"We'll provide solid security which you can ignor
> 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 th
On Mar 20, 2013, at 1:10 PM, Russ White 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 response g
> 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 s
On , Russ White <> wrote:
>> 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 o
inline.
On Mar 20, 2013, at 4:21 PM, Danny McPherson wrote:
> On 2013-03-20 09:00, Roque Gagliano (rogaglia) wrote:
>
>> 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 R
> 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 ori
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
On 2013-03-20 09:00, Roque Gagliano (rogaglia) wrote:
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).
Much of the work presented here is not "
Hey Danny,
I read the paper. Maybe it's that I'm missing the voice-over for the
slides, but I don't really see anything new here. Every new security
mechanism creates a new DOS possibility. If you screw up your HTTPS cert
or your CA revokes it, your website goes down. This happens because only
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 Mar 20, 2013, at 9:44 AM, Stephen Kent
> You cite DDoS mitigation as an example, whereas it seems to be more the
> example.
Bah.. How many examples do you need?
> Also, it's not clear
> that asserting a new origin AS for a target of such an attack is the only way
> to deal with the pr
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 'vulnerabilities'
they mention (quotes intended, I'm not sure the word is properly applied
given the context) appear to (
Danny,
On 2013-03-18 10:47, Stephen Kent wrote:
There are at least two issue here: how quickly a new/changed ROA is
published
after it is created/modified, and how quickly one should expect all
RPs to have acquired this info. The RPKI propagation model for ROAs was
based on the observation tha
On Mar 20, 2013, at 7:21 AM, Danny McPherson 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 to att
>> Danny - Is there really a "tight coupling" if providers are
>> following the recommend BGP origin validation best practices?
>
> I said BGPSEC...
However, my statement does apply to origin validation as well, in some
envisaged deployment models...
-danny
__
> 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
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.pd
On Mar 20, 2013, at 6:50 AM, Danny McPherson 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 But, i
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 2013-03-18 10:47, Stephen Kent wrote:
There are at least two issue here: how quickly a new/changed ROA is
published
after it is created/modified, and how quickly one should expect all
RPs to have acquired this info. The RPKI propagation model for ROAs
was
based on the observation that, typ
34 matches
Mail list logo
