Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 4 Sep 2015 17:08:34 +0000

Doug and I have discussed the issues raised in this thread in some detail.
We feel that the following considerations (with corresponding changes in the document) 
would help resolve the issue(s) we are dealing with:

1.  As mentioned already, signature should cover more data so that 
the collusion vulnerability that David pointed out can be addressed.

2.  It was a conscious design decision to not require (MUST) validation before
path selection and signing in all cases. Lazy (or deferred) evaluation 
(e.g., the ability to select and sign a path before validation) adds 
performance / robustness options to implementations that address 
real operational concerns (e.g., convergence time on table dumps, bootstrap, etc.) 
that were identified early in the BGPsec design process.

3.  In consideration of the above (#2), the document should instead 
strongly recommend that “if an AS signs an update without verifying first, 
it SHOULD return to the update at its earliest and verify, and forward 
a new signed update, if necessary." Make this a strong BCP recommendation.

4. If this recommendation (#3) is followed, then other collusion/replay effects 
that have been identified on the list will be short lived 
(e.g. Oliver’s:  http://www.ietf.org/mail-archive/web/sidr/current/msg07248.html  ). 
Adverse effects would be short lived, if the duration of deferment of 
verification (if any) is short.

Sriram

---

From: David Mandelberg <[email-masked]>
Date: Tue, 08 Sep 2015 20:52:03 -0400

> a new signed update, if necessary." Make this a strong BCP 

Without replay protection, I don't see how this recommendation would 
help. I.e., the old signed update would still be valid.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 15 Sep 2015 00:54:39 +0000

>help. I.e., the old signed update would still be valid.

In the example with   -- > A --> B --> C --> D -->, if B and C 
(the ones that were signing but not verifying) return to the update to verify, 
then they will realize that the update they last signed (for the prefix) was invalid,
and will propagate an alternate valid signed announcement or 
send a withdrawal message to D.
At this point, B and C have taken their corrective action.
Their well-behaving neighbors (others besides D) will act on 
the new valid announcement or the withdrawal.
But if D is still malicious and suppresses the new valid announcement
or the withdraw, then that would be 
a classic withdraw suppression / replay attack.
(B and C are not contributing to collusion anymore at this point.)
And the solution at that point is whatever remedy 
draft-ietf-sidr-bgpsec-rollover-04 offers. 

Sriram

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Sep 2015 07:12:16 +0600

> In the example with -- > A --> B --> C --> D -->, if B and C (the ones
> that were signing but not verifying) return to the update to verify,
> then they will realize that the update they last signed (for the
> prefix) was invalid, and will propagate an alternate valid signed
> announcement or send a withdrawal message to D.

and all the packts will return to their origins with a loud swoosh and
re-route correctly :)

> At this point, B and C have taken their corrective action.

not really.  the internet is all about the data plane.  the control
plane is there to help the data plane.

randy