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

Re: ipsec error protocol

"Scott G. Kelly" wrote:
> 
> Hi Frederic,
> 
> Frédéric Detienne wrote:
> >
> > 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.
> 
> But the crashed host is precisely what you are trying to detect, and in
> this case, you will need to set up at least one new ike SA anyway, so
> this is not persuasive.

I agree. I just say that this does not bring anything really "new".

> 
> > 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.
> 
> <stuff trimmed...>
> 
> Use of an explicit phase 2 SA for this has been suggested by at least 2
> other wg participants, if I remember correctly. What are the benefits vs
> drawbacks of this
> when compared to an ike-based solution?
> 
> Benefits:
> o allows you to eliminate the ike/stack interaction required of an
> ike-based mechanism
> o phase 2 control messages could be authenticated without changing ike
> 
> Drawbacks:
> o overhead for maintaining additional SA state
> o may require definition of additional SA characteristic in DOI (ike vs
> control), although not strictly necessary
> 

Allow me to bring the conversation on an other ground:


Types of black holes
====================

There are two "types" of black holes in IPSec:

1) you send things to a peer that is dead in an IP prospective

2) you send things to a peer that is dead in an IPSec prospective


It is not the role of IPsec to detect (1) and here is why:
. In the case of IPSec as a tunneling protocol, there are solution to this problem: routing protocols. (there are other solutions but less generic).
. In the case of a peer to peer protocol, it does not matter for IP&IPSec since the other side is dead anyway. It is up to the upper layer protocols to recover.


Now, when the dead peer comes back to live, it causes issues (missing SA's on one side). There are several ways to detect (2):
a) acknowledgements
b) polling
c) invalid SPI notifications

I know that incidently, (a) and (b) solve (1) but this is not the main purpose.

(b) is a poor solution that
. consumes bandwidth (esp. in IPsec concentration)
. keeps dialup lines up for nothing (except with some nice tricks)
. converges slowly

(a) and (c) are much better.


(a) is easy to implement without chaning IPSec nor IKE (I have a solution that needs a separate RFC but it would be good for any tunneling protocol, including IPSec) but relies on timeout => slow

(c) certainly requires some changes to the current RFC. I think of at least one fair solution with a new ISAKMP payload.

If you go for acknowledgements (point (a)), you can transport it in anything:
. an IPSec packet with a dedicated SA
. an IKE payload.
. an IPsec packet using the other SA of the SA pair to respond (what I would recommend as it can be implemented without changing the current RFC's).

And this is were I wanted to go:

I do not criticize Sankar's proposal. I just mean it does not add anything new: discussing the way to transport notifications, acknowledgements or echo (requests and replies) does not bring anything as we can chose. Sorry about that, period.

Now, we can go a step further

Solutions proposals
===================

1) Acknowledgments
++++++++++++++++++

Acknowledgments can be sent by the receiving end regularly (based on a number of bytes or packets received). If a certain time has elapsed without the other side receiving the acknowledgement, the corresponding SA's should be torn down.

How to send those acknowledgements. There are two obvious solutions.

a) by changing IPSec
--------------------

When a number of bytes/packets have been decrypted on an inbound IPSec SA, send a packet using the outbound IPSec SA. Use piggy backing when possible but send and empty payload if necessary.

Only works if the SA contains some sort of authentication (AH or ESP w/ auth).

b) without changing IPSec
-------------------------

define a new generic IP payload of type "acknowledgement" that would have a header like

ack header ::= next protocol | size | <generic acknowledgment> 

<generic acknowldegment> would be defined for different types of protocol and in particular AH and ESP. It could contain the SPI number and the last received ID.

The "next payload" would allow the header to carry an other IP packet or payload allowing the acknowledgement to be piggy backed without touching IPSec.


Drawbacks of (a) and (b): you rely on timers, this converges slowly but anyway polling too.

2) Notifications
++++++++++++++++

There are again two cases.

a) the SA was mistakenly deleted and B still has a phase 1 SA (by chance, this *can* happen)
-------------------------------------------------------------

B simply sends an AUTHENTICATED delete notification  (under the cover of the phase 1) to A and a phase 2 can restart if necessary.


b) B really respawned and does not have a phase 1 SA (more frequent)
----------------------------------------------------

By adding a new payload of saying "in order to delete SA with SPI xxx" in the initial offer.

Say peer A and peer B have a pair of SA's. B reboots and loses its SA's. A keeps sending traffic, B has nothing to send and receives IPSec packets with unknown SPI's from A.

B could then say

IP(B->A) UDP (500,500) CKi,0 | SA proposal | "in order to delete SA with SPI xxx"

If A does NOT have SPI number xxx, it simply ignores the request. Otherwise, it responds and copies the "in order to delete SA with SPI xxx" payload.

IP(A->B) UDP (500,500) CKi,CKr | SA chosen | "in order to delete SA with SPI xxx"

and the exchange continues normally. So we have the same level of protection as with the usual Cookies. Just an extra payload and no extra crypto.

At the end of phase 1, B can now send an AUTHENTICATED delete notification to A.


Am I missing something ?

regards,

	fred


> I'm sure there are other entries in each list - I invite others to add
> to these lists.
> 
> Scott
References: