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

Hi Maureen,

and thanks for your comments!

>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. 
>
Yes, this is an issue.

>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.
>  
>
There may not be 1-to-1 mapping between the threats
and countermeasures. But maybe it would help to number
the threats as you suggested above, and then refer to the
numbers when talkking about the countermeasures later
on (e.g., this countermeasure addresses threat 1.).

>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. 
>  
>
Makes sense.

>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.*)  
>  
>
Hmm. Do you you have a suggested rewrite of this sentence?

>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. ***
>  
>
This needs to be synchronized with the rest of the draft.
First paragraph of Section 2.6 does talk about that, so maybe
a reference to that would be sufficient.

>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.
>  
>
The new text is shorter, but it may not describe well
why what happens in ND matters for MOBIKE. That
was the intent of the sentence that talked about indications.

>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.  
>  
>
Thanks for the suggestions, I think this makes the section
better, and does indeed help readers understand what
is covered and what is not. Lets give Pasi some editing
freedom to fix this...

--Jari