Re: WGLC on the design draft

[issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html
 working copy of document:
 http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt]

Francis Dupont writes:
> there is nothing about the fact the design and the protocol are about
> a first version of the MOBIKE tools. I support anyone who'd like to
> make it an issue as the current solution addresses only one part of
> the charter scenarios.

Jari has already several times asked me to remove all references to
the charter, thus I am not going to add anything new about the charter
or future work... 

> > 1.  Introduction
> >    ...
> >    single pair in the outer IP headers.  Existing documents make no
> >    provision to change this pair after an IKE SA is created.
> 
> this is not true: RFC 3775 and 3776 K bit stuff does exactly this.

We are now talking about the IPsec. As far as I know those RFCs only
cover MOBILE IP case, thus they are not generic IPsec solutions. I
might be wrong, as I have not followed what was done there. 

> > 3.2.  Multihoming Scenario
> > 
> >    ...
> >    Note that MOBIKE does not aim to support load balancing between
> >    multiple IP addresses.  That is, each peer uses only one of the
> >    available IP addresses at a given point in time.
> 
> This is not the common definition of load balancing (where the
> restriction to only one address is per communication).

I think we have discussed this enough earlier. If you have exact text
changes I can check them out, but I am not going to start discussion
about what is load balancing and what is not again. 

> > 5.3.  Scope of SA Changes
> ranges of SPI values don't make sense: please use a reasonnable
> argument or no argument at all!

Would you be happier if that would be list of ranges of SPI values?

Actually ranges makes perfectly sense there, as the end allocating
them can allocate them so that he can effectively move the SPIs he
wants to move by just having one range (or few ranges). 

> >    automatically move all IPsec SAs when the IKE SA moves, then we only
> >    need to keep track of which IKE SA was used to create the IPsec SA,
> >    and fetch the IP addresses from the IKE SA, i.e. there is no need to
> >    store IP addresses per IPsec SA.  Note that IKEv2 [I-D.ietf-ipsec-
> 
> I don't believe there is an implementation which doesn't store IP
> addresses per IPsec SA.

Might be true now, but might be more common in the future, as they
might want to store the IP address to the shared state, so they can
update is very quickly for thousands of SAs (and save memory etc).

> >    On the other hand, even if we tie the IKE SA update to the IPsec SA
> >    update, then we can create separate IKE SAs for this scenario, e.g.,
> >    we create one IKE SA which has both links as endpoints, and it is
> >    used for important traffic, and then we create another IKE SA which
> >    has only the fast and/or cheap connection, which is then used for
> >    that kind of bulk traffic.
> 
> We can drop the whole MOBIKE stuff using the same argument.

I think there is few orders of magnitude difference there. I would
guess there would be at most 2-3 different types of IPsec SAs which
would be moved separately. On the other hand there can be hundreds or
thousands of movements in quite short time in certain time period.
Thus we do need MOBIKE, but we might still be able to use only few IKE
SAs for different types of traffic.

Anyways this issue is already decided in the protocol draft (issue 8),
thus discussion of the issue itself is pointless. If you have exact
text changes to the document, then send them, but discussion about the
issue 8 should not be restarted. 

>    The working group decided to move all IPsec SAs implicitly when the
>    IKE SA address pair changes.  If more granular handling of the IPsec
>    SA is required, then multiple IKE SAs can be created one for each set
>    of IPsec SAs needed.
> 
> Please keep this and not try to give poor arguments to defend
> the decision (it is the WG decision ".")

If you have good arguments in either direction which is not mentioned
in the draft, send text.

Working group did decided to select the issue 8 with all IPsec SAs
move when IKE SA move, so the arguments were enough for the working
group. I think the main reason was that it is simplier, and the
feature is not needed that much.
-- 
[email protected]