Re: issue 45 - clarifications to security considerations

<[email protected]> Mon, 24 Oct 2005 14:01:36 +0300
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
Jari Arkko wrote: 
>
> I think the only thing that Mohan wanted to do was to
> explain the condition of the attack that NO_NATS_ALLOWED
> protects against. Here's the simple text modification:
> 
>    MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
>    detect modification, by outsiders, of the addresses in the 
>    IP header.
>    ...
> 
> =>
> 
>    MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
>    detect modification, by outsiders, of the addresses in the 
>    IP header.
>    Such modifications can only be performed by attackers who are on
>    the path and capable of modifying the IKEv2 and IPsec packets.

This sounds redundant to me: it basically says that modifications
can be performed only by attackers who can modify the packets...??

(And attacks by the IKE peer are discussed in section 6.3, not here)

> Add the following text to the end of this paragraph:
> 
>   ... Such an attack could also be defeated by use of
>   negative acknowledgements, such as TCP RST and ICMP
>   errors. However, too eager reliance on such acknowledgements
>   has some denial-of-service issues itself. Also, many networks
>   filter ICMP messages, and in our case the lack of a valid SA
>   in the victim prevents TCP processing of incoming ESP packets.

No, this is misleading: the victim sees only a bunch of ESP
packets it cannot decrypt, and it doesn't even know who
the real sender (e.g., TCP endpoint) is. And if you don't know 
that, where do you send the TCP RSTs or other negative acks?

BR,
Pasi