RE: Peer liveliness

[Charlie_Kaufman@notesdev.ibm.com]

> Charlie, I can't remember, is the sending of
INITIAL-CONTACT a MUST in the
> latest IKEv2 draft? Would it be a good idea to make INITIAL-CONTACT
> notification a MUST, if it is not already? Doing so would help shorten
the
> tunnel black hole in most cases, regardless of dpd settings.
> 
The current spec acknowledges in section 1.1 that there are different
usage scenarios for IKE, but does not in later sections
specify
MUSTs and SHOULDs according to usage scenario. You
make a good argument
for INITIAL-CONTACT in the gateway to gateway tunnel
scenario, where after
a gateway reboots you want to other end to start sending
packets to
the new gateway asap (hopefully before the TCP connections
time out for
the nodes behind the gateways). But it makes little
or no sense when
a mobile node is connecting to a corporate gateway.
If the mobile node
crashed, all of its existing connections crashed with
it, so there is
likely nothing to gain by trying to rapidly get packets
to those dead
connections running. And if the corporate gateway
crashed, it can't
call back the mobile node anyway. It must wait for
the mobile node to
figure out that something went wrong and restart the
connection.

So the current spec says only that you MAY send the
INITIAL_CONTACT, and
the recipient is also allowed to ignore it.

My view is that this is OK, though a plausible enhancement
would be to
include as an implementer hint that in the gateway
to gateway case use
of INITIAL_CONTACT would be a really good idea and
explain why. Do you
have a concrete proposal?


> The next question is: what is the best behavior
for a (rebooted) peer who
> receives an invalid SPI? Today the mandate is to drop silently. But,
if two
> rules are checked first, it can be fine (i think) to respond. Those
rules
> are:
>   - do I have an active SA with the sender of the invalid SPI?
If yes, drop
> silently. If no, go to next rule check...
>   - do I have the source IP of the sender in my SPD? i.e. is
the sender a
> valid peer? If no, drop silently. If yes...
>   - initiate IKE per SPD definition.

Today the mandate is to either drop silently or to
send a NOTIFY message
of type INVALID_SPI to the source IP address. If there
is an IKE SA to the
source IP address, that message can be sent protected
and interpreted as
definitive by the other end. Otherwise, it is sent
unprotected and at
most can be a hint to the other end that something
is wrong. Because these
messages are easily forged (as are the messages with
invalid SPIs that
cause them to be generated), there is no way to use
them to speed up
failover (i.e. avoiding a timeout) without risking
a denial of service
attack.

        --Charlie