Subject: [Mobike] straw poll on issue 20 (selection ipsec sa addresses and who decides)

From: Jari Arkko <[email-masked]>
Date: Wed, 18 May 2005 15:12:02 +0300

Folks,

At IETF-62 and on the list we discussed this issue
that relates to what (outer) addresses are selected for the IPsec
SAs, and who decides these addresses, the initiator, both peers,
etc.

This is a central question for the design of the mobike protocol,
as it is hard to design further details without knowing the
what we decide here. For this reason I'd like us to do a straw poll
on what alternative people feel most comfortable with. The
alternatives are discussed in

  http://www.vpnc.org/ietf-mobike/issue20.txt

in more detail, but essentially its a question of
the following choice:

  Option 1: "MOBIKE just informs the peer of our addresses; how
  they get used is a matter of local policy beyond our scope."

  Option 2: "Use the preferred/primary address"

  Option 3: "Initiator decides"

  Option 4: "Use the preferred/primary address if possible"

  Option 5: "Peers decide the source addresses independently"

(There are potential other variants of design but these
seem to be the main ones, or at least the current concrete
proposals for the MOBIKE protocol are covered above.)

Please make your opinion, along with its justifications,
known by May 25th.

--Jari

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 18 May 2005 10:15:04 -0700

I prefer option 3.

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "MOBIKE Mailing List" <[email-masked]>
Sent: Wednesday, May 18, 2005 5:12 AM
Subject: [Mobike] straw poll on issue 20 (selection ipsec sa addresses
andwho decides)

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 May 2005 11:06:41 +0300

>   Option 3: "Initiator decides"

As we need to support NATs and supporting NAT quite often means that
either the design goes complicated or the host behind NAT (initiator)
decides which addresses to use.

So I vote for the this option. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 19 May 2005 14:52:42 -0700

>   Option 3: "Initiator decides"
I am assuming that this means that the initiator tests for bidirectional
reachability and then tells the peer about the working address.
One main reason why this seems favorable is because it works well
with NATs and Firewalls. It does not mean that it does not work when
they are not there. But may not work ideally e.g. two SGs connected
and only one of them can decide. So, why build a protocol with
this limitation ?  Does providing an option for either one of them to
choose or both of them to choose complicate the protocol (perhaps
there could be the ping-pong effect of each one changing back and
forth if both of them can choose) ? For example, the initiator says that
it wants to be the deciding factor. The responder knows that the initiator
is not behind a NAT (by looking at NAT-D payloads), then it might be
okay for the responder to choose also, right ? So, the responder can also
choose to be the deciding factor in this case. 

Though i *like* this option, it might make sense to provide some
flexibility for this option.

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 May 2005 07:20:58 +0300

Hi Mohan,

>choose to be the deciding factor in this case. 
I'm not sure if this is what you were looking for, but
the peers do have some ability to select who decides,
simply by choosing who is the initiator... and if you
don't like the initial arrangement, you could presumably
take the current connection down and re-initiate yourself.

--Jari

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 May 2005 08:50:38 -0700

<co-chair hat on>

At 3:12 PM +0300 5/18/05, Jari Arkko wrote:
>what we decide here.

I hope everyone in the WG noted that sentence. We are able to go 
ahead with the little input we have gotten so far, but it would be 
much better if we hear from many more people.

>  For this reason I'd like us to do a straw poll

That would be tomorrow, at least in my geographic location.

--Paul Hoffman, Director
--VPN Consortium

---

From: Geoffrey Huang <[email-masked]>
Date: Tue, 24 May 2005 10:15:53 -0700 (PDT)

I prefer option 3 for its simplicity. Also, it seems to me that the mobile
client-to-gateway scenario is such a compelling use case for Mobike, it
makes it natural for the initiator to decide.

-g

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 25 May 2005 17:57:31 -0700

> >  Option 3: "Initiator decides"

This seems to be the best choice to me.

Though I think we haven't yet precisely nailed down what we mean by
"initiator".  

					- Bill

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 May 2005 06:58:44 +0300

>This seems to be the best choice to me.
Yes, I like it too.

>Though I think we haven't yet precisely nailed down what we mean by
My understanding was that we are talking about the
original initiator of the IKEv2 connection, not the initiator
of a particular exchange later on. But I could be mistaken.

--Jari

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 26 May 2005 19:12:18 -0700

> of a particular exchange later on. But I could be mistaken.

so, the way I see it is that choosing the "one side in control" model is
the central part of resolving issue 20.

after we have implementation experience we may discover that certain
uses for mobike (sg-sg or other peer-to-peer uses) may require a
different way to pick which end is in control and we can add that
later... but only if absolutely necessary.

						- Bill

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 May 2005 08:33:19 -0700

It's pretty clear that there is consensus on Option 3: "Initiator decides".

--Paul Hoffman, Director
--VPN Consortium

---

From: Jari Arkko <[email-masked]>
Date: Sun, 29 May 2005 17:46:06 +0300

The issue list has five pending issues, some of which are now
being closed. This e-mail attempts to summarize the status
of those five issues:

3 (nat) -- My suggestion is that we close this issue at
               the level of detail we have now, and open new
               issues during protocol work, if necessary. See
    http://www.machshav.com/pipermail/mobike/2005-May/000807.html

6 (rr) -- closed. See
    http://www.machshav.com/pipermail/mobike/2005-May/000806.html

11 (window) -- closed, but here too we may open new issues
    when we see two alternative proposals here, now just one
    proposal available. See also
    http://www.machshav.com/pipermail/mobike/2005-May/000778.html

19 (same addresses in both directions) -- pending, discussion to
     end by Friday. See
    http://www.machshav.com/pipermail/mobike/2005-May/000805.html

20 (who decides) -- closed
    http://www.machshav.com/pipermail/mobike/2005-May/000804.html

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 29 May 2005 18:47:56 +0300

Folks,

It looks like we are coming nearer to concluding
our design issues. Great!

I'm sending this e-mail just to let you know that
Paul and I are discussing the next steps. Hannes
is already updating the design draft. But we also
need to start actual protocol work -- not just in
order to finally complete our work, but also because
we believe that the remaining details are hard to
discuss without seeing a concrete protocol in
front of us, designed in the manner that the WG
wanted.

We've had a number of individual drafts be published
and improved while the design discussion was going on.
Our intention is to get a WG draft out in its -00 form
in June. The idea is not to "pick a winner" among the
individual drafts, but rather to choose an editor and
have him or her write a protocol draft according to
guidance from the WG and using the design that we
agreed on. The protocol will be called MOBIKE, and
will most likely inherit quite a bit from individual
proposals (with appropriate acknowledgements for
contributions, of course). We've already got some
volunteer editors, but additional volunteers are very
welcome -- please contact either Paul or myself off the
list.

After the WG protocol draft is out we can start
reviewing it and looking at whether there are new
problems or design issues that we should worry about.
If all goes well, in Paris we will spend most of our time
polishing final details of the design draft and discussing
what needs to change in the protocol draft in its
next revision. I'm actually quite hopeful in terms of
not finding too many major issues in the protocol,
now that we have spent quite a lot of time and energy
on thinking about the design. So WG last call might
not be that far away. But this requirements effort
from everyone to talk about the issues, review the
initial draft, and so on.

--Jari

P.S. Please comment on the remaining issues (and
in time). We'd like to see more people participate the
discussion.