Subject: [Mobike] WGLC on the design draft

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Dec 2005 13:10:02 +0200

We are now starting the Working Group Last Call on
the design document. Here is the URL:

     http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-05.txt

The WGLC will end on December 24th, 2005. Please review
this document and post your review results to the list (even if
you found no complaints). If you have multiple issues, it would
help the subsequent discussion if you broke them up in parts
that are sent in separate e-mails and with appropriate subject
lines (e.g., "section N problem" or "editorial issues").

--Jari

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Dec 2005 15:42:12 +0200

> you found no complaints). If you have multiple issues, it would

As I haven't received any comments yet (not even ones saying "no
complaints"), I would like to remind people to read this document... 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Wed, 21 Dec 2005 15:37:47 +0100

In your previous mail you wrote:

   the design document.
   
=> here are my comments:

Abstract

   ...

   This document discusses the involved network entities, and the
   relationship between IKEv2 signaling and information provided by
   other protocols.  Design decisions for the MOBIKE protocol,
   background information and discussions within the working group are
   recorded.

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

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.

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

3.3.  Multihomed Laptop Scenario

   ...
   GPRS adaptor, a Bluetooth interface or USB hardware.  Not all
   interfaces are used for communication all the time for a number of
   reasons (e.g., cost, network availability, user convenience).  The

=> "not all" is not "only one".

5.3.  Scope of SA Changes

   ...
   If IPsec SAs should be updated separately then a more efficient
   format than the Notify payload is needed to preserve bandwidth.  A
   Notify payload can only store one SPI per payload.  A separate
   payload could have a list of IPsec SA SPIs and the new preferred
   address.  If there is a large number of IPsec SAs, those payloads can
   be quite large unless ranges of SPI values are supported.  If we

=> ranges of SPI values don't make sense: please use a reasonnable
argument or no argument at all!

   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.

   If we do allow address set of each IPsec SA to be updated separately,
   then we can support scenarios where the machine has fast and/or cheap
   connections and slow and/or expensive connections, and wants to allow
   moving some of the SAs to the slower and/or more expensive
   connection, and prevent the move, for example, of the news video
   stream from the WLAN to the GPRS link.

=> exactly

   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.

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

5.4.  Zero Address Set Functionality

(I've stopped here, I'll put comments about next stuff in another message).

Regards

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Wed, 21 Dec 2005 17:51:34 +0100

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Dec 2005 19:06:10 +0200

>=> I submitted a 03 version this morning.
Ack.

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

>              Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
Both of these ARE referenced. The other reference has
a linebreak I think, which may have caused you to not
notice. The references are from the definitions in Sect. 2.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 21 Dec 2005 18:43:37 +0100

Both of these ARE referenced.

=> you're right (I did the grep in the wrong file).

Regards