Subject: Re: a proposal of address management for IKEv2

From: Tero Kivinen <[email-masked]>
Date: 13 Feb 2003 03:57:06 +0200

[email-masked] (Francis Dupont) writes:
> 2.1.4 Extensions of the IKEv2 draft
> 
>     The first things to fix in the current IKEv2 draft [1] are the
>     notifications for NAT traversal (NAT-DETECTION-*-IP):
> 
>      - They use a hash of the SPIs, address and port, following
>        a specification for IKEv1. This makes no sense for IKEv2.

Why not? The reason they are hashed, is that some users do not want to
give out information about the addresses used inside internal net.
They might want to give that information out AFTER the authentication
(i.e after phase 1 has completed, not during the phase 1), and they
may want to give that information out only when using transport mode
(there is no need to give the ip address and port out in case of
tunnel mode). 

>      - There is no specified way to request the inclusion of
>        these notifications in messages.

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. 

> 2.2 NAT traversal requirements
>
>      - When there are several VPN clients behind a NAT, the ability to
>        request a three way handshake (a.k.a. a return routability
>        check) is needed [6].

three way handshake does not really help here nor is it needed. It
will make the attackers job little bit harder, but if the attacker can
modify the packets on the wire, he can also redirect and modify the
packets used by the three way handshake.

The reason for that is that there is no way we can authenticate the
outer address of the NAT, and no matter how many packets we send it
will not help there.

> 3.4 Implicit address update
> 
>     For address update, there is a choice between implicit and
>     explicit mechanisms for IPsec SAs and IKE SAs.
> 
>     We claim that the implicit mechanism for IPsec SAs is far too
>     unsecure: this mechanism is very (too?) simple. When a packet is
>     received from another address, the peer addresses of the IPsec SA
>     pair are updated. This opens the door to easy denial of service
>     attacks and assumes extra-processing by the receiver device.

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.

In most cases if he can do that he can also remove all the packets and
that is much easier denial of service attack, than modifying the
packets. 

>     For the implicit mechanism for IKE SAs the things are even
>     simpler. The implicit mechanism is mainly activated by keepalive
>     exchanges: to switch from the implicit mechanism to the explicit
>     one, only an update notification has to be included. The real
>     difference is in the explicit case an observed peer address change
>     is only a trigger.

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.

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

>     When the receiver of an update request has to check the validity
>     of the new peer address, it MAY use a return routability check
>     sending an informational request at the new address and waiting
>     for an answer. As informational exchanges are protected no more is
>     needed.

No, informational exchanges are not protected, because the IP address
of the packet are not protected, thus this does not protect anything. 

>     Example of a return routability check:
> 
>      I --- address update request --> R
>      I <-- informational RR request - R
>      I --- informational RR reply --> R
>        now the responder knows the initiator should be where it said.
>      I <--- address update reply ---- R

And the attack against this is that the attacker takes the
informational RR request from the point it was going and sends it to
the I, and then it will modify the reply by the I to have the ip
address where the original RR request was going. 

> 4. Security Considerations
...
>    The second (a.k.a. the return routability check) works only with at
>    least three messages, i.e., for the initial exchange (with the
>    address stability requirement) and for the explicit optional
>    checks. IMHO these checks SHOULD be required by default.

As those checks are easy to spoof also, they do not really offer any
more protection. Instead of modifying 1 packet, we need to modify 3. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Feb 2003 19:05:07 +0100

In your previous mail you wrote:

   
=> 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. Same for the port (even I can't
find a reason to keep the port secret).

   
=> I don't know if we can reach a consensus about this in an IPv6
context (where there should be no NATs :-)...

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

   
=> no, you forgot the reverse way (the other SA of the pair) which
is updated too.

=> your argument assumes the routing is symmetrical. If it is not
an attacker on one path can mess the reverse path.

   
=> 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 disagree.
   
=> about the idea of an explicit mechanism itself or about the details?

   
=> the peer addresses are protected by the peer address notification
when the NAT traversal feature is disable (see a previous answer).

   
=> 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 agree the RR check provides only weak security (please don't
forward this to the mobile-ip WG list :-). But without it in the
mobility or multihoming cases, we can only trust your peer...
With it, you can catch some config errors and the attack has to
be an active one.

Regards

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 13 Feb 2003 21:06:00 +0200

Francis Dupont writes:
> 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.

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

> a bit the security, as it is cheap IMHO we should keep a way to

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. 

> => no, you forgot the reverse way (the other SA of the pair) which

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. 

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

> any peer address modification en route is easily detected by peer

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

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

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

> 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. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Feb 2003 10:22:13 +0100

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

=> for privacy issues, a standard secret peer address is better than
a hash because it obviously never lacks knowledge.

   

   
=> look at my previous answer.

   
=> I don't need to be convinced. My concern is I don't know if it will
be easy to convinced others.

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

   
=> I disagree, your argument assumes that both paths go through same
routers and links and that intervals between packets are equivalent
in both ways.

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

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

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

   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
   
=> I disagree. The same mechanism could be used in both cases.

=> support or use? Don't forget the only guy who can put a bad address
is the peer itself.

Regards

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 14 Feb 2003 15:35:15 +0200

> a hash because it obviously never lacks knowledge.

If the this stays static it will leak out information (i.e make the
tracking of user easy). Also you assume that the client will know if
there is NAT beteen (i.e use secret peer address only when there is
NAT, and otherwise use normal address). If there is no NAT then client
must use his own address otherwise we enable NAT-T every time. 

> that I rejected and you seem to like to keep. What is the opinion of

I think that implicit mechanism is very important and usefull for
NAT-T case, and SHOULD or MUST NOT be used in the mobile-ip or
multihoming case (where we can get proper security by explicit
update). 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Sun, 16 Feb 2003 16:29:27 +0100

=> if there is no NAT the secret address will be as it in the packet
header and no more secret. So I assume that when someone wants to
keep it address secret it begins by insert a NAT in the path...

=> IMHO we should avoid to have two worlds, one with NAT-T enabled,
one with NAT-T disabled but with a dedicated mechanism for mobility
and multi-homing. But this is an architectural issue: it is not in the
scope of the IPsec WG and should be submitted to the IESG/IAB.
Until we get an advice from them, can we try to fix all the other
minor details (in fact what I suggested for this pre-last call)?

Thanks

PS: have we enough numbers about renumbering of flows through NATs.
For instance, the mean delay between two renumberings.

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 16 Feb 2003 18:28:31 +0200

> keep it address secret it begins by insert a NAT in the path...

Yes, but the client does not know if there is NAT between before it is
tested, and it might not know if the address is secret or not if it is
given by dhcp. If we give out the static address always in the nat
discovery protocol then there is no way to keep that address secret.
That was the reason the addresses are hashed in the NAT-T draft. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Sun, 16 Feb 2003 18:33:51 +0100

given by dhcp.

=> now I can see your problem.

   If we give out the static address always in the nat
   discovery protocol then there is no way to keep that address secret.

=> so obviously the address should not be in the discovery request.

=> I still don't believe this is the good solution. In fact the initiator
knows there is a NAT only with the reply: my proposal is to keep the
unspecified address as the secret one and to rely on the reply (which
will contain the address received by the responder). The only difference
is the responder can believe there is a NAT in the path when there is none
but we have to handle the case where a NAT is inserted or removed from
the path so this is not a problem...
BTW what is the best mechanism for the switch between ports 500 and 4500?

Thanks

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 Feb 2003 15:43:24 +0200

> will contain the address received by the responder). The only difference

Note, that either one of the ends can be behind NAT. We need to detect
which one (or both) is behind the NAT, to enable keepalives.

> the path so this is not a problem...

I don't think there are cases where NAT is inserted or removed in the
path during the IPsec connection, thus we do not need to take care of
those cases. There are cases where the other ends IP address either
changes or does not change (i.e mobile ip) in transit, but those cases
are NOT NAT cases, as we do know when the address changes and we can
send explicit notification about that.

In my talks NAT is the box in the path that will not give out any
notifications and there is no way to modify its functionality. The
Mobile IP cases are not NAT cases, as we can get information when and
how they modify the ip-addresses.

To fix various attacks, the NAT-T handling MUST NOT be enabled if
there is no NAT between. 

> BTW what is the best mechanism for the switch between ports 500 and 4500?

Immediately when the NAT is detected we switch to 4500 and we stay
there as long as the connection is open (i.e all rekeying etc happens
in that port). When the IKE SA is deleted we SHOULD still remember to
use port 4500 for few minutes (i.e in case we reconnect we should use
the port 4500 for reconnection for next few minutes). After few
minutes there is no need to remember to use port 4500 as the NAT has
already deleted the mapping because we do not send keepalives anymore.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/