[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some concerns about last IKEv2 draft
In your previous mail you wrote:
Francis Dupont writes:
> There are cases where a NAT box decides to remove mappings that
> are still alive (for example, the keepalive interval is too long,
> or the NAT box is rebooted). To recover in these cases, hosts that
> are not behind a NAT SHOULD send all packets (including retried
> packets) to the IP address and port from the last valid
> authenticated packet from the other end. A host not behind a NAT
> SHOULD NOT do this because it opens a DoS attack possibility. Any
> authenticated IKE packet or any authenticated IKE encapsulated ESP
> packet can be used to detect that the IP address or the port has
> changed.
>
> => the SHOULD and the SHOULD NOT apply to the same case (host no behind
> a NAT). Obviously there is a typo, IMHO the right version is:
> "A host behind a NAT SHOULD NOT do this ...".
Yep, that seems to be typo.
=> we agree.
> BTW the "any authenticated IKE encapsulated ESP" wording is poor and
> should be removed, or replaced by something which takes into account
> the whole IPsec traffic (both for the detection of the address change
> and for the update of the endpoint behind NAT address).
I think there was also typo, it should say:
"any authenticated UDP encapsulated ESP packet"
=> this is fine but doesn't take into account that these packets too
should be sent to the IP address and port from the last valid...
I.e., the "implicit peer address mechanism" for the peer behind a NAT
should be applied to all the UDP 4500 IKE and ESP packets, not only
to IKE packets. This is both more resilient (as explain at the beginning
of the mentioned paragraph) but also more secure (a pseudo-NAT attacker
has to stay on the path). BTW IMHO it is easier to implement too (only
one state of the UDP 4500 stuff per peer).
Note, that we do not need to care about AH, as they cannot be
encapsulated in the UDP (the current NAT-T does not have support for
AH).
=> I agree: only ESP in tunnel mode support is really useful here.
> - just after this paragraph, there is:
>
> Note that similar but probably not identical actions will likely
> be needed to make IKE work with Mobile IP, but such processing is
> not addressed by this document.
>
> => the Mobile IP case can be symmetrical so an identical action can't
> work in all cases because it would open the door to the DoS attack.
I think the current wording is ok, i.e it says we do not handle those
cases here. I do not understand what your actual concern is in that
paragraph?
=> in fact I don't propose to change the current text: it is not really
wrong, it is only clearly a bit too optimitist: this is more a remark
than a real concern.
> - there is nothing about the protection of peer addresses, so IKEv2 can
> be used to launch DoS attacks... I still believe the easiest fix is
> to make the peer addresses explicit parameters of the IKE SA.
As described above the other mobility, multihoming, sctp, roaming etc
issues are left out from this document, and there will be another
document (from different wg) to take care of those later.
=> the issue about the (lack of) protection of peer addresses is not
part of mobility, multihoming, sctp, etc, issues: these issues just
stress it.
There is NO easy way we can make IKEv2 so that there is no possibility
to do launch DoS attacks. The attacker can always cause the other end
to send cookie request to the faked address, i.e causing a DoS. Only
way to protect against that would require the responder to somehow
authenticate the first packet sent by the initiator without sending
anything back, and that would propably need costly public key
operation, causing easy DoS against the responder.
=> my purpose is not to make IKEv2 100% DoS attack resilient but
to fix to recognized way to use IKEv2 to launch DoS attack.
And if it is easy I can't explain why it is not done.
In the current version attacker can cause packets to diver to
different address by modifying the packets on the fly, but only one by
one basis (i.e each packet needs to be diverted separately).
=> unfortunately this is true only for IKE itself, not for the IPsec
traffic managed with IKE.
If the
other end is behind NAT, then the host behind NAT can be diverted to
send packets to wrong host (DoS attack), but the situation will be
fixed immediately when the attacker stops modifying packets and first
packet from the real host behind NAT comes to the host behind NAT.
=> I agree: in the NAT traversal case, the explicit peer address
update mechanism is a good defense (so it should be completely
specified, and its support encouraged (SHOULD). Cf, the beginning
of messages).
There is no way to protect against that without co-operating with the
NAT box, if we want to allow NAT boxes to be rebooted etc. That part
of the document is only SHOULD so if implementor can leave it out if
he does not care about the problem. I.e for example is willing to pay
the cost of couple of minutes of the packets dissappearing and
reauthentication after NAT changes the IP address. The problem with
reauthentication is that it might require new password/secur-id etc to
be requested from the user.
=> my purpose is to fix the issue in the case there is no NAT or for
the peer which is not behind a NAT. Today an attacker who modifies
only one IKE message in a CREATE_CHILD_SA can divert the IPsec
traffic of the new SA. And my proposed fix is very simple: I'd like
to verify that the peer addresses are IKE SA parameters. As there are
many defenses against an en-route modification of them in the initial
exchanges (NAT detection, cookie, check against ID or CERT, etc), it
is enough to use the IKE SA peer addresses for new IPsec SA endpoint
addresses than the addresses in the last message. And IMHO a SHOULD
is enough, it makes people who take the issue as serious (like mobility
people, please read RFC 3519 Security Considerations) happy, and people
who like unbound but justified use of "address agility" too.
Thanks
Francis.Dupont@enst-bretagne.fr
PS: so what I'd like is a clarification in 2.11 Address and Port Agility, in:
IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
AH associations for the same IP addresses it runs over.
This is no a real definition of what are the IP addresses IKE runs over,
i.e., if different addresses are used which one should be used: this
opens an implementation issue and a flexibility/security trade-off,
solved only in the NAT traversal case for the peer behind a NAT.