J. Sun writes:
> 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
> result, it would be what you consider a copy. However, you shouldn't
> really think about it in that way. Depending on implementation,
> generally speaking - CHILD_SAs existing in a SAD would simply have an
> object that essentially references the parenting IKE_SA. After the
> successful IKE_SA Rekey, the CHILD_SA simply would update this object to
> simply point to its new parent, the rekeyed IKE_SA. But to qualify, it
> all really depends on implementation.
Actually it is more like of move, not copy, i.e. just like you explain
in the end. There is no two copies of the same Child SA, there is only
one, and that one has exactly one parent SA, i.e. either the old or
new IKE SA, depending on where we are at the IKE SA rekey process.
I.e. it is mostly:
IKE SA A - Expiring IKE SA B - Rekeyed
No Child SAs Moved Child SA from A
all Childs are moved to new IKE SA SPI (incoming) 0x12345678
Protocol AH
Same cryptographic suite
as A's Child SA (moved)
I.e. after that you MUST send all management traffic relating the
Child SA using the new IKE SA B, you cannot use IKE SA A anymore for
delete notifications or similar relating to the Child SA which was
moved.
Note, also that in case of the simultaneous rekeys, you need to move
the Child SAs to the winning IKE SA.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
