Re: peer address protection
Francis Dupont <Francis.Dupont@enst-bretagne.fr> Wed, 23 April 2003 12:37 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16034 for <ipsec-archive@lists.ietf.org>; Wed, 23 Apr 2003 08:37:52 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25138 Wed, 23 Apr 2003 05:55:18 -0400 (EDT)
Message-Id: <200304230959.h3N9xZof001659@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Tero Kivinen <kivinen@ssh.fi>
cc: ipsec@lists.tislabs.com
Subject: Re: peer address protection
In-reply-to: Your message of Wed, 16 Apr 2003 07:05:06 +0800. <16028.36898.778373.788474@tero.kivinen.iki.fi>
Date: Wed, 23 Apr 2003 11:59:35 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
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
- peer address protection Francis Dupont
- Re: peer address protection Tero Kivinen
- Re: peer address protection Francis Dupont