Re: peer address protection

[Tero Kivinen <kivinen@ssh.fi>]

Francis.Dupont@enst-bretagne.fr (Francis Dupont) writes:
> 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 do not think there is any need to protect them in IKEv2. 

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

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. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/