Comments to draft-ietf-mobike-protocol-00.txt
Tero Kivinen <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
> 1.2 MOBIKE protocol overview
...
> One important aspect of this information gathering that has to be
> visible in the messages is determining whether a certain pair of
> addresses can be used. IKEv2 Dead Peer Detection (DPD) feature can
> provide information that the currently used pair does or does not
> work. There are, however, some complications in using it for other
> addresses, and thus MOBIKE adds a new IKEv2 message that can be used
> to "test" whether some particular pair of addresses works or not,
> without yet committing to changing the addresses currently in use.
I do not agree on that reason. It is very simple to say in the MOBIKE
protocol, that implementations MUST NOT do dynamical address update if
MOBIKE extensions are enabled, i.e. they MUST always do address
updates only when receiving CHANGE_PATH message in case MOBIKE
extensions are enabled.
That will take care of all the problems using normal IKEv2 packet to
test path.
> 1.3 Terminology
>
> 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).
Any reason why the draft-ietf-mobike-design-02.txt and this document
defined Path differently? The Path from the design draft do include
the route, the Path here matches the more or less the (operantional)
address pair in the design draft.
I think we should try to keep them in sync.
> 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)
As we are probably going to follow the IKEv2 document style, which
says that payload MUST come in the order they appear in pictures, I
think we might want to keep this and IKEv2 documents consistent. The
CERTREQ is mentioned in the IKEv2 document, so it's order is fixed, so
I would move NAT_DETECTION_*_IP from the reply to the end, i.e:
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni,
N(MOBIKE_SUPPORTED),
[N(NAT_DETECTION_*)] -->
<-- HDR, SAr1, KEr, Nr,
[CERTREQ],
N(MOBIKE_SUPPORTED),
[N(NAT_DETECTION_*)]
> 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.)
I think we should say that responder never updates IKE_SA without
explicit CHANGE_PATH. Not by any dynamic updates because of NAT-T code
or any other reason. We simpy say that it always keeps the IKE_SA
addresses intact.
> 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.
I assume that this implicitly means that retransmissions sent during
that time are sent to new address instead of old one? This is not
really mentioned anywhere, and it needs a lot of text more to describe
that.
That same text is also needed if we want to get rid of the PATH_TEST
exchange completely.
This text should be enough:
----------------------------------------------------------------------
When sending any IKE packets we first try the operational
address pair. If we do not get reply back from that we try all
other address pairs until we get reply back, or the exchange
times out, in which case the IKE SA is deleted. The order in
which the address pairs are tried is implementation specific,
and can use information from various places.
The other end receiving those packets, should reply to all of
them it receives, with the addresses and ports reversed.
Recipient of any other packet than N(CHANGE_PATH) MUST NOT
cause any update in the IKE_SA or IPsec SA addresses (also in
case when NAT-T is used).
This way any IKE packet can be used to test weather the path
works or not. If during the sending of IKE packet we detect
that the operational address pair is not working anymore, the
original initiator (not the exchange initiator) should take
actions to fix the situation by finding new operational
address pair, and sending N(CHANGE_PATH) for the new
operational address pair.
If it was original initiator who was initiating the IKE
exchange, then after the exchange finishes it already knows
the new address pair which works, so he can simply send
N(CHANGE_PATH) to update to new working operational address
pair.
If it was original responder who was initiating the IKE
exchange, it does NOT do any updates itself, it simply assumes
that original initiator seeing IKE packets coming from
different address pair than current one is, initiates a DPD
test itself to verify weather the operational address pair is
working, and after that will fall back to another address
pairs, and result update to the operational address pair in
initiator, it will then send N(CHANGE_PATH) notify to update
the operational address pair.
If operational address pair is broken down when we are sending
N(CHANGE_PATH) exchange, then it is possible that the
responder will be updated to the some other address pair than
what initiator originally intended (in case of uni-directional
connection, i.e. responder getting the first N(CHANGE_PATH)
in, but initiator not getting the reply back, thus trying
other addresses, and finally getting reply back). In this case
the initiator should immediately update his own operational
address pair to the one that is working, and do another
N(CHANGE_PATH) exchange with the known working address pair to
make sure that the initiator and responder do agree on the
address pair. Only after when he gets reply back from the
address pair he intended to use in the first place, he can be
sure that both peers agree on the address pair.
In case NAT-T is enabled then implemenations MUST make sure
that initiator does DPD in a way that will take care of the
updating the other peers addresses in case the NAT mapping is
lost. This means that when initiator who is behind NAT start
DPD because of the lack of packets from the other peer, he
includes the N(CHANGE_PATH) to the exchange too, to make sure
that the other peer will update its mapping. If it does not
get reply back using operational address pair, it tries other
address pairs, and if it does get reply back it does normal
operation, i.e. restarts the N(CHANGE_PATH) for that new
operational address pair.
----------------------------------------------------------------------
> Note that if the responder has NAT Traversal enabled, it can update
> the addresses in both the IKE_SA and IPsec SAs as usual (if it
> implements the "SHOULD" from [IKEv2] Section 2.23.
There is no reason for the other end to enable the SHOULD in case the
MOBIKE is used. We can simply say that it MUST NOT do the dynamic
address updates in case MOBIKE is enabled.
> 2.4 Updating additional addresses
...
> There is one additional complication: when the responder wants to
> send a new additional address list, the currently used path may no
> longer work. In this case, the responder uses the additional address
> list received from the initiator, the list of its own addresses, and,
> if necessary, the path testing feature (see Section 2.5) to determine
> a path that works, updates the addresses in the IKE_SA (but not IPsec
> SAs), and then sends the INFORMATIONAL request. This is the only
> time the responder uses the additional address list received from the
> initiator.
This is no way only related to the updating addresses, it might be
also break down during any other exchange, and if the responder does
not do try all address pairs when sending IKE packets, it will cause
IKE SA to deleted because of timed out exchange unless the initiators
DPD timers are much shorter than responders negotiation timeout
timers.
I mean if initiator does DPD, and notices that everything is fine,
then address pair breaks down, and then responder starts sending some
IKE packet. If this IKE packet manages to time out before the next DPD
has started, and detected the problem, and found the new working
address pair, and sent an address update by N(CHANGE_PATH) then the
responder will delete the IKE SA.
There are cases where the responder cannot do anything, because of the
NATs, so in those cases this will happen anyways, but if there is no
NATs preventing original responder for sending packets to original
initiator then the original responder can simply try other address
pairs, to see if them work. If not, then delete the IKE SA, if one of
them work, fine, he did get his operation done, and original initiator
probably got some hint about something being wrong...
If we decide that we do not need this feature, then we can simply
leave out the address lists in the responder side completely, and say
that responder will not try to fix any situations, and it will not
support break-before-make style movement to new addresses unknown by
the initiator.
> 2.5 Path testing
If we take my previous text in 2.3, then this section would simply
say:
Any IKE packets can be used for path testing as long as it has
property that responder cannot generate reply packet to it
without seeing the request packet. Normally any INFORMATIONAL
exchange with N(COOKIE2) is enough.
> MOBIKE introduces a new IKEv2 exchange type, PATH_TEST, for testing
> connectivity. This exchange is not part of any IKE_SA, so it is not
> cryptographically protected. It also does not result in the
> responder keeping any state.
I do not like this non-protected exchange, as its security
implications are not known. For example the text below, does not say
what to do if the N(COOKIE2) are not matching. The other place said we
tear down IKE SA, but we do not want to do it here.
> The reason for introducing a new exchange type, instead of using
> INFORMATIONAL exchanges, is to simplify implementations by allowing
> MOBIKE to work with window size 1.
I do not think it will simplify implementations at all. We need the
similar processing of the outgoing IKE exchanges anyways, i.e. each
IKE exchange needs to be able to be retransmitted using another
address pair, thus doing it 2-3 times (first with broken address pair,
then detecting that address pair does not work, and finding out new
address pair using PATH_TEST and then chaging to that new address
pair, and perhaps that new pair broke down before we managed to use
it) or 10 times (use the IKE packet to do the PATH_TEST, i.e. iterate
through all addess pairs) does not really make it more complicated.
We do not need window size above 1 even for those.
Also taking care of the dynamic updates in case if NAT-T is easy, we
simply say you MUST NOT do those if MOBIKE is enabled.
If we simply want to test weather the address pair works we do
INFORMATIONAL without N(CHANGE_PATH).
> 2.6 Return routability check
...
> To ensure that the peer cannot generate the correct INFORMATIONAL
> response without seeing the request, a new payload is added to all
> INFORMATIONAL messages. The sender of an INFORMATIONAL request MUST
> include a COOKIE2 notification payload, and the recipient of an
> INFORMATIONAL request MUST copy the payload as-is to the response.
> When processing the response, the original sender MUST verify that
> the value is the same one as sent. If the values do not match, the
> IKE_SA MUST be closed.
I donot think we need to moify all INFORMATIONAL exhcnages to include
N(COOKIE2), only those that are used for the return routability
checks.
> There is one additional issue that must be taken into account. If
> the destination address in the IKE_SA has been updated after the
> INFORMATIONAL request was sent, then it is possible that the request
> has been sent to several different addresses. In this case,
> receiving the INFORMATIONAL response does not tell which address is
> the working one; thus, a new INFORMATIONAL request needs to be sent.
This should probably be clarified better, i.e. if we fall back to the
other addresses, then the malicious peer can take those later messages
that did reach him and send them back using different address pair,
i.e. faking the reply of return routability check.
There is no description here what should be done in that case. We need
to send ACK to the N(CHANGE_PATH) quite soon, we cannot wait for the
return routability check to finish, as it might be so that the
initiator sends N(CHANGE_PATH) and then address pair stops working,
thus we cannot do return routability check, but on the other hand
initiator cannot do anything to fix the situation as he might have
window size of 1, and cannot send another N(CHANGE_PATH) before the
one that is being processed is ACK'ed.
So we probably want to return ACK to N(CHANGE_PATH) immediately, but
update the actual IP-addresses only after the return routability
checks finish, and if during that time we get new N(CHANGE_PATH) we
simply change the base address where to do return routability checks.
> 2.7 NAT prevention
...
> 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.
Why does it need to do the return routability check? IKEv2 NAT-T does
not do return routability checks there, why should we do? Note, that
the initiator will not see any IPsec packets thus he cannot for
example start TCP sessions, as those are not retransmittede to
secondary addresses. I cannot really see how he could mount any real
attack at this phase.
> 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.
What does that simplify? In normal case implementations will never do
that as it wastes 4 bytes for each IKE packet.
> 3. Payload formats
>
> 3.1 MOBIKE_SUPPORTED notification payload
>
> The MOBIKE_SUPPORTED notification payload is included in the
> IKE_SA_INIT messages to indicate that the implementation supports
> this specification.
>
> The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA
> (16396..40959). The Protocol ID field is set to one (1), and SPI
> Size is set to zero. There is no data associated with this Notify
> type.
How about adding 32 bits of data, with the MOBIKE version number,
initially 0?
Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.
> 3.2 ADDITIONAL_ADDRESS notification payload
>
> Both initiator and responder can include ADDITIONAL_ADDRESS payloads
> in the IKE_AUTH exchange and INFORMATIONAL exchange request messages;
> see Section 2.2 and Section 2.4 for more detailed description.
>
> The Notify Message Type for ADDITIONAL_ADDRESS is TBD-BY-IANA
> (16396..40959). The Protocol ID field is set to one (1), and SPI
> Size is set to zero. The data associated with this Notify type is
> either an IPv4 address or an IPv6 address; the type is determined by
> the payload length.
I think it is better to take 2 different notification types for IPv4
and IPv6. Checking the lenght is bad, as then we cannot extend the
structure later by adding more information to the notification data.
The design draft asks this in the section 5.11, i.e. make the format
so we can extend in the future it with new data, like load balancing
weight (currently out of scope, but one of the possible future works).
Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.
> 3.3 CHANGE_PATH notification payload
>
> This payload is included in INFORMATIONAL exchange requests sent by
> the initiator of the IKE_SA to update addresses of the IKE_SA and
> IPsec SAs (see Section 2.3).
>
> The Notify Message Type for CHANGE_PATH is TBD-BY-IANA
> (16396..40959). The Protocol ID field is set to one (1), and SPI
> Size is set to zero. There is no data associated with this Notify
> type.
Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.
> 3.4 UNACCEPTABLE_PATH notification payload
>
> The responder can include this notification payload in an
> INFORMATIONAL exchange response to indicate that the address change
> in the corresponding request message (which contained a CHANGE_PATH
> notification payload) was not carried out.
>
> The Notify Message Type for UNACCEPTABLE_PATH is TBD-BY-IANA
> (40..8191). The Protocol ID field is set to one (1), and SPI Size is
> set to zero. There is no data associated with this Notify type.
There is a problem in case the UNACCEPTABLE_PATH is not for address in
the IP header but some other address pair. I mean the initiator sends
packet with IPA1, IPB1 N(CHANGE_PATH). That reaches the responder, but
he decides to send N(UNACCEPTABLE_PATH) back. The reply never reaches
the initiator because of uni-directional connection or something. The
initiator retransmits the packet with IPA2, IPB2 N(CHANGE_PATH). This
would be ok for the responder, but as he has already generated the
reply N(UNACCEPTABLE_PATH) he will retransmit that back. This will
reach the initiator and he will be receiving wrong information which
path was unacceptable.
Fixing this is quite simply, we add the address pair that was
unacceptable to the notify data. In case there is NAT in the path the
responder might not recognize all the addresses, but in case of no
NATs it immediately knows which address pair wasn't acceptable.
Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.
> 3.5 COOKIE2 notification payload
>
> This payload is included in all INFORMATIONAL exchange messages for
> return routability check purposes (see Section 2.6). It is also used
> in PATH_TEST messages to match requests and responses (see
> Section 2.5).
I would say we define this in more generic way:
----------------------------------------------------------------------
This payload MAY be included in any IKEv2 exchange. The data
associated with this notification MUST be between 8 and 64
octets in length (inclusive), and MUST be chosen in a way that
is unpredictable to the recipient. The recipient MUST copy
this notification to his reply packet. The negotation
initiator MUST then check that the N(COOKIE2) received from
the other peer matches the one he sent out.
This message MUST be included in the IKE exchanges used as a
return routability check.
The Notify Message Type for this message is TBD-BY-IANA
(16396..40959). The Protocol ID field is set to zero (0), and
SPI Size is set to zero.
----------------------------------------------------------------------
(already changed protocol id to zero).
> 3.6 NAT_PREVENTION notification payload
>
> See Section 2.7 for a description of this payload.
>
> The data associated with this notification is the SHA-1 hash
> [FIPS180-2] of the following data: IKE SPIs (in the order they appear
> in the header), the IP address and port from which the packet was
> sent, and the IP address and port to which the packet was sent. The
> Notify Message Type for this message is TBD-BY-IANA (16396..40959).
> The Protocol ID field is set to one (1), and SPI Size is set to zero.
Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.
> 3.7 NAT_PREVENTED notification payload
>
> See Section 2.7 for a description of this payload.
>
> The Notify Message Type for NAT_PREVENTED is TBD-BY-IANA (40..8191).
> The Protocol ID field is set to one (1), and SPI Size is set to zero.
> There is no data associated with this Notify type.
Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.
> 4. Security considerations
...
> Protection of MOBIKE payloads
>
> The payloads used in MOBIKE are encrypted, integrity protected,
> and replay protected. This assures that no one except the
> participants can, for instance, give a control message to change
> the addresses.
This is not true, as PATH_TEST packets in the current document are not
encrypted or proteced. This should be mentioned here, and security
analysis of all possible attacks this new protocol might cause should
be done.
I remember that I promised to write a section describing how to do the
protocol without nerw PATH_TEST protocol, but instead of using the any
IKE packets with that, and with working for window size 1. The text up
there in section 2.3 comments should actually be enough. I do not
think we need more text, but we can remove all references to the
PATH_TEST exchange.
--
[email protected]