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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.