issue 45 - clarifications to security considerations

Looking at this again...

>- Section 6.1 
>
>The last paragraph talks about NO_NATS_ALLOWED. The attack of
>modifying the header to cause DoS attack is only possible if the
>attacker knows that NO_NATS_ALLOWED is carried within the payload. As
>payloads are encrypted, it may not be that easy always. It is easy if
>it is the IKE_SA_INIT message.It might be worth stating when the
>attack is possible.
>  
>
I think the only thing that Mohan wanted to do was to
explain the condition of the attack that NO_NATS_ALLOWED
protects against. Here's the simple text modification:

   MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
   detect modification, by outsiders, of the addresses in the IP header.
   ...

=>

   MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
   detect modification, by outsiders, of the addresses in the IP header.
   Such modifications can only be performed by attackers who are on
   the path and capable of modifying the IKEv2 and IPsec packets.
   ...

>- Section 6.3
>
>   Normally such attacks would expire in a short time frame due to the
>   lack of responses (such as transport layer acknowledgements) from the
>   victim.  However, as described in [Aura02], malicious participants
>   would typically be able to spoof such acknowledgements and maintain
>   the traffic flow for an extended period of time.
>
>This attack is possible because the victim does not have a valid SA
>for the incoming ESP traffic and never reaches the TCP layer and hence
>no TCP RSTs. Might be worth mentioning here.
>  
>
Add the following text to the end of this paragraph:

  ... Such an attack could also be defeated by use of
  negative acknowledgements, such as TCP RST and ICMP
  errors. However, too eager reliance on such acknowledgements
  has some denial-of-service issues itself. Also, many networks
  filter ICMP messages, and in our case the lack of a valid SA
  in the victim prevents TCP processing of incoming ESP packets.

--Jari