Review of draft-ietf-mobike-protocol-00
Lakshminath Dondeti <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Organization | Qualcomm |
| Message-ID | <[email protected]> |
Overall the document is very well written and excellent for a -00-.
Please look for "<LD> </LD>" below for some suggested revisions. Thanks.
regards,
Lakshminath
++++++++++++
Network Working Group P. Eronen, Ed.
<LD> Wrong WG name </LD>
+++++++++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.
<LD> 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)
</LD>
+++++++++++++++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
<LD> Edit: s/in better position/in a better position
</LD>
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
<LD> This sentence is garbled. Please rewrite.
</LD>
large amounts of traffic. Second, a "NAT prevention" feature ensures
<LD> I may have overlooked the discussion on terminology, but
prevention doesn't seem to convey the intended meaning.
</LD>
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).
<LD> 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-
</LD>
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.
<LD>
NAT_DETECTION_* needs to be explained. Also, IKEv2 (-17) uses
NAT_DETECTION_*_IP.
</LD>
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)*] }
<LD> Does the * above mean that zero or more ADDITIONAL ADDRESS payloads
MAY be included?
</LD>
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.
<LD> Since this is optional, suggest using the keyword MAY or OPTIONAL
</LD>
Initiator Responder
----------- -----------
HDR, SK { N(CHANGE_PATH),
N(COOKIE2),
[N(NAT_DETECTION_*),]
[N(NAT_PREVENTION)] } -->
<LD>
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.
</LD>
o Updates the IP addresses in the IKE_SA and IPsec SAs with the
values from the IP header.
<LD> 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.
</LD>
o If NAT Traversal is supported and NAT detection payloads were
included, enables or disables NAT Traversal.
<LD> I may be wrong, but is disabling NAT Traversal a possibility here?
</LD>
o Replies with an INFORMATIONAL response:
Initiator Responder
----------- -----------
<-- HDR, SK { N(COOKIE2),
[N(NAT_DETECTION_*)] }
<LD>
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.
</LD>
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+++++++++++
Initiator Responder
----------- -----------
HDR, SK { N(ADDITIONAL_ADDRESS)+,
N(COOKIE2) } -->
<-- HDR, SK { N(COOKIE2) }
When the initiator receives an INFORMATIONAL request containing
ADDITIONAL_ADDRESS, it stores the information and also determines
whether the currently used path needs to be changed (for instance, if
the currently used address is no longer included in the list); if it
does, the initiator proceeds as described in the previous section.
<LD> I must say that I don't like overloading the Notification payload
with IP addresses.
IKEv2 uses ID payloads for this purpose, why not use those?
</LD>
Initiator Responder
----------- -----------
<-- HDR, SK { N(ADDITIONAL_ADDRESS)+,
N(COOKIE2) }
HDR, SK { N(COOKIE2) } -->
If the implementation supports window sizes greater than one, it also
has to keep track of the Message ID of the latest update it has
received, to avoid the situation where new information is overwritten
by older.
+++++++++snip++++++++
<LD> 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.
</LD>
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.
<LD> Please use one of the 2119 keywords, MAY or OPTIONAL in the above
paragraph.
</LD>
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
<LD> 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.
</LD>
Eronen Expires December 30, 2005 [Page 11]
Internet-Draft MOBIKE Protocol June 2005
replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any
state.
<LD> The labels NAT_PREVENTION, NAT_PREVENTED are confusing.
For a little while I thought they are the same, but realize they are
different.
NAT_PREVENTION seem to mean that the sender is guaranteeing/indicating
that there is no NAT. Perhaps, NAT_NOTSUPPORTED or NAT_ABSENT or
something like that might be more appropriate. Instead of NAT_PREVENTED,
NAT_PRESENT or NAT_DETECTED might be more appropriate. The Initiator
then can compare its claim from its state that NAT_ABSENT against
NAT_PRESENT to detect that its claim is incorrect.
</LD>
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.
<LD> Is the may a "MAY" in the sentence above?
</LD>
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.
<LD> Since we cannot use bold or other types of emphasis, I suggest using
subsections so that each of the topics below stand out.
</LD>
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.