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

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

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 protected]>
https://www.machshav.com/mailman/listinfo.cgi/mobike