> On Dec 16, 2014, at 11:45 AM, Ashok Kumar <[email protected]> wrote:
>
> Hi Paul,
>
> I agree that it helps to avoid delivering duplicate packets to the end system.
> But I am not convinced about the following statement.
>
> > The purpose is to avoid delivering duplicate packets to the end system,
> > where (depending
> > on the protocol) they might cause applications to malfunction.
>
> The IPsec is transparent to end system. So IIUC, end-to-end system/application
> shouldn't assume that it will never receive duplicate packets. So regardless
> of
> whether IPsec is used/deployed or not, it is end system/application
> responsibility
> to handle any duplicate packets. Isn't it?
Conventional protocol design concentrates on handling events that occur
normally in a network. For example, accidental data corruption occurs on
physical links due to noise and the like. Packet reordering occurs due to how
routing works. Packet duplication may also occur normally on occasion. In all
these, the design focuses on non-malicious events: random or otherwise
intermittent events but not events constructed by an adversary intent on
breaking things.
By contrast, security protocols such as IPSec specifically aim to handle events
created by a malicious adversary. Consider the data corruption case: CRC works
very well for random bit errors, which is why data link layers (such as
Ethernet) use it widely. CRC and checksums work well for some other classes of
accidental data errors, which is why SCTP and iSCSI uses CRC, and TCP uses a
simpler checksum.
None of those are any help at all against deliberate attacks. It is utterly
trivial to modify packets in a way that leaves the checksum or CRC unchanged
(or, for that matter, to adjust the checksum so it still looks correct). So
IPSec does not do it that way; instead, it uses a keyed secure hash, which does
have the property that it resists deliberate malicious modification.
So too with duplicate packets. TCP, for example, deals with duplicate packets,
within limits, and assuming that there isn’t an active attacker modifying the
packet stream. But the TCP mechanisms are not designed for and do not handle a
deliberate attack by a skillful attacker. On the other hand, the IPSec replay
prevention mechanism does address such attacks.
So while it may seem that IPSec does a bunch of things that other protocols
already do, or should already do, this is generally not the case; the key
difference is “accidental” vs. “deliberate” in each of these areas.
paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
