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:
> > 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. 
-- 
[email protected]