Re: [Ipsec] Purpose of sequence numbers
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ipsec] Purpose of sequence numbers



Ulrich Weber wrote:
But I don't get the meaning of sequence numbers in IPSec at all. What are
their purpose ?

Most of the encrypted traffic is tcp, which has its own sequence number and
is invulnerable against Ipsec replay attacks.

TCP sequence numbers wrap (quiet quickly on high speed links). By replaying the same packet over and over again, an attacker will likely hit the TCP window on the next sequence number wrap, corrupting the stream which is supposed to be secure.


Secound biggest amount of traffic is udp. Ok its vulnerable against replay
attacks, but what harm could someone do with dns replay attacks, where no
data can be modified within the udp packet ?

Total DOS against the UDP transmission. Replay the same packet over and over again on a secure UDP video/audio channel will completely garble the reception. Again, this channel is supposed to be secure.


So the only possibilty I can think of are DOS attacks to consume as much cpu
power for decrypting ipsec packets as possible.

Yup, another reason for early detection of replays. The processing involved in replay detection is trivial compared to the decryption/authentication processes.


Arent the SPI numbers sufficient enough to prevent third party attackers (who
are not able to sniff the ipsec traffic) from dos attacks ?

A replay attack assumes that the traffic can be sniffed, as bogus packets cannot be arbitrarly created by an attacker without the hash keys.


Cheers,

Michael

--
Michael Bowler                                mbowler at ellipticsemi.com
IC Design Engineer                                  (613) 254-5456x107
Elliptic Semiconductor                            www.ellipticsemi.com


_______________________________________________ Ipsec mailing list Ipsec at ietf.org https://www1.ietf.org/mailman/listinfo/ipsec




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.