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

Re: ipsec error protocol

In this case, you assume there is a phase 2 SA available and identified by a reserved SPI. What if the host crashed ? It does not have a phase 2, and would have to negotiate a new one, possibly involing a phase 1, thus opening the door to clogging.

This is just an other way to transport a delete notification or a keepalive but has the same drawbacks as the solutions proposed so far.

ISAKMP already proposes such a mechanism (notification payloads -- except keepalives) but as they are unauthenticated, they can not be trusted.

regards,

	frederic detienne

sankar ramamoorthi wrote:
> 
> There has been a lot of discussion in the past about state-synchronization
> issues in ipsec, packets vanishing into blackhole because of ipsec peers
> getting out-of-step, potential DOS problems in suggested solutions,
> need for secure in-band error communication etc.
> 
> As for as I know, there was no clear resolution on this issue and it
> still remains unsolved. The closest working solution was using keep-alives,
> which many (including me) opposed as too heavyweight to solve a basic
> protocol problem.
> 
> Using inband-pings would be nice way to check if the peer's state is in
> sync.
> This in conjunction with a suitable icmp error from the peer, would allow
> one
> to detect quickly if the ipsec SA state is in sync between both the
> communicating parties.
> 
> One of the opposition to using inband-ping was that it was difficult to
> distinguish from customer traffic.
> 
> Here is a suggestion for adding control messages to ipsec
> 
> spi values 1-255 are reserved by IANA for future use. I was wondering
> if a reserved spi, could be used for ipsec control communication.
> This could allow control messages including secure echo-replies to be
> implemented. The control messages of the form
> 
>   ip packet
>   esp header with special spi indicating payload is ipsec-control
>   ipsec control payload (yet to be defined)
> 
> The receiving entity MUST handle the control packets when it receives
> a ah/esp packet with the special spi value. The control message can be
> of the type encrypted echo/echo-reply for a specific tunnel, authenticated
> or encrypted error notification etc.
> 
> Welcome your feedback on this idea.
> 
> Thanks,
> 
> -- sankar ramamoothi --
Follow-Ups: References: