Re: WGLC on the design draft

 In your previous mail you wrote:

   We are now starting the Working Group Last Call on
   the design document. Here is the URL:
   
=> comments from 5.4...
   
5.6.  IPsec Tunnel or Transport Mode

   Current MOBIKE design is focused only on the VPN type usage and
   tunnel mode.  Transport mode behavior would also be useful, but will
   be discussed in future documents.

=> (this is a comment for the mailing list) as the issue is the addresses
are in the traffic selectors so it is hard to change them a priori,
I'll extend my proposed document about transport mode to handle all
the cases where the issue does not exist, in particular SCTP (without
dynamic addresses) where all the addresses are already in the selectors
(so one only changes the "active" part of selectors) and tunnels a la
Joe Touch where there is no addresses in selectors (i.e., the interface
is the only meaningful selector).

6.3.  Message presentation

   ...
   Load balancing is currently outside the scope of MOBIKE, however

=> as you shot in your feet with the non standard definition of load
balancing now you are in trouble because you still don't want the real
load balancing (multiple addresses in the same SA at the same time)
but want the thing in the middle (one address per SA but different
addresses in SAs and/or in time).

   future work might include support for it.  The selected format needs
   to be flexible enough to include additional information in future
   versions of the protocol (e.g. to enable load balancing).  This may
   be realized with an reserved field, which can later be used to store
   additional information.  As there may arise other information which
   may have to be tied to an address in the future, a reserved field
   seems like a prudent design in any case.

6.4.  Updating address list

=> s/list/set/ (this is important because lists should be ordered but
not sets). Here we have sets with a particular element.

   MOBIKE could send the full peer address list every time any of the IP

=> s/full/whole/ ?

7.  Security Considerations

   As all the messages are already authenticated by IKEv2 there is no
   risk that any attackers would modify the contents of the packets.

=> as messages and packets are not the same this is not correct
(as the following show), so s/packets/messages/

   The IP addresses in the IP header of the packets are not
   authenticated, thus the protocol defined must take care that they are
   only used as an indication that something might be different, and
   that do not cause any direct actions, except when doing NAT
   Traversal.

=> I strongly disagree: not authenticate the IP addresses just leaves
the protocol vulnerable to attacks modifying them, i.e., you can
establish the IKE SA and IPsec SAs with a bad address (cf what I call
the "transient pseudo-NAT" attack. There are three "solutions"
 - authenticate the IP address using something else, for instance
   check if it is in the certificate (this is the usual way)
 - don't care and leave a security flaw (I am afraid this is the option
   of many road-warrior VPNs :-)
 - reflect the IP address in messages in order to detect changes.
   This is the option used by Mobike which requires either NAT dectection
   or NAT prevention
So please update the design security considerations!

10.2.  Informative References

   [I-D.dupont-mipv6-3bombing]
              Dupont, F., "A note about 3rd party bombing in Mobile
              IPv6", draft-dupont-mipv6-3bombing-02 (work in progress),
              June 2005.

=> I submitted a 03 version this morning.

   [I-D.ietf-mip6-ro-sec]
              Nikander, P., "Mobile IP version 6 Route Optimization
              Security Design Background", draft-ietf-mip6-ro-sec-03
              (work in progress), May 2005.

=> this was published as the RFC 4225 (with many authors).

   [I-D.ietf-ipv6-optimistic-dad]
              Moore, N., "Optimistic Duplicate Address Detection for
              IPv6", draft-ietf-ipv6-optimistic-dad-06 (work in
              progress), September 2005.

=> not referenced (it seems the last xml2rfc detects this)

   [I-D.ietf-ipv6-unique-local-addr]
              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
              progress), January 2005.

=> same issue.

Regards

[email protected]