Subject: AW: [Mobike] latest draft snapshot

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 10 Feb 2005 22:17:34 +0100

# hi bora, 

# please see my comments below; 

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email-masked]] 
> Sent: Sunday, February 06, 2005 7:45 AM
> To: 'Bora Akyol'; [email-masked]
> Subject: AW: [Mobike] latest draft snapshot
> 
<snip>
> > 1) Editorial:
> > 
> > I think in section (3) scenarios, if we had previously reached 
> > consensus that at a given time only one address pair will be used, 
> > then I recommend trimming this section down to:
> >   -- Break-before-make address transition
> >   -- Make-before-break address transition: (the bottom two 
> are really 
> > examples of MBB address transition)
> 
> you mean instead of the differentiation between the three scenarios?
>     3.1  Mobility Scenario
>     3.2  Multihoming Scenario
>     3.3  Multihomed Laptop Scenario
> 
> or do you want to further differentiate the mobility scenario 
> into sub-sections that provide more details on the 
> break-before-make  vs.
> make-before-break scenario?

No actually, I think you should have just two scenarios:

break-before-make AND
make-before-break

these are the root scenarios for MOBIKE from what I can understand.

# i am not quite sure. in a multi-homing environment there is no notion of
break-before-make or make-before-break.
hence, why don't we stay with the original scenarios where we have
multi-homing, mobility and the combination of both? 

> > 
> > Figure 3: Framework (while being really a nice figure) does not 
> > capture many implementations and scenarios that are deployed in 
> > various devices today. So I would consider this figure as 
> an example 
> > of a UNIX-centric host implementation as opposed to what may end up 
> > being deployed in a security gateway. I suggest (and I can 
> help with 
> > this), replacing this figure with something considerably 
> simpler that 
> > has basic building blocks.
> 
> if you have a suggestion for a better figure please let me know. 
> i am probaly not the best ascii art designer. 

There is nothing wrong with the drawing of the figure, what is wrong with it
is that it takes a UNIX centric view of how IPSEC/IKE implementations work.

This is what I was trying to point out.

# do you think we would be fine if we write a sentence below the figure?
something like:
"this figure is only one way of implementing mobike in a system. it serves
illustrative purposes only."

# i don't want to redraw the figure - ascii drawing takes such a long
time...

<snip>
> 
> > 
> > In general, I think rename this draft to be "Framework for MOBIKE." 
> > Then do a requirements draft that has as little text as possible.
> 
>  i hope that we do not need a requirements draft since we 
> already came quite far and are hopefully finished with the 
> work in mobike. making progress would be a good thing. 

Well, I think the WG has a choice on this, I think this document is
suitable as a framework document, for requirements, I think we need
a more terse and succint document just pointing out what the implementation
needs to do. That is of course my opinion.

# i would like to make some progress in the working group. we are already
spend far too long on the existing work. 
# if there are some requirements which we haven't discussed then they should
be included in the current document. 
# regarding the implementation requirements: the specs should provide
information on what is MUST, SHOULD or MAY. 

> 
> > 
> > 2) Substantive:
> > 
> > I disagree strongly with the need to be able to "test connectivity 
> > along a path and thereby detect an outage situation" other 
> than what 
> > we do in IKEv2 DPD today.
> 
> i have only tried to use a different name for the actual 
> concept used by a particular solution specification. as you 
> have there is the possbility to reuse the dead peer detection 
> mechanism (or a slightly modified version of it). 
> 
> there is nothing more behind this connectivity test - no 
> fancy new mechanism. 

Right, but why is this a requirement of __any__ implementation?
At best it should remain as an __optional__ capability.

# i think that dead peer detection is already a mandatory implementation
feature in ikev2. 
# if we use this approach (or a slightly modified version) then i don't
really see a big problem. 
# what do you fear? the implementation overhead - not really? 

> > With mobile users expected to be in the 1,000,000 range per 
> security 
> > gateway, the amount of state and processing that needs to 
> be performed 
> > is significant when the SG tries to detect path changes other than 
> > what we do with DPD. If the client decides to do this, then it is 
> > fine. However, even with DPD, then the SG needs to try several IP 
> > addresses to see which ones work is a significant burden on the SG. 
> > Therefore, I would suggest that we clarify what functionality is 
> > required on a client vs security gateway (yes, this focuses 
> mostly on 
> > the VPN scenario, but that is the main push for MOBIKE as far as I 
> > understand).
> 
> i fully understand your concern.
> 
> based on my clarification above do you see the need for a 
> clarification somewhere in the draft?
> 

Yes, I think we should point out that for the SG, this capability is
optional.

# a connectivity test does not work if only one entity supports it. 
# furthermore, you can already use dead peer detection or other messages
that perform the same function already today. 
# what is the problem? 

> > 
> > Fundamentally, I think we have three problems that we need to solve:
> > 
> > 1) Identify a peer regardless of the IP address it chooses to use.
> > (Not-mutable Peer Identity)
> 
> yes, but this is an issue for ikev2 or rather for the network 
> architects/users to decide which identity they want to use 
> for authentication. 

Regardless of whether this is an IKEv2 issue or not, without this
capability,
we can not do MOBIKE, right?

# that's true and it is true for all mobility protocol (mobile ip, for
example). 
  
> > 2) Change the IP address pairs associated with IPSEC and 
> IKE SAs while 
> > not impacting the data path significantly.
> 
> certainly, the address update aims to be efficient. 
> 
> > 3) Clean up resources on both ends of the connection(s) so that 
> > neither end (but especially the SG is not susceptible to resource 
> > outages)
> 
> which resources do you want to clean up? do you mean when a 
> peer crashes it must be ensured that no orphan states are 
> left behind? 
> 
> > 
> > 
> > I think the framework does a good job of identifying these problems.
> 
> yes, the working group has done a good job of discussing the 
> various design issues that effect a solution. 
> 

# ciao
# hannes

Thanks

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

---

From: "Bora Akyol" <[email-masked]>
Date: Thu, 10 Feb 2005 14:49:27 -0800

See inline:

> Sent: Thursday, February 10, 2005 1:18 PM
> > or do you want to further differentiate the mobility scenario into 
> > sub-sections that provide more details on the break-before-make  vs.
> # i am not quite sure. in a multi-homing environment there is 
> no notion of break-before-make or make-before-break.
> hence, why don't we stay with the original scenarios where we 
> have multi-homing, mobility and the combination of both? 

Bora: From a functionality perspective, there really are two cases IMHO
you either do MBB or BBM, are there any other. If I were writing software
for this, I will code functionality which is two.

> There is nothing wrong with the drawing of the figure, what 
> is wrong with it is that it takes a UNIX centric view of how 
> IPSEC/IKE implementations work.
> 
> "this figure is only one way of implementing mobike in a 
> system. it serves illustrative purposes only."

Bora: Sounds good to me
> 
> # i don't want to redraw the figure - ascii drawing takes 
> such a long time...

;-)

> already came 
> > quite far and are hopefully finished with the work in 
> mobike. making 
> > progress would be a good thing.
> 
> Well, I think the WG has a choice on this, I think this 
> document is suitable as a framework document, for 
> requirements, I think we need a more terse and succint 
> document just pointing out what the implementation needs to 
> do. That is of course my opinion.
> 
> # i would like to make some progress in the working group. we 
> are already spend far too long on the existing work. 
> # if there are some requirements which we haven't discussed 
> then they should be included in the current document. 
> # regarding the implementation requirements: the specs should 
> provide information on what is MUST, SHOULD or MAY. 
> 
OK
> concept used 
> > by a particular solution specification. as you have there is the 
> > possbility to reuse the dead peer detection mechanism (or a 
> slightly 
> > modified version of it).
> > 
> > there is nothing more behind this connectivity test - no fancy new 
> > mechanism.
> 
> # i think that dead peer detection is already a mandatory 
> implementation feature in ikev2. 

Yes
> # if we use this approach (or a slightly modified version) 
> then i don't really see a big problem. 

The problem is not doing DPD, but doing DPD as a way of deciding which path
to follow for each user, this is an unnecessary burden on the security
gateway
esp. one that supports on the order of 500,000 or more users.

Simple rule: If a client wants to keep their session up, they need to
notify the gw, otherwise, the gateway will not actively probe
for alternate paths, IP addr, etc.

> # what do you fear? the implementation overhead - not really? 
Scalability.

> Yes, I think we should point out that for the SG, this 
> capability is optional.
> 
> # furthermore, you can already use dead peer detection or 
> other messages that perform the same function already today. 
> # what is the problem? 

The problem is not DPD, that works, the problem is for a gateway to
be responsible for tracking clients, trying alternate IP addresses etc.

This does not scale, it makes the standards cumbersome.
I would rather have the client be responsible for notifications.

> > architects/users to decide which identity they want to use for 
> > authentication.
> 
> Regardless of whether this is an IKEv2 issue or not, without 
> this capability, we can not do MOBIKE, right?
> 
> # that's true and it is true for all mobility protocol 
> (mobile ip, for example). 

Mobile IP does not rely on IKE. It actually has an IP address that
never changes in its home IP address. Mobike does not have that luxury.

> > which resources do you want to clean up? do you mean when a peer 
> > crashes it must be ensured that no orphan states are left behind?
> > 
> > > 
> > > 
> > yes, the working group has done a good job of discussing 
> the various 
> > design issues that effect a solution.
> > 
> 
> # ciao
> # hannes
> 
> 
> Thanks
> 
> Bora
>