Re: New issue 18: Threat discussion

 In your previous mail you wrote:

   The way I understand the pseudo-NAT problem, the attacker does
   modification of addresses in the IP header. The authenticated/encrypted
   IKE datagram does not get affected. Since the attack is on the general 
   IP header, the problem is general in nature than specific to MOBIKE.
   Though I agree it has relevance for MOBIKE.
   
   If a general solution is offered,

=> the general solution is easy: protect the addresses in the IP header.
Of course it has an immediate drawback: NAT traversal is no more possible.

   it would work as much for IP traffic

=> for general IP traffic it is named AH.

   as for the MOBIKE traffic.

=> MOBIKE (and any other signaling protocol) is different because the
attack has a side effect outside the MOBIKE traffic itself (this is why
the attack is qualified as "transient" pseudo-NAT attack).

   The converse may not be true, i.e. a MOBIKE-only
   solution may not work for the general IP case.

=> I agree but this doesn't matter because the MOBIKE security target
is higher, i.e., any MOBIKE mechanism should include a defense against
the transient pseudo-NAT.

   I think Francis expressed his
   non-preference for a MOBIKE-only solution, in an earlier message. 
   
=> my position is the attack should be in the list of attacks considered
in the design phase/document. BTW it is in, and the discussion is more
about the 3rd party bombing, i.e., in my terminology the attack performed
by an authenticated/authorized peer (and obviously something is not right
in the authentication/authorization in this case).
Another point of interest is the security of NAT traversal (not in order to
modify it, but in order to compare) which is of course subject to the attack
but which includes its own defense (implicit update to the last seen peer
address and keepalive mechanisms which narrow the window of attack effect).

Regards

[email protected]