RE: latest draft snapshot

 
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)

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.

PF_KEY API while being used in the text does not seem to have a direct
reference (quite possibly I missed this).

In general, I think rename this draft to be "Framework for MOBIKE." Then do
a requirements draft that has as little text as possible.

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

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


I think the framework does a good job of identifying these problems.

Regards,

Bora