of Stephen Kent [k...@bbn.com]
Sent: Monday, November 24, 2014 12:35 PM
To: sidr@ietf.org
Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10
Wes,
To first order I agree with your concern of this DoS vulnerability,
but with some minor clarifications.
1. BGPsec-signed updates
Wes,
To first order I agree with your concern of this DoS vulnerability,
but with some minor clarifications.
1. BGPsec-signed updates are sent only between ASes that agree to
send and receive (separate choices) this signed data. So, an
attack of this sort is perpetrated only against an
-ietf-sidr-bgpsec-protocol-10
Wes,
To first order I agree with your concern of this DoS vulnerability,
but with some minor clarifications.
1. BGPsec-signed updates are sent only between ASes that agree to
send and receive (separate choices) this signed data. So, an
attack of this sort
On Sun, Nov 16, 2014 at 7:13 PM, Randy Bush ra...@psg.com wrote:
Per discussion during IDR/SIDR meeting Friday, there may need to be
some text in the security considerations around the attack vector of
sending many updates with long (but valid) AS_Paths
could you please describe how an
On 11/17/14, 12:13 AM, Randy Bush ra...@psg.com wrote:
could you please describe how an attacker can send many long bgpsec
paths? how are these long paths signed?
Though I'm guessing it might be possible to try it as a replay attack
(grab a string of signed ASNs from the path of one or more
Per discussion during IDR/SIDR meeting Friday, there may need to be
some text in the security considerations around the attack vector of
sending many updates with long (but valid) AS_Paths
could you please describe how an attacker can send many long bgpsec
paths? how are these long paths
Just posted the -10 revision of the document.
The only normative change was to decouple BGPsec validation from
Origin Validation. (This is a normative change to the validation
algorithm in Section 5.) This is based on working group discussions at
IETF 90 and confirmed on the list in September.
