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

From: <[email-masked]>
Date: Mon, 3 Oct 2005 18:06:43 +0300

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

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

Jari, do you have any text to suggest?

Best regards,
Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 3 Oct 2005 20:10:24 -0700

> message: e.g. exchange type and message length).

If you read the previous paragraph :

   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.It says when and how the attack can be launched. I just thought it wouldmake sense to do the same for
NO_NATS_ALLOWED. > > > >- 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.> I thought this attack is where you establish a TCP connection, redirectto a victim, and keep sending
acknowledgements ?-mohan> Jari, do you have any text to suggest?> > Best regards,> Pasi>
_______________________________________________> Mobike mailing list> [email-masked]>
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 3 Oct 2005 20:34:12 -0700

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

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

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

> their destination IP address was not correct. So TCP RSTs would
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