Re: Issue 41: Mandate NAT prevention if not doing NAT-T?
Jari Arkko <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
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 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? --Jari