[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Heartbeats Straw Poll (part 2)
Part 2: alternate proposals
> SGW2 could do a Main Mode under any Phase 1 policy that he
> has to SGW3 and in
> the process, tell him INITIAL-CONTACT. No subsequent QM's
> would happen until
> the next packet hits SGW3. You would want to rate limit this
> to prevent the
> obvious DoS attack on the receiving side. Our product
> implements this and it
> works well. (Of course, our clustered gateways have
> replicated IKE state, so
> this is a non-problem for most of our customers.)
Well, yes we do this too, and we also have clustering capabilities, but I
don't think this is necessarily the correct solution. The rate limiting
approach has too many loopholes, and I don't think it would stand up against
a concerted attack.
I also think it is better if the side which has the state initiates the
As for clustering, maybe that is the correct business case. Normally,
clustering only prevents service interruptions during a reboot, but I
suppose it could also prevent synchronization problems from happening.
It still bugs me to not have self-stablization properties in a protocol
which allows many divergent implementations and which does not make an
effort to avoid synchronization problems.
Maybe if we went back and required continuous channel mode, re-introduced
acknowledged notifies, and mandated the use of redundant clusters, then we
could get away with a protocol that isn't self-stabilizing.
As a note about clusters, I do believe there are some customers who have the
requirement that a sgw must never divulge a key, not even to another cluster
member. (That was one of the motivations for Vlado's draft, BTW.)
> I know of two different implementations that have an
> interoperable "IKE-level
> ping"-- one side sends a "LIKE_HELLO" (private notify value
> 30000) the other
> sends back "SHUT_UP" (private notify value 30002). It's very useful.
Ah yes, the famous code segment:
// results of richardson
NOTIFY_LIKE_HELLO = 30001,
which has been in our code for years but no one ever knew what it meant (not
even Roy, who wrote it). Legend has it this was developed in a bar amongst
much drunken hilarity?!? BTW, it seems that our magic numbers are wrong,
which is strange...
> If you're really that worried about the resources for "dead" SAs,
> negotiate relatively short rekey times, at which point if your peer
> disappears, the SA will timeout in a relatively short time.
In which case the QM negotiation is effectively acting as a heartbeat. A
REALLY EXPENSIVE heartbeat!
> If we have the system sign a "birth certificate" when it reboots
> (including a reboot time or boot sequence number), we could include
> that with a "bad spi" ICMP error and in the negotiation of the IKE SA.
That is not a bad idea at all. Again, it only solves one problem -- the
rebooting problem -- but it solves it well. This could be be used in
conjunction with other techniques as part of a comprehensive solution.
> If you really need to know if an SA is dead, use a layered solution.
> The IPsec endpoint can periodically send a protected ICMP ECHO to the
> far end. If it is acknowledged, all is well. More generally, *any*
> traffic received can reset the timer. If m pings in a row are lost,
> throw away the SA and let any new traffic from your side create a new
> one. The far side can run the same protocol; if your side
> discards its
> half of the SA, the far side won't receive any response to its pings,
> so it will tear down its side as well.
This is just a different heartbeat mechanism which uses phase 2 instead of
phase 1. The reason we didn't go this way is that there is no standardized
mechanism for sending management traffic across a phase 2 SA.
If there was such a standard (e.g. all traffic between the public IPs of the
gateways is managment traffic; the normal filtering rules do not apply; icmp
echo replies MUST be enabled; byte counts for accounting should not be
updated; idle timeouts should not be circumvented, etc.) then we probably
would have come out with an IPsec heartbeat draft instead of an Isakmp one.
But as you can see, the very mention of adding special rules to IPsec SAs
invokes the ire of many people in this WG, which is why we decided to take
what we thought was the easier approach.
> > I would hope the original is destroyed. This really shouldn't be
> > any different than a new phase 1/2 SA negotiation sequence with a
> > peer which didn't receive the SA delete messages.
> Well, certainly you should send using the newest SA which matches your
> policy. with respect to reception, at a minimum, I would hope that
> there's a grace period there around rekey time to accept packets sent
> to the old SA which were delayed in transit.
> I don't see the harm in letting the SA's live until they expire unless
> a DELETE or INITIAL-CONTACT or other affirmative indication that
> they're gone on the other end comes in..
The harm is that you are now consuming memory for an SA that is not being
used. While this may not seem like a huge problem (memory is cheap,
yadayadayada), it is a problem if an adversary can coax you into negotiating
multiple redundant SAs.
> From my experience, a number of commercial firewalls with
> IPsec support make
> that assumption implicitly (that an SA negotiated for traffic
> between two
> nets can also be used for traffic between the two gateways).
Maybe that should be allowed, but if so then it should be documented. I
don't think this is implicitly allowed by the spec; IMHO you shouldn't do
anything controversial like this without enabling it via negotiation.
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.