Re: issue 27 -- security for path testing

Tero Kivinen wrote:

>Jari Arkko writes:
>  
>
>>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.
>>    
>>
>
>I do not know if the is belongs to here, but the those path test
>messages might also be filtered out by statefull content inspection
>devices (firewalls, intrusion detection / prevention systems etc), as
>they are not part of any existing IKE SA, and some devices might
>consider source IKE SPI being 0 as an attack.
>  
>
This is certainly something that we should document.
Thanks for bringing it up!

>I do know that old NAT boxes used to do IKE SA session tracking based
>on the IKE SPIs and they did the demultiplexing of the incoming
>packets based on the IKE SPIs instead of ports. This shouldn't be
>problem here as we are using port 4500 instead of port 500, and NATs
>should not do that on port 4500.
>
>I am just wondering if there is any boxes that filter IKE packets in
>that kind of statefull way.
>
>The paragraph above also requires some text about replay attacks, i.e.
>stating that each cookie used MUST be unique, and each cookie has only
>certain time window and after that it is forgotten, and if packet
>having that cookie is later received it must not be accepted. If we
>use the path testing inside IKE, then there is message id's taking
>care of the replays, thus cookies does not need to be unique, they
>simply need to be non-guessable. 
>  
>
Yes. Uniqueness is handled in Section 3.5 already, I think.
For the rest we need new text.

>Also in general each cookie is tied to the specific address pair it
>was sent to. I.e. if same cookie is used for multiple addresses pairs,
>then malious host B can fake an response back from the address where
>it actually didn't see the message. This is mostly for B as there we
>do need to retransmit the packet to other addresses if we do not get
>reply back (and in which case we should restart path testing), but
>also for C as this must be taken care of in both cases. 
>  
>
Right. Thanks. Here's an updated text:

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.

  Given that the path test messages use cookie values of zero
  for both ends, its possible that firewalls that inspect
  IKE packets may filter out packets with the sender's SPI
  set to zero.

  Sections 2.5 and 3.5 provide a mechanism which ensures that
  old path test messages can not be replayed, and that responses
  can not be blindly switched to appear to come from a different
  address.

Add to 2.5 COOKIE2 notification payload:

   The use of COOKIE2 is necessary to ensure that the peer cannot
   generate the correct response without seeing the request. The
   sender of the PATH_TEST exchange MUST include a COOKIE2 notification
   payload. The data in this payload MUST be randomly chosen
   as described in Section 3.5, for each new packet that is
   sent.

   The recipient MUST copy the payload as-is to the response.
   When processing the response, the original sender MUST verify that
   the value is the same one as sent, within a reasonable time window
   to avoid replaying old values.  If the values do not match, the
   response MUST be silently ignored.