D111 More comments from Francis

From: Francis Dupont
Subject: Re: [Mobike] WGLC on the design draft
Date: Wed, 21 Dec 2005 17:51:34 +0100

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

From: Tero Kivinen
Subject: Re: [Mobike] WGLC on the design draft
Date: Tue, 3 Jan 2006 19:46:22 +0200

Francis Dupont writes:
| | 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.

Done. 

| |    MOBIKE could send the full peer address list every time any of the IP
| 
| s/full/whole/ ?

Done.

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

Done.

| |    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 IP addresses in the IP header are not authenticated. That is state
of fact.

Only solution to fix that would be running MOBIKE over AH, which would
authenticate the IP address in the *IP header*.

So this text here tells that if protocol uses those address from the
*IP header* it needs to take care. 

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

This option does not make IP addresses in the *IP header*
authenticated. It will make separate copy of the IP addresses in the
payload, which will be then authenticated, and those can be used in
places where the unauthenticatede IP addresses from the *IP header*
cannot be used.

| So please update the design security considerations!

If you have exact text changes, please send them.