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