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

From: David Mandelberg <[email-masked]>
Date: Wed, 26 Aug 2015 17:26:24 -0400

Hi all,

I think I found an issue with draft-ietf-sidr-bgpsec-protocol-13's 
security guarantees. Apologies that I didn't catch this earlier, before 
WGLC ended.

The security guarantee with the issue is in section 7.1, "For each AS 
in the path, a BGPsec speaker authorized by the holder of the AS number 
intentionally chose (in accordance with local policy) to propagate the 
route advertisement to the subsequent AS in the path."

It appears that this guarantee will not always hold. Specifically, if 
two non-adjacent ASes conspire, and they are separated by a sequence of 
ASes that sign path data that they have not verified, then the 
conspiring ASes can violate the guarantee. The ASes that signed path 
data they didn't verify are behaving properly, since the spec says "In 
particular, the BGPsec attribute SHOULD NOT be removed even in the case 
where the BGPsec update message has not been that has not successfully 
validated." I have not yet been able to come up with a practical attack 
that uses this issue to do anything particularly bad, but I am concerned 
that one might exist.

I think this problem might be fixed if we modify the protocol to sign 
all of the preceding signed data (rather than just the immediate, 
previous signature).

Thoughts?

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Aug 2015 09:20:20 +0900

good catch.

one consequence

an intermediate AS, which does not validate but signs, could apply
prefix-based local policy based on the wrong prefix.  same for any
bgp4 peers it may have.

randy

---

From: Rob Austein <[email-masked]>
Date: Wed, 26 Aug 2015 22:49:45 -0400

At Wed, 26 Aug 2015 17:26:24 -0400, David Mandelberg wrote:
...
> all of the preceding signed data (rather than just the immediate, 

Agreed, assuming this means adding the (theoretically invariant)
fields from the data to be signed in section 4.1 to the data to be
signed in section 4.2.

Taking "Origin AS Number" in section 4.1 as equivalent to "Signer's AS
Number" in section 4.2, this leaves the algorithm suite identifier,
the AFI, the SAFI, and the NLRI to be added to the data to be signed
in section 4.2.  I doubt that there's any practical attack based on
fiddling with the algorithm suite identifier (I'd expect any games
there to cause validation failure, end of story), but maybe somebody
has a more twisted imagination than mine, and, given that the
algorithm suite ID is one byte long, I don't think it's worth trying
to optimize that byte out of the section 4.2 signature.

Presumably we want to keep the existing signature chaining, so I
wouldn't remove anything from the data to be signed in section 4.2,
just add the fields that are currently only present in section 4.1.

David, if this is consistent with what you meant, cool, if not, say on.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 27 Aug 2015 15:45:49 +0000

>conspiring ASes can violate the guarantee. 

Agree with that. 
What do you think of the following two-update collusion scenario?
-- > A --> B --> C --> D --> E
A and D are colluding. B and C are signing without verifying.
First update at time= t0:
A signs and forwards an update normally (without any corruption). 
The update propagates via B and C to D.
D receives it and stores it, but does not forward to E (or anyone).
Second update at time= t1 (= t0 + delta):
A sends an intentionally corrupted version of the update (signed),
while keeping the same NLRI as before. 
B and C are still signing but not verifying.
The update propagates via B and C to D. Now D replaces 
this corrupted update with the earlier clean one (received at t0), 
and propagates to E. The resulting update from D to E is valid.
One can argue that there is violation of the guarantee (in Section 7.1)
at time t1. The valid route propagated from D to E does not
agree with the route that B or C forwarded (at time t1)
for the NLRI in consideration.

>all of the preceding signed data (rather than just the immediate,

If we agree that the above two-update collusion scenario 
is something we care about, then it should be noted that
this fix does not prevent it.

Sriram

---

From: Rob Austein <[email-masked]>
Date: Thu, 27 Aug 2015 13:58:26 -0400

> for the NLRI in consideration.

If I understand your scenario correctly, as far as folks further along
the path are concerned, this is a replay attack by D.  That D is doing
this to cover up something bad that A is doing to B and C is almost
irrelevant, as is the specific nature of whatever bad thing A is doing
to B and C.

So, yeah, OK, it's a form of collusion, but it's not one that relies
on a weakness in the signature semantics, it's one that relies on lack
of protection against replay attacks, something the WG discussed and
rejected.  Can't speak for anybody else, but I'm not particularly
interested in exhuming the replay horse at this late date.

---

From: "Borchert, Oliver" <[email-masked]>
Date: Thu, 27 Aug 2015 19:15:52 +0000

If I understand David¹s attack vector correct than the attack would look
as follows:

For the path ‹ > A ‹> B ‹> C ‹> D ‹> E with A and D conspiring and B and C
only signing but not validating:

A signs the path to D and not to B but sends it to B. Because B and C
don¹t validate, just sign they forward the path to D.
D removed B and C from the path and forwards the path as ‹> A ‹> D  to E.
Now E verifies the path as valid and moves on.

If this is what David had in mind then I agree that the security guarantee
in 7.1 does not hold up.

Oliver

On 8/27/15, 1:58 PM, "sidr on behalf of Rob Austein"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr

---

From: "Borchert, Oliver" <[email-masked]>
Date: Thu, 27 Aug 2015 19:23:45 +0000

I noticed Outlook changed some characters so here again:

If I understand Davids attack vector correct than the attack would look
as follows:

For the path -> A -> B -> C -> D -> E with A and D conspiring and B and C
only signing but not validating:

A signs the path to D and not to B but sends it to B. Because B and C
do not validate, just sign they forward the path to D.
D removed B and C from the path and forwards the path as -> A -> D  to E.
Now E verifies the path as valid and moves on.

Oliver

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 27 Aug 2015 16:45:11 -0400

Speaking as regular ol’ member:

> an intermediate AS, which does not validate but signs, could apply

I’d say that the intermediate AS who didn’t verify the signatures it received could be acting on bad info at any time, without any conspiring ASs around.  The intermediate AS has no more assurance than a non-bgpsec speaker that the route it receives is valid.

So I don’t think anything that happens to the intermediate AS is something to worry about.

> prefix-based local policy based on the wrong prefix.  same for any

I see nothing in David’s message about a prefix, so I’m not sure what you are talking about.

But the intermediate AS and any bgp4 (i.e. non-bgpsec speakers?) peers have chosen to be insecure - I see no reason to be concerned.

—Sandy, speaking as regular ol’ member

---

From: Randy Bush <[email-masked]>
Date: Fri, 28 Aug 2015 06:02:27 +0900

> I’d say that the intermediate AS who didn’t verify the signatures it
> received could be acting on bad info at any time, without any
> conspiring ASs around.  The intermediate AS has no more assurance than
> a non-bgpsec speaker that the route it receives is valid.

it is not worse than unsecured is a form of reasoning i do not buy.

> I see nothing in David’s message about a prefix, so I’m not sure what

sorry, i forgot that bgp announces beers.

the colluding systems could have signed a hash of lager when the label
on the announcement was pils.  the intermediate system which does not
validate could base it's mains order on pils and tell it's
non-validating peers to have a pils with them.

> But the intermediate AS and any bgp4 (i.e. non-bgpsec speakers?) peers
> have chosen to be insecure - I see no reason to be concerned.

same fallacious argument.  we are supposed to be making things better,
not leaving them the same.

randy

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 28 Aug 2015 21:45:17 +0000

>interested in exhuming the replay horse at this late date.

It appears you agree that the two-update collusion scenario that 
I described is feasible. It is basically another mechanism by which the 
colluders seem to achieve the same effect as in David's collusion scenario.
(I think so, but I'm open to being proven wrong about that.) 
The latter, it appears, can be mitigated by signing 'all of the preceding 
signed data', but not the former (two-update collusion). 
Both scenarios or threats rely on intermediate ASes not verifying. 
So both of these scenarios are mitigated by requiring intermediate 
ASes to verify. This is the observation I would like to make.

Since you made contrary comments, let me point out respectfully 
that replay attack mitigation is in the requirements (RFC 7353):
4.3  Replay of BGP UPDATE messages need not be completely prevented,
        but a BGPsec design SHOULD provide a mechanism to control the
        window of exposure to replay attacks.

And there is an active SIDR WG draft dealing with replay attack mitigation:
https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-04#section-4.2 

However, a solution for the specific collusion threat we are discussing 
does not benefit at all from replay attack mitigation techniques.
All that D is doing (in my example) is to hold the first update for 15 or 30 seconds.
The bgpsec-rollover draft proposes router key rollovers, 
but (thank goodness) not on that small/tiny (seconds) time scale!

Sriram

---

From: Randy Bush <[email-masked]>
Date: Sat, 29 Aug 2015 04:30:49 +0200

can we start a new thread for replay?

randy