--------------------

Francis Dupont (2005-09-08):

   Currently the idea is that if you support NAT-T, you include
   NAT_DETECTION_*_IP payloads; if you don't want NAT-T and do want
   the "NAT prevention" feature, you include NAT_PREVENTION (but
   not NAT_DETECTION_*).
   
=> I agree, my concern is there must be no case without any NAT_XXX.

--------------------

Pasi Eronen (2005-09-09):

(I've split this away from issue 40.)

The current version of the protocol draft does not require hosts 
that do not support NAT-T to use the "NAT prevention" feature.

Francis has suggested that this "middle ground" should be eliminated;
in other words, the initiator would always include either
NAT_DETECTION_*_IP (if it supports NAT-T) or NAT_PREVENTION (it it
doesn't) in all IKE_SA_INIT and UPDATE_SA_ADDRESSES messages.

Any comments about this?

My gut feeling is that we should keep this middle ground; after all,
implementations that don't bother to implement NAT-T and UDP
encapsulation can still work through (manually configured) static NATs
and some types of IPv4/v6 translators.

NAT_PREVENTION also creates a denial-of-service vulnerability even
when no malicious attackers are present: a misconfiguration or
introduction of a non-malicious translator causes the peers not to use
that path (and if it was the only one, connection fails).

Or as I put in my IETF63 slides, this is a "trade-off between DoS-ing
yourself and religious beliefs". In my opinion, we don't need to
settle this trade-off in the protocol spec by saying "MUST use NAT
prevention if not using NAT-T": the functionality is available for
those who really want to use it (and understanding NAT_PREVENTION is
mandatory for the responder).

--------------------