Subject: [Mobike] Changes to draft-ietf-mobike-design-08.txt from IESG etc

From: Tero Kivinen <[email-masked]>
Date: Wed, 12 Jul 2006 18:28:20 +0300

Here is list of changes to the draft-ietf-mobike-design-08.txt from
the IESG etc. I think all of those are minor editorial comments that
can be put into to the document during AUTH48 (or actually rfc-editor
can put them in directly while editing the draft if they like).

----------------------------------------------------------------------
Change in section 3.1 (from Lisa, changed "mobile node" to "mobile node (MN)")

3.1.  Mobility Scenario

   Figure 1 shows a break-before-make mobility scenario where a mobile
   node changes its point of network attachment.  Prior to the change,
   the mobile node had established an IPsec connection with a security
   gateway which offered, for example, access to a corporate network.
   The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took
   place over the path labeled as 'old path'.  The involved packets
   carried the MN's "old" IP address and were forwarded by the "old"
   access router (OAR) to the security gateway (GW).

To
   
3.1.  Mobility Scenario

   Figure 1 shows a break-before-make mobility scenario where a mobile
   node (MN) changes its point of network attachment. Prior to the
   change, the mobile node had established an IPsec connection with a
   security gateway which offered, for example, access to a corporate
   network. The IKEv2 exchange that facilitated the setup of the IPsec
   SA(s) took place over the path labeled as 'old path'. The involved
   packets carried the MN's "old" IP address and were forwarded by the
   "old" access router (OAR) to the security gateway (GW).

----------------------------------------------------------------------
Change title of 5.2 (from Lisa, added "(NAT-T)")

5.2.  NAT Traversal

To

5.2.  NAT Traversal (NAT-T)

----------------------------------------------------------------------
Change in section 1 (From Russ, changed RFC2401bis to "the Security
Architecture for the Internet Protocol", Eric Gray noted same)

   The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306].  As
   IKEv2 is built on the architecture described in RFC2401bis [RFC4301],
   all protocols developed within the MOBIKE working group must be
   compatible with both IKEv2 and the architecture described in RFC4301.
   This document does not discusses mobility and multi-homing support
   for IKEv1 [RFC2409] nor the IPsec architecture described in RFC2401
   [RFC2401].

To

   The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306].
   As IKEv2 is built on the architecture described in the Security
   Architecture for the Internet Protocol [RFC4301], all protocols
   developed within the MOBIKE working group must be compatible with
   both IKEv2 and the architecture described in RFC4301. This document
   does not discusses mobility and multi-homing support for IKEv1
   [RFC2409] nor the IPsec architecture described in RFC2401
   [RFC2401].

----------------------------------------------------------------------
Change in sectin 4 (From Russ, changed "IKE" to "IKEv2")

4.  Scope of MOBIKE

    Getting mobility and multihoming actually working requires many
    different components to work together, including coordinating
    decisions between different layers, different mobility mechanisms,
    and IPsec/IKE.  Most of those aspects are beyond the scope of MOBIKE:

To

4.  Scope of MOBIKE

    Getting mobility and multihoming actually working requires many
    different components to work together, including coordinating
    decisions between different layers, different mobility mechanisms,
    and IPsec/IKEv2. Most of those aspects are beyond the scope of
    MOBIKE:

----------------------------------------------------------------------
Change in section 5.1 (From Russ, changed ":" to ".")

5.1.  Choosing Addresses

   One of the core aspects of the MOBIKE protocol is the selection of
   the address for the IPsec packets we send.  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, and could be forced to be the same by design).

To

5.1.  Choosing Addresses

   One of the core aspects of the MOBIKE protocol is the selection of
   the address for the IPsec packets we send.  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, and could be forced to be the same by design).

----------------------------------------------------------------------
Change in section 5.1.1 (from Russ, change ", e.g., Mobile IP, and" to
"other mobility protocols such as Mobile IP, and they")

   These triggers are largely the same as for, e.g., Mobile IP, and are
   beyond the scope of MOBIKE.

To

   These triggers are largely the same as for other mobility protocols
   such as Mobile IP, and they are beyond the scope of MOBIKE.

----------------------------------------------------------------------
Change in section 5.1.2 (from Russ, changed "address the request came
from" to "address from which the request came")

   There can be two kinds of connectivity "failures": local failures and
   path failures.  Local failures are problems locally at an MOBIKE peer
   (e.g., an interface error).  Path failures are a property of an
   address pair and failures of nodes and links along this path.  MOBIKE
   does not support unidirectional address pairs.  Supporting them would
   require abandoning the principle of sending an IKEv2 reply to the
   address the request came from.  MOBIKE decided to deal only with
   bidirectional address pairs.  It does consider unidirectional address
   pairs as broken, and does not use them, but the connection between
   peers will not break even if unidirectional address pairs are
   present, provided there is at least one bidirectional address pair
   MOBIKE can use.

To

   There can be two kinds of connectivity "failures": local failures and
   path failures.  Local failures are problems locally at an MOBIKE peer
   (e.g., an interface error).  Path failures are a property of an
   address pair and failures of nodes and links along this path.  MOBIKE
   does not support unidirectional address pairs.  Supporting them would
   require abandoning the principle of sending an IKEv2 reply to the
   address from which the request came.  MOBIKE decided to deal only with
   bidirectional address pairs.  It does consider unidirectional address
   pairs as broken, and does not use them, but the connection between
   peers will not break even if unidirectional address pairs are
   present, provided there is at least one bidirectional address pair
   MOBIKE can use.

----------------------------------------------------------------------
Change in section 5.2.1 (from Russ, ", i.e., if" to ". If")

   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 either.

To

   The NAT-T support should also be optional. 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 either.

----------------------------------------------------------------------
Change in section 5.2.2 (from Russ, "old" to "the old")

   There are some cases which cannot be carried out within MOBIKE.  One
   of those cases is the case where the party "outside" a symmetric NAT
   changes its address to something not known by the the other peer (and
   old address has stopped working).  It cannot send a packet containing
   the new addresses to the peer because the NAT does not contain the
   necessary state.  Furthermore, since the party behind the NAT does
   not know the new IP address, it cannot cause the NAT state to be
   created.

To:

   There are some cases which cannot be carried out within MOBIKE.  One
   of those cases is the case where the party "outside" a symmetric NAT
   changes its address to something not known by the the other peer (and
   the old address has stopped working).  It cannot send a packet containing
   the new addresses to the peer because the NAT does not contain the
   necessary state.  Furthermore, since the party behind the NAT does
   not know the new IP address, it cannot cause the NAT state to be
   created.

----------------------------------------------------------------------
Change in section 5.2.4 (from Russ, change "where the responder can
move to," to "to which the responder can move." and change "i.e. the"
to "That is, the"). 

   MOBIKE can work in cases where the responder is behind static NAT,
   but in that case the initiator needs to know all the possible
   addresses where the responder can move to, i.e. the responder cannot
   move to an address which is not known by the initiator, in case
   initiator also moves behind NAT.

To

   MOBIKE can work in cases where the responder is behind static NAT,
   but in that case the initiator needs to know all the possible
   addresses to which the responder can move. That is, the responder
   cannot move to an address which is not known by the initiator, in
   case initiator also moves behind NAT.

----------------------------------------------------------------------
Change in section 5.2.5 (from Russ, change ", i.e. if" to ". If")

   One new feature created by MOBIKE is NAT prevention, i.e. if we
   detect NAT between the peers, we do not allow that address pair to be
   used.  This can be used to protect IP addresses in cases where it is
   known by the configuration that there is no NAT between the nodes
   (for example IPv6, or fixed site-to-site VPN).  This avoids any
   possibility of on-path attackers modifying addresses in headers.
   This feature means that we authenticate the IP-address and detect if
   they were changed.  As this is done on purpose to break the
   connectivity if NAT is detected, and decided by the configuration,
   there is no need to do UNSAF processing.

To

   One new feature created by MOBIKE is NAT prevention. If we
   detect NAT between the peers, we do not allow that address pair to be
   used.  This can be used to protect IP addresses in cases where it is
   known by the configuration that there is no NAT between the nodes
   (for example IPv6, or fixed site-to-site VPN).  This avoids any
   possibility of on-path attackers modifying addresses in headers.
   This feature means that we authenticate the IP-address and detect if
   they were changed.  As this is done on purpose to break the
   connectivity if NAT is detected, and decided by the configuration,
   there is no need to do UNSAF processing.

----------------------------------------------------------------------
Change in section 5.4 (from Russ, change "IKE-SA" to "IKE SA" to be
consistent in document)

   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.

To

   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.

----------------------------------------------------------------------
Change in section 5.5.2 (from Russ, add comma to "On the other hand,
return ...")

   If the return routability check fails, we need to tear down the IKE
   SA if we are using IKEv2 INFORMATIONAL exchanges to send return
   routability checks.  On the other hand return routability check can
   only fail permanently if there was an attack by the other end, thus
   tearing down the IKE SA is a suitable action in that case.

To

   If the return routability check fails, we need to tear down the IKE
   SA if we are using IKEv2 INFORMATIONAL exchanges to send return
   routability checks.  On the other hand, return routability check can
   only fail permanently if there was an attack by the other end, thus
   tearing down the IKE SA is a suitable action in that case.

----------------------------------------------------------------------
Change in section 5.6 (from Russ and Brian, change "but will" to "and
might be")

   Current MOBIKE design is focused only on the VPN type usage and
   tunnel mode.  Transport mode behavior would also be useful, but will
   be discussed in future documents.

To

   Current MOBIKE design is focused only on the VPN type usage and
   tunnel mode.  Transport mode behavior would also be useful and
   might be be discussed in future documents.

----------------------------------------------------------------------
Change in section 6.2 (from Russ, change "packets.  I.e. a" to
"packets; a")

   Working group decided to use normal IKEv2 exchanges for path testing,
   and decided to change the dynamic address updating of NAT-T to MUST
   NOT for IKE SA packets.  I.e. a new protocol outside of IKEv2 was not
   adopted.

To

   Working group decided to use normal IKEv2 exchanges for path testing,
   and decided to change the dynamic address updating of NAT-T to MUST
   NOT for IKE SA packets; a new protocol outside of IKEv2 was not
   adopted.

----------------------------------------------------------------------
Change in section 6.3 (from Russ, change "notify, i.e. there" to
"notify. There")

   Working group decided to use IKEv2 Notify payloads, and put only one
   data item per notify, i.e. there will be one Notify payload for each
   item to be sent.

To

   Working group decided to use IKEv2 Notify payloads, and put only one
   data item per notify. There will be one Notify payload for each
   item to be sent.

----------------------------------------------------------------------
Change in section 6.4 (from Russ, change "IP-addresses" to "IP
addresses", this same change should be done on section 5.2.5, 6.2 (2
times), and here). 

   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 are considered as one address of the peer, even
   when not present in the list.

To 

   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 are considered as one address of the peer, even
   when not present in the list.

----------------------------------------------------------------------
Change in section 7 (from  Russ, change "modify" to "undetectedly
modify"). 

   As all the packets are already authenticated by IKEv2 there is no
   risk that any attackers would modify the contents of the packets.
   The IP addresses in the IP header of the packets are not
   authenticated, thus the protocol defined must take care that they are
   only used as an indication that something might be different, and
   that do not cause any direct actions, except when doing NAT
   Traversal.

To

   As all the packets are already authenticated by IKEv2 there is no
   risk that any attackers would undetectedly modify the contents of
   the packets.  The IP addresses in the IP header of the packets are
   not authenticated, thus the protocol defined must take care that
   they are only used as an indication that something might be
   different, and that do not cause any direct actions, except when
   doing NAT Traversal.

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Jul 2006 10:35:38 -0400

>can put them in directly while editing the draft if they like).

All seem minor and fine.

--Paul Hoffman, Director
--VPN Consortium