--------------------
Lakshminath Dondeti (2005-07-08):
Overall the document is very well written and excellent for a -00-.
Please look for " " below for some suggested revisions. Thanks.
regards,
Lakshminath
(Issue list maintainer's note: Added numbers after each comment.)
++++++++++++
Network Working Group P. Eronen, Ed.
Wrong WG name (1)
+++++++++snip+++++++++
Abstract
This document describes the MOBIKE protocol, a mobility and
multihoming extension to IKEv2. The purpose of MOBIKE is to update
the (outer) IP addresses associated with IKE and IPsec Security
Associations (SAs). The main scenario for MOBIKE is making it
possible for a remote access VPN user to move from one address to
another without re-establishing all security associations with the
VPN gateway.
Perhaps the abstract could be revised to include what's being
done for multihoming as well. The last sentence could be: MOBIKE
allows IPsec end points to change addresses (for multihoming or due to
mobility) without re-establishing all SAs with peers. (that sentence
didn't come out all that well, but a revision thereof might be better)
(2)
+++++++++++++++snip+++++++++++++++
1.2
Paragraph 3
Making the decision at the initiator is consistent with how normal
IKEv2 works: the initiator decides which addresses it uses when
contacting the responder. It also makes sense especially when the
initiator is the mobile node: it is in better position to decide
Edit: s/in better position/in a better position
(3)
which of its network interfaces should be used for both upstream and
downstream traffic.
Section 1.2, last paragraph
Updating the addresses of IPsec SAs naturally has to take into
account several security considerations. MOBIKE includes two
features design to address these considerations. First, a "return
routability" check can be used to verify the addresses provided by
the peer. This makes it more difficult flood third parties with
This sentence is garbled. Please rewrite.
(4)
large amounts of traffic. Second, a "NAT prevention" feature ensures
I may have overlooked the discussion on terminology, but
prevention doesn't seem to convey the intended meaning.
(5)
that IP addresses have not been modified by NATs, IPv4/IPv6
translation agents, or other similar devices. This feature is mainly
intended for site-to-site VPNs where the administrators may know
beforehand that NATs are not present, and thus any modification to
the packet can be considered to be an attack.
1.3 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
IPsec Security Association (SA)
An ESP or AH Security Association.
Path
A particular combination of source IP address and destination IP
address (note: this definition does not consider the route taken
by the packets in the network).
Terminology again: why not use the phrase "address pair" instead
of path. I realize that it results in a large number of changes in
the document, but this is still a -00-
(6)
2. MOBIKE protocol exchanges
2.1 Signaling support for MOBIKE
Implementations that wish to use MOBIKE for a particular IKE_SA MUST
include a MOBIKE_SUPPORTED notification in the IKE_SA_INIT request
and response messages.
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni,
N(MOBIKE_SUPPORTED),
[N(NAT_DETECTION_*)] -->
<-- HDR, SAr1, KEr, Nr,
[N(NAT_DETECTION_*)],
[CERTREQ],
N(MOBIKE_SUPPORTED)
The MOBIKE_SUPPORTED notification payload is described in Section 3.
NAT_DETECTION_* needs to be explained. Also, IKEv2 (-17) uses
NAT_DETECTION_*_IP.
(7)
2.2 Additional addresses
Both the initiator and responder MAY include one or more
ADDITIONAL_ADDRESS notification payloads in the IKE_AUTH exchange (in
case of multiple IKE_AUTH exchanges, in the message containing the SA
payload).
Initiator Responder
----------- -----------
HDR, SK { IDi, [CERT], [IDr], AUTH,
[CP(CFG_REQUEST)]
SAi2, TSi, TSr,
[N(ADDITIONAL_ADDRESS)*] } -->
<-- HDR, SK { IDr, [CERT], AUTH,
[CP(CFG_REPLY)],
SAr2, TSi, TSr,
[N(ADDITIONAL_ADDRESS)*] }
Does the * above mean that zero or more ADDITIONAL ADDRESS
payloads MAY be included?
(8)
2.3 Changing path of IPsec SAs
In MOBIKE, the initiator of the IKE_SA decides what addresses are
used in the IPsec SAs. That is, the responder never updates any
IPsec SAs without receiving an explicit CHANGE_PATH request from the
initiator. (As described below, the responder can, however, update
the IKE_SA in some circumstances.)
The description in this section assumes that the initiator has
already decided what the new addresses should be. How this decision
is made is beyond the scope of this specification. When this
decision has been made, the initiator
o Updates the IKE_SA and IPsec SAs with the new addresses, and sets
the "pending_update" flag in the IKE_SA.
o If NAT Traversal is not enabled, and the responder supports NAT
Traversal (as indicated by NAT detection payloads in the
IKE_SA_INIT exchange), and the initiator either suspects or knows
that a NAT is likely to be present, enables NAT Traversal.
o When the window size allows, sends an INFORMATIONAL request
containing the CHANGE_PATH notification payload (which does not
contain any data), and clears the "pending_update" flag.
Since this is optional, suggest using the keyword MAY or OPTIONAL
(9)
Initiator Responder
----------- -----------
HDR, SK { N(CHANGE_PATH),
N(COOKIE2),
[N(NAT_DETECTION_*),]
[N(NAT_PREVENTION)] } -->
This is the first occurrence of COOKIE2. Suggest briefly explaining
what it is or providing a forward reference to the appropriate section
where it is defined.
(10)
o Updates the IP addresses in the IKE_SA and IPsec SAs with the
values from the IP header.
Suggest adding a sentence here or in a more appropriate place
that the address changes are implicit, in that the new addresses are
not obtained from the IP header, not IKEv2 or MOBIKE payloads.
(11)
++snip++
(issue list maintainer's note: for this text see issue 22)
++snip++
o Replies with an INFORMATIONAL response:
Initiator Responder
----------- -----------
<-- HDR, SK { N(COOKIE2),
[N(NAT_DETECTION_*)] }
Should the other optional Notification payloads be present in this
message as well? NAT_PREVENTED, UNACCEPTABLE_PATH are discussed below,
but are not in the above message.
(12)
When the initiator receives the reply, it
o If the response contains the NAT_PREVENTED payload, processes it
as described in Section 2.7.
o If the response contains an UNACCEPTABLE_PATH notification
payload, the initiator MAY select another path and retry the
exchange, keep on using the current path, or disconnect.
o If NAT Traversal is supported and NAT detection payloads were
included, enables or disables NAT Traversal.
2.4 Updating additional addresses
As described in Section 2.2, both the initiator and responder can
send a list of additional addresses (in addition to the one used for
IKE_SA_INIT/IKE_AUTH exchange) to the initiator in the IKE_AUTH
exchange. If this list of addresses changes, a new list can be sent
in any INFORMATIONAL exchange request message.
When the responder (of the original IKE_SA) receives an INFORMATIONAL
request containing ADDITIONAL_ADDRESS payloads, it simply stores the
information, but no other action is taken.
++++++++++snip+++++++++++
(issue list maintainer's note: for this text see issue 23)
+++++++++snip++++++++
In Section 2.5, there is a reference to "as described in the
previous section" Please replace the "previous section" with the
section name, since a reorganization of the sections might make that
an incorrect reference.
(13)
2.6 Return routability check
Both the initiator and the responder can optionally verify that the
other party can actually receive packets at the claimed address.
This "return routability check" can be done before updating the IPsec
SAs, immediately after updating them, or continuously during the
connection.
Please use one of the 2119 keywords, MAY or OPTIONAL in the above
paragraph.
(14)
By default, return routability check SHOULD be done before updating
the IPsec SAs. In environments where the peer is expected to be
well-behaving (many corporate VPNs, for instance), or the address can
be verified by some other means (e.g., the address is included in the
peer's certificate), the return routability check MAY be skipped or
postponed until after the IPsec SAs have been updated.
2.7 NAT prevention
IKEv2/IPsec implementations that do not support NAT Traversal can, in
fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6
translation agents in tunnel mode. This may be considered a problem
in some circumstances, since in some sense any modification of the IP
addresses can be considered to be an attack.
The "NAT prevention" feature allows both the initiator and responder
to have a policy that prevents the use of paths that contain NATs,
IPv4/IPv6 translation agents, or other nodes that modify the
addresses in the IP header. This feature is mainly intended for
site-to-site VPN cases, where the administrators may know beforehand
that NATs are not present, and thus any modification to the packet
can be considered to be an attack.
This specification addresses the issue as follows. When an IPsec SA
is created, the tunnel header IP addresses (and port if doing UDP
encapsulation) are taken from the IKE_SA, not the message IP header.
The NAT_PREVENTION payload is used to guarantee that NATs have not
modified the address used in IKE_SA. However, all response messages
are still sent to the address and port the corresponding request came
from.
The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT
request. The responder MUST compare the NAT_PREVENTION payload with
the values from the IP header. If they do not match, the responder
The sentence "The responder MUST compare ..." might need to be
rewritten. The responder recomputes the hash included in the
NAT_PREVENTION payload using the address from the IP header to verify
if the claim that there is no NAT, is indeed true.
(15)
++snip++
(issue list maintainer's note: for this text see issue 24)
++snip++
If the values do match, the responder initializes (local_address,
local_port, peer_address, peer_port) in the to-be-created IKE_SA with
values from the IP header. The same applies if neither
NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if
the responder does not support NAT Traversal.
If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but
no NAT_PREVENTION payload, the situation is different since the
initiator may at this point change from port 500 to 4500. In this
case, the responder initializes (local_address, local_port,
peer_address, peer_port) from the first IKE_AUTH request. It may
also decide to perform a return routability check soon after the
IKE_AUTH exchanges have been completed.
Is the may a "MAY" in the sentence above?
(16)
IKEv2 requires that if an IPsec endpoint discovers a NAT between it
and its correspondent, it MUST send all subsequent traffic to and
from port 4500. To simplify things, implementations that support
both this specification and NAT Traversal MUST change to port 4500 if
the correspondent also supports both, even if no NAT was detected
between them.
+++++++++++snip++++++++++++++
4. Security considerations
The main goals of this specification are to not reduce the security
offered by usual IKEv2 procedures and to counter mobility related
threats in an appropriate manner. In some specific cases MOBIKE is
also capable of protecting address changes better than existing NAT
Traversal procedures.
Since we cannot use bold or other types of emphasis, I suggest using
subsections so that each of the topics below stand out.
(17)
The threats arising in scenarios targeted by MOBIKE are:
Traffic redirection and hijacking
Insecure mobility management mechanisms may allow inappropriate
redirection of traffic. This may allow inspection of the traffic
as well as man-in-the-middle and session hijacking attacks.
--------------------
Pasi Eronen (2005-07-12):
Thanks for your review, Lakshminath!
I've filed the editorial comments as issue 21 and the more
technical comments as issues 22..24 in the issue list:
http://www.vpnc.org/ietf-mobike/issues.html
I'll reply to the technical comments in separate emails
to make the issue tracking easier. Replies to some of the
editorial comments:
> Abstract
>
> This document describes the MOBIKE protocol, a mobility and
> multihoming extension to IKEv2. The purpose of MOBIKE is to
> update the (outer) IP addresses associated with IKE and
> IPsec Security Associations (SAs). The main scenario for
> MOBIKE is making it possible for a remote access VPN user to
> move from one address to another without re-establishing all
> security associations with the VPN gateway.
>
> Perhaps the abstract could be revised to include what's
> being done for multihoming as well. The last sentence could
> be: MOBIKE allows IPsec end points to change addresses (for
> multihoming or due to mobility) without re-establishing all
> SAs with peers. (that sentence didn't come out all that well,
> but a revision thereof might be better)
>
Yes, the abstract was written in a bit of an hurry..:-) How
about rewriting it to
This document describes the MOBIKE protocol, a mobility and
multihoming extension to IKEv2. MOBIKE allows mobile and/or
multihomed hosts to update the (outer) IP addresses
associated with IKE and IPsec Security Associations
(SAs). The main scenario for MOBIKE is making it possible for
a remote access VPN user to move from one address to another
while keeping the VPN connection with the gateway active.
> large amounts of traffic. Second, a "NAT prevention"
> feature ensures
>
> I may have overlooked the discussion on terminology,
> but prevention doesn't seem to convey the intended meaning.
>
Hmm... I agree that NAT prevention is perhaps not the best
possible word. Any better suggestions? Would "address integrity
protection" be any better..? Comments from anyone else?
> Path
>
> A particular combination of source IP address and
> destination IP address (note: this definition does not
> consider the route taken by the packets in the network).
>
> Terminology again: why not use the phrase "address pair"
> instead of path. I realize that it results in a large number
> of changes in the document, but this is still a -00-
>
Mainly because "path" is shorter and leads IMHO to more
understandable text. RFC 2960 (SCTP) also uses the word "path"
with pretty much the same meaning in many places.
> 2.3 Changing path of IPsec SAs
>
> In MOBIKE, the initiator of the IKE_SA decides what
> addresses are used in the IPsec SAs. That is, the responder
> never updates any IPsec SAs without receiving an explicit
> CHANGE_PATH request from the initiator. (As described
> below, the responder can, however, update the IKE_SA in some
> circumstances.)
>
> The description in this section assumes that the initiator
> has already decided what the new addresses should be. How
> this decision is made is beyond the scope of this
> specification. When this decision has been made, the
> initiator
>
> o Updates the IKE_SA and IPsec SAs with the new addresses,
> and sets the "pending_update" flag in the IKE_SA.
>
> o If NAT Traversal is not enabled, and the responder supports
> NAT Traversal (as indicated by NAT detection payloads in
> the IKE_SA_INIT exchange), and the initiator either suspects
> or knows that a NAT is likely to be present, enables NAT
> Traversal.
>
> o When the window size allows, sends an INFORMATIONAL request
> containing the CHANGE_PATH notification payload (which does
> not contain any data), and clears the "pending_update" flag.
>
> Since this is optional, suggest using the keyword MAY or
> OPTIONAL
Which part are you referring to?
> o Updates the IP addresses in the IKE_SA and IPsec SAs with
> the values from the IP header.
>
> Suggest adding a sentence here or in a more appropriate
> place that the address changes are implicit, in that the new
> addresses are not obtained from the IP header, not IKEv2 or
> MOBIKE payloads.
>
Hmm.. it's not "implicit" in the sense that change of address
is explicitly requested by the initiator (as opposed to just
updating the SAs based on some more vague hints that a change
might be needed)... but I'll add something to clarify this.
> o Replies with an INFORMATIONAL response:
>
> Initiator Responder
> ----------- -----------
> <-- HDR, SK { N(COOKIE2),
> [N(NAT_DETECTION_*)] }
>
>
> Should the other optional Notification payloads be present in
> this message as well? NAT_PREVENTED, UNACCEPTABLE_PATH are
> discussed below, but are not in the above message.
>
Hmm, actually no, since this step in the process is never
reached if the NAT_PREVENTED or UNACCEPTABLE_PATH cases happen
(they're already handled in earlier steps).
> 4. Security considerations
>
> The main goals of this specification are to not reduce the
> security offered by usual IKEv2 procedures and to counter
> mobility related threats in an appropriate manner. In some
> specific cases MOBIKE is also capable of protecting address
> changes better than existing NAT Traversal procedures.
>
> Since we cannot use bold or other types of emphasis, I
> suggest using subsections so that each of the topics below
> stand out.
>
Hm... they're pretty short to be separate subsections, but I
could try changing the indentation from 3 to 6 or something...
--------------------
Lakshminath Dondeti (2005-07-12):
++snip++
Yes, the abstract was written in a bit of an hurry..:-) How
about rewriting it to
This document describes the MOBIKE protocol, a mobility and
multihoming extension to IKEv2. MOBIKE allows mobile and/or
multihomed hosts to update the (outer) IP addresses
associated with IKE and IPsec Security Associations
(SAs). The main scenario for MOBIKE is making it possible for
a remote access VPN user to move from one address to another
while keeping the VPN connection with the gateway active.
Sounds ok. We can revisit that later too. I guess my point was that
multihoming is also what this protocol sets out to handle, so as long
that gets similar prominence, we are ok.
++snip++
Hmm... I agree that NAT prevention is perhaps not the best
possible word. Any better suggestions? Would "address integrity
protection" be any better..? Comments from anyone else?
Address integrity protection sounds fine, but having the word NAT in
there might help. Let us see if anyone has some ideas.
++snip++
Mainly because "path" is shorter and leads IMHO to more
understandable text. RFC 2960 (SCTP) also uses the word "path"
with pretty much the same meaning in many places.
I read that draft just now and found this definition:
"Path: The route taken by the SCTP packets sent by one SCTP
endpoint to a specific destination transport address of its peer
SCTP endpoint. Sending to different destination transport
addresses does not necessarily guarantee getting separate paths."
That is closer to the dictionary definition of the word path than MOBIKE
uses, no? I think address pair is still better, while not as convenient
path, it imparts the correct meaning.
++snip++
> Since this is optional, suggest using the keyword MAY or
> OPTIONAL
Which part are you referring to?
Ok, this may be a bit of nitpicking but I am trying to have documents
"spell out" what's clearly optional.
"When the window size allows" does mean that sending CHANGE_PATH
notification is optional. Or are you saying that "when the window size
allows" it is a MUST.
++snip++
Hmm.. it's not "implicit" in the sense that change of address
is explicitly requested by the initiator (as opposed to just
updating the SAs based on some more vague hints that a change
might be needed)... but I'll add something to clarify this.
Thanks.
++snip++
>
> Should the other optional Notification payloads be present in
> this message as well? NAT_PREVENTED, UNACCEPTABLE_PATH are
> discussed below, but are not in the above message.
>
Hmm, actually no, since this step in the process is never
reached if the NAT_PREVENTED or UNACCEPTABLE_PATH cases happen
(they're already handled in earlier steps).
Ok, I should have read a bit more carefully! There is some
inconsistency in that page though. The case of UNACCEPTABLE_PATH is
inline with the text and the case of NAT_DETECTION_* is specified with
headers and such. Please make it consistent in the future versions --
or perhaps use my suggestion and say that the resultant message after
considering all the steps would be HDR, SK{N(COOKIE2), [N()], N[]}.
Perhaps your way of separating them out is better, but please make it
consistent.
++snip++
Hm... they're pretty short to be separate subsections, but I
could try changing the indentation from 3 to 6 or something...
Others on the list had some suggestions on this section. Let us wait
and see how it evolves.
At this point, let me say again that you did a great job for a -00-.
The draft is already on an excellent path already (hope there are no
NATs in the way) :-).
--------------------
Pasi Eronen (2005-07-13):
>
> I read that draft just now and found this definition:
>
> "Path: The route taken by the SCTP packets sent by one SCTP
> endpoint to a specific destination transport address of
> its peer SCTP endpoint. Sending to different destination
> transport addresses does not necessarily guarantee getting
> separate paths."
>
> That is closer to the dictionary definition of the word path
> than MOBIKE uses, no? I think address pair is still better,
> while not as convenient path, it imparts the correct meaning.
>
Well, RFC 2960 continues at that point: "Primary Path: The
primary path is the destination and source address that will
be...", so it's also using the word path to refer to an address
pair in some cases.
++snip++
>
> Ok, this may be a bit of nitpicking but I am trying to have
> documents "spell out" what's clearly optional. "When the
> window size allows" does mean that sending CHANGE_PATH
> notification is optional. Or are you saying that "when the
> window size allows" it is a MUST.
>
That text is part of the process the initiator follows when it
already has decided to change the path; that involves sending a
CHANGE_PATH notification, so it's not optional (once you've
made the decision).
"When the window size allows" simply means that initiator may
have to wait for responses to previous requests before it can
send a new request. Since it's just descriptive text and not a
new requirement, probably there's no need for any RFC 2119
keywords.
++snip++
>
> Ok, I should have read a bit more carefully! There is some
> inconsistency in that page though. The case of
> UNACCEPTABLE_PATH is inline with the text and the case of
> NAT_DETECTION_* is specified with headers and such. Please
> make it consistent in the future versions -- or perhaps use my
> suggestion and say that the resultant message after
> considering all the steps would be HDR, SK{N(COOKIE2), [N()],
> N[]}. Perhaps your way of separating them out is better, but
> please make it consistent.
>
Currently the logic is that the "normal case" (when everything
succeeds) is shown in a separate message diagram, but error
cases (which hopefully occur only rarely) are described in-line
with the text. But I'll try to make it more consistent in future
versions..
--------------------
Pasi Eronen (2005-07-18):
Fixed grammar and clarified some parts based on discussion
on mailing list.
--------------------
Issue closed on 2005-07-26.
--------------------