Re: MOBIKE WG Agenda for IETF-64, take 1

 In your previous mail you wrote:

   We have rfc3554 implemented, but I do not think any of our customers
   actually uses it. Or at least none of the customers have ever
   complained or questioned anything about it from our support people,
   and that usually means that they are not using it at all.
   
=> perhaps they are waiting for IKEv2/2401bis? (:-)

   Note also that RFC3554 had this wierd text that indicated that you
   could actually use ID_LIST in the Phase 1 IDs too, and that is not
   possible in the IKEv2. The ID payload of the IKEv2 is always single
   identity, not a list.

=> it seems the ID_LIST in the Phase 1 can be replaced by the additional
address stuff ("Specify multiple Phase 1 IDs, which are used to validate
Phase 2 parameters (in particular, the Phase 2 selectors)").

   The traffic selectors used in the IPsec SAs are
   lists so there should not be problem to use those in the SCTP.
   
=> I agree.

   The IKEv2 traffic selectors sent by the initiator must of course be
   such that the responder can narrow the TSr to be his own set of
   IP-addresses, i.e. the initiator sends TSi list with his own
   addresses, and sends 0.0.0.0.-255.255.255.255 and
   ::-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ip-adderess as TSr, so
   responder can then narrow it down to his own set of IP-addresses.
   
=> you assume the initiator doesn't know the responder addresses.

   I have not followed SCTP documents, but RFC3554 says that there
   currently is no way to modify the addresses when they are in use. Does
   anybody know if that has already changed, i.e. does the SCTP now
   support changing the addresses while it is in use? At least there are
   no RFCs yet about that.
   
=> there are some drafts which can add and/or delete addresses from
the peer address sets.

   Also the current SCTP model seems to be that it uses only the one
   IP-address pair at time, and only uses the others when the primary
   address pair is not working. This actually means that supporting that
   in IKEv2/MOBIKE is quite simple, and only requires basic MOBIKE
   abilities (i.e. the things we have in the draft now).

=> yes, the current SCTP model is the "failover" one.

Thanks

[email protected]

PS: the support of multiple *simultaneous* addresses in SAs seems to
be both not necessary and perhaps problematic in the 2401bis framework.
IMHO the update mechanism is enough so we should be able to adapt
easily (i.e., nothing to change, only an application note) current
MOBIKE to current SCTP, including SCTP mobility support.