Comments on draft-ietf-mobike-protocol-00.txt

Sections 1, 2 and 3 look great to me.  Thanks for the fast turnaround.

Comments on 4. Security considerations

The IESG security reviewer of this section will be concerned with 3
issues:

1. Is there a mitigation for every threat?
2. Which mitigations are associated with which threats?
3. For each threat, what are the specific mitigation(s)?

This section does not make this explicit.  Here is a suggestion for
this, which is to label the threats and countermeasures and refer to
them, but other ways will work as well.  I have included more technical
comments inline.

Threat 1: 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.

      The scope of these attacks in the MOBIKE case is limited, as all
      traffic is protected using IPsec.

Mitigation: Countermeasure 1 - Payload traffic protection, etc.

      (* Delete this and move to threat 2 *) However, it should be
observed
      that security associations originally created for the protection
      of a specific flow between specific addresses may be moved through
      MOBIKE.  The level of required protection may be different in a
      new location of a VPN client, for instance.

I would argue that this second paragraph is really a separate threat
that has nothing to do with traffic redirection and hijacking.  So I
have made a separate threat number 2 as follows. 

Threat 2: Roaming into a network with a different security policy

      Note that security associations originally created for the
protection
      of a specific flow between specific addresses may be moved through
      MOBIKE.  The level of required protection may be different in a
      new location of a VPN client, for instance.

Mitigation: Countermeasure 6 - Policy enforcement for roaming clients,
etc.

Threat 3: Third-party denial-of-service through flooding

Mitigation: Countermeasure 6 - Strong authentication for IKEv2, etc.

Threat 4: Spoofing indications related to network connectivity

(* There is a discussion here of this issue and then a similar
discussion is repeated in the countermeasure section OUTSIDE of the list
of countermeasures.  It starts with the sentence: "MOBIKE does not
provide any protection of its own for indications..."  I'm not sure why
it is structured this way and it is confusing.*)  

Mitigation: Countermeasure 5 - Use of security mechanisms in network and
lower layers, etc. 

Threat 5: Denial-of-service of the participants through  MOBIKE

Mitigation: Countermeasure 5 - Use of security mechanisms in network and
lower layers, etc.

MOBIKE addresses these threats using the following countermeasures:

Countermeasure 1: Payload traffic protection

Countermeasure 2: Protection of MOBIKE payloads

Countermeasure 3:  Explicit Address change

When NAT Traversal is supported, the peer's address may be updated
      automatically to allow changes in NAT mappings.  The "continued
      return routability" feature, implemented by the COOKIE2 payload,
      allows verification of the new address after the change.  This
      limits the duration of any "third party bombing" attack by off-
      path (relative to the victim) attackers.

*** I'm not sure what a "continued return routability" feature means.
It is not defined anywhere else.  You need another sentence or something
in the earlier section on return routability to clarify this. ***

Countermeasure 4: Return routability tests

***Delete the last paragraph  beginning with:
   MOBIKE does not provide any protection of its own for indications
   from other parts of the protocol stack.  However, MOBIKE is resistant
   to incorrect information from these sources in the sense that it
   provides its own security for both the signaling of addressing
   information as well as actual payload data transmission.  Denial-of-
   service vulnerabilities remain, however.  Some aspects of these
   vulnerabilities can be mitigated through the use of techniques
   specific to the other parts of the stack, such as properly dealing
   with ICMP errors [ICMPAttacks], link layer security, or the use of
   [SEND] to protect IPv6 Router and Neighbor Discovery.***

Substitute this with a countermeasure:

Countermeasure 5: Use of security mechanisms in network and lower layers

   These
   vulnerabilities can be mitigated through the use of techniques
   specific to the other parts of the stack, such as properly dealing
   with ICMP errors [ICMPAttacks], link layer security, or the use of
   [SEND] to protect IPv6 Router and Neighbor Discovery.

Countermeasure 6: Policy enforcement for roaming clients

This mitigation is strictly dependent on policy so there are many
acceptable scenarios for mitigating this risk.  The following scenario
is included for illustrative purposes only.

Suppose the level of protection is greater at the new location than it
is at the old.  Then this new address should not be included in any
address list and a new security association should be created when this
client moves.

Suppose the level of protection is less at the new location that at the
old.  Then it is allowable to include this network address in the
additional address list. 

This may seem overly nit picking, but what I'm really doing here is
making the case that you have a sound security threat analysis and a
list of effective countermeasures that will stand up under security
scrutiny.  I haven't worked out all the text here and I realize there
are holes in this writeup but this shows the general idea.  

As always, just my 2 euros.  Good job on the security section as well. 

-- Maureen