RE: latest draft snapshot

See inline:
 

> -----Original Message-----
> From: Tschofenig Hannes [mailto:[email protected]] 
> Sent: Thursday, February 10, 2005 1:18 PM
> To: 'Bora Akyol'; [email protected]
> Subject: AW: [Mobike] 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? 

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.

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

Bora: Sounds good to me
> 
> # 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. 
> 
OK
> > 
> > > 
> > > 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. 

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.

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

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.


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

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.

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