Let's assume that we have a path with
three ASes, one, two, and three, and that each
AS has a public-private key pair. Let's assume that
we have a network with three ASes and that
each AS along the path has a public-private
key pair. An AS can sign a message or
a route with its own private key, and any
other AS can check that signature. With the AS's
public key. So let's suppose that AS one
advertises a route for prefix p. So that route
would contain the prefix as well as an address
attestation which we're not showing, but let's look at
the path attestation. So as usual, the BGP announcement
would contain the prefix p,and the as path, which
so far is just one. And, the path at
a station, which is actually the path to one.
Signed by, the private key, of AS1. When AS2, re advertises that route
announcement, it of coarse advertises the new AS path to one. It adds its own at
route at test station, three, two, one signed by it's own private key. And it
also includes the original path atastation signed
by AS1. A recipient of a route along
this path can thus verify every step of the AS path. AS3 can
use the first part of the path attestation to verify that the path in fact, goes
from AS2 to AS1, and does not contain any other ASs in between. It can use the
second part of the path attestation to insure. That the path between it,
AS3, and the next hop is in fact, AS2, and that no other ASs could've inserted
themselves on the path between two and three.
This is precisely why the AS signs a
path attestation with not only its own part
of the AS path in the path attestation.
But also, the hop of the AS that
is intended to receive the BGP route advertisement.
To see the importance of this part of the path at a station. Suppose, that
these AS's were not there in the path at station. In this case. We have a very
nice well-formed VGP route advertisement for prefix with
the AS path suffix to one, and we
have each segment signed, so an attacker could
in fact, take such an announcement and advertise
sub strings of this route advertisement as their own. Thus an attacker,
AS4, could claim that it was connected to prefix P via AS1 when in
fact no such link existed. Simply by stealing or replacing the path atastation
one that's signed by K1. But, note that in reality AS1 never generates
this signature. In fact it generates the signature,21. Or in this case, it would
somehow have to generate the signature 41
signed by AS1's private key, whereas if AS1
only signed a message with its own AS in the message, such a segment or
attestation could easily be replayed. There's actually
no way that AS4 Could forge the path
attestation for one, signed by AS1's private
key because it doesn't own this private key
and AS1 never generated a path attestation with
this particular signed path., This is the reason
that each AS not only signs a path attestation with its own AS on the AS path.
But also the next AS along the path. This particular mode of signing not
only prevents the type of hijacking that we explored but it also prevents path
shortening attacks. For example, when AS4 receives
the legitimate route to ASP through the path
three, two, one it would be impossible
for the AS to shorten that advertisement to
say three, one. Because it would somehow
have to generate a path attestation four, three,
one, signed by its own secret key. However, if it did that, the receiving AS
would look for another path attestation with
just three, one signed by AS3. Yet, such
a path attestation would not actually exist.
So, these path attestations can prevent against some
kinds of hijacks, as we've seen; they can
prevent against these path shortening attacks; and they
can also prevent against modification of the AS
path. However, there are certain attacks that path
attestations cannot defend against. So, if an AS
fails to advertise a route or a route withdrawal
There is no way for the path [UNKNOWN] or PGP sec to prevent from that kind
of attach. Certain types of replay attacks such
as a premature re-advertisement of a withdrawn route also
cannot be defended against and of course, there is no
way to actually guarantee that the data traffic travels along
the advertised AS path, which is a significant weakness of
DGP that is yet to be solved by any routing protocol.