On 3-okt-2006, at 13:41, Fred Baker wrote:
The purposes of the TCP-MD5 protocol is to ensure that two TCPs
that don't have the same keys can't communicate. I think it
accomplishes that, sooner or later.
Your concern is that it might be too frisky getting there. I'm
proposing that you be in control of how quickly you get there by
how you set the "delete" timer.
Well, sure, if your intent is to make sure you stop communicating
with your peer when they don't implement a new key, that will
certainly work.
My concern is the case where this happens by accident because of some
operator error or miscommunication between the two ASes involved.
What happens today in this case is that the session goes down
immediately after the operator configures the new key. This means the
issue can be resolved rightaway.
In a system where old keys are retired at some point in time AFTER
the configuration change, it's much harder to resolve any issues.
This is made worse by the fact that the time when the problem occurs
can't be predicted reliably: you never know whether your timestamp
will determine the change or the one set by the other side, and if
the other side didn't put in the right key they could also very
easily have put in the wrong timestamp, even without NTP or timezone
problems.
So I think most operators would prefer to do a key rollover where the
old key remains valid indefinitely and is removed manually rather
than automatically after some time.
Suggestion: don't start sending ALL traffic with all keys, just
throw in a copy of a packet signed with the new key once in a
while and keep using just the old key for most traffic until a
packet with the new key is received from the other side.
Well, one approach to my "optimization" would be start sending all
new traffic with the new key, but retransmit with the old key.
This is exactly the kind of complexity that is best avoided... It
would be much better to have the key rollover mechanism function
autonomously without having to be aware of higher layer state.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf