Re: [karp] Supporting Authentication Trailer for OSPFv3 -- replays

[Sam Hartman <[e-mail]>]

I've dropped the OSPF group from the CC list as I'm following up in part
from a conversation at the last KARP meeting.

Manav, your draft looks very interesting.  I definitely think that
protecting the IP address is an important addition to OSPF
authentication. As you helped us point out in
draft-hartman-ospf-analysis,an attacker who can observe packets can
destroy an adjacency in at least one direction simply by flipping the IP
addresses around.

Your draft doesn't handle what you described as inter-connection replay
protection.
In particular, the same key is used for all traffic, and the sequence
space is not subdivided.

If you use a time stamp as a sequence number, you are vulnerable to
significant denial of service attacks using intra-connection replays.

However, if you use a per-packet sequence number, you will eventually
run out of sequence numbers and wrap. One problem is that your
adjacencies go down when you wrap.  Another problem is that an attacker
who captured one of your old packets with a higher sequence number can
replay it after  the wrap and bring down your adjacency.

Your draft doesn't fix this problem.

we could decide we're not going to fix inter-connection replay issues. I
think that would be a huge mistake. We learned at the unwanted traffic
workshop that DOS concerns with routing protocols are a huge concern and
a powerful attacker tool. I think that is very much still true today. I
think it is especially true on enterprise and campus networks.

If we're going to solve this problem, we need to figure out where.  Eric
and Gregory were having a discussion about this during the last KARP
meeting.  Eric said that in order to use the key derivation process that
Gregory favored, there would need to be some sort of nonce
exchange. Eric was concerned that the routing protocols would not
change/did not already have the mechanisms to make this possible.

Let's take a look at how this could work in your draft. Let's assume
that in addition to sending a sequence number you sent a random nonce
that was constant until a peer reboots or needs to change its sequence
number.  Routers would need to keep track of the nonce in the neighbor
table and would also need to have some exchange  for proving liveness of
a nonce.

Here's how proving liveness would work. Router A receives a packet
including nonce and sequence number from B. A will be able to use the
nonce and sequence number to know if future packets from B are
replays. However A needs to know if this nonce is really B's current
nonce or if the initial packet is a replay. So, A needs to somehow get B
to send it a packet including fresh information provided by A along with
its current nonce. This could either be a new exchange or something
integrated into the hello process. It's possible that aspects already
present in the OSPF protocol could be used to accomplish this.  For
example, if we could convince ourselves that replays prior to an
adjacency actually reaching database exchange are harmless, perhaps we
could do something based off the database exchange or the like without
introducing any new messages.

It seems that if we're going to do this, we should do it in your draft.
Alternatively we could decide that adding the sort of nonces Gregory is
looking for is not something we can do.  In that case, I think we can
only get inter-connection replay with a KMP. Some of the reasoning here
is discussed in section 2.1 of draft-hartman-karp-mrkmp.

I'd appreciate your thoughts.