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

From: Sandra Murphy <[email-masked]>
Date: Tue, 1 Sep 2015 09:54:24 -0400

Speaking as a regular ol’ member

On Aug 27, 2015, at 5:02 PM, Randy Bush <[email-masked]> wrote:

>>> 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.
> 
> it is not worse than unsecured is a form of reasoning i do not buy.
> 
> 

<snip>

>> 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.

Are you saying that any system that does NOT check the protections and does not spot invalid signatures should still be protected?  I think that’s a pretty tall order.

My concern is with those who do check the signature but who, because conspiring ASs “violate the guarantee”, do not get the bgpsec protection in some way.

David’s suggestion that more of the data should be covered by the signature still does not help the hapless intermediate AS who does not check the signature, I would think.  That AS could still fooled.  So I don’t think that the new signature makes anything better for the non-checkers.

—Sandy, speaking as a regular ol’ member

---

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

On 2015-08-26 22:49, Rob Austein wrote:
> At Wed, 26 Aug 2015 17:26:24 -0400, David Mandelberg wrote:
> ...
>> 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).
>
> 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.

It is not consistent with what I meant, so I'll be more explicit about 
what I meant. I meant to remove the signature chaining, and have each AS 
sign the data that is currently covered by signature chaining. I.e., 
each AS (origin or intermediary) would sign the same data structure 
(with different, but related, data in the structure):

Target AS Number (4 octets)
AS Count (4 octets)
<AS Count> instances of:
     AS Number (4 octets)
<AS Count> instances of:
     pCount (1 octet)
     Flags (1 octet)
Algorithm Suite Id. (1 octet)
AFI (2 octets)
SAFI (1 octet)
NLRI (variable)

The sequence of AS Numbers is split from the sequence of (pCount, 
Flags) to preserve alignment, but the two sequences form a single 
logical sequence of (AS Number, pCount, Flags). (This could also be 
represented with 2 bytes of padding per AS, without 4-byte alignment, or 
with 3 parallel sequences; I don't really care which.) Regardless of the 
logical sequence's representation, the first (AS Number, pCount, Flags) 
entry corresponds to (Origin AS Number, pCount, Flags) from section 4.1. 
Subsequent entries correspond to (Signer's AS Number, pCount, Flags) 
from section 4.2, in order from the origin's next hop to the current 
signer.

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

---

From: David Mandelberg <[email-masked]>
Date: Tue, 08 Sep 2015 21:01:22 -0400

On 2015-08-27 15:23, Borchert, Oliver wrote:
> 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.
>
> If this is what David had in mind then I agree that the security 
> guarantee
> in 7.1 does not hold up.

This is one type of attack that uses the issue I raised, but this 
specific attack doesn't seem problematic to me. A and D can always set 
up a BGPsec tunnel to accomplish the same result of removing B and C 
from the path, and there's not much we can do to stop that.

---

From: Rob Austein <[email-masked]>
Date: Tue, 08 Sep 2015 21:07:09 -0400

Hmm, I would have thought we'd want to keep the chaining, in the sense
that non-originating would sign the previous signature.  I've no real
objection to signing everything else again, it's just removal of the
previous signature that I find odd here.

The benefit I see to keeping the signature chaining is that it adds an
ordering constraint to the signatures (signature A must have been
created after signature B), corresponding to the order in which we
expect the update to travel between signers.  This seems like a good
thing, and I don't see why we'd want to remove it.  As you've
demonstrated, it doesn't remove all possible forms of mischief, but it
raises the bar a bit, and it's cheap, so why not?

Am I missing something?  Where's the benefit in removing the chaining?

---

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

> raises the bar a bit, and it's cheap, so why not?

I agree that signature chaining provides the guarantee you stated, that 
signatures were generated in order. But in the presence of 
non-validating signers, I don't think it provides any other guarantee.

What does the guarantee about signature order provide? I don't see how 
it's useful, but I could be missing something.

> Am I missing something?  Where's the benefit in removing the 

There's no benefit to removing it, except that I don't see any benefit 
to keeping it (if we sign the full data, as I described).

---

From: Rob Austein <[email-masked]>
Date: Tue, 08 Sep 2015 23:15:17 -0400

> it's useful, but I could be missing something.

I can't point to any concrete threat.  Just a suspicion that we should
grab a cheap opportunity to reduce the number of potential violations
of the Principal of Least Astonishment.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Sep 2015 15:09:20 -0400

David,

> it's useful, but I could be missing something.
At least initially, sig order was required to match the AS transit 
order, to ensure that the
AS transit order is accurately represented. Is that no longer true?

Steve

---

From: David Mandelberg <[email-masked]>
Date: Thu, 10 Sep 2015 20:28:06 -0400

> AS transit order is accurately represented. Is that no longer true?

Are you talking about (1) the order of the signatures on the wire, (2) 
the order of which AS path is covered by which signature, or (3) the 
chronological order in which the signatures are generated? I think Rob 
and I were talking about (3), but Rob should tell me if I misunderstood 
him.

For (1), the order needs to specified such that each signature can be 
correctly verified. Having the order of the signatures match the AS 
transit order seems like the most sensible way to do this.

For (2), I think it's critical that each signature covers that correct 
AS path, in the correct order.

For (3), the signatures will typically be generated in order, but I 
don't see the value of enforcing that. I.e., while I don't see the point 
of pre-computing signatures before including them in a BGPsec UPDATE, I 
also don't see any harm in it.