![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
>> But the real problem are application session: They might break during
>> these communication interrupts, and are guaranteed to break if the
>> INTERNAL_ADDRESS changes.
>
>I agree, thats why I think the way you presented there where you first
>remove the IKE SA and then start it over so you get the same address
>is the only one that really works. In most cases for remote
>access cases you have only one IPsec SA so creating new IKE SA and
>that IPsec SA is fast and should not disturb normal TCP/IP flows
>(unless your operating system does stupid things, like destroy all
>TCP/IP flows when you do the recreationg of the IKE SA).
Are we clarifying the IKEv2 clarifications now? RFC 4718 states:
IKEv2 does not have any special support for reauthentication.
Reauthentication is done by creating a new IKE_SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
payloads), creating new CHILD_SAs within the new IKE_SA (without
REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
deletes the old CHILD_SAs as well).
The suggestion above contradicts 4718. It seems as if the best resolution
would be to add real support for reauthentication.
Dave Wierbowski
z/OS Comm Server Developer
_______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec