> >- 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.