[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
References: