Re: WGLC on the design draft

 In your previous mail you wrote:

   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... 
   
=> to refer to the charter is only one way to solve the issue.

   > > 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. 
   
=> I agree, IMHO the word "internal" (to IPsec) or something equivalent
is enough, for instance "Existing IPsec documents" works well.

   > > 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. 
   
=> so the text should be more accurate about what it calls load balancing,
i.e., why not add this definition in the terminology section? (the idea is
the document may use what it likes as soon as it is either a common
term or a defined-within term).

   > > 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?
   
=> no, ranges don't make sense with pseudo-random 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). 
   
=> RFC 4302 says "arbitrary value". I am not convinced there is no
attack against predictable SPIs. As far as I know all implementations
use (pseudo) random SPIs... This is what I assume when I say ranges don't
make sense there.

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

=> I am not against this "authority" argument, my concern is about a
poor argumentation to defend the decision, i.e., I strongly suggest
to remove the whole argumentation and just to say it is the WG decision.

   If you have exact text changes to the document, then send them, but
   discussion about the issue 8 should not be restarted.
   
=> I don't want to restart it this time, just to remove it (:-).

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

=> as your idea is to keep the cover on the pot you should follow my
suggestion: just keep the presentation of the issue and the decision.

Regards

[email protected]