AW: latest draft snapshot

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
>