>Recall that the problem being addressed (which was the topic of two
presentations at the last RPSEC WG meeting) is how to quickly
determine if purported management (vs. subscriber) traffic directed
to a router is from an authorized source.
Now, first, I must admit that I had been meaning to read over the
previous exchanges carefully, so I might have missed a subtle shift
in the discussion, so what I say here might have been overtaken by events.
I thought that the presentations in the IETF meetings were devoted
to this problem with a bit of an addition ".... and no crypto techniques
run fast enough to solve this with authentication. In fact, using
crypto makes the problem worse." Given that comments on the list have
been claiming that TCP MD5 is not useful in preventing the DoS attacks
against the BGP port because it just makes the router processor work
harder for each packet, I'm not sure that a crypto-focused proposal
would win over those proposing the TTL=255 approach.
If the benefit is that it is the interface card that is doing the crypto,
not the router processor, would moving the TCP MD5 processing to the
interface card provide the same benefits as your technique? (OK, so
TCP MD5 doesn't have sequence numbers, and this technique does, but
off-loading wise.) Or perhaps the advantage of this approach is that the
amount of data processed by the one-way function is very small, resulting
in increased speed?
--Sandy
I think it would be wrong to maintain that "no crypto techniques run
fast enough" since we have some pretty fast, simple techniques that
have become available over time. Note that we don't need a MAC or
hash function for this purpose. A simple stream cipher would probably
suffice. Moving MD5 to the interface card would address the current
problem for BGP neighbor traffic, but since it is a TCP-level
mechanism, it would entail moving a lot more mechanism to the card
than just the crypto check.