The section 2 describing RFC4306 crash recovery is not complete. It
does not include the normal processing happining on the peer that is
not rebooting.
I suggest adding following text:
--
When the one peer loses state or reboots i
Raj Singh writes:
> > It's actually worse than that. If message #4 was missed, and 5-8 were
> > received, then messages 5-8 are stored, but not processed. This has to be
> > so, because suppose message 7 deletes the SA that was created in message 4,
> > you can't process it before message 4. In any
Yaron Sheffer writes:
> >> Alternatively it would simplify things immensely if we mandate that SPIs
> >> be random for implementations that support QCD (possibly only on the
> >> gateway side). Can we do it without having to "update RFC 4306"?
> >
> > I think it's enough to require this of the toke
Pekka Riikonen writes:
> - Should there be way to negotiate support for IKE SA window sync but not
> for IPSEC SA sync? Currently by sending SYNC_SA_COUNTER_INFO_SUPPORTED
> you agree to support both, which can mean you may receive the IPSEC SA
> syncs.
That was my main request during the last
Raj Singh writes:
> Now, say failover happened at 30, 500. So, standby member
> becomes active, and it start using IPsec replay counter from 30,
> 000. It will be considered as Replay Attack and SA has to be
> destroyed.
If you have replayed incoming packets, you do consider that replay
attac
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 t
Tero writes:
> I think it would simplify the implementations and the protocol by just
> limiting that only responders can be token makers without loosing any
> of the functionality.
I don't think we should limit this. First, rekeys can easily reverse the
sense of who is initiator. Second, it i
Scott C Moonen writes:
> > I think it would simplify the implementations and the protocol by just
> > limiting that only responders can be token makers without loosing any
> > of the functionality.
>
> I don't think we should limit this. First, rekeys can easily reverse the
> sense of who is init
: 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 pac
Tero,
> I was thinking about the original initiator, not the exchange
> initiator.
Ok, but this then imposes an awkward new requirement to remember the
"original original initiator," as it were. Today the initiator of the
rekey becomes the original initiator of the rekeyed IKE SA.
> > Second,
On Wed, 8 Sep 2010, Tero Kivinen wrote:
: In many environments it is quite possible to keep the IKE SA state in
: sync between the cluster members, especially if the liveness checks
: are used correctly, i.e. only when needed, not every n seconds. I.e if
: IKE SA messages are only sent when Child
11 matches
Mail list logo
