At 11:05 PM +0200 2/11/11, Yaron Sheffer wrote:
Hi Steve,
[Cross-posted to ipsecme]
I have always wondered about these sequence numbers, and the concept
of anti-replay in IPsec.
- IPsec is architecturally a "plug-in replacement" for IP. And IP
allows for arbitrary packet deletion, duplication and reordering.
- Anti-replay counters are giving us no end of trouble in clustered
environments (e.g.
http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ipsecha-protocol/).
- IPsec (unfortunately) does not have an application API, at least
in most implementations. Such an API might indeed have put this
feature to good use.
- And lastly, IPsec anti-replay is optional, which signifies to me
that it's always been an iffy feature.
I have looked at RFC 4301 again (the IPsec architecture), and it
provides only weak justification for this feature. Can you please
point me to a more convincing reasoning?
Thanks,
Yaron
Can any Steve reply?
While IP allows arbitrary packet arrival, IPsec allows a receiver to limit
the extent of such OOO arrival, to enable it to detect and reject
replay attacks. That is the rationale for AR and it is just as
applicable in a clustered receiver context as in a single receiver
context.
The fact that it is optional to use (not to implement) is NOT an
indication that it is "iffy." It is an indication that not all apps
might require its use, and some might find it in conflict with the
app. That is a app-specific decision, not a decision to be made by an
IPsec vendor. Use of this feature is declared via the SAD, so an
administrative interface is one way to specify use of this feature
based on the protocol and port #'s.
I'm sorry that AR is causing problems in clustered contexts, but that is not a
justification to not support it.
Steve
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
