Subject: [Mobike] Review of draft-ietf-mobike-protocol-00

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 08 Jul 2005 15:16:45 -0400

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.

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