Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening

[Jakob Heitz <[e-mail]>]

 B's router ignores AS_PATH
How can you assume this?

--
Jakob Heitz.


On Apr 8, 2012, at 9:07 AM, "Sriram, Kotikalapudi" <[e-mail]<mailto:[e-mail]>> wrote:

Andrew,

There isn't a reason for the problem as you point out to arise.
Your analysis assumes that there a conventional BGP-4 AS_PATH field and then there is
is BGPSEC_Path_Signatures from which AS path info can be inferred separately.
This is not true in the latest BGPSEC update format as Matt presented it in Paris.
Please see slide 8 of the BGPSEC Protocol presentation:
https://datatracker.ietf.org/meeting/83/materials.html
Matt stated in his presentation that there will soon be an -03 version of the draft
which will include this update format.

What the latest BGPSEC update format has is a field upfront (outside of the BGPSEC_Path_Signatures)
that provides the sequence of ASNs and their respective pCounts.
Matt has called it the Secure Path (see Slide 8).
Corresponding to each AS in the Secure Path there must be one signature present (in the Sig Block)
in order for the BGPSEC update to be considered well-formed (otherwise it is malformed).
Referring to your example, B is simply not in a position to do what you say he does, namely,
"ignores AS_PATH and just uses BGPSEC_Path_Signatures."
B is required to look at the Secure Path (i.e., ASNs and pCounts) first;
then B expects to see one signature for each AS in the Secure Path;
B finds that this is violated because he sees C's ASN in the Secure Path
but no signature for it (per your description);
now B declares that the BGPSEC update from A is malformed.
B would neither verify nor propagate the update any further.
So C does not even get the update.

The good thing about the update format (slide 8) is that
if some AS inserted an AS in the "Secure Path" (without a signature for it),
then the next hop AS knows (even before any signature verification)
that the update is malformed.

I hope this clarification helps.

Sriram

________________________________________
From: [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[e-mail]>] On Behalf Of Andrew Chi [[e-mail]<mailto:[e-mail]>]
Sent: Friday, April 06, 2012 3:21 PM
To: Murphy, Sandra
Cc: sidr wg list
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &        lengthening

On 4/6/2012 2:10 PM, Murphy, Sandra wrote:
So where's the dos attack?

(Do note that the bgpsec signatures would detect this at the first point that checked the signatures, so your neighbor would have spotted the injection - unless it was the source of the injection.)

So I think I finally see what Shane's getting at.  Let's say:

- I'm a bad actor (A)
- Bob is my neighbor (B)
- Charlie is Bob's neighbor (C)

A is trying to cause B and C to have different views of the world.  In
addition, we must assume:

- B's router ignores AS_PATH and just uses BGPSEC_Path_Signature
- C's router checks both AS_PATH and BGPSEC_Path_Signature

As the bad actor, A injects C into the AS_PATH (malicious), but
processes BGPSEC_Path_Signature normally, and sends the update to B.

- B verifies BGPSEC_Path_Signature only, passes it to C
- C detects a loop in AS_PATH and drops the update

A has just caused B to accept an update while simultaneously causing C
to drop it silently.  While not a very strong attack (B could always
filter the route anyway), I could imagine it being a starting point for
causing confusion.

This is solved by prescribing that AS_PATH/AS4_PATH is ignored when
BGPSEC is enabled, but Shane has a good point that we might need to
coordinate with IDR on this.  I defer to the WG chairs on that coordination.

-Andrew

_______________________________________________
sidr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sidr