Re: a proposal of address management for IKEv2
Francis Dupont <Francis.Dupont@enst-bretagne.fr> Fri, 14 February 2003 11:02 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 GAA15983 for <ipsec-archive@lists.ietf.org>; Fri, 14 Feb 2003 06:02:08 -0500 (EST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA19825 Fri, 14 Feb 2003 04:21:03 -0500 (EST)
Message-Id: <200302140922.h1E9MDof003209@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: a proposal of address management for IKEv2
In-reply-to: Your message of Thu, 13 Feb 2003 21:06:00 +0200. <15947.60568.261489.957133@ryijy.hel.fi.ssh.com>
Date: Fri, 14 Feb 2003 10:22:13 +0100
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 writes: > => I don't buy this argument because it implies there is a known NAT > on the path. In this case any address which cannot be the address > seen by the other peer does the job. Yes, the other end will know there is nat between, but he does not know which address is actually used by the host behind NAT. Some IT-adminstrators want to keep the internal addresses hidden. => it seems we agree. If you believe this is a common case, I can add some text about this, for instance making the unspecified peer address the value to use when the peer wants to keep it address secret. The example case is when someone is using host behind corporate firewall which also does the NAT for all the addresses, and connects to some known service in the external net (say www.cnn.com). The IT-adminstrator does not want to give out the information about the internal ip-address, to this external machine. They might not want to give out information that this connection is coming from the same host than the previous connection few days earlier (i.e privacy issues). => for privacy issues, a standard secret peer address is better than a hash because it obviously never lacks knowledge. If the ip-address is public or if there is no randomness in it (spi/cookie/nonce or similar) then the other end (www.cnn.com) can track the users behind the corporate firewall because their internal ip-addresses are typically static. > Same for the port (even I can't find a reason to keep the port > secret). For source ports there is no need to keep it secret, and in most cases it will be always same. If the users want to have better privacy protection, they can always use random source port to make the brute force attack harder. The attacker can do brute force attack against hash. I.e take the other stuff and try all possible ip-addresses. As the ip-address space is usually quite small for ipv4 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 == 17891328 hosts) the attacker can break the hash, but it requires active expensive attack against each hash separately. The hashing does not help for attacker who has enough computing power, but it does make passive tracking of users impossible. => look at my previous answer. > In the IKEv1 they were always included if the support for NAT-T was > detected by vendor-IDs, in IKEv2 I would say we MUST always include > them. > => I don't know if we can reach a consensus about this in an IPv6 > context (where there should be no NATs :-)... True, but I think that making the protocol simplier has more value than the cost caused by extra hash in the packet. And I do not know what all kind of 6to4 etc conversions will do for the packets, and I think they will be detected as NATs so having them in the ipv6 space also would help in those cases. I do not know enough about those issues to be sure. => I don't need to be convinced. My concern is I don't know if it will be easy to convinced others. > => the purpose of the RR check is mainly operational according > to Jayant Shukla. There are other cases where an RR check improves > a bit the security, as it is cheap IMHO we should keep a way to > perform it. As the IKEv2 peer can always send empty notification to other end assume to get reply back, there is always a way to do it. I.e we do not need to specify anything for it, it is simply a implementation issue (i.e implementation might want to do it, or it might not do it). It does not affect interoperability. => the RR text is mainly an example (I don't use new things), I have just to make it more clearly an example, haven't I? > Note, that the attacker needs to continue attacking before he can gain > anything. If he only modifies one packet the correct address will be > updated back when the next packet is sent. I.e for the attacker to > cause denial of service attack he needs to along the path and modify > every single packet going on one direction. > > => no, you forgot the reverse way (the other SA of the pair) which > is updated too. True, but it is updated back immediately when the first non-modified packet is left through to the other end. Also usually if the attacker can modify/remove packets in one direction he can modify/remove packets in the other direction too. => I disagree, your argument assumes that both paths go through same routers and links and that intervals between packets are equivalent in both ways. > => your argument assumes the routing is symmetrical. If it is not > an attacker on one path can mess the reverse path. I think symmetrical routing is the most common case, => I believe that most of NANOG people will object. Unfortunately it seems that symmetrical routing is no more the common case. and even if it is not, the attacker can send the first packet so that the return routability check packet comes to place where he can reach it. => I used the asymmetrical routing argument for two points: - implicit IPsec SA update - return routability check. I shan't really defend the RR check with this argument because the RR check is known to provide weak security. But for the implicit IPsec SA routing the argument is far stronger. In fact, I don't believe you can argue the implicit IPsec SA update has no security problems, i.e., you can sell it to the IPsec WG. > And the attacker can still take the explicit return routability test > packet and forward it to proper place and finish the 3 way handshake > to get the same attack. Again he needs to stay in the path and he > needs to do some extra work, but I don't really think that will be > that much harder to do. > > => this attack works *only* when the NAT traversal feature is enabled > (and I argued that in this case you have near no defense, look at > draft-dupont-transient-pseudonat-01.txt). For mobility or multihoming > any peer address modification en route is easily detected by peer > address notification. I am only talking about the cases where we have detected NAT, and enabled NAT traversal. The IKEv1 NAT draft tries to be clear that any of these are only done if the other end behind the NAT (i.e if you have client behind NAT and server is directly connected, then only server will update the peer addresses, the client will never do it). => the purpose of my address management proposal is mainly the support of mobility and multihoming. As the NAT traversal feature shares many points with it and was too quickly copied from the IKEv1 NAT draft, I took the opportunity to fix and extend it, but for the security point of view I didn't fix the NAT traversal security flaw (IMHO it cannot be fixed by simple solutions), I tried to avoid new security problems for mobility and multihoming. > > 3.5 Explicit address update > > The explicit mechanism MUST be used. A new notification has to > > be defined. We propose to copy it from the delete notification. > I disagree. > => about the idea of an explicit mechanism itself or about the details? About the MUST. => it is more a MUST NOT for implicit IPsec SA update. I think it can be MAY, i.e the implemenation MAY do the return routability check, but in most cases there is no need for it, and it does not offer more protection against denial of service attacks. => I have no requirement for the RR check but I should add some: - MUST support it (but in fact this is an empty requirement because the RR check is not a new specification) - MAY use it - default config SHOULD enable it. What the host behind NAT might want to do is to make sure it sends some packets to the other end every now and then, especially if it has not received anything back (i.e if the attacker modified the packet and the other end updated peer address, the client should send some packets every now and then to fix the situation when the attacker stops active attack). > => the peer addresses are protected by the peer address notification > when the NAT traversal feature is disable (see a previous answer). If NAT traversal feature is disabled then I do not think we should ever update the other ends address (execpt for mobile-ip, but I everything I have been saying only handles NAT-T). => this is the difference between us. I want the support of mobility and multihoming, you want the support of NAT-T. I believe we can get both if we agree about the security stuff. For mobile-ip this kind of thing is usefull, but we cannot use the same mechanism in the NAT-T, thus I think we should keep them separate. => I disagree. The same mechanism could be used in both cases. > => idem. I never pretended to have a solution to the NAT traversal > feature intrinsic security flaw. Thanks for many examples of it (:-). > Now, if the NAT traversal feature is disabled, do you believe there > are remaining new security threats? I haven't considered the case without NAT-T, so I cannot say for sure, but I think there explicit return routability check is MUST. => support or use? Don't forget the only guy who can put a bad address is the peer itself. Regards Francis.Dupont@enst-bretagne.fr PS: the main question is about the implicit IPsec SA update mechanism that I rejected and you seem to like to keep. What is the opinion of the IPsec WG people? To summary it, the peer address of the other end is the external address of the last received valid packet of the (incoming) SA. The security issue is that at the exception of AH SAs, this address is not protected at all and a change has an effect on other SAs (for instance the other SA of the pair). IMHO there are some implementation efficiency issues too... Note that if such a mechanism is accepted there is no more need for an (other) address management in IKEv2 and I'll have to revised my proposal (i.e., flush large parts of it).
- a proposal of address management for IKEv2 Francis Dupont
- Re: a proposal of address management for IKEv2 Tero Kivinen
- Re: a proposal of address management for IKEv2 Francis Dupont
- Re: a proposal of address management for IKEv2 Tero Kivinen
- Re: a proposal of address management for IKEv2 Francis Dupont
- Re: a proposal of address management for IKEv2 Tero Kivinen
- Re: a proposal of address management for IKEv2 Francis Dupont
- Re: a proposal of address management for IKEv2 Tero Kivinen
- Re: a proposal of address management for IKEv2 Francis Dupont
- Re: a proposal of address management for IKEv2 Tero Kivinen