Hi Sam, On 01/21/2011 06:13 AM, Sam Hartman wrote:
"Michael" == Michael Barnes<[email protected]> 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
