[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipsec error protocol
sankar ramamoorthi wrote:
> >After a config reset, some sort of config reload is generally
> >required; that can include resetting system time to a known correct
> >value.
>
> What if the previous time was wrong for some reasons?
Then quit trusting all form of certificate because they are time stamped.
> >
> >> What if the private key that is used to sign the sequence number is
> >> lost?
> >
> >The intent is that the key used to sign the birth cert is the same as
> >the key used to authenticate the IKE exchange.
> >
> >If you lose that, you need to generate a new one and have certificates
> >reissued, etc.,
>
> Which means during the intervals when certs are reissued and propagated,
> the 'invalid spi' notification cannot be sent out because the private
> key with with it has to be signed is lost.
Fixed by the combined method. You sign the last IKE packets, period.
And btw, you do not change certs very often... and in the cert of birth method alone, you could also include the CA cert. This is riduculous.
> As I try to understand the scheme better I see a number of problems
>
> . operational problems (as described above - there could be more)
> They probably could be worked around but it seems to me the solution
> is now extending from ipsec to ike to device configuration and
> management.
The combined method fixes this.
> . lack of a time-variant(replay sequence as in ESP or AH) allows
> one conjure some scenarios where replay attacks are possible
The combined method does that too: IKE is replay protected.
And btw, your method has the same problem: the seq # in ESP goes in the clear and it is protected only if authentication is available on the SPI you are probing.
> . extra overhead of authenticating notifications during DOS attack.
The combined method would stop before doing any crypto computation (cookie protection).
And btw, your probe has to be protected and the reply has to be protected too...
> Considering all this I feel an error control protocol in ipsec is
> preferable as a mechanism towards ipsec-state synchronization problem.
I do not see the relationship.
> The protocol is limited to ipsec, does not try to impose a solution
> to state synchronization but provides a building block. Conforming
> implementations just need to support simple ipsec error processing
> and no other changes are required.
>
> There are a lot of similarities to proposed ipsec error control
> mechnism and icmp. icmp is an ip error control protocol and uses
> a reserved protocol number from the transport-layer protcol space.
> The proposed ipsec error control mechanism uses a spi from the
> reserved spi space. Like icmp, ipsec error control can be used
> to provide a number of error/control functionality.
You certainly mean there are parallels between ICMP-type/code and the SPI number... not the protocol type of ICMP and the SPI number. ICMP is multipurpose your SPI would be single purpose (like the type/code in ICMP).
Whatever.
I agree that looks nice but does that bring anything ? The group could also have built IKE on top of ICMP. Since IPSec is somehow part of IP(v6), that would have made sense... I do not feel that IKE is such misplaced, though. But I will leave you that as I am not interested in a philosophical debate.
In any case, this does not make your recovery mechanism efficient (even when NOT under DoS): 1 notification, several*[probe + timeout] before starting phase 2, timing out, then phase 1... keepalives in disguise.
Finally, if you do not like IKE, you certainly do not like my method (which is NOT Cert of Birth only) but I have not introduced anything new in IKE (in terms of hazard).
On your side, you still have not explained the shape of your probe packets and the way you protect them (key usage and generation). Can you proceed ?
Regards,
frederic detienne
Follow-Ups:
References: