Re: a proposal of address management for IKEv2

[Tero Kivinen <kivinen@ssh.fi>]

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.

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

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.

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

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

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

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

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

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

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