issue 27 -- security for path testing

This issue relates to the lack of security considerations
text on path testing. In Paris we decided, obviously
enough, that more text would be needed and that
the actual text would depend on the resolution to issue
34, how path testing is actually done.

In an effort to speed the process up a bit, I wrote
the below text suggestions that correspond to the
different outcomes of issue 34.

The first text suggestion (A) is what we would use if
we continue to use the path testing scheme in -01.
That is, the path test messages are unprotected.

The next text suggestion (B) is what we would use if
we adopt Tero's path testing scheme where the
test messages are regular IKEv2 Informational
exchanges.

Finally, there are some common text changes (C) that
are needed in any case.

Please comment.

--Jari

Change A
======

Add a new paragraph at the end of Section 4:

  MOBIKE also employs its own path test messages
  and can only provide limited protection for them. Specifically,
  these messages are sent outside the protection of the IKE
  SA and can therefore be spoofed, modified, or read. However,
  MOBIKE initiators do not use these messages beyond confirming
  that a sent message gets a response and finding out the
  characteristics of the path (addresses and NATs).  MOBIKE
  responders do not use these messages at all, beyond
  blindly responding to them.

  A cookie mechanism ensures that attackers cannot send a response
  blindly without seeing a request first. Nevertheless, on-path
  attackers can intercept legitimate requests and responses,
  and either prevent them from reaching the destination,
  carrying them to the destination even across networks that
  would not let other packets through, or modify NAT behaviour
  enroute. As a result, these attacks may lead to denial-of-service.
  Note that denial-of-service is typically possible for on-path
  attackers even without the MOBIKE messages, e.g., by blocking
  IKE messages.

Change B
======

Add a new paragraph at the end of Section 4:

  MOBIKE also employs its own path test messages
  and can only provide limited protection for them. Specifically,
  while these messages are protected by the IKE SA, the
  relevant information in these messages is mainly in the
  unprotected parts such as the IP header, and can therefore
  be spoofed, modified, or read. MOBIKE initiators do not
  use these messages beyond confirming
  that a sent message gets a response and finding out the
  characteristics of the path (addresses and NATs).  MOBIKE
  responders do not use these messages at all, beyond
  blindly responding to them.

  A cookie mechanism ensures that attackers cannot send a response
  blindly without seeing a request first. Nevertheless, on-path
  attackers can intercept legitimate requests and responses,
  and either prevent them from reaching the destination,
  carrying them to the destination even across networks that
  would not let other packets through, or modify NAT behaviour
  enroute. As a result, these attacks may lead to denial-of-service.
  Note that denial-of-service is typically possible for on-path
  attackers even without the MOBIKE messages, e.g., by blocking
  IKE messages.

Common Changes C
=============

In Section 4 we have the following text:

   Spoofing indications related to network connectivity

         Attackers may also spoof various indications from lower layers
         and the network in an effort to confuse the peers about which
         addresses are or are not working.  For example, attackers may
         spoof ICMP error messages in an effort to cause the parties to
         move their traffic elsewhere or even to disconnect.  Attackers
         may also spoof information related to network attachments,
         router discovery, and address assignments in an effort to make
         the parties believe they have Internet connectivity when in
         reality they do not.

         This may cause use of non-preferred addresses or even denial-
         of-service.

Add the following to the end of the second paragraph:

        Finally, attackers may spoof information related to the path
        test messages employed by MOBIKE itself.