AW: latest draft snapshot

# hi bora, 

# please see my comments below; 

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email protected]] 
> Sent: Sunday, February 06, 2005 7:45 AM
> To: 'Bora Akyol'; [email protected]
> 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