[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ipsec error protocol
To clarify, I am not assuming there is a phase2 SA avialable for the
I am suggesting we use the reserved SPI as a way to specify error packets
The reserved SPI is an identifier to say the payload inside is an ipsec
The payload may be an error packet of type 'encrypted ping' for any specific
that the peer wants to check the health of.
The format I was proposing was
ESP with reserved SPI
Header for ipsec error (different type of errors/controls can also be
adefined a.k.a icmp)
IPSec error/control payload (can be another ESP header containing the
encrypted ping payload
for a specific SPI that the peer is interested in)
As you can see, the reserverd SPI is only used to tunnel the actual
error/control packet we
are interested in. Using the reserved SPI clearly can allow an ipsec
implementation to identify
the payload as a control packet for ipsec purposes.
There can be no phase2 SA with reserved SPI, since it cannot be negotiated
as per the spec.
Hence if an ike implementation receives a ESP payload with reserved SPI, it
can be safely
treated as carrying a ipsec control packet in the clear.
Different type of ipsec control packets can be defined one of which can be
ping on a specific phase2 SA the peer is interested in. If the receiving
has the SA and is able to decrypt the encrypted ping-request, it can send a
tunneled in ESP payload with the reserved SPI.
Currently as defined ipsec is a network layer encapsulation method without
clear path for
error/control packets. This proposal tries to address it.
-- sankar --
[mailto:firstname.lastname@example.org]On Behalf Of Frédéric Detienne
Sent: Wednesday, January 17, 2001 3:14 AM
To: sankar ramamoorthi
Subject: 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.
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
> 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
> This in conjunction with a suitable icmp error from the peer, would allow
> 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.
> -- sankar ramamoothi --