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

 In your previous mail you wrote:

   >=> I don't believe it is very useful to discuss about the
   >transport mode/Mobike I-D (according to comments about it in
   >the list, BTW the I-D does not address issue #7).
   >
   >For SCTP it is clear there is something to do but not so clear what...
   >BTW is the RFC 3554 supported? (if it is we should get the feedback
   >from an implementor)
   >
   >For multi-homing in general I believe we should reconsider
   >the issues #8 and #20. Of course the issue #63 could apply.
   >(who should present this? IMHO we mainly need a discussion)

   The transport draft does not have too many details.

=> it doesn't need to get more details (:-). What do you want
which is not in issue #7?

   We do not have a written proposal on the table for
   SCTP support nor issue #8 extension of MOBIKE*.
   
=> for SCTP we have to know what is really need.
For the issue #8 the proposal is to simply add the list
of IKE and IPsec SAs to update with a simpler form which
updates every SAs (as we already have).

   However, as we are progressing with the base protocol
   we now have some possibilities to discuss future things.
   I think we should use this opportunity now, and if you
   think some of the above issues are important, I would
   recommend reserving a slot to talk about it.

=> I believe this was implied by my answer to the agenda call?

   It may
   require some preparation from you, however, such
   as figuring out what the SCTP implementation situation
   is or what issues are in providing additional IPsec/MOBIKE
   support for SCTP.
   
=> I prefer we get first feedback for RFC 3554 implementors:
IMHO if nobody has implemented it and nobody cares, it is the
sign the RFC 3554 way is wrong.

   Obviously, drafts and details are going to be needed at
   some point, but what we actually wanted to talk about in
   the meeting, I think, is more about the requirements more
   than the bits.

=> this is why I've begun with old issues which are about design
choice, i.e., requirements.

   What do we want to achieve? Who would use
   that, and would it fall within our job or somewhere else?
   Details would also be useful in order to get an
   understanding of what functionality X would mean in
   terms of the bits, but they are not an absolute requirement.
   
=> I agree: it depends on the case.
   
   *) I don't think #8 extension needs #20, and personally
   I'd rather not see #20 changed.
   
=> the "initiator decides" is very bad for multi-homing and
full freedom can become too easily full mess. My idea is to
split between initial and update:
 - initial IKE SA addresses are the addresses used in initial
   exchanges (IKE_SA_INIT and IKE_AUTH)
 - initial IPsec SA addresses are the addresses of the
   IKE SA which creates it at the creation time
 - updates can change any IKE SA or IPsec SA pair addresses
   (the new remote one has to be in the set declared by the peer).
 etc.
IMHO this setup then move is enough and simple enough to be
well understood.

Regards

[email protected]