Re: Issue 45: Clarifications to security considerations(was: Comments on draft-ietf-mobike-protocol-03.txt)

It looks like my previous response got garbled up..so retyping it here..

> > >- Section 6.1
> > >     
> > >       The last paragraph talks about NO_NATS_ALLOWED. The attack
> > >       of modifying the header to cause DoS attack is only possible
> > >       if the attacker knows that NO_NATS_ALLOWED is carried within
> > >       the payload. As payloads are encrypted, it may not be that
> > >       easy always. It is easy if it is the IKE_SA_INIT message. It
> > >       might be worth stating when the attack is possible.
> > 
> > Right. Thanks for spotting this!
> 
> Er.. since the last paragraph of Section 6.1 doesn't talk about
> DoS attacks, what exactly should be changed there?
> 
> Causing DoS by modifying a packet containing NO_NATS_ALLOWED
> is mentioned in Section 4.8, but the attacker doesn't need to know
> which packets contain NO_NATS_ALLOWED: it's probably easier to
> modify all of them. (And the attacker could also make a pretty 
> good guess just by looking at the unencrypted parts of the 
> message: e.g. exchange type and message length).
> 
Hmm.. section 6.1 contains:

   However, just like with normal IKEv2, the actual IP addresses in the
   IP header are not covered by the integrity protection.  This means
   that a NAT between the parties (or an attacker acting as a NAT) can
   modify the addresses and cause incorrect tunnel header (outer) IP
   addresses to be used for IPsec SAs.  The scope of this attack is
   limited mainly to denial-of-service, since all traffic is protected
   using IPsec.        ^

It talks about DoS attack here...

   This attack can only be launched by on-path attackers that are
   capable of modifying IKEv2 messages carrying NAT detection payloads
   (such as Dead Peer Detection messages).  By modifying the IP header
   of these packets, the attackers can lead the peers believe a new NAT
   or a changed NAT binding exists between them.  The attack can
   continue as long as the attacker is on the path, modifying the IKEv2
   messages.  If this is no longer the case, IKEv2 and MOBIKE mechanisms
   designed to detect NAT mapping changes will eventually recognize that
   the intended traffic is not getting through, and update the addresses
   appropriately.

Here, it talks about how/why an attacker can launch attacks packets that
carries NAT-D payloads. So, it might make sense to explain the same for
NO_NATS_ALLOWED also. One can modify all ESP packets (without
knowing whether NAT-D payload is included or not) to launch  the attack
described in the previous paragraph, but similar things can be done things
outside of MOBIKE also and hence not very interesting..

> > >- Section 6.3
> > >
> > >        Normally such attacks would expire in a short time frame
> > >        due to the lack of responses (such as transport layer
> > >        acknowledgements) from the victim.  However, as described
> > >        in [Aura02], malicious participants would typically be able
> > >        to spoof such acknowledgements and maintain the traffic
> > >        flow for an extended period of time.
> >
> > >   This attack is possible because the victim does not have a valid
> > >   SA for the incoming ESP traffic and never reaches the TCP layer
> > >   and hence no TCP RSTs. Might be worth mentioning here.
> > 
> > Ok.
> 
> Probably the packets would not even reach the TCP layer, since
> their destination IP address was not correct. So TCP RSTs would
> not happen anyway.
> 
My understanding of this attack is the client establishes the TCP connection,
redirects the stream to a victim and sends false acknowledgements ? (Similar
attack exists in MIP6 and packets get discarded because of Home address
option at the IP layer).

-mohan

> Jari, do you have any text to suggest?
> 
> Best regards,
> Pasi
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike