[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: peer address protection
In your previous mail you wrote:
Francis.Dupont@enst-bretagne.fr (Francis Dupont) writes:
> The peer addresses are not protected in IKEv2 and are not clearly
> protected in IKEv1
I do not think there is any need to protect them in IKEv2.
=> 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.
> - 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).
=> yes, in this case the peer has the control on its address(es).
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
=> with a SHOULD (MUST is only needed in some cases, not all cases)
and a peer address update payload or any equivalent I agree.
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
=> 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.
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.
=> this is an effect of the decoupling of peer addresses and "outer"
addresses... BTW I don't understand what you'd like to prove.
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).
=> 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.
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.
=> 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.
Ps. I will be on the vacation for about two weeks starting tomorrow,
so I might not be able to read replies before that.
=> 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
Francis.Dupont@enst-bretagne.fr