Re: peer address protection and NAT Traversal

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:
   
   I've now read and understood draft-dupont-transient-pseudonat-01.txt. I'd
   like to propose language in the IKEv2 and NAT traversal documents to
   address it, but I'm eager to hear from the NAT Traversal folk whether the
   fix will break too many real cases.
   
=> My purpose is not to drop the NAT traversal feature but to make it
optional. This should place the discussion on the default, IMHO we should
be default enable NAT traversal for IPv4 and disable it for IPv6.

   Francis Dupont <[e-mail]> wrote:
   >  The I-D editor has just announced the new version of my I-D about
   > the transient pseudo-NAT attack and its application to Mobile IPv4
   > (documented in the security section of the NAT traversal extension)
   > and to IKE... Its name is draft-dupont-transient-pseudonat-01.txt.
   >  I believe we should fix the issue (the security flaw) for the next
   > version of the IKEv2 document.
   
   I could imagine lots of clever ways to try to deal with this... all with
   clever countermeasures that allow an attacker to exploit them.
   
=> this is my claim: there is no easy defense against the attack which
keeps the NAT traversal feature...

   So what I'd like to propose is that IPsec SAs *not* try to survive
   mid-connection NAT renumberings.

=> this is another problem, in fact we have several issues:
 - IKE and IPsec SAs built with fake addresses (my I-D).
 - mid-connection renumbering of IKE SAs (with or without return
   routability, i.e., with or without more than two packets exchange)
 - mid-connection renumbering of IPsec SAs
and for the two last we have the choice between explicit and implicit
renumbering...

   That an IP address and UDP port be
   associated with an SA during initialization and that all subsequent traffic
   be sent to that address and port until it is timed out and closed. Requests
   *from* an unexpected IP address/port should be ignored. (Perhaps there is a
   way to respond with an alert to make the timeout process converge faster,
   but I couldn't think of one that couldn't be exploited by an attacker).
   
=> so you are against the implicit mid-connection renumbering of IPsec SAs.

   There is a residual attack here where the attacker gets in the middle of
   the initial SA setup and tricks the endpoints into sending to the wrong
   address by forwarding all the packets during setup. (If it continues to
   forward packets throughout the SA, everything works... essentially it *is*
   a NAT. But if it stops it can temporarily get traffic misdirected).

=> this is the transient pseudo-NAT attack.

   This seems like a difficult attack more easily mounted against
   other UDP based protocols.

=> I don't understand the second part of your argument (the "more easily").
BTW my I-D describes a second example (Mobile IPv4) where the issue was
not ignored (cf. the security consideration of the NAT traversal for
Mobile IPv4 I-D).

   And preventing it seems to require detecting NATs and refusing to
   operate through them.

=> exactly.

   Perhaps there should explicitly be a configuration
   parameter in IPsec implementations allowing this.
   
=> I agree (and I propose a default config in the first answer).

   I'm out of my depth here. What do existing implementations do?

=> In many cases the peer address is bound to the authentication
(is the SubjectName of the peer certificate for instance) and is
indirectly checked (this is why this issue is related to the "revised
identity" proposal). In other cases the attack works.

   Do they not support mid-connection renumbering

=> they should support implicit renumbering of IKEv1 SAs
but they should not support it for IPsec SAs, at least by default.

   or are they subject to the DOS attack?

=> there is a little margin between not flexible enough and subject
to attacks. IMHO we should avoid implicit mechanisms (i.e., request
a to-be-defined(*) explicit renumbering exchange) and define some
configuration parameters with defaults in common cases.

   Is there a known better fix?
   
=> see above.

Thanks

[e-mail]

PS (*): IKEv2 rekeying is already usable, even a bit expensive, as
a renumbering exchange for enough flexible implementations (IMHO
we should request this flexibility).