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

RE: ipsec error protocol

Hi,

To clarify, I am not assuming there is a phase2 SA avialable for the
reserved SPI.
I am suggesting we use the reserved SPI as a way to specify error packets
for ipsec.
The reserved SPI is an identifier to say the payload inside is an ipsec
error packet.
The payload may be an error packet of type 'encrypted ping' for any specific
phase2 SA
that the peer wants to check the health of.

The format I was proposing was

    ip header
    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
an encrypted
ping on a specific phase2 SA the peer is interested in. If the receiving
ipsec implementation
has the SA and is able to decrypt the encrypted ping-request, it can send a
encrypted-reply
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 --


-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Frédéric Detienne
Sent: Wednesday, January 17, 2001 3:14 AM
To: sankar ramamoorthi
Cc: ipsec@lists.tislabs.com
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.

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 --
References: