Re: New issue 18: Threat discussion

 In your previous mail you wrote:

   > => 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 ?

=> detecting NAT is the job of IKE. For MOBIKE itself it comes after the
initial exchange so uses only protected exchanges. As soon as an address
is inside an exchange (and it should be in an explicit mechanism) it is
protected.

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

=> the original message is a bit old today. Please refer to it.

   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 ?
   
=> yes (the original message listed attacks and refered to my terminology.)

   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.
   
=> this is the definition in the IKE context.

Regards

[email protected]