: Pekka Riikonen writes:
: > The window at the remote peer will move to 31000; no replay errors.
:
: That is true for outgoing packets. That is not possible for the
: incoming packets, as attacker can replay packets sent to you just
: before it caused you to crash, thus causing those replayed packets to
: get through.
:
: > The issue is only with outbound sequence numbers, because as we know, the
: > window can move always forward with incoming packets. So even if the
: > incoming window is lagging behind it will always move forward when the
: > remote sends new packets to us.
:
: But before there is any packets from the real peer having bigger
: sequence numbers, the attacker can send old replayed packets from time
: before crash, and cause those replayed packets to be accepted.
:
I agree there is a small window for attacker to be able to replay old
packets, but this would mean the attacker has to record old packets and
has to know exactly when the failover happens (of course if attacker can
induce the failover, this is serious).
In principal I'm not against having the IPSEC SA sync also in this
protocol, but if it is left in, I think we have to have a way to negotiate
which of the sync methods peer wants to use. Either message id sync, or
ipsec SA sequence number sync or both.
Pekka
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
