[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime)
>From: Paul Koning [pkoning@xedia.com]
>Sent: Thursday, January 20, 2000 6:44 AM
>To: Sankar@vpnet.com
>Cc: akrywaniuk@TimeStep.com; ipsec@lists.tislabs.com
>Subject: RE: Notify Invalid Spi/Cookie (was RE: Phase 1 KB lifetime)
>
>>>>>> "Sankar" == Sankar Ramamoorthi <Sankar@vpnet.com> writes:
>
> >> ...
> >> On the other hand, the issue was that a half-open connection (SAs
> >> on one side but not the other) is not self-correcting. You CANNOT
> >> use unauthenticated notifies to fix that for the reasons you
> >> mentioned. Since you cannot, it makes sense for the spec to say
> >> that generating such a notify is optional and you're also allowed
> >> to take no (protocol) action at all for invalid SPI packets.
>
> Sankar> In addressing the half-open connection state you seem to only
> Sankar> consider two possiblities, a clear notify or a notify sent
> Sankar> using an existing SA. Is it possible to send an authenticated
> Sankar> notify without an existing SA? If one such message is
> Sankar> possible, it can get the parties involved out of the half
> Sankar> open state (the cost to create such a message could be
> Sankar> cheaper than getting an SA created and one can always rate
> Sankar> control the creation of such messages to minimize DOS
> Sankar> attack).
>
>I can see a total of 4 approaches:
>1. unauthenticated notify
>2. notify authenticated using an existing phase 1 SA
>3. notify authenticated using a newly created phase 1 SA
>4. notify authenticated by a different mechanism not involving a phase
> 1 SA
>
>As far as I can see, (4) means a public key signature or equivalent.
>The cost of such a beast is on the same order as that of (3), i.e.,
>*much* greater than (2) which is already too expensive for comfort.
>
>Yes, I suppose any of these things can be protected by rate limiting,
>and one would be wise to do that for notifies of any kind (including
>those that use an existing SA). Minimally that takes a timer, but it
>may also involve a hash table of recently-notified addresses. All
>that adds up, which is a good reason for the present rule.
>
> paul
I don't fully agree with the rationale of the present rule.
With the present rule, one end of the communication could endup
sending packets into a blackhole and there is no way to notice
it till the sender's SA expires - which forces me to implement
keepalive (works only in intranet scenarios) solution to detect
the problem. I would have rather preferred a solution mandated
by the protocol and find ways to optmize the performance cost
in the implementation.
-- sankar --
Follow-Ups: