[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bidding down attach on NAT-T



 In your previous mail you wrote:

   > Please read the NAT-DETECTION-*-IP stuff and say whether you are happy
   > with it (I am *not*)?
   
   Please do, everyone...

=> the first thing I don't understand is why they are in the first
two messages...
   
   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 really like the last thing (a mandatory config knob to turn NAT-T
off when it is supported).

   How important is it for everyone to support NAT-T?

=> I don't believe a MUST support is a good idea because this makes no
sense for an IPv6 implementation.
   
   > => 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,

=> this is a point I don't understand the reason of.

   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.
   
=> I prefer direct protection. For instance, it makes the caching of
NAT detection (the only way to reach an initial responder behind a NAT)
far easier to code safely.

   >   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.
   
=> IMHO Michael assumed an implicit peer address update mechanism
which is very common in NAT-T context.

   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).

=> this is why the peer address update mechanism is used. And it is not
unsecure, in fact, one can argue it improves security.

   One or both endpoints MAY then try to open a new SA with the new addresses
   and ports.
   
=> only the endpoint behind the NAT can. And this is really painful.
Note that rekeying doesn't really solve the issue because the NAT
is by definition out of control: it can change mappings when it likes
and of course never sends notifications to its victims.

   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.
   
=> I disagree, in the case of NAT-T the solution *is* to implement
an implicit peer address update mechanism.

   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

=> these attacks are possible as soon as the NAT-T feature is active.
So the implicit mechanism must be enabled only in this case.

   and we should try to defend against them.

=> with NAT-T the best defense is the implicit mechanism: it opens
a race between the attacker and the peer behind the NAT, the attacker
has to stay on the path, i.e., it becomes an ordinary rogue NAT.

   But is there really a need? TCP connections fail if
   addresses and ports change in the middle of a connection.

=> we never assumed that the tunnel mode is no more used (:-).

   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?
   
=> the two other common cases where an address management is needed,
mobility and multi-homing, need an explicit mechanism with peer address
protection. Today, there is a very inefficient explicit mechanism,
rekeying, and still no good way to protect peer addresses.

Thanks

Francis.Dupont@enst-bretagne.fr

PS: I noted I have to add a protection against long term bidding down
attacks for NAT-T in my draft. The text will be something like:

   In order to avoid a bidding down attack, the implicit mechanism
   MUST verify the presence of a NAT on the path, i.e., the new
   peer address MUST be checked against the peer address in the
   corresponding peer address notification.

   NOTE: what to do when they match?

PPS: has someone a good idea about the note?