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

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Oct 2005 10:37:36 +0300

IETF-64 MOBIKE WG Agenda

Time:
  WEDNESDAY, November 9, 2005
  1300-1500 Afternoon Session I
  1510-1610 Afternoon Session II

Chairs:
  Jari Arkko <[email-masked]>
  Paul Hoffman <[email-masked]>

PRELIMINARIES (10 minutes)

 Bluesheets
 Agenda Bash
 Document Status
 Open Issue Summary:
 http://www.vpnc.org/ietf-mobike/issues.html
 Presentations and agenda online at:
 https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64

Base Protocol (Pasi Eronen)
  http://www.vpnc.org/ietf-org/draft-ietf-mobike-protocol-06.txt (to appear)
  - Discussion of remaining last call issue resolutions, if any
  - We intend to close everything before Vancouver and once the
    document submission re-opens, submit and send the draft to the
    ADs

Design Draft (Tero Kivinen)
  http://www.vpnc.org/ietf-org/draft-ietf-mobike-design-04.txt (to appear)
  - Discussion of remaining issues
  - Note: this is NOT for rehashing the decisions to change the protocol.
    This is about documenting the decisions and their rationale.

Extensions and New Work

  (Please submit agenda requests. Transport, SCTP, API, etc?)

Discussion of next steps (chairs)

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 10:56:23 +0200

In your previous mail you wrote:

   Extensions and New Work

=> 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)

Regards

[email-masked]

PS: http://www.vpnc.org/ietf-mobike/issues.html
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Oct 2005 14:34:11 +0300

>(who should present this? IMHO we mainly need a discussion)
The transport draft does not have too many details.
We do not have a written proposal on the table for
SCTP support nor issue #8 extension of MOBIKE*.

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. 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.

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. 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.

--Jari

*) I don't think #8 extension needs #20, and personally
I'd rather not see #20 changed.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 15:36:30 +0200

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

=> 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).

   recommend reserving a slot to talk about it.

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

   It may
   
=> 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.

   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
   
=> I agree: it depends on the case.

=> 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

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 26 Oct 2005 09:59:10 -0700 (PDT)

--- Jari Arkko <[email-masked]> wrote:

>From what i can remember reading the transport draft
last time, it is not clear to me what it was trying to
address. It talked about how MOBIKE can be used for
MIPv6 BU protection and SCTP which are both transport
mode. Today, it already works with IKEv1/IKEv2. So,
why do we need MOBIKE ? 

Another *possibility* for transport mode MOBIKE is the
following. Today NAT-T works for transport mode SAs
also. This means if you establish a TCP connection
across a NAT to the server on a public address, and
the NAT changes the mapping and the TCP connection
would still work. TCP connection on the server is
still bound to the old NAT public address but IPsec
has updated itself to the new address. Now i don't
know how many implementations really work for this
case. (Perhaps it works only for L2TP, GRE over IPsec
like tunnels). With MOBIKE, one can still change
the address and send an UPDATE to the peer. The
transport connection should work without a change.
I have not thought out all the details. Is this an
interesting case to be solved by MOBIKE ?

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 19:27:22 +0200

=> MIPv6 BU protection and SCTP have an authorization issue
(remember the zillion of messages in the mip WG mailing list
about this). The address management provided my MOBIKE
is a clean and simple solution to this issue.
So MOBIKE is not needed but simplifies the world.
(you should reread the draft, even you are one of the few
persons I know they have read it :-).

   also.

=> not in the IKEv2 framework (i.e., NAT-T support for
transport mode is an extension).

   This means if you establish a TCP connection
   case.

=> only a little number because the IPsec marker is VPN,
i.e., tunnel mode only.

   (Perhaps it works only for L2TP, GRE over IPsec
   like tunnels). With MOBIKE, one can still change
   the address and send an UPDATE to the peer.

=> note with transport mode you don't change the endpoint
addresses but the traffic selectors.

   The transport connection should work without a change.
   I have not thought out all the details. Is this an
   interesting case to be solved by MOBIKE ?
   
=> this is the issue #7 and I explicitely didn't propose
to reopen it (you can but please don't mix this with my
transport mode/MOBIKE draft).

Regards

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 26 Oct 2005 11:22:15 -0700 (PDT)

--- Francis Dupont <[email-masked]>

> persons I know they have read it :-).
In the case of MIP6 it might make sense because
MN-HA MUST use IPsec to protect BUs and MOBIKE
provides the RR check for the CoA. But SCTP has to
solve the authorization issue anyway because you
may not use IPsec with SCTP always.

> transport mode is an extension).
I am not sure i understand this.
Can you point me to a section in IKEv2 draft which
states this ? 

> => only a little number because the IPsec marker is
Agreed.

> addresses but the traffic selectors.
Not in this case. In this case the traffic selectors
don't change across mobility. I just realised that
this has the same problems as the "spi collisions"
issue. The transport connection is still bound to the
original address which can be reused by some other
node. But should be less of an issue with "IP-IP"
transport mode like tunnels i guess.

> transport mode/MOBIKE draft).
Issue 7 is about transport mode. You have to reopen
it for your draft too :-)

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 23:07:43 +0200

In the case of MIP6 it might make sense because
   MN-HA MUST use IPsec to protect BUs and MOBIKE
   provides the RR check for the CoA.

=> hum, it seems we are in complete misunderstanding...
In MIPv6 the MN-HA IKE is run over the CoA but the IPsec SA
pair in transport mode must be established with the HoA.
So IKE has to check if the MN has the authorization to use
this particular HoA. In place to have a dedicated code for MIPv6
in IKE I simply propose to use the MOBIKE framework to add the
HoA as an additional address and to check (not using RR please :-)
if it is authorized.

   But SCTP has to
   
=> I am talking about authorization of additional peer addresses
in IKE/IPsec.

   > => not in the IKEv2 framework (i.e., NAT-T support
   > for transport mode is an extension).

=> I believed there was no NAT-T support for transport mode because
there is no NAT-OA but you are right:

      The original source and destination IP address required for the
      transport mode TCP and UDP packet checksum fixup (see [Hutt04])
      are obtained from the Traffic Selectors associated with the
      exchange.

Note this makes more complex to path the Traffic Selectors (:-).

   But should be less of an issue with "IP-IP"
   transport mode like tunnels i guess.

=> yes, the IP-IP transport mode is clearly a special case.
(there is a comment by Joe Touch about this in issue #7)

=> the issue #7 question is a bit ambiguous but as it is from
a comment of mine, the real issue is about peer address change
for transport mode SAs (so not addressed by my draft)
So can we agree that to reopen the issue #7 is to look at
if/how to update transport mode SAs?

BTW my opinion is the complexity is too high and the current
solution (reestablish SAs with new addresses) is enough
in the general case.
   
Regards

PS: for the tunnel special case (the traffic is selected by it is
in the tunnel, i.e., a particular interface and protocol) we have
two choices:
 - write a specific document
 - add it in the transport document (I can provide the current
   version in xml2rfc to a co-author who shall write the text).
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 26 Oct 2005 14:54:56 -0700 (PDT)

wrote:

>    > (you should reread the draft, even you are one
> of
>    > the few
hmm.. i am not sure whether there were zillions of
mail
on this case :-)

> HoA as an additional address and to check (not using
So, the authorization still happens the same way as
defined in RFC 3776.  It is just that you are using
a different mechanism to convey the home address i.e
instead of ID/Traffic selectors i.e you are using
MOBIKE mechanism. Am i understanding this right ? 

> if/how to update transport mode SAs?
At least that was my understanding :-)

> solution (reestablish SAs with new addresses) is
I am not sure i agree on why this is more complex.

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Oct 2005 00:40:43 +0200

defined in RFC 3776.

=> yes, the authorization is still needed.

   It is just that you are using
   a different mechanism to convey the home address i.e
   instead of ID/Traffic selectors i.e you are using
   MOBIKE mechanism.

=> I still use the traffic selectors but never the ID.

   Am i understanding this right ? 

=> more but perhaps not yet the whole idea. How to do express
the authorization in your favorite IKE implementation?
Does it work well with a dynamic HoA? With MOBIKE there is no
problem, or if your prefer, MOBIKE has the problems and
MIPv6 relies on the solutions used for MOBIKE.
   
   > So can we agree that to reopen the issue #7 is to
   > look at if/how to update transport mode SAs?

   > BTW my opinion is the complexity is too high and the...

=> I have done many times the code for MIPv6 (updating tunnel endpoints
in IPsec SAs, SPDs, IKE) so I know it is not so difficult. I don't know
how to do for general transport mode, i.e, updating traffic selectors.
So I prefer to avoid a specification which is too hard to implement
(so won't be implemented) without a proof of a real need.
   
Regards

---

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Oct 2005 10:23:45 +0300

Hi Mohan,

>So MOBIKE is not needed but simplifies the world.
These are precisely the type of questions we'd
have to figure out before starting work.

>interesting case to be solved by MOBIKE ?
Possibly. What I'd like to see before taking
on any new work is a rationale why some
function is needed and a scenario where this
is used. I can see what you are saying technically,
but we'd have to figure out who would use
it. Where is transport mode IPsec used today,
and would it benefit from MOBIKE support?
Would potential users adopt it?

--jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 27 Oct 2005 09:11:45 -0700

> Would potential users adopt it?
Completely agreed.

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Oct 2005 11:44:51 +0300

> sign the RFC 3554 way is wrong.

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.

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. The traffic selectors used in the IPsec SAs are
lists so there should not be problem to use those in the SCTP.

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.

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.

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).
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Oct 2005 12:02:20 +0300

>support changing the addresses while it is in use? At least there are
Real experts should be answering this, but
draft-ietf-tsvwg-addip-sctp-12.txt appears to be
able to do that. Tracker says the draft is "active",
which does not tell me much.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Oct 2005 11:30:37 +0200

> sign the RFC 3554 way is wrong.
   
   We have rfc3554 implemented

=> fine! It seems we have found the right person to launch the
discussion.

Regards