Issue 27: Security and path testing (was: Comments on draft-ietf-mobike-protocol-00.txt)

Mohan Parthasarathy wrote:
> -Path testing: 
>- The security impact of this is not discussed in the 
> Security consideration section ?

True, something needs to be added.

> - It states that the reason for new message type is to support
> window size 1.  But it does not state why it can't be secure ? 
> You can still have a separate window space for this message and 
> still provide security, right ? This was discussed in the mailing 
> list. Do you see problems with it ?

It certainly would be possible to encrypt and integrity protect
the path test messages, but I'm not sure if this would actually
improve the security at all.

- An attacker can see the contents of the messages, but since
  they don't actually contain anything interesting, encryption
  does not help here (e.g. NAT detection payloads are sent in 
  clear even in normal IKEv2).

- An attacker could drop the messages and cause the initiator 
  to believe the path does not work (well, that would be a 
  reasonably correct belief in this case). Clearly integrity
  protection does not help here.

- An attacker could modify the contents of the messages. 

  Modifying the COOKIE2 payload has the same effect as dropping 
  the message (initiator thinks the path does not work, reasonably
  correctly so), so no benefit from integrity protection here
  either.

  Modifying the NAT detection payloads seems to have roughly the
  same effect as modifying the IP header or UDP ports, causing
  the parties to detect a NAT where one doesn't exist.

- An attacker can "manufacture" a path test request: not a 
  problem, since this achieves nothing.

- An attacker can "manufacture" a path test response (if it sees
  the corresponding request): I don't think this is a problem
  either. If the attacker has a working path to the responder, it
  could just forward the packet, and let the response come back
  without manufacturing anything.  And the path test message is
  not used as a substitute for dead peer detection anyway, so if
  the peer is really dead, an attacker can't hide that.

And encrypting and integrity protecting these messages is not as
easy as it sounds. For instance, if the response message is
lost, and the initiator retransmits the same request, does the
new response have to be identical to the previous one?  (For
normal IKEv2 messages, the answer is yes. But this implies
keeping state in the responder, with window mechanism to limit
the amount of state that needs to be kept. If the answer would
be yes for path test messages as well, how many path test
messages would have to be kept?)

But perhaps there's some angle I haven't thought about yet;
more comments are welcome...

Best regards,
Pasi