Subject: Re: [Mobike] MOBIKE WG Agenda for IETF-64, take 1

From: Francis Dupont <[email-masked]>
Date: Wed, 02 Nov 2005 10:39:39 +0100

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-masked]

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.

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 2 Nov 2005 15:19:18 +0200

> => you assume the initiator doesn't know the responder addresses.

I assume he does not know all of the address the responder is using.
He might know one or few, but not necessarely all. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 2 Nov 2005 19:01:53 -0800

Folks,

This is the summary of the use cases for transport mode SA as far as i understand it.

1)  SCTP : IKEv2 already supports proposing multiple addresses using TSi/TSr.
                  SCTP seems to support a draft where one can add address dynamically.
                  MOBIKE needs to be used for supporting that draft.

2) MIP6 : Related to the transport mode SA used in sending Binding updates.

        a) Adding Home address to the peer address set (don't know how RR would work
           for this). Mentioned in Francis draft. 

        b) Another potential use case is using it for CoA  authorization check 
            where MOBIKE provides the RR check for the CoA in the BU
            (this is different from the one mentioned in Francis draft)

3) Issue 7: IP-IP tunnel with transport mode SA protection. MOBIKE support for upating
                 the tunnel endpoints.

4) TCP connection : Similar to how IKEv2 NAT-T is supported, MOBIKE can also be
                                supported.

>From the discussion in the list, 

    - it looks like (1) is not that heavily used and so may not justify adding support
    - 2.a and 2.b should at least be discussed in the MIP6 mailing list also
    - (3) may be a more common case that needs to be supported
    - 4 may never be implemented today and hence not attractive at all.

Comments ? Does (3) make sense ?

-mohan

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Nov 2005 22:40:27 -0800

> Comments ? Does (3) make sense ?

IMO, yes - see RFC 3884 ;-)

Joe

---

From: Francis Dupont <[email-masked]>
Date: Thu, 03 Nov 2005 10:54:14 +0100

This is the summary of the use cases for transport mode SA as far
   as i understand it.
   
   1) SCTP : IKEv2 already supports proposing multiple addresses using
      TSi/TSr. SCTP seems to support a draft where one can add address
      dynamically. MOBIKE needs to be used for supporting that draft.
   
   2) MIP6 : Related to the transport mode SA used in sending Binding updates.
           a) Adding Home address to the peer address set (don't know
              how RR would work for this). Mentioned in Francis' draft. 
           b) Another potential use case is using it for CoA
              authorization check where MOBIKE provides the RR check
              for the CoA in the BU
              (this is different from the one mentioned in Francis' draft)
   
   3) Issue 7: IP-IP tunnel with transport mode SA protection. MOBIKE
      support for updating the tunnel endpoints.
   
   4) TCP connection : Similar to how IKEv2 NAT-T is supported, MOBIKE
      can also be supported.
   
   >From the discussion in the list, 
   
       - it looks like (1) is not that heavily used and so may not
         justify adding support

=> IMHO there is no support to add: we need only an "application note"
explaining how to use IKEv2/2401bis/MOBIKE for SCTP.

=> in this case we need a text and a place to put it.

=> I agree!

=> it seems easy so as soon as someone has an interest in it...

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 03 Nov 2005 10:58:37 +0100

=> thanks, I was waiting for your opinion.