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

RE: ipsec error protocol



>From: goofy@cisco.com on behalf of Frederic Detienne [fd@cisco.com]
>Sent: Tuesday, January 30, 2001 2:21 PM
>To: sankar ramamoorthi
>Cc: sommerfeld@East.Sun.COM; skelly@redcreek.com;
>ipsec@lists.tislabs.com
>Subject: Re: ipsec error protocol
>
>sankar ramamoorthi wrote:
>> >notice that you made a lot of progress. Your "slight changes" actually
>> shift the original paradigm from a "keepaplive in disguise" into
>> "acknowledgement in disguise".
>>
>> No, it is more like 'acknowledgements-when-needed'
>
>turn it the way you want. They are acks.
>
>> >Take my first emails and re-read: acknowledgments are better.
>> >
>> acknowledgements only when needed is still better :-)
>
>no, it is slower.
>
>>
>> >Your problem is that you really want to trigger this with an "invalid
SPI"
>> message. And you come up with pretty fancy packets. Not that I do not
like
>> them (they're a valid vector after all) but now your philosophically
correct
>> pseudo-ICMP's tunnel data :)
>>
>> Yes, but not all error/packets though, only the 'receipt-needed' type of
>> control packet.
>
>Not all pink rabits have green sunglasses...
>
>[stuff trimmed]
>
>>
>> As for as I understand the scheme, you have
>>
>
>I corrected your sketch. There is no notification message.
>

Thanks for pointing it out. I missed this part.

>
>    peer wih out-of-sync/no ipsecSA                    peer sending data
>
>                                 step1
>                               send ESP data
>                         <-----------------------
>
>     no ipsec or ike state with
>     peer. send notification in
>     IKE offer.
>
>                                 step2
>                         initiate directed-ike phase1
>                         or phase2 exchange
>                         (ike for a particular reason)
>                         sa proposal + 'because I do
>                                        not have SA xxx and you do'
>                         --------------------------->
>
>                                            if reason is satifactory
>                                            respond to IKE exchange
>                                            from peer
>                                 step4
>                         <---------------------------
>                         responder proposal (2nd
>                         message of ike exchange
>                         sa proposal + 'because you did
>                                        not have SA xxx'
>
>                          ... (IKE continues and terminates with a CoB).
>
>> Seems to be a neat way to avoid passive attacks. However the
>> initial IKE message is not authenticated and it now carries
>> additional information.
>
>The first four Main Mode IKE packet are NEVER authenticated anyway. So what
? They contain keying material and your policies... who cares ?
>
>Think of it: there are active attacks against IKE but they are very
specific and take you nowhere or people live with that (been debated). I do
not introduce (I think) any [new] weakness in IKE. Period.
>

On the face of it it looks fine, you will need rate limiting though
- otherwise one can end up with a lot of ike timers under DOS conditions.

A question.

How will directed exchange work in ipsra scenario?

Assume the remote access server has lost state about a remote-client.
On receiving the ESP packet, the server has to start a directed ike
exchange, which means it has to have a SPD policy entry for the
remote client.

In some of the remote access implmentations, it is always the remote
client which is the initiator  - ie: a dynamic SPD policy is created for
the remote client once it is authenticated (not through IKE but through some
legacy auth mechanism). The dynamic SPD policy is deleted once the SA is
deleted.
So the server may not even know the right SPD policy for the client to
start the directed IKE negotiation.


>>
>> With the ipsec error protocol, speed of recovery is left to the
>> implementation.
>
>Mmmh... heard of round trip time ? High speed high latency ?
>
>Take the time you want but think you can lose quite a few packets
inbetween.
>
>It could be your broker, your VoIP call to the police, your remote
surgeon...
>
>
>> If one side needs a very fast recovery, a keep-alive
>> equivalent protocol can be implemented using the messages provided
>> in ipsec error protocol.
>
>NO. Once and for all: keepalives are Bad. Evil. Broken.
>
>You shifted your own scheme from keepalives to acknowledgements...
>

Agreed - The arguments seem to be similiar to what people had for
TCP_KEEPALIVE.

Just one comment about the acknowledgements in ipsec error protocol.
The ipsec error protocol does not use acknowledgemnts in the usual sense.
It uses 'recipt' packet to indicate that some valid ESP packet was received
on the inbound-SA. It is not an acknowledgemnt to a particular packet.
It is more of an acknowledment to say that the channel is alive.
Hence reordering is not an issue.

-- sankar --





References: