[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2401bis Issue # DD -- Anti-replay notification
Angelos D. Keromytis writes:
> Karen, since IKE-negotiated SAs (in fact, any non-manual SA) are supposed to
> have anti-replay protection on, my sense is that the original REPLAY-STATUS
> message was unnecessary to begin with. Do you foresee the case of an
> IKEv2-established SA that would not use anti-replay protection ?
Only reason for those are are high-availability and load-balancing
systems, where it is quite hard to maintain the replay window
consistency between multiple machines. In those systems two or more
machines share the same SAs (both IKE and IPsec SAs).
In the high-availability cases, the machines are already most likely
snooping each others traffic, thus they can update the incoming replay
window etc (both/all machines must be powerfull enough to handle all
traffic, thus both of them can process all data, including decrypting,
checking for replay, maintaining replay-window etc for all packets).
For sending the high-availability system can be configured so that
only the master host is doing the actual sending, the other only
snoops those packets and updates its state accordingly, or if both
hosts are sending, it can be configured so that host 1 uses odd
numbers, and host 2 uses even numbers, and both snoop the packets sent
by each other to make sure that the sequence numbers stay in sync (i.e
they take last snooped outgoing packet and increment their own
sequence number by 2 until it is larger than the last one the other
host sent out).
So in high-availability cases it is possible to get the anti-replay
protection working. The load-balancing case is different.
In the load-balancing case one machine cannot handle all the traffic,
thus it cannot update its replay-window or sequence number for the
packets going to other hosts. Also the hosts cannot communicate that
information per packet basis. There are tricks you can do, like
instead of sharing all SAs, they only share IKE SAs, but not IPsec
SAs. Each load-balancing host generates their own IPsec SA to each
clients using the one shared IKE SA they have with the other end. Each
of those SAs are going to have identical IP numbers etc, thus for the
other end it looks like the load-balancing server simply created one
IKE SA and multiple identical IPsec SAs. Now each server can send data
to other end, and they select who needs to decrypt the packet based on
the SPI numbers (the SPI database is common for all of them, i.e odd
numbers go to host 1, even to host 2 etc).
If one of hosts fail the others can send the IKE SA delete for the
IPsec SAs it had. The problem is that the host on the other end see
only n identical SAs, and it is up to it how it uses them. It might
simply only use one of them and ignore the others, thus sending all
traffic to only one of the hosts, or it might send packets out based
on the ToS bits to different SAs etc.
Good thing is that in most cases single host is capable of handing all
of the traffic coming from one client, thus the load-balancing server
can balance the number of clients to each host. I.e only one host
creates IPsec SA and talks to client etc. They can then see the load
of each machine, and move IPsec SAs around as needed (another host
creates new IPsec SA, and the old host deletes it).
So now the question is really do we need load-balancing servers where
one server in the pool cannot handle traffic sent by the other ends
single host, and in that case we would need to disable anti-replay?
With current hardware technology, I would say that we do not need
support for disabling the anti-replay. We can manage the
load-balancing and high-availability cases with current protocol, and
in most cases we actually might want to keep the anti-replay even when
using those systems.
> -Angelos
>
> In message <p05200f50bb9ecb6ebc18@[128.89.89.115]>, Karen Seo writes:
> >Folks,
> >
> >At present, RFC2407 ("The Internet IP Security Domain of
> >Interpretation for ISAKMP") defines a REPLAY-STATUS notify message
> >that IKEv1 can use to tell a peer whether or not it has anti-replay
> >enabled for a particular SA. (It's chained onto a Quick Mode message
> >a la RESPONDER-LIFETIME.) The default is to assume anti-replay is
> >enabled. But this capability is not in IKEv2.
> >
> >We'd like to propose that IKEv2 also allow the receiver to notify the
> >sender whether or not anti-replay is enabled. In the case where
> >anti-replay isn't being supported by the receiver, this would allow
> >the sender to avoid setting up a new SA when the replay counter rolls
> >over.
If you do not want to set up new SA so often, use extended sequence
numbers, i.e do not disable it (it is on by default for IPsec SAs
created using IKEv2).
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/