[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ICMP "Destination unreachable" - should it be sent?

On Fri, 29 Sep 2000, Michael Thomas wrote:
>  > The central question is whether the ICMP message is believable...
>  > If it will flow via an insecure path, then what good is it?  The receiver
>  > can't trust it to tell the truth...
> 
>    This strikes me as completely backward: the sender should *always*
>    send it. It is the *receiver's* job to determine whether it is
>    believable.

As already noted, the receiver might not have complete information.
Arguably the sender should not send it if he *knows* it will go via an
insecure path.

However, on further analysis I see an inherent problem -- of a slightly
different flavor -- in trying to be too smart here.  The problem is that,
as I briefly noted, such a message may well be useful as a hint, requiring
confirmation from another source, but prompting the receiver to check with
that source when it otherwise wouldn't think to.  Given this, the sender
should probably send regardless... although he should probably rate-limit
the sending, in case the receiver is ignoring the messages.

In particular, this strikes me as possibly part of a scalable solution for
the problem of one end of an IPsec connection rebooting but not realizing
it should inform the other end.  The still-up end will be sending packets
on IPsec SAs that the rebooted end no longer recognizes, and it is highly
desirable for the rebooted end to have some way of notifying the still-up
end that something is wrong.  (The alternative is heartbeats, which scale
poorly, require arbitrary patience settings, and can't tell the difference
between link failure and loss of memory on the other end.)  Authenticating
this notification is difficult -- the rebooted end may not know enough to
initiate an IKE negotiation -- but treating it as a (rate-limited!) hint
minimizes the problems therefrom.

(Of course, the receiver still needs to have some way of checking the
hint, e.g. an IKE-level ping.  That's the other part of the scalable 
solution.)

>  Having the sender second guess what the receiver 
>    should and should not discard sounds like a great way to cause
>    an interoperability deadlock.

We already have this problem, since it's easy to read RFC 2401's current
wording (section 5.2.1, step 1) as forbidding notification altogether.

                                                          Henry Spencer
                                                       henry@spsystems.net