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
1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02
actually a problem that the WG needs to address? (Answer: yes or no.
Additional information is welcomed, but I don't want people to repeat
the whole discussion.)
[WEG] yes, but I tend to agree that it's not a technical
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
17 matches
Mail list logo
