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

<[email protected]>
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
(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).

Best regards,
Pasi
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.