--------------------

TEMP-draft-kivinen-mobike-design-00.txt:

2.3 Scope of SA changes

   When the IKE SA address set changes, do we automatically change all
   the IPsec SAs negotiated with the IKE SA, or do separately request a
   change in each IPsec SA separately.

   If we want to update each IPsec SA separately, we propably need more
   efficient format than notification payload, as it can only store one
   SPI per payload. I.e. we want separate payload which have list of
   IPsec SA SPIs and new address set for them. If we have lots of IPsec
   SAs, those payloads can be quite large unless we support ranges in
   SPIs or at least have some kind of notation of move those SAs not
   moved separately (i.e. rest of the SA indication). We also have some
   problems that we need to keep state per IPsec SA which IP-addresses
   are used for that SA. If we automatically move all IPsec SAs when the
   IKE SA moves, then we only need to keep track which IKE SA was used
   to create the IPsec SA, and fetch the IP-addresses from that (Note,
   that IKEv2 [I-D.ietf-ipsec-ikev2] already requires implemenations to
   keep track which IPsec SAs are created using which IKE SA).

   If we do allow each IPsec SAs address sets to be updated separately,
   then we can support scenarios, where the machine have fast and/or
   cheap connection and slow and/or expensive connection, and it wants
   to allow moving some of the SAs to the slower and/or more expensive
   connection, and forbid some SAs to move. I.e. never move the news
   video stream from the WLAN to the GPRS link.

   On the other hand, even if we tie the IKE SA update to the IPsec SA
   update, then we need to create separate IKE SAs for this scenario,
   i.e. we create one IKE SA which have both links as endpoints, and it
   is used for important traffic, and then we create another IKE SA
   which have only the fast and/or cheap connection, which is then used
   for that kind of bulk traffic.

--------------------

IETF59 MOBIKE WG minutes:

Pasi Eronen: Is there a difference in functionality if we 
  could have redundant IKE SA's ?
Tero Kivinen: Some overhead for creating second IKE SA, but not that
  much. But this is one thing we have to decide.
Gregory ?: "Manual" option probably won't be needed, because you
  need some sort of policy saying which to move when.
Paul Hoffman: Same thing occured elsewhere, don't have policy
  to tell what to do.
Francis Dupont: I think it is useful to move separate SAs.

--------------------

Jari Arkko (2004-10-31):

Lets have a consensus call on this. From the list
discussion so far I don't see enough people commenting
on this that would enable us to make decision. For
a more accurate decision, I have broken the issue down
into three questions.

1. Would it be useful to treat different flows or applications
    in a different manner with regards to their multihoming
    behaviour? For instance, keep one flow always in GPRS
    but allow another flow to use LAN where available.

    Yes, mandatory [ ]
    Yes, optional  [ ]
    No             [ ]

2. Would you like to provide this functionality through

    Separate IPsec SAs and their independent addresses   [ ]
    Separate IKE SAs and their independent addresses     [ ]

3. If you prefer the use of IPsec SAs for this purpose,
    would you like

    always manage each SA separately           [ ]
    provide a default where all SAs are moved  [ ]

Send your answers by Wednesday, Nov 3rd, 2004. The rationale
behind your answers will help others form their opinions, so
please state also why you are answering in a particular way.

--------------------

Pasi Eronen, Mika Joutsenvirta, James Kempf, Tero Kivinen, Mohan
Parthasarathy, and Atul Sharma supported either not handling the 
whole issue, or making support for it optional; and if optional, 
handling it with separate IKE SAs.

Francis Dupont supported handling these with one IKE SA.

Thus, it seems the rough consensus was that "The addresses in 
all child SAs are updated at the same time."

--------------------