Re: Issue 41: Mandate NAT prevention if not doing NAT-T?

 

> Some further thoughts. Even in v4, the benefit
> of the no-preventation-and-no-traversal case is
> extremely small.  Basically, its only different
> to the NAT preventation case if you happen
> to have a rare type of a NAT between. For
> normal NATs, the communication would fail.
> 
> So I would actually like to say something like
> "NAT preventation SHOULD be enabled by default
> if NAT traversal is not enabled." I also checked
> with Pasi that he seems OK with this approach.
> 
> I also reviewed our security considerations
> text, and it seems that we have sufficient
> text to describe what the impact of the
> NAT prevention payloads (or lack of thereof) is.
> However, I did not see sufficient text to
> talk about how temporary or permanent these
> attacks are. I'd like to suggest the following
> text be added between paragraphs 2 and 3
> in Section 4.1:
> 
>   This attack can only be launched by on-path
>   attackers that are capable of modifying either
>   the initial IKE packets or other packets carrying
>   NAT detection payloads (such as Dead Peer Detection
>   messages). By modifying the outer addresses in

Hmm.. with issue 34, we are also allowing updates
from ESP packets..

>   these packets, the attackers can make the peers
>   believe a new NAT or a changed NAT binding exists
>   between them. The attack can continue as long as
>   the attacker is on the path, modifying packets. If this
>   is no longer the case, IKEv2 and MOBIKE mechanisms
>   designed to detect NAT mapping changes will eventually
>   recognize that the intended traffic is not getting through,
>   and update the addresses appropriately.
> 
> Does this work for everyone?
> 
Looks okay to me.

-mohan

> --Jari
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike