D101 Editorial comments from Jari
From: Jari Arkko
Subject: [Mobike] design draft issue: editorial
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/
From: Tero Kivinen
Subject: [Mobike] #D101: design draft issue: editorial
Date: Tue, 3 Jan 2006 17:16:53 +0200
Jari Arkko writes:
| 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 ...".
Done.
| 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."
Done.
| | 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.
Changed to:
The MOBIKE protocol is assumed to work on top of IKEv2 <xref
target="I-D.ietf-ipsec-ikev2"/>.
| | 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 ..."
Done.
| Section 2:
| ==========
|
| | Peer:
|
| I think the colon is unnecessary here.
Removed colons from all terms.
| | local-addr]. That is, it is not an IPv6 link-local.
|
| ... address.
Added.
| | 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.
I was wondering that if someone who is very familiar with the shim6
work would not notice that we are using different definition here, so
we should point out the differences, but if the terms defined there
are not well defined yet, then better remove the differences part.
| Similar for the other definitions.
I do not think there was differences in other terms, but fixed the
references.
| 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 ..."
Done.
| 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/
Done.
| "mainly"?
There used to be some more text about transport mode here, but now we
only say that there will be future ducouments, so removed "mainly"
| And there's some duplication with end of Section 3. Suggest: merge
| the paragraphs and place them in Section 4.
Can you give more exact editing instructions, so I can do the changes.
| | 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..."
Done.
| | 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.
Removed.
| 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.
Done.
| | 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".
Removed the definition. This used to be the only place earlier, but
forgot to remove this when added the definition to the terminology
section.
| | 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//
Done.
| | 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//
Done.
| s/lots/many/
Done.
| | One of the main decisions in designing the MOBIKE protocol is who
|
| s/decisions/questions/
| s/is/was/
Done.
| | As a consequence the outcome cannot
| | be asymmetric decisions.
|
| ... the outcome is always the same for both parties.
Done.
| | 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/
Done.
| | 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".
Hmm.... Then reader might be wondering why we cannot do that. Protocol
might be able to be designed to support those cases, but they are out
of scope of the charter, thus we cannot do them with MOBIKE.
Anyways removed the text about charter restrictions.
| | 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/
Done.
| (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.)
There is way too many occurrences that I do not want to start fixing
them all now. Actually I myself find it sometimes easier to read text
that uses "we" than text written to avoid using "we".
| | 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.
RFC 4306, section 2.23 second last paragraph. It is little bit hard to
put exact references to the section 2.23 as it is several pages long
and this text refers to the one paragraph in there.
If you search "dynamically update the address" from the ikev2 document
you will find the correct place.
Didn't do anything for this yet.
| | 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?
As zero address set functionality would be solving those two issues, I
would say it addresses those issues, not raises them. They are already
present in the current protocol, and we do not propose any solution
for them now. I.e the issues is that we waste bandwidth by sending
data which will be ignored by the other end, and we tear down the IKE
SA because the other end cannot reply to our signaling packets.
Perhaps better way woud be to say "From a technical point of view this
would provide following two features:"?
| | 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.
Done.
| | 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/
Done.
| | 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.
Done.
| | 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.
Done.
| 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.)
Done. (ispell do claim that "balancer" is correct because of root word
"balance").
| | the correct IP addresses before the initiator can belive it is alive
|
| s/belive/believe/
Done. (Ispell did consider belive to be correct because of root word
"bel" :-)
| | redirections by an authenticated attacker. Return routability checks
|
| s/redirections/redirection/
Done.
From: Tero Kivinen
Subject: [Mobike] #D101: design draft issue: editorial
Ok, added the lengthy pointer, easier now when the rfc is out as I
know the text does not change anymore.