[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a proposal of address management for IKEv2
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).