[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay mandatory?
> I wonder if I am missing something.
I think the only thing you're missing is that you CAN have no replay
protection on your SA(s). (There is no window size when you have no replay.)
I see people saying, "If you use replay, the minimum window size MUST be 32
packets." And let's look at your concerns.
> Today, in an IPsec-less environment, if I get IP packets for 1000 different
> TCP circuits, I have to have some pool of local copies of packets to deal
> with out-of-order IP packets.
Basically, each TCP connection has state which will queue up the packets that
arrive out of order, rather than deliver them to the appropriate application.
If a segment arrives out-of-order, it gets queued at the TCP control block
(or whatever you call yours), and that memory is held until such time as the
data is delivered and consumed.
> If I implement IPsec, with NO replay, things are the same. I decrypt, I
> send it to the next step in the process, and presumably the same pool could
> be used.
If the same memory block (mbuf, mblk, whatever you use) ISN'T being used
after you've decrypted (OR AUTHENTICATED, DON'T FORGET AH, FOLKS), I question
your design. :)
You're right, you just deliver as before w/o replay.
> If I require a replay window of 32 for 1000 different Security
> Associations, that means I need to keep 32*1000 copies of IP packets
> around.
Not necessarily. It's POSSIBLE that you'll have 31*1000 copies of IP packets
queued up, assuming a Byzantine failure. Besides, at some point in time, you
just assume that packet <foo> didn't arrive, drop it, then deliver the
<foo+1>.. etc packets. Delivery will free up the resources.
Keep in mind that with larger replay windows, system resources CAN be
consumed at a faster rate. It doesn't, however, mean that they WILL be
consumed at a faster rate.
> I can't spread the pool cost among the 1000 like I could in the non-IPsec
> case.
I understand that you're concerned about system resources. It sounds like,
in your system, you allocate a fixed number of buffers allocated to network
traffic. Yes, a large replay window will perhaps exhaust your finite supply
of buffers quicker than no replay.
If packets are behaving themselves and arrive mostly in-order, even with a
replay window of 256, you won't be burning your buffers very quickly. I
suspect that's the common case.
Finally, if I understand, if you're that concerned about system resources,
you can have a policy of no-replay-protection in your KMd.
Dan
References: