Re: New issue 18: Threat discussion

 Francis,


> 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.
> 
Agreed. 

>    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.
> 
Do you mean "defense" as in detecting NAT (like NAT_PREVENTION in
Pasi's draft) OR a solution that would work when moving behind 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).

This is a bit confusing. Are you saying that the attack is 3rd party bombing if
performed by authenticated peer and transient pseudo-NAT attack if done
by someone else ?

> 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).
> 
It might be useful to clarify what we mean by NAT traversal in these threads.

1) NAT traversal : As defined in IKEv2 base spec. It works only during the beginning
    of IKE session.

2) Behavior of MOBIKE when moving behind NAT  - this is MOBIKE mechanism to support
     moving behind a NAT which is also NAT traversal. But this is something specific
     to MOBIKE and works during anytime not just during SA setup. MOBIKE may or may not
     end up supporing t this feature or it may support partially etc. But this is distinctly different from (1).

-mohan


 > Regards
> 
> [email protected]