Subject: peer address protection

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Apr 2003 19:19:49 +0200

The peer addresses are not protected in IKEv2 and are not clearly
protected in IKEv1 (in fact many implementations loosely bind them
to the ID or to a CERT subject name so attacks work only in the
road warrior case which of course conflicts...).
I propose a very simple scheme:
 - the first exchange (IKE_SA_INIT) is done using UDP port 500
   (common case) or UDP port 4500 (if someone believes there should
   be a NAT in the path). The NAT detection, using NAT_DETECTION_*_IP
   notifications, MUST be performed in this first exchange.
 - First case: a NAT is detected and NAT traversal is enabled:
   IKE and IPsec SAs run over UDP port 4500, implicit address update
   is enabled ONLY for the peer(s) which is behind the NAT (i.e., the
   address of a peer which is not behind a detected NAT is not allowed
   to change). This implicit address update mechanism SHOULD be supported
   and when it is triggered a check MUST be performed between the new
   address and the corresponding NAT_DETECTION_*_IP initial notification:
   if the addresses are the same (i.e., the detected NAT has disappeared)
   we fall into the third case or the IKE SA SHOULD be closed and
   reopened over UDP port 500.
 - Second case: a NAT is detected and NAT traversal is disabled:
   the connexion MUST be rejected.
 - Third case: no NAT is detected and for some reasons the initiator
   wants to run over UDP port 4500. It MAY keep the UDP port 4500
   but as there is a bidding down attack against performances (NAT
   traversal has a cost, note that there is no security problem because
   as no peers are behind a NAT the implicit update mechanism MUST
   NOT be allowed) so a SHOULD is needed for the last case.
 - Fourth/last case: no NAT is detected: IKE and IPsec SAs SHOULD be
   run over UDP port 500 and peer addresses MUST be protected using
   PEER_ADDRESS_SOURCE and PEER_ADDRESS_DESTINATION notifications
   included in the encrypted payload of all messages.

The concrete proposal for these notifications are:

<to be inserted at the end of 3.10.1>

        PEER_ADDRESS_SOURCE                      2458X

            This notification is used to protect the source peer
            address against en route modifications. It includes the
            address family (from IANA Address Family Numbers, IPv4 is
            1 and IPv6 2) on 16 bits, followed by the source port on
            16 bits and the peer source address. It MUST be in an
            encrypted payload. At least one PEER_ADDRESS_SOURCE
            notification MUST be included into each message after
            the first exchange when no NAT has been detected.

            When multiple PEER_ADDRESS_SOURCE notifications are
            included, they encode its whole peer source address
            set, but the first one MUST be for the used source
            address.  To allow the reduction of the peer source
            address set to one address, an address MAY be repeated.

            In case of a mismatch between the source address and the
            corresponding peer address notifications, there is a
            dangling update or an attack. If the possibly compromised
            message is a new request, its content MUST be ignored and
            a warning notification sent, but the message counter MUST
            be incremented in order to accept next requests. If it is
            a retransmitted request, the cached reply MUST be sent. If
            it is a reply, the corresponding request MUST be retransmitted.

        PEER_ADDRESS_DESTINATION                 2458X

            This notification is used to protect the destination peer
            address against en route modifications. It includes the
            address family (from IANA Address Family Numbers, IPv4 is
            1 and IPv6 2) on 16 bits, followed by the destination port
            on 16 bits and the peer destination address. It MUST be in
            an encrypted payload. At least one PEER_ADDRESS_DESTINATION
            notification MUST be included into each message after
            the first exchange when no NAT has been detected.

            When multiple PEER_ADDRESS_DESTINATION notifications are
            included, they encode its whole peer destination address
            set, but the first one MUST be for the used destination
            address.  To allow the reduction of the peer destination
            address set to one address, an address MAY be repeated.

            In case of a mismatch between the destination address and
            the corresponding peer address notifications, there is a
            dangling update or an attack. If the possibly compromised
            message is a new request, its content MUST be ignored and
            a warning notification sent, but the message counter MUST
            be incremented in order to accept next requests. If it is
            a retransmitted request, the cached reply MUST be sent. If
            it is a reply, the corresponding request MUST be retransmitted.

NOTES:
 - can the "first one MUST be for the used source address" be a problem,
   i.e., should we use a SHOULD or a MUST? Note that the NAT detection
   gives the used address and IPsec assumes the source (and destination)
   addresses are stable.
 - there is no defined warning in case of address mismatch, so please
   add after:

        PEER_ADDRESS_ALERT                       2458X

            This notification is used to signal possible problems
            with peer addresse. For instance it MUST be included in
            replies when a new request has been received with a
            modified en route peer address and was ignored.

Thanks

[email-masked]

PS: as an implementor I clearly chose simplicity over message size!
The remaining stuff is for 2.11 (address and port agility) which needs
to be extended and of course for 2.13 (NAT traversal) but for the last
thing I'll wait for Tero's new wording integration. The introduction
of this message can give a good idea of my current opinion...
PPS: an overbroken NAT can mess all attempts to run IKE over UDP port 500
so we have to allowed both to run IKE over UDP port 4500 (which is an
optimization if there is a NAT) and to keep the port 4500 if the NAT
doesn't show itself.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Apr 2003 07:05:06 +0800

> road warrior case which of course conflicts...).

I do not think there is any need to protect them in IKEv2. 

>    included in the encrypted payload of all messages.

If we do not have NAT between (meaning that NAT-T is disabled), then
this also means that the host changing ip address will know when it
does so (it is mobile node, which gets new ip address or it is
multihoming device which decides to use another interface for the
traffic).

This means that to update any of the IPsec or IKE SA peer addresses,
it MUST send the SOURCE-ADDRESS-CHANGED notification telling that this
will be its new source IP address/port. It SHOULD do this immediately
when it can receive from the new address/port, and I think it MAY send
it from the old address/port. This notification will tell the new
source IP address and port.

If some attacker will modify some IP header source address or port of
the IKE packet that does not affect anything else, than that the
responce is sent back to this modified address. It does not affect to
the future packets sent in the IKE SA nor does it change the tunnel
endpoint addresses used for the IPSec SAs. The future IKE packets
still use the same official IKE SA IP address, which was used in the
beginning, or which was changed using SOURCE-ADDRESS-CHANGED
notification.

For the tunnel endpoints the IKE will also use the same official IKE
SA IP address, thus even if the packet seemed to come from different
address the tunnel endpoint address is taken from the IP address
associated with the IKE SA.

Only way to change this IP address associated with the IKE SA is to
use SOURCE-ADDRESS-CHANGED (this whole discussion is discussing case
where we do NOT have NAT, i.e when the NAT-T is not enabled).

I.e only thing attacker can gain by modifying the source address is to
get one reply packet to be sent to wrong address. This not really a
attack, as he could have sent the packet directly there (i.e it is one
extra packet to wrong address per one modified packet).

I do not thing we need PEER_ADDRESS_SOURCE, 
PEER_ADDRESS_DESTINATION or PEER_ADDRESS_ALERT notifications. The
SOURCE-ADDRESS-CHANGED is the only thing we need.

I cannot see any pseudo NAT attack that will work with this protocol.
If you can see something, can you explain it to mee (with exact packet
examples, please).

Ps. I will be on the vacation for about two weeks starting tomorrow,
so I might not be able to read replies before that. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Wed, 23 Apr 2003 11:59:35 +0200

In your previous mail you wrote:

   [email-masked] (Francis Dupont) writes:
   > protected in IKEv1

=> please reread draft-dupont-transient-pseudonat-01.txt...
This is not a dramatic need (i.e., we have not to fix IKEv1 too)
because the issue is DOS attacks using IKE, but we should take
the opportunity to cleanup this in IKEv2.

   
=> yes, in this case the peer has the control on its address(es).

=> with a SHOULD (MUST is only needed in some cases, not all cases)
and a peer address update payload or any equivalent I agree.

=> I believe the complexity of updating to another address than the one
used for the transport of the update is higher than possible benefits.
Note we have the same issue for CREATE_CHILD_SA exchange: uses the peer
addresses from the IP headers or send the "outer" addresses in a payload
or a notification. The second is strictly more powerful but far more
complex too.
BTW if I've understood all the details of your proposal in fact the
SOURCE-ADDRESS-CHANGED notification MAY be sent from any address/port,
i.e., not only from the old or new address/port.

   
=> this is an effect of the decoupling of peer addresses and "outer"
addresses... BTW I don't understand what you'd like to prove.

   
=> there is no such address lock in the current draft. If we introduce
one, we have to be accurate in the exchange which locks the addresses
(for instance the IKE_SA_INIT one) and at a side effect it makes the
support of an peer address update payload/notification mandatory because
a rekeying won't be enough to change "outer" addresses.
I.e, this is a real change and I am afraid we have not enough time
to decide about it.

   
=> in fact it seems you propose to replace my explicit protection
of the peer addresses with a peer address update payload by a different
scheme which should roughly give the same things.
In your proposal:
 - the peer addresses are "locked" in the IKE_SA_INIT exchange
   (this exchange because this is the only exchange where the peer
    addresses are indirectly protected by the NAT detection notifications
    and the AUTH payload of the IKE_AUTH exchange).
 - the "locked" pair of peer addresses is used for tunnel endpoint
   addresses (what I called the "outer" addresses),
 - as they are "locked", there is no need to protect them further but
   only a pair of peer addresses are managed by a IKE SA.
 - the only way to change this pair of peer addresses is the
   SOURCE-ADDRESS-CHANGED which has a global effect (global in place
   of per IKE SA/IPsec SA pair).
I have three main concerns:
 - only one peer address is managed per peer when in some cases
   (mainly in multi-homing) it is better to manage an address set.
   This shan't be a real problem without the second point.
 - your SOURCE-ADDRESS-CHANGED notification has a global effect,
   i.e., it is not possible to update only an IPsec SA pair and
   to keep the "old" address for the IKE SA and other IPsec SA pairs.
   In a PS I give a scenario where this is a real problem.
 - rekeying doesn't change the locked pair of peer addresses so
   the support of your SOURCE-ADDRESS-CHANGED notification should
   be mandatory in mobility and multi-homing environments (i.e.,
   the update mechanism is no more an optimization).

   I cannot see any pseudo NAT attack that will work with this protocol.
   If you can see something, can you explain it to me (with exact packet
   examples, please).
   
=> I agree that when the peer addresses are "locked" in the IKE_SA_INIT
exchange a pseudo NAT attack cannot setup a SA with NAT traversal inactive
(addresses are protected by the NAT detection notifications which are
themselves protected as the content of IKE_SA_INIT messages by the AUTH
payloads in the IKE_AUTH exchange). The only possibility for a pseudo
NAT attack is to force a NAT detection but the implicit update mechanism
(which SHOULD be supported for this reason) removes the "transient"
property, i.e., this becomes a common NAT attack and IKE no more needs
a specific defense against it.

=> I'm back from vacation and in the announce of the draft 07 there is
something for us: "My inclination is to leave that for a subsequent
effort, possibly to be folded into a future revision when it stabilizes".
I'm afraid that the NAT traversal support is postponed too which was
never in my intention...

Thanks