I want to echo Randy's comment on this paragraph.
i am confident that the folk providing third-party mitigation services
are clever enough to figure out their own hacks around this problem, and
we do not need to second guess what might best work for them.
Lets keep in mind that for origin
I don't have plans to be at NANOG in February, so perhaps IETF in March?
Yes, I plan to attend the IETF in March.
--snip--
(2) is being established in emergency after the victim came under attack and
made a panic phone call to the DDoS mitigator (Proxy AS1)?
Yes.
If it is case (1),
On Wed, Dec 26, 2012 at 12:37 PM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
However, I would note that the use case I've outlined above is more broad
than 'just' DDoS attack. Specifically, think of natural or man-made
disasters. In the latter case, it's often the case that a
On 12/18/12 11:48 AM, Randy Bush wrote:
I am trying to understand why our fellow engineers at Verisign are
obsessed with global propagation of RPKI data on the order of a few
minutes. Then a friend hit me with the clue by four. It's about third
party DDoS (and other attack) mitigation.
When
On Dec 19, 2012, at 1:13 PM, Randy Bush wrote:
o there is a useful poster child for the need for O(minutes) rpki (or
perhaps just roa) propagation. as folk have repeatedly said, we
need concrete examples and goals.
I really think these should feed requirements analysis too [1]. I
FWIW, I disagree with your assertions, but am cutting to the chase, because I
think you're still failing to understand why/when it's not possible to
spoof the Victim's AS.
Sorry, I tried my best to try to understand your point but well …
But thanks very much indeed for your patience.
I
Excuse me. I misunderstood. In either case, the prefix originates out of AS2 so
the existing ROA would be valid and you would just have to worry about tie
breaking factors anywhere that the AS path length was 2.
Thanks,
Bryan
On Dec 20, 2012, at 10:50 AM, Bryan Weber brweb...@yahoo.com wrote:
I feel _this_ is where a lot of our group's false-logic starts. This
(and similar) statement(s) assume that we must deploy a global
replicated state machine, which has a complete and coherent image of a
globally distributed set of resource holders' states, at all RPs at
all times in order
On Dec 20, 2012, at 11:03 AM, Randy Bush wrote:
bgpsec+rpki does not have the highly globally synced requirement.
So, in bgpsec, you (as an RP) don't need to know ROAs a priori in order to
validate routes as they arrive in updates?
your
application does. you are tryin to add the
On Dec 20, 2012, at 11:30 AM, Randy Bush wrote:
bgpsec+rpki does not have the highly globally synced requirement.
So, in bgpsec, you (as an RP) don't need to know ROAs a priori in
order to validate routes as they arrive in updates?
see highly synched above. as a rp, an hour or three
I keep hearing:
this is not fast enough
we have a requirement to make it faster
etc.
But nobody has answered Tim:
I would really like to echo Chris's last paragraph here. What do you
think is a reasonable time to propagate from an operator editing the
RPKI (A) - 99.9% of Bs?
On Dec 20, 2012, at 11:59 AM, Arturo Servin wrote:
I would really like to echo Chris's last paragraph here. What do you
think is a reasonable time to propagate from an operator editing the
RPKI (A) - 99.9% of Bs?
I understand that half a day is way too long. Instantaneous is
On Dec 20, 2012, at 8:39 AM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
FWIW, I disagree with your assertions, but am cutting to the chase, because
I think you're still failing to understand why/when it's not possible to
spoof the Victim's AS.
Sorry, I tried my best to
On 20/12/2012 15:35, Eric Osterweil wrote:
On Dec 20, 2012, at 11:59 AM, Arturo Servin wrote:
I would really like to echo Chris's last paragraph here. What do you
think is a reasonable time to propagate from an operator editing the
RPKI (A) - 99.9% of Bs?
I understand that half a day
On Dec 20, 2012, at 1:53 PM, Eric Osterweil wrote:
On Dec 20, 2012, at 1:27 PM, Arturo Servin wrote:
That's is not true. We have seen some challenges in the current
architecture since long ago and some are trying to address them:
On Dec 18, 2012, at 3:03 PM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
Adding to Oliver's suggestion, it will be even more effective if, in the
origin only case,
the mitigator announces a slightly more specific (e.g., two /17s for a /16)
if the maxlength of the victim's
The proposed solution would work fine in practice as well.
Whichever prefix (or more specific of it) that the mitigator and the victim
decide to
propagate (via the mitigator) for DDoS mitigation today in BGP, the same
prefix can also
be propagated with BGPSEC (and more securely).
How
Whichever prefix (or more specific of it) that the mitigator and the victim
decide to
propagate (via the mitigator) for DDoS mitigation today in BGP, the same
prefix can also
be propagated with BGPSEC (and more securely).
I thought we were just talking about _Origin_ Validation, not
Hi Danny, WG,
People have mentioned that if the security was somehow part of the updates
themselves, then you could have security at the speed of updates. I don't see
how this could work, it would have to be a completely different set of
standards from what's currently being worked on. Most
Sriram,
On Dec 19, 2012, at 8:25 AM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
Whichever prefix (or more specific of it) that the mitigator and the victim
decide to
propagate (via the mitigator) for DDoS mitigation today in BGP, the same
prefix can also
be propagated with
[1] I'd also note there are legitimate cases where customers may be
unable to serve traffic for their content/service/application, (think:
unexpected, but legitimate flash crowds/traffic combined with
under-provisioned tail circuit capacity). In that case, it may be far
easier for the customer to
On Wed, Dec 19, 2012 at 12:33 PM, Pradosh Mohapatra (pmohapat)
pmoha...@cisco.com wrote:
In these use cases, what breaks if we allow two ROAs to co-exist in the
system (one authorizing the customer AS and one authorizing the proxy AS
the system already permits multiple ROA's for the same
[ apologies for having the attention span of a chihuahua, but i am being
eaten by airplanes and relatives ]
i was trying to make only two points
o there is a useful poster child for the need for O(minutes) rpki (or
perhaps just roa) propagation. as folk have repeatedly said, we
need
On 12/19/12 3:33 PM, Pradosh Mohapatra (pmohapat) wrote:
[1] I'd also note there are legitimate cases where customers may be
...
In these use cases, what breaks if we allow two ROAs to co-exist in the
system (one authorizing the customer AS and one authorizing the proxy AS
to originate
In these use cases, what breaks if we allow two ROAs to co-exist in the
system (one authorizing the customer AS and one authorizing the proxy AS
to originate the prefix) _much before_ the attack (or storm) takes place?
After all, this is a valid business relationship. Choose your pill wisely.
In these use cases, what breaks if we allow two ROAs to co-exist in the
system (one authorizing the customer AS and one authorizing the proxy
AS
to originate the prefix) _much before_ the attack (or storm) takes
place?
After all, this is a valid business relationship. Choose your pill
wisely.
In these use cases, what breaks if we allow two ROAs to co-exist in the
system (one authorizing the customer AS and one authorizing the proxy AS
the system already permits multiple ROA's for the same prefix, right?
Yes (e.g. multihoming) and hence the question of why we can't use that
On Wed, Dec 19, 2012 at 1:54 PM, Pradosh Mohapatra (pmohapat)
pmoha...@cisco.com wrote:
No, thanks for clarifying. For DDoS mitigation at least, I thought there
would be a prior business relationship. I am not familiar with on-the-fly
relationship building process.
for that case, and shane's
There are still a few problems with your proposal:
1) Spoofing the Origin ASN means you will always have a longer AS_PATH
length (Spoofed Origin ASN + Proxy AS) vs. just originating the IP prefix
from
the Proxy AS. Yes, you can _try_ to workaround that using some of the
'tricks'
I outlined
In these use cases, what breaks if we allow two ROAs to co-exist in the
system (one authorizing the customer AS and one authorizing the proxy AS to
originate the prefix) _much before_ the attack (or storm) takes place?
After all, this is a valid business relationship. Choose your pill wisely.
On Dec 19, 2012, at 2:12 PM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
[--snip--]
FWIW, I disagree with your assertions, but am cutting to the chase, because I
think you're still failing to understand why/when it's not possible to spoof
the Victim's AS.
2) I'm sure you
I am trying to understand why our fellow engineers at Verisign are
obsessed with global propagation of RPKI data on the order of a few
minutes. Then a friend hit me with the clue by four. It's about third
party DDoS (and other attack) mitigation.
When an NTT (just an example) customer is
...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Randy
Bush
Sent: Tuesday, December 18, 2012 2:48 PM
To: sidr wg list
Subject: [sidr] the need for speed
I am trying to understand why our fellow engineers at Verisign are obsessed
with global propagation of RPKI data on the order of a few
[apologies if I am sending this multiple times, having trouble with replying]
A concept that could be borrowed from DNS side is the ability for
anyone to go from the top and skip the cache(s) on an ad hoc basis.
Perhaps we need a similar capability here, for anyone to query from
the top. This
On Tue, Dec 18, 2012 at 4:24 PM, Dongting Yu dongting...@cl.cam.ac.uk wrote:
[apologies if I am sending this multiple times, having trouble with replying]
A concept that could be borrowed from DNS side is the ability for
anyone to go from the top and skip the cache(s) on an ad hoc basis.
Adding to Oliver's suggestion, it will be even more effective if, in the
origin only case,
the mitigator announces a slightly more specific (e.g., two /17s for a /16)
if the maxlength of the victim's existing ROA permits it (of course, victim’s
AS is inserted
as the origin AS as suggested).
On Dec 18, 2012, at 2:48 PM, Randy Bush wrote:
I am trying to understand why our fellow engineers at Verisign are
obsessed with global propagation of RPKI data on the order of a few
minutes. Then a friend hit me with the clue by four. It's about third
party DDoS (and other attack)
So to mitigate an attack you conduct another one ...
Ross
On 18/12/2012, Sriram, Kotikalapudi kotikalapudi.sri...@nist.gov wrote:
Adding to Oliver's suggestion, it will be even more effective if, in the
origin only case,
the mitigator announces a slightly more specific (e.g., two /17s for a
Anderson [ross.ander...@cl.cam.ac.uk]
Sent: Tuesday, December 18, 2012 5:10 PM
To: Sriram, Kotikalapudi
Cc: Borchert, Oliver; Randy Bush; sidr wg list
Subject: Re: [sidr] the need for speed
So to mitigate an attack you conduct another one ...
Ross
On 18/12/2012, Sriram, Kotikalapudi kotikalapudi.sri
I am trying to understand why our fellow engineers at Verisign are
obsessed with global propagation of RPKI data on the order of a few
minutes. Then a friend hit me with the clue by four. It's about third
party DDoS (and other attack) mitigation.
In other words, when you can't provide a
On Dec 18, 2012, at 6:24 PM, Sriram, Kotikalapudi wrote:
Since the intent is good, it is not an “attack” (at least as far as the
mitigator and the victim are concerned).
In BGPSEC (i.e. the path validation case), the proposed solution (below) is
clearly not even an apparent attack.
The
: Borchert, Oliver; Randy Bush; sidr wg list
Subject: Re: [sidr] the need for speed
So to mitigate an attack you conduct another one ...
Ross
On 18/12/2012, Sriram, Kotikalapudi kotikalapudi.sri...@nist.gov wrote:
Adding to Oliver's suggestion, it will be even more effective
correctly.
Sriram
From: Eric Osterweil [eosterw...@verisign.com]
Sent: Tuesday, December 18, 2012 7:15 PM
To: Sriram, Kotikalapudi
Cc: ross.ander...@cl.cam.ac.uk; sidr wg list
Subject: Re: [sidr] the need for speed
On Dec 18, 2012, at 6:24 PM, Sriram
On Dec 18, 2012, at 5:03 PM, Sriram, Kotikalapudi wrote:
Adding to Oliver's suggestion, it will be even more effective if, in the
origin only case,
the mitigator announces a slightly more specific (e.g., two /17s for a /16)
if the maxlength of the victim's existing ROA permits it (of
On Dec 18, 2012, at 3:03 PM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
Adding to Oliver's suggestion, it will be even more effective if, in the
origin only case,
the mitigator announces a slightly more specific (e.g., two /17s for a /16)
if the maxlength of the victim's
On Dec 18, 2012, at 4:52 PM, Christopher Morrow wrote:
(to which I would argue the RIRs already has enough
resources to handle it, or some tricks can be perhaps applied to make
do they?
Heh, fine question Chris.. If they don't, they'd better get busy increasing
fees and putting business
On Dec 18, 2012, at 9:35 PM, Shane Amante wrote:
Sound fine in theory, but will not work in practice. *When* the original
announcement is a (IPv4) /24 and all providers filter on announcements /24
... you're, umm, up a creek without a paddle if you don't have an ability to
[immediately]
On Dec 18, 2012, at 12:48 PM, Randy Bush ra...@psg.com wrote:
I am trying to understand why our fellow engineers at Verisign are
obsessed with global propagation of RPKI data on the order of a few
minutes. Then a friend hit me with the clue by four. It's about third
party DDoS (and other
48 matches
Mail list logo
