Subject: [Mobike] design draft issue: editorial

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Dec 2005 12:49:53 +0200

I have reviewed the design draft -05 revision. This and
the following e-mails raise some issues that I have found.

My overall conclusion is that the document is in good
shape, but needs some additional editing and better
alignment with terminology and other aspects of the
protocol draft. This is why we are having the WGLC, but
reviews by WG members are essential to get there!
So please read the document now and comment.

Abstract:
======

>    The MOBIKE (IKEv2 Mobility and Multihoming) working group is
>    developing extensions for the Internet Key Exchange Protocol version
>    2 (IKEv2).

For someone that reads this later the references to WG may not make a
lot of sense. Rewrite as "MOBIKE (...) is an extension of the ...".

Section 1:
==========

> However, this can be problematic, as the device
> might be too slow for this task.

Maybe "However, this is a relatively expensive operation,
and can be problematic when such changes are frequent."

>    The work of the MOBIKE working group and therefore this document is
>    based on the assumption that the mobility and multi-homing extensions
>    are developed for IKEv2 [I-D.ietf-ipsec-ikev2].  As IKEv2 is built on

Another unnecessary reference to the WG. Just say "The MOBIKE protocol
is assumed to work on top of ..." or something to that effect.

>    This document neither discusses mobility and multi-
>    homing support for IKEv1 [RFC2409] nor the IPsec architecture
>    described in RFC2401 [RFC2401].

There seems to be something wrong with "neither" here. Say "This document
does not discuss ..."

Section 2:
==========

>    Peer:

I think the colon is unnecessary here.

>          local-addr].  That is, it is not an IPv6 link-local.

... address.

>       This definition is taken from [I-D.arkko-multi6dt-failure-
>       detection], and adapted to the MOBIKE context (we do allow
>       [RFC1918] addresses here, they are very common addresses used
>       inside NATs).

Just add a plain reference, not explain the differences, since the
differences keep changing as the SHIM6 work proceeds. Also, the
reference is I-D.ietf-shim6-failure-detection.

Similar for the other definitions.

Section 3:
==========

>    Even if IP addresses change due to interface switching or mobility,
>    the IP address obtained via the configuration payloads within IKEv2
>    remain unaffected.  The IP address obtained via the IKEv2
>    configuration payloads allow the configuration of the inner IP
>    address of the IPsec tunnel.  As such, applications might not detect
>    any change at all.

This text in Section 3.3 seems to apply to all scenarios. Say "In all
of these scenarios, even if ..."

Section 4:
==========

>    This
>    current design document focuses mainly on tunnel mode, everything
>    going inside the tunnel is unaffected by the changes in the tunnel
>    header IP address, and this is the mobility feature provided by the
>    MOBIKE, i.e., applications running inside the MOBIKE controlled IPsec
>    tunnel might not detect the movement since their IP addresses remain
>    constant.

s/This current/The/

"mainly"?

And there's some duplication with end of Section 3. Suggest: merge
the paragraphs and place them in Section 4.

>    MOBIKE interacts with the IPsec engine using for
>    example the PF_KEY API [RFC2367].  Using this API, the MOBIKE daemon
>    can create entries in the Security Association (SAD) and Security
>    Policy Databases (SPD).

Maybe say "... using an internal API (such as those based on
PF_KEY [RFC2367]). Using such an API..."

>    Extensions of the PF_KEY interface required by MOBIKE are also within
>    the scope of the working group.  Finally, certain optimizations for
>    wireless environments are also covered.

Don't talk about the other work items in the WG. Delete this
paragraph.

Section 5:
==========

>    Choosing addresses for
>    the IKEv2 request is a somewhat separate problem: in many cases, they
>    will be the same (and in some design choice they will always be the
>    same).

... will be the same, and could be forced to be the same by design.

>    MOBIKE
>    does not support unidirectional address pairs (i.e. where you can
>    only send traffic in one direction when using single address pair).

No need to redefine the term here. Just end after the word "pairs".

>    Note that MOBIKE is not really concerned about the actual path used,
>    it cannot even detect if some path is unidirectionally operational if
>    the same address pair has some other unidirectional path back.

s/really//

>    To detect connectivity, i.e., failures along the path, the MOBIKE
>    protocol needs to have a mechanism to test connectivity.  If a MOBIKE

s/, i.e., failures along the path//

>    problem worse by sending lots of DPD packets.

s/lots/many/

>    One of the main decisions in designing the MOBIKE protocol is who

s/decisions/questions/
s/is/was/

>    As a consequence the outcome cannot
>    be asymmetric decisions.

... the outcome is always the same for both parties.

>    The NAT-T support should also be optional, i.e., if the IKEv2
>    implementation does not implement NAT-T, as it is not required in
>    some particular environment, implementing MOBIKE should not require
>    adding support for NAT-T as well.

s/as well/either/

>    There are some cases which cannot be carried out within the
>    restrictions of the MOBIKE charter. 

To avoid talking about the charter, just say "... within MOBIKE".

>    On the other hand, as all implementations supporting NAT-T must be
>    able to respond to port 4500 all the time, it is simpler from the
>    protocol point of view to change the port numbers from 500 to 4500
>    immediately when we detect that the other end supports NAT-T.  This
>    way we do not need to start changing ports after we later detected
>    NAT, which would have caused complications to the protocol.

s/when we detect/upon detecting/
s/we do not need to start changing/it is not necessary to change/

(Its better style to not use "we", I think. Go through the rest of
the document, too, there are multiple occurrences. Such as in the
next paragraph.)

>    The working group decided that MOBIKE uses NAT-T mechanisms from the
>    IKEv2 protocol as much as possible, but decided to change the dynamic
>    address update for IKEv2 packets to MUST NOT (it would break path
>    testing using IKEv2 packets, see Section 6.2).  The working group
>    also decided to only send keepalives to the current address pair.

Dynamic address update for IPsec packets? I'm unsure what you mean
here. In any case, pointing to the actual requirement in IKEv2 spec
would be useful here.

>    From a technical point of view this feature addresses two issues:
> 
>    o  There is no need to transmit IPsec data traffic.  IPsec protected
>       data can be dropped which saves bandwidth.  This does not provide
>       a functional benefit, i.e., nothing breaks if this feature is not
>       provided.
> 
>    o  MOBIKE signaling messages are also ignored.  The IKE-SA must not
>       be deleted and the suspend functionality (realized with the zero
>       address set) may require the IKE-SA to be tagged with a lifetime
>       value since the IKE-SA should not be kept alive for an undefined
>       period of time.  Note that IKEv2 does not require that the IKE-SA
>       has a lifetime associated with it.  In order to prevent the IKE-SA
>       from being deleted the dead-peer detection mechanism needs to be
>       suspended as well.

... this feature raises two issues?

>    Due to the fact that this extension could be complicated and there
>    was no clear need for it, a first version of the MOBIKE protocol will
>    not provide this feature.

Due to its complexity and no clear requirement for it, it was decided
that MOBIKE does not support this feature.

>    What happens there is that the initiator does the normal address
>    update, and that succeeds, and then the responder starts a return
>    routability check.

s/does/performs/

>    the same as the return routability check in MIP6: The MIP6 WG decided

is different from Mobile IPv6 [RFC 3775], which does not
perform return routability operations between the mobile node
and its home agent at all.

>    Working group decided to use a protocol format where both ends send a
>    full list of their addresses to the other end, and that list
>    overwrites the previous list.  To support NAT-T the IP-addresses of
>    the received packet is added to the list (and they are not present in
>    the list).

...are considered as one address of the peer, even if not present
in the list.

Other:
=====

>       be routed along a different path, for example by load balancers.

s/by load balancers/due to load balancing/

(My speller didn't think "balancer" is a word.)

>    the correct IP addresses before the initiator can belive it is alive

s/belive/believe/

>    redirections by an authenticated attacker.  Return routability checks

s/redirections/redirection/

--Jari

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