Re: bidding down attach on NAT-T

[Charlie_Kaufman@notesdev.ibm.com]

Francis Dupont <Francis.Dupont@enst-bretagne.fr> wrote:
> Please read the NAT-DETECTION-*-IP stuff and say whether you are happy
> with it (I am *not*)?

Please do, everyone. I tried to copy the philosophy of the NAT-T documents
into IKEv2, but I may have gotten it wrong and the documents I copied may
have been wrong. Proofreading by people knowledgeable in this space is
vital.

For example, I was just rereading ESP encapsulation and it is different
than I remembered and different than what I wrote in IKEv2-05. It's a
detail, but it's important. How does a packet sent to UDP port 4500 get
identified as ESP or IKE. What I remember (and wrote) was that IKE messages
have four bytes of zero prepended and ESP SPIs are not allowed to be zero.
This leads to no overhead for ESP and 4 bytes for IKE. But reading
draft-ietf-udp-encaps-01.txt (April 2002), it calls for eight bytes of zero
prepended to ESP packets and IKE SPIs are not allowed to be zero. This
results in no overhead for IKE packets and 8 bytes for ESP. Did this change
somewhere along the line, and if so which proposal won? Either design
works, but they can't be mixed on a single port.

>    I do think that NAT-T support should be required.
>
> => I have no objection but:
>  - configuration must have a knob to disable NAT-T support
>  - NAT detection must be secure.
>
>    You never know when there will be a NAT between you and your peer.
>
> => I agree but there are some cases where you don't want to support
> a NAT between you and your peer.

Currently ikev2-05 says that NAT support is optional in an IKE
implementation. There are other statements that could be made. It could say
that implementations MUST support NAT-T but that it MAY be configured off.
It could say that if an implementation supports NAT-T, then it MUST have a
configuration switch to turn it off.

I don't have strong feelings. My priorities are keeping the MUST features
minimal while assuring that any two implementations with the MUST features
can be configured to interoperate. How important is it for everyone to
support NAT-T?

> => yes but the current draft does the NAT detection in the only unsecured
> IKE messages, i.e, too soon!

The current draft does NAT detection in the first two messages, which are
not directly cryptographically protected. They are indirectly protected,
however, because MACs of the first two messages are included in subsequent
messages. So someone faking out the NAT detection messages would not
successfully set up an SA.

Michael Richardson <mcr@sandelman.ottawa.on.ca> wrote:
>   The thing that we could do, is require some kind of three way handshake
to
> change the UDP port #/IP address. That could be a rekey.
>
>   This assures that the flow doesn't get aimed at some innocent
bystandard
> until the real client speaks again.
>
>   The sequence would go something like this:
>
>       gateway receives new UDP port #/IP
> #1    sends notify to old UDP port #/IP,
>        indicating that it thinks it should change
> #2    sends notify to new UDP port #/IP,
>        indicating that it thinks it is time to rekey

I think you're assuming a feature in the protocol that's not there.

There is no way specified to change the UDP port # / IP address of an
existing SA. The assumption is that if the NAT changes the translation of
ports and addresses in the middle of the SA, packets in at least one
direction will stop being delivered and the SA will fail (by timing out).
One or both endpoints MAY then try to open a new SA with the new addresses
and ports.

Something missing from the spec in general is how often to retry failed SAs
and whether to retry immediately when one fails. One could imagine some
really bad strategies (from a performance point of view). I thought it
unnecessary to specify it because it does not affect interoperability and
prescribing such behavior requires that we agree on what it should be. But
some "implementer's hints" would probably be a good idea.

If we were to support address and port changes in the middle of an SA,
there would be possible attacks of the sort you describe and we should try
to defend against them. But is there really a need? TCP connections fail if
addresses and ports change in the middle of a connection. The endpoints are
expected to start over. With Mobile-IP, this may be a common case, so
perhaps they have to deal with it. But do we?


          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).