This is a 2 week working group last call for
draft-ietf-ipsecme-ikev2-redirect-08. The target status for this document is
Proposed Standard. This is the document's second last call, following
comments by a number of people and several document revisions.
Please send your comments to the ipsec list
I see that in section 6 the following:
In such cases, the gateway should send the REDIRECT notification
payload in the final IKE_AUTH response message that carries the AUTH
payload and the traffic selectors. The gateway MUST NOT send and the
client MUST NOT accept a redirect in an ear
I don't know the current status about this.
I would suggest that this could be left as it currently is. When reading the
section about rekeying IKE SAs (1.3.2), it is easily deduced that rekeying
will have the effect of resetting the Message IDs of the SA to 0. Section
2.18 also states this.
Perh
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working
Group of the IETF.
Title : Heuristics for Detecting ESP-NULL packets
Author(s) : T. Kivinen, D. McDonald
Hello,
When rekeying an IKE SA, the traffic from the old (expiring) SA has to be
moved to the new (rekeyed) SA. How does this go about? Are equivalent Child
SAs created for the rekeyed IKE SA created and the ones in the old IKE SA
deleted (by deleting the IKE SA), or is all data of the Child SA (S
Matthew,
It has to be Case #2. No where in the CREATE_CHILD_SA - IKE_SA Rekey
exchange do you update to the other endpoint the new CHILD_SA SPIs -
without exchanging the CHILD_SA SPIs, you'll most definitely run into
interoperability issues, namely you'll start black holing traffic. As a
re
Hello,
Yoav Nir wrote:
I see that in section 6 the following:
In such cases, the gateway should send the REDIRECT notification
payload in the final IKE_AUTH response message that carries the AUTH
payload and the traffic selectors. The gateway MUST NOT send and the
client MUST NOT a
