Re: [OSPF] [karp] Security Extension for OSPFv2 when using Manual Key Management

[Michael Barnes <[e-mail]>]

Hi Sam,

On 01/21/2011 06:13 AM, Sam Hartman wrote:
>>>>>> "Michael" == Michael Barnes<[e-mail]>  writes:
>
>      Michael>  I don't think the bandwidth is really an issue, but CPU
>      Michael>  is. It is important that processing of these packets can be
>      Michael>  completed as quickly as possible. We are constantly being
>      Michael>  asked to scale to ever larger number of neighbors and
>      Michael>  adding overhead to Hello packets could make this security
>      Michael>  mechanism undesirable in those settings.
>
> So, I don't think we can avoid a bit of overhead when we are bringing up
> a new neighbor association: we're trying to do new things in that
> situation.  I've thought about it and the overhead in that situation of
> having the exchange in the hello is less than with extra challenge
> response packets.
>
> So, we're left with the question of what's the overhead when we already
> have a neighbor relationship That's the common path and so it is our
> primary goal for optimization.
>
> I went to read the description of receiver behavior in the draft to
> confirm my understanding of what the overhead is.  I found a bug: it
> turns out that the behavior of hello packets for neighbors in two-way or
> greater is unspecified.  It's intended to be the same as the behavior
> for non-hello packets.
> So, let's look at what that behavior is:
>
>          <t>If a packet other than a hello is received with the new
>          cryptographic authentication option, it must correspond to an existing
>          neighbor relationship in at least the 2-way state. If the neighbor is
>          not in 2-way state or greater, the packet is discarded. If the session
>          ID does not match the session ID recorded with the neighbor, the
>          packet is discarded. If the sequence number in the cryptographic
>          authentication option is not strictly greater than the sequence number
>          associated with the neighbor, then the packet is discarded. If the
>          cryptographic verification of the checksum fails, the packet is
>          discarded. Otherwise, the packet is accepted by the cryptographic
>          authentication and the sequence number associated with the neighbor is
>          updated to be the sequence number in the packet.</t>
>
> So, if we update that first sentence to say that section applies to all
> packets where the neighbor is in 2-way state or greater, we get correct
> behavior.  So, what new overhead do we need?  First, we need a compare
> against the neighbor state; if it is not 2-way or greater, we need to go
> to a less optimal path.  Then we need to compare the session ID.
>
> That's the only new behavior.  We change the sequence number check from
> greater than or equal to to strictly greater than, but on all hardware
> I'm aware of, that's the same performance.  So, we've added two
> operations to the reception of packets for existing neighbors. The
> operations can be executed in parallel. On a general purpose CPU, both
> operations would be single instructions.
>
> My opinion is that is likely to be acceptable to any environment where
> cryptographic authentication is acceptable.
>
> Note that while we send additional information in a hello packet, we
> only need to look at that information when setting up a new neighbor.
>
> So, let's take a look at what we've done to sending a hello packet
> because that's also a common operation.
>
> We've added two items of state for each neighbor: the session ID and
> nonce. I guess copying these values into a constructed outgoing packet
> could be considered per-neighbor overhead. However, an implementation
> could choose to construct the neighbor list of the outgoing hello packet
> and store it in a buffer, updating only when the neighbor list
> changes. So, there is an implementation strategy that does not change
> the cost of sending a hello in the steady state.
>
> I'll also note that the effort required for the "slow" path (updating
> set of neighbors) is modest: we're talking about a couple of compares
> and neighbor structure updates.
>
> This conversation has been fairly useful.  I've noticed a couple of
> places where we can optimize receiver behavior to reduce number of
> packets and to improve convirgence in case of reboot.  We might even be
> able to optimize what locks you're likely to hold when a bit. (I realize
> that where locks are in a data structure is very implementation
> dependent, but there are things we can do like minimizing the cases
> where fields need to be updated that are valuable here.)
>
> So, I'll work with the other authors to fix the bug I pointed out above
> and to improve the receiver behavior.
>
> Now that I've thought about the tradeoffs between challenge packets and
> using the hello, I think that the CPU impact of hello packets will be
> lower than that of challenge packets. So, my preference is to stick with
> our original design.

I do have a concern which I don't think you addressed. The size of the 
packet may have increased significantly (for some link types we may have 
more than a handful of neighbors). So when considering a stable link it 
may be hundreds of thousands of Hello packets exchanged for a given 
interface where that extra data is not needed yet the hash algorithm 
must be run, on both sender and receiver, for all of that unused data. 
Multiply by dozens or perhaps even hundreds of interfaces. I disagree 
that over the long term the CPU impact will be lower than if challenge 
response packets were used. I'm not really happy about wasting CPU 
cycles that way.

Regards,
Michael