Subject: AW: [Mobike] latest draft snapshot

From: Tschofenig Hannes <[email-masked]>
Date: Sun, 6 Feb 2005 16:44:59 +0100

hi bora, 

please see my comments inline:

> Hi
> 
> I also have a few comments on this draft (sorry I am behind 
> by a few weeks),
> and I will classify them into two categories (by the way, the 
> Jan 29 version
> is much better than 01):
> 
> (SG : security gateway)
> 
> 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?

> 
> 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. 
 
> 
> PF_KEY API while being used in the text does not seem to have a direct
> reference (quite possibly I missed this).

fixed. 

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

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

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

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

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

---

From: "Bora Akyol" <[email-masked]>
Date: Mon, 7 Feb 2005 10:38:01 -0800

> -----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:
> or do you want to further differentiate the mobility scenario 
> into sub-sections that provide more details on the 
> break-before-make  vs.

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.

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

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.

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

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

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

> 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?
  
> > 2) Change the IP address pairs associated with IPSEC and 
> IKE SAs while 
> > not impacting the data path significantly.
> 
> > 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? 
> 
> > 
> > 
> yes, the working group has done a good job of discussing the 
> various design issues that effect a solution. 
> 

Thanks

Bora